W3C home > Mailing lists > Public > www-style@w3.org > April 2015

Re: [cssom-view] Easing the transition to spec-compatible body scrollTop behavior

From: Rick Byers <rbyers@chromium.org>
Date: Mon, 13 Apr 2015 15:20:42 -0400
Message-ID: <CAFUtAY8edHHPrhOeyr-WwLwvc8=Ysz_PWzpbRHHzRnfX9CzJrw@mail.gmail.com>
To: Simon Pieters <simonp@opera.com>
Cc: "Robert O'Callahan" <robert@ocallahan.org>, "www-style@w3.org" <www-style@w3.org>
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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:30 UTC