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

I'm personally unclear why this is the right path. Given the existence of e.g. https://github.com/mathiasbynens/document.scrollingElement it seems like we are essentially baking a jQuery-style browser normalizer ... into the browser. Which means we'll have to support it going forward forever.

Why does this drop-in replacement need to be provided by the browser? It's marginally easier for authors, but is it worth the long-term cost of adding cruft, in the future where document.scrollingElement just becomes a synonym for document.documentElement? You have to consider the cognitive burden for future authors who read code and see document.scrollingElement, then have to go look up what that does, instead of just seeing document.documentElement and knowing immediately what it does. (And yes, it's not just a synonym in quirks mode, but I don't think adding a new API for quirks-mode users is really that interesting).

I also don't understand how we expect this to work out. Is the envisioned sequence something like this?

- spec says document.scrollingElement === document.documentElement
- Blink implements document.scrollingElement === document.body; Gecko implements document.scrollingElement === document.documentElement
- Hopefully nobody writes code that assumes one or the other (e.g. uses document.scrollingElement.firstChild or document.scrollingElement.addEventListener(...)), or uses UA-sniffing such that different code paths within the same app depend on the different behaviors for document.scrollingElement
- We try switching to standards-compliant behavior?

I am worried about the "hopefully" here, as it just seems to set us up for repeating the cycle. Likely I am missing something.


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