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 <[email protected]> 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 𐑯(ټ)𐑥 <[email protected]>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 𐑯(ټ)𐑥 <[email protected]>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 > [email protected] > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
