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

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

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>
Message-ID: <op.xw1ukqg5idj3kv@simons-mbp>
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  


Simon Pieters
Opera Software
Received on Monday, 13 April 2015 21:14:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:53 UTC