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 -~----------~----~----~----~------~----~------~--~---
