Re: [spec-reviews] CSSOM View document.scrollingElement (#51)

I agree there is some cause for concern here.  I believe your argument is only compelling when your ignore quirks mode.  Even in the future when Blink/WebKit are fixed, libraries still need a bit of logic to determine which element is the scrolling element.

Trying to get sites to update to support the spec compliant behavior without a UA check it'be become clear to me that scrollingElement is a big help in practice.  Facebook made use of such an API internally, was unwilling to do the (somewhat intrusive iframe-measurement) hack and so had to make a fairly substantial change to their codebase to follow separate get ('||' the two values) and set paths (set on both elements).  Closure is even worse - their public API has 'goog.dom.getDocumentScrollElement'.  We course of course could argue that they (and anyone else like them) should use an iframe measurement hack (like the above polyfill - which by the way still has issues), or they should deprecate this public API.  But that would take way more debate/effort than at least I'm willing to stomach.

If we think the value of document.scrollingElement isn't high enough, then that's OK with me.  I'll give up trying to ever fix this wart in blink and be resigned to either the status quo (continuing the LONG tradition of violating the CSS spec here) or trying to convince the spec and other browsers to change  to bake WebKits bug into their design (thereby making body-scrollers confusingly unavailable to JavaScript).

So to me the choice of long term future seems to be between:
1) All browsers eventually behave the same and we have a somewhat questionable tiny additional API
2) All browsers have irrational behavior where body doesn't truly behave like an element, and documentElement controls scrolling via some APIs (CSS overflow) and not others (scrollTop)
3) Status quo - confusing differences between browsers

I'd be happy to be proven otherwise.  There have been several failed attempts over the years to fix this wart, but adding a new API to ease the transition is the one thing that hasn't been tried.  Perhaps I'm just crazy for trying again to solve this (after IE told me they were forced to copy our bug in EdgeHTML).

---
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/spec-reviews/issues/51#issuecomment-93776653