Most excellent. I'm building 1.6 right now and will test this with gwt-dnd, using handlers and the new methods.
On Tue, Mar 10, 2009 at 11:51 AM, Joel Webber 𐑯(ټ)𐑥 <j...@google.com>wrote: > Fred, > I just listed you as a reviewer on this code-review thread: > http://gwt-code-reviews.appspot.com/12802 > > Bruce has been reviewing most of the details, but would you mind having a > look to see if these APIs are sufficient to deal with the problems you've > run into in Drag&Drop and GlassPanel? > > Many thanks, > joel. > > On Tue, Mar 10, 2009 at 12:25 PM, Fred Sauer <fre...@google.com> wrote: > >> Joel, >> I like the new proposed methods and I have no issues with the proposed >> enable*Scrolling() methods. >> >> I've never had a need for both document.documentElement and document.body >> at the same time. In fact whenever I've needed one, I *generally* need the >> other when the rendering mode is toggled. That's hardly ever a complete >> picture though. Here are the three ingredients I've found myself needing: >> >> - Need to access document.documentElement or document.body, depending >> on rendering mode >> - Other things also depend on rendering mode so accessing >> $doc.compatMode is still necessary, which also has subtle issues, see >> http://code.google.com/p/google-web-toolkit/issues/detail?id=1981 >> - Cross browser differences as you point out; as part of this also >> older flavors of our supported browsers behaving slightly differently >> >> >> I was just looking at some of the crazy stuff I had to put in GlassPanel. >> Below are a few use cases that pretty much cover my needs. You'll find a >> number of TODOs and weird hacks: >> >> http://google-web-toolkit-incubator.googlecode.com/svn/trunk/src/com/google/gwt/widgetideas/client/impl/GlassPanelImplMozilla.java >> >> http://google-web-toolkit-incubator.googlecode.com/svn/trunk/src/com/google/gwt/widgetideas/client/impl/GlassPanelImpl.java >> >> http://google-web-toolkit-incubator.googlecode.com/svn/trunk/src/com/google/gwt/widgetideas/client/impl/GlassPanelImplIE6.java >> >> http://google-web-toolkit-incubator.googlecode.com/svn/trunk/src/com/google/gwt/widgetideas/client/impl/GlassPanelImplSafari.java >> >> On a side note, I see that the patch that ultimately went in for issues >> 1400 (http://code.google.com/p/google-web-toolkit/issues/detail?id=1400) >> doesn't actually expose "document root" to Java land, which results in the >> necessity to use the violator pattern in >> http://google-web-toolkit-incubator.googlecode.com/svn/trunk/src/com/google/gwt/widgetideas/client/impl/GlassPanelImpl.java >> >> Thanks >> Fred >> >> >> >> On Tue, Mar 10, 2009 at 8:55 AM, Joel Webber 𐑯(ټ)𐑥 <j...@google.com>wrote: >> >>> I've done a bit more digging, and it looks like "document root" is even >>> less useful than I originally thought. In my research, I missed the fact >>> that all Safari versions report the document's scrollLeft/Top on the <body> >>> element, even in strict mode. So this seems to imply that we *do* need >>> explicit methods on the document for all these operations, because they can >>> be different in subtle ways. So my new proposal is this: >>> Document. >>> get/setScrollLeft/Top() >>> getClientWidth/Height() >>> enableHorizontal/VerticalScrolling() >>> >>> I really don't like the "enable scrolling" method very much, but I can't >>> think of an obvious alternative that doesn't expose a magically-invented >>> "viewport" element that has no standard corollary, and which invites >>> developers to mess with it in ways that will probably just behave oddly. >>> >>> On Tue, Mar 10, 2009 at 10:43 AM, Joel Webber 𐑯(ټ)𐑥 <j...@google.com>wrote: >>> >>>> All, >>>> I'm in the process of cleaning up the code in c.g.g.dom that depends >>>> upon $doc (which it shouldn't, as this code is all intended to work with >>>> multiple documents) and upon DocumentRootImpl (which it *really* shouldn't, >>>> for the same reason). This is forcing me to answer the question "just what >>>> the heck *is* this document root element, anyway?". The best >>>> characterization I can come up with is something like: >>>> >>>> "the element, which is either document.body or >>>> document.documentElement, which you need to >>>> use if you want to work with document scrolling, client size (i.e. the >>>> window's client area), and the >>>> magic 'body offset' on some browsers". >>>> >>>> It's not a standard DOM element or property, but it's definitely needed. >>>> I originally created the method Document.getDocumentRootElement(), but this >>>> just feels kind of wrong. The only alternative approach I can think of >>>> would >>>> be to explicitly define methods such as Document.scrollLeft/Top, >>>> Document.clientLeft/Top/Width/Height, and Document.getBodyOffsetLeft/Top() >>>> (the last of which already exists). However, this still leaves the >>>> element's >>>> CSS properties -- so, for example, if you want to turn off document >>>> scrolling, you have to set the "document root" element's overflow style. To >>>> do this using the same pattern, I would have to add something ugly like >>>> Document.enableScrolling() (like the existing Window.enableScrolling()), or >>>> perhaps Document.getStyle() (the former of which feels really weirdly >>>> special-cased, and the latter of which feels wrong, because the Document >>>> object doesn't technically have a style). >>>> >>>> One other completely simplifying possibility would be to *only* provide >>>> document.getDocumentElement(), and simply redefine it to return the <body> >>>> element in quirks-mode. Does anyone know if the "real" >>>> document.documentElement serves any purpose in quirks mode? If not, I'm >>>> inclined to simply redefine it, which would make all these problems go >>>> away. >>>> >>>> @Fred: I seem to recall discussing some of the ins and outs of this with >>>> you in the past. Any opinions? >>>> >>>> Thanks, >>>> joel. >>>> >>> >>> >> >> >> -- >> Fred Sauer >> Developer Advocate >> Google Inc. 1600 Amphitheatre Parkway >> Mountain View, CA 94043 >> fre...@google.com >> >> > -- Fred Sauer Developer Advocate Google Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 fre...@google.com --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
