- From: Simon Pieters <simonp@opera.com>
- Date: Mon, 13 Apr 2015 23:13:28 +0200
- To: "Rick Byers" <rbyers@chromium.org>
- Cc: "Robert O'Callahan" <robert@ocallahan.org>, "www-style@w3.org" <www-style@w3.org>
On Mon, 13 Apr 2015 21:20:42 +0200, Rick Byers <rbyers@chromium.org> wrote: >> What do you think the behavior should be for a document in quirks mode >> when the body element has an associated scrolling box? In that case >> there >> is really NO viewport scrolling element (setting body.scrollTop changes >> the >> body element's scroll position, and documentElement.scrollTop is >> defined to >> be always 0). >> >> Your current wording says document.scrollingElement should be 'body' in >> this case, but null feels more logical (and slightly simplifies >> implementation and probably the ultimate spec wording of scrollTop >> etc.). >> However it might be more convenient for libraries that want to assume >> there's some scrollingElement if we returned body in this case. WDYT? >> > > Ping. > > I'm implementing this case as 'null' in blink at the moment (but won't > ship > it until we reach consensus here of course). It really does seem to make > the most sense to me. I believe it allows the spec text (and therefore > implementation) of all the other Element scrolling APIs to be strictly of > the form: "If this == document.scrollingElement then operate on the > viewport else operate on this". Also returning null in this case is the > only way to guarantee that > document.scrollingElement.scrollTop===window.scrollY (either true or > throws). Yeah, it should be null to match scrollTop's behavior. This was an oversight. https://github.com/w3c/csswg-drafts/commit/ad098d66cfc02a4952e8af2eeea742c520d10c2b -- Simon Pieters Opera Software
Received on Monday, 13 April 2015 21:14:00 UTC