This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23603 - should body.scrollTop/Left return an overflown body's scroll offset in both strict and quirks modes?
Summary: should body.scrollTop/Left return an overflown body's scroll offset in both s...
Status: RESOLVED FIXED
Alias: None
Product: CSS
Classification: Unclassified
Component: CSSOM View (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Simon Pieters
QA Contact: public-css-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-23 06:40 UTC by Antonio Gomes
Modified: 2013-10-24 11:13 UTC (History)
1 user (show)

See Also:

Attachments
simple testcase used (339 bytes, text/html)
2013-10-23 09:25 UTC, Antonio Gomes 		Details

Description Antonio Gomes 2013-10-23 06:40:09 UTC 
As of now the spec says [1] 

"
1) If the element does not have any associated CSS layout box or the element is the root element and the Document is in quirks mode return zero and terminate these steps.
2) If the element is the root element return the value of scrollY.
3) If the element is the HTML body element, the Document is in quirks mode, return the value of scrollY.
4) Return the y-coordinate of the scrolling area at the alignment point with the top of the padding edge of the element.
"

According to the above (specifically items 3 and 4), if body itself is scrollable (see for example [2]), body.scrollTop will only return the body's scroll Y offset if in in strict mode (see item 4 above), since in quirks mode it should return the frame scroll Y offset unconditionally instead, regardless of if body itself is scrollable.

Opera 12 (Presto) works like the above.
Mozilla (Gecko), returns body's scroll offset if body itself is scrollable, in both strict and quirks modes.

I would like clarify tat behavior in order to implement things on Blink. I have not tested IE. 

[1] http://dev.w3.org/csswg/cssom-view/#dom-element-scrolltop
[2] http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2558#
Comment 1 Antonio Gomes 2013-10-23 06:42:57 UTC 
If Gecko's behavior is preferred, item (3) could get amended as:

3) If the element is the HTML body element, the Document is in quirks mode, *and the element has no associated scrolling box*, return the value of scrollY.

likewise, scrollLeft would have to be changed, as well as the symmetric set operations (setting scrollTop and scrollLeft).
Comment 2 Antonio Gomes 2013-10-23 09:25:11 UTC 
(In reply to Antonio Gomes from comment #1)
> If Gecko's behavior is preferred, item (3) could get amended as:
> 
> 3) If the element is the HTML body element, the Document is in quirks mode,
> *and the element has no associated scrolling box*, return the value of
> scrollY.
> 
> likewise, scrollLeft would have to be changed, as well as the symmetric set
> operations (setting scrollTop and scrollLeft).

