- From: Rick Byers <rbyers@chromium.org>
- Date: Mon, 13 Apr 2015 15:20:42 -0400
- To: Simon Pieters <simonp@opera.com>
- Cc: "Robert O'Callahan" <robert@ocallahan.org>, "www-style@w3.org" <www-style@w3.org>
- Message-ID: <CAFUtAY8edHHPrhOeyr-WwLwvc8=Ysz_PWzpbRHHzRnfX9CzJrw@mail.gmail.com>
On Fri, Apr 10, 2015 at 12:04 PM, Rick Byers <rbyers@chromium.org> wrote: > > > On Thu, Apr 9, 2015 at 9:01 AM, Simon Pieters <simonp@opera.com> wrote: > >> On Thu, 09 Apr 2015 14:47:30 +0200, Rick Byers <rbyers@chromium.org> >> wrote: >> >> On Thu, Apr 9, 2015 at 7:48 AM, Simon Pieters <simonp@opera.com> wrote: >>> >>> On Thu, 09 Apr 2015 13:14:27 +0200, Robert O'Callahan < >>>> robert@ocallahan.org> wrote: >>>> >>>> In most ways, the root element acts as the viewport element. So I think >>>> >>>>> scrollingElement would make more sense here. >>>>> >>>>> >>>> OK. I'm fine with either name. Anyone else have opinions about the name? >>>> If not I'll change to scrollingElement. >>>> >>>> >>> I prefer scrollingElement as well (could use 'viewportScrollingElement' >>> to >>> be pedantic, but that seems overly long). Thanks! >>> >> >> OK, changed. >> >> https://github.com/w3c/csswg-drafts/commit/9550767396214e0710ef77abe74b27 >> 15cc5cc3f2 > > > Thanks! > > 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). Do you think the spec text for scrollTop/Left/Width/Height could now be >>> simplified by referring to the scrollingElement (rather than repeating >>> the >>> rules for each API)? That's probably how I'll implement it in blink. >>> >> >> Yeah... filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28450 >> >> cheers >> >> -- >> Simon Pieters >> Opera Software >> > >
Received on Monday, 13 April 2015 19:21:31 UTC