Contact emails
Spec
http://dev.w3.org/csswg/cssom-view/#dom-document-scrollingelement
Tag review: not necessary, this is a trivial addition
Summary
Adds a simple 'scrollingElement' property on Document which returns either document.body or document.htmlElement depending on which element can currently be used to scroll the viewport.
Motivation
The spec for the Element scrolling APIs (eg. scrollTop) is non-trivial when it comes to body vs. htmlElement due to legacy reasons. WebKit and Blink still don't implement the spec properly and unfortunately sites (eg. Facebook) and frameworks (eg. Closure) have come to rely on UA checks to expect the WebKit behavior. There isn't a great replacement for such UA checks to enable developers to reliably choose between using body or scrollTop for scrolling (the typically advocated approaches tend to be broken in some scenarios).
This API provides a simple way for the browser to tell the web page which element is used for scrolling the viewport, making it trivial to update existing code. Tactically I feel this is essential to ease the migration to spec-compliant behavior in blink. But even long term this is still somewhat useful since the spec-compliant behavior is non-trivial (depends on quirks mode).
Compatibility Risk
Low. This is a tiny feature with just a little extra surface area. It's almost certainly going to lead to improved compatibility. That said it's a brand new API (I just thought to suggest spec'ing it yesterday), so there's still some chance other vendors will object somehow. To avoid making the scroll interop problem even worse (eg. the latest Spartan builds copy our bug), I still think we should ship this API immediately. If (in the unlikely event) the spec looks like it might change before we hit stable, I'll pull it out.
Ongoing technical constraints
None
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes
OWP launch tracking bug?
Link to entry on the feature dashboard
I created one feature for the bigger picture issue: Interopable body/documentElement scroll behavior
Requesting approval to ship?
Yes
Sounds reasonable to me :)
For a compatibility proof solution that doesn't check for the browser like the aboveexample, just get the total value of both:document.documentElement.scrollTop + document.body.scrollTopThis will return the same value on all browsers, as one of the values is the documentscroll, and the other one will be 0.
Agreed returning the offset on both elements isn’t a good option, for the reason you mention.
Aside from inconsistency with the spec and other implementations, my main objection to the current Webkit/Blink behavior is that it has strange results in cases where both the documentElement and body have non-“visible” overflow. Consider this example, where the body element is scrolling, the body element is receiving the scroll event, but the body element’s scrollTop remains 0:
http://codepen.io/anon/pen/emqEJw
I don’t think there’s an easy solution to that wart without enabling ScrollTopLeftInterop. A web developer could sort of work around it by watching the boundingClientRect of a dummy element, but that would be pretty hacky.
Reporting the offset on the body also means that layout viewport metrics are spread across two elements, which is strange. The documentElement.clientWidth/Height gives the dimensions of the layout viewport but the body.scrollTop/Left (or scrollingElement.scrollTop/Left) would give its position. Except in double-non-“visible” cases as noted above.
Thanks,
-Matt
We’ve had a couple bugs in the past unique to that construction, so I know the usage is non-zero. I’m not certain of any top-tier examples offhand though. The window scrolling APIs don’t work in this case, presumably because they’re targeting the top level scroller.
We’ve had a couple bugs in the past unique to that construction, so I know the usage is non-zero. I’m not certain of any top-tier examples offhand though.
The window scrolling APIs don’t work in this case, presumably because they’re targeting the top level scroller.
LGTM3 to implement. Alex is making a template for requesting TAG
review, but to speed things along simply opening an issue in
https://github.com/w3ctag/spec-reviews/issues ought to work.
I'm keen to know what is known about the compat problems with aligning
with the spec on documentElement-vs-body issue. The hope is that
adding document.scrollingElement will make it much easier to do
outreach to fix sites that sniff to determine which element to use for
scrolling. Further, the hope is that the outreach will make a big
enough dent in the problematic usage that it would unblock the change
needed in Blink.
I share these hopes, but wonder if there's reason to be optimistic. It
seems that more often than not, there's some bit of code that has been
copied around the Web or ended up in a popular framework that makes
outreach entirely ineffective because the problem is spread uniformly,
as opposed to being concentrated in a few big sites.
If we don't have a good idea about what will break by fixing the
documentElement-vs-body situation, we could try to just make the
change and let it set for a while in the non-stable channels to
collect bug reports and then reverting. If the scope of the problem
seems small enough, might we not simply fix the problem?
>> Anyway, given the above I believe we should proceed with shipping
>> scrollingElement. I'll work to try to identify and update known sites
>> relying on a UA check to prefer scrollingElement.
No strong opinion here. I believe the amount of content that rely on
the quirks current behavior is non-trivial, I do not see
scrollingElement helping legacy content out there.
Still, if it does not get the situation worse, it seems worth it to try.
No strong opinion here. I believe the amount of content that rely on
the quirks current behavior is non-trivial, I do not see
scrollingElement helping legacy content out there.
Still, if it does not get the situation worse, it seems worth it to try.Don't you think your changes here (eg. consolidated in this CL) would have been made somewhat simpler by document.scrollingElement? It's not as bad as a case like closure (where their public API depends on being able to identify a single element as the document-scrolling element), but still seems like it would have at least eased your pain substantially (could have become a simple regex: s/\.body\.scroll/\.documentElement\.scroll/g).
>> Separately we can re-discuss when / whether we should try to enable
>> ScrollTopLeftInterop by default.
>>
>> WDYT?
I agree.
Since the scrollingElement polyfill exists, what is keeping Closure from using it instead?
Funny, they are using browser detection which is a very bad practice and you have to fight the battle with them. This is ridiculous. Especially for Closure - Google always advocates feature detections.