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 23448 - Should setting scrollTop on root element really reset scrollLeft to 0?
Summary: Should setting scrollTop on root element really reset scrollLeft to 0?
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-07 16:59 UTC by Antonio Gomes
Modified: 2013-10-07 20:16 UTC (History)
2 users (show)

See Also:


Attachments

Description Antonio Gomes 2013-10-07 16:59:41 UTC
http://dev.w3.org/csswg/cssom-view/#dom-element-scrolltop says:

"
(...)
When setting the scrollTop attribute these steps must be run:
(...)
4 - If the element is the root element invoke scroll() with zero as first argument and y as second, and, if the given value is a ScrollOptionsVertical object, the given value as the third argument.
(...)
"

This is not what browsers do, as one can see here running this sample here: http://jsfiddle.net/4bRQc/4/ . IE, Firefox, Opera 12 (pre-blink) and Safari nightly builds do not zero X when setting scrollTop on the root/documentElement node. Similarly, when setting scrollTop on body node, in quirks-mode.

ps: Blink/Opera work to match other engines, is under works.

Unless, this divergence between the spec description and web engines' behavior is still relevant at this point, I propose wording it like:
"4 - If the element is the root element 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."

That would also make step (4) to match step (5).
Comment 1 Simon Pieters 2013-10-07 20:16:29 UTC
https://dvcs.w3.org/hg/csswg/rev/b79ac21fc79c

Thanks!