I like this new formulation; it's probably a lot safer to denormalize like this.
On Tue, Mar 10, 2009 at 11: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. >> > > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