Tested on IE8 (old!) and the behavior is even more different:
- on quirks mode, IE does not respect the body's overflow:scroll property at all;
- on strict mode, it does, and creates "scrollable body" (not the documentElement element). It then behaviors like Opera and Firefox, as far as I can tell.
Comment 3 Antonio Gomes 2013-10-23 09:25:58 UTC 
Created attachment 1411 [details]
simple testcase used
Comment 4 Antonio Gomes 2013-10-23 10:19:27 UTC 
(In reply to Antonio Gomes from comment #2)
> (In reply to Antonio Gomes from comment #1)
> > If Gecko's behavior is preferred, item (3) could get amended as:
> > 
> > 3) If the element is the HTML body element, the Document is in quirks mode,
> > *and the element has no associated scrolling box*, return the value of
> > scrollY.
> > 
> > likewise, scrollLeft would have to be changed, as well as the symmetric set
> > operations (setting scrollTop and scrollLeft).
> 
> Tested on IE8 (old!) and the behavior is even more different:
> - on quirks mode, IE does not respect the body's overflow:scroll property at
> all;
> - on strict mode, it does, and creates "scrollable body" (not the
> documentElement element). It then behaviors like Opera and Firefox, as far
> as I can tell.

Hum, http://www.cs.tut.fi/~jkorpela/quirks-mode.html says that in quirks mode body is the root element, so IE seems to be doing the right thing above, as oppose to WebKit, Presto and Gecko: no body specific scrollable box is created. Then scrolltop of body in quirks mode is the actual root element's scroll Y offset.

@Simon, please let me know your thoughts.
Comment 5 Antonio Gomes 2013-10-23 10:58:54 UTC 
(In reply to Antonio Gomes from comment #1)
> If Gecko's behavior is preferred, item (3) could get amended as:
> 
> 3) If the element is the HTML body element, the Document is in quirks mode,
> *and the element has no associated scrolling box*, return the value of
> scrollY.
> 
> likewise, scrollLeft would have to be changed, as well as the symmetric set
> operations (setting scrollTop and scrollLeft).

After reading setscrolltop/left, they already have this:

"
If the element is the HTML body element, the Document is in quirks mode, ****and the element does not have any vertical overflow****, invoke scroll() with scrollX as first argument and y as second, and, if the given value is a ScrollOptionsVertical object, the given value as the third argument.
"

So, my proposal should be ok.
Comment 6 Simon Pieters 2013-10-23 11:58:28 UTC 
body is not the root element in quirks mode. That's not the right mental model. It might be in old IE, kinda, but not in other browsers or the specs.

I'm happy to align with Gecko here if you think that's preferable.
Comment 7 Simon Pieters 2013-10-23 12:15:20 UTC 
[2] http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2558# is not in quirks mode.

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2584 illustrates this: per current spec, the viewport is scrolled, but the proposal is to scroll the <body> (if it's scrollable).
Comment 8 Simon Pieters 2013-10-23 12:18:33 UTC 
Sorry, that's testing the setter, this bug is talking about the getter. It would indeed be sane for getter and setter to behave the same...
Comment 9 Simon Pieters 2013-10-23 12:28:40 UTC 
Hmm. Dispatching on overflow in the two directions separately seems confusing, though. Gecko doesn't appear to do that, just dispatches on whether there's a scrolling box.

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2585
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2586

I think I'll go with that since using the body in one direction and the viewport in the other is just asking for trouble...
Comment 10 Mike Sherov 2013-10-23 12:33:37 UTC 
If I'm reading the spec and the proposal here correctly, it *seems* that quirks mode has no non-buggy behavior, unless in quirks mode there is no way to scroll the frame independently of the body. The same would go for standards mode, unless there is no way to scroll the root element independently of the frame. 

I'm mobile at the moment, so excuse my lack of a link to a test case. In theory, in quirks mode, a user can do this: body {height:120%; overflow:scroll;}. There is then no way the user can determine the correct scrollOffset, because you can't detect when the difference between both the body and frame being independently scrolled vs. only the body being scrolled.

Again, the same would be true of standards mode and the root element unless they can't be independently scrolled.

This surfaces as bugs in jQuery UI FWIW.
Comment 11 Mike Sherov 2013-10-23 12:38:24 UTC 
Wow, let's try that again:

I'm mobile at the moment, so excuse my lack of a link to a test case. In theory, in quirks mode, a user can do this: body {height:120%; overflow:scroll;}. There is then no way the user can determine the correct scroll offset of a child of the body, because you can't detect the difference between both the body and frame being independently scrolled vs. only the frame being scrolled.
Comment 12 Simon Pieters 2013-10-23 13:15:33 UTC 
If you want to scroll the viewport, use scrollX/Y on window directly.

The root element can't ever be scrolling because 'overflow' on the root element propagates to the viewport.

The body element can be scrolling in both standards mode and quirks mode. I think compat requires that these attributes operate on the viewport in quirks mode when body itself is not scrollable. Body being scrollable is quite rare, I think.

With the proposal, if you are in quirks mode and body is scrollable, the viewport and body are independent. Maybe it's clunky to find out if the body is scrollable, though.

Do you have links to the jQuery UI bugs?
Comment 13 Simon Pieters 2013-10-23 13:18:32 UTC 
https://dvcs.w3.org/hg/csswg/rev/3ab831142070

I fixed some related issues in this commit as well. Please reopen if something is still broken.

Also see https://www.w3.org/Bugs/Public/show_bug.cgi?id=23607
Comment 15 Simon Pieters 2013-10-23 14:48:57 UTC 
(In reply to Mike Sherov from comment #14)
> http://bugs.jqueryui.com/ticket/6258
> http://bugs.jqueryui.com/ticket/9379

I don't understand what the problem is with these and whether there's something that should be changed in the spec.

> http://bugs.jqueryui.com/ticket/9315

This appears to be caused by WebKit/Blink not following the spec for document.documentElement.scrollTop on the root element in standards mode, right?
Comment 16 Mike Sherov 2013-10-23 17:01:27 UTC 
Hi Simon,

You've resolved the issue with your edits :-) I was just providing the links for context because you asked. jQuery UI doesn't support quirks anyway, so, my issue was #2.

Thanks again!
Comment 17 Antonio Gomes 2013-10-24 03:01:30 UTC 
(In reply to Simon Pieters from comment #9)
> Hmm. Dispatching on overflow in the two directions separately seems
> confusing, though. Gecko doesn't appear to do that, just dispatches on
> whether there's a scrolling box.
> 
> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2585
> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2586
> 
> I think I'll go with that since using the body in one direction and the
> viewport in the other is just asking for trouble...

Thanks for te fix, Simon. These links are great too!

So after playing with these two samples on Firefox, it seems if there is an scrollable box (with or without overflown content), body.scrolltop/left won't never get applied to the viewport. It happens in both strict and quirks mode. Does it sound correct?

If so, Firefox does pretty well..
Comment 18 Simon Pieters 2013-10-24 08:36:46 UTC 
Mike, OK, great. Thanks!

Antonio, yeah, that seems about right.

Another case is http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2589
Comment 19 Antonio Gomes 2013-10-24 09:45:22 UTC 
(In reply to Simon Pieters from comment #18)
> Mike, OK, great. Thanks!
> 
> Antonio, yeah, that seems about right.
> 
> Another case is
> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2589

Oh interesting. I wondering in what category of the algorithm it falls into..
Comment 20 Simon Pieters 2013-10-24 11:13:02 UTC 
It goes like this (omitting things that don't apply):

[[
When setting the scrollTop attribute these steps must be run:

1. ...

2. ... let y be the given value.

3. ...

4. ...

5. If the element is the HTML body element, the Document is in quirks mode, and the element does not have an associated scrolling box, invoke scroll() with scrollX as first argument and y as second, and, if the given value is a ScrollOptionsVertical object, the given value as the third argument, and terminate these steps.

...
]]