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. > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
