CSSOM View behavior for scrollLeft, scrollTop, scrollWidth etc

# Frédéric Wang (8 months ago)

I'd like to announce that I started to implement the behavior for scrollLeft, scrollTop, scrollWidth, scrollHeight, scrollTo, scrollBy and scrollingElement [1] as specified by the CSSOM View specification [2].

To summarize, the main difference is which element to use in order to set or get the scroll properties of the viewport in standard (non-Quirks) mode:

  • The CSSOM View spec says it should be document.documentElement and most browsers implement it that way.
  • Chromium used to use document.body but this has recently been changed to follow the CSSOM View spec [3].
  • WebKit still uses document.body and I'm proposing to change this behavior.

Note that this is likely to break existing content. The change was attempted in WebKit in the past but broke some non-regression tests [4]. Chromium people also had some issues when trying to ship the change but things went well at the end [5].

For now I'm developing it under a CSSOMViewScrollingAPI developer flag. I was able to run the tests with that flag enabled, modulo a few test adjustments.

[1] bugs.webkit.org/show_bug.cgi?id=5991 [2] drafts.csswg.org/cssom-view [3] groups.google.com/a/chromium.org/forum/#!topic/blink-dev/X64Sg16RhT4 [4] bugs.webkit.org/show_bug.cgi?id=106133, bugs.webkit.org/show_bug.cgi?id=121876 [5] groups.google.com/a/chromium.org/forum/#!msg/blink-dev/2iOz5-fgD8Y/GO7qLkg4BwAJ ; bugs.webkit.org/show_bug.cgi?id=5991#c20

Contact us to advertise here
# Frédéric Wang (8 months ago)

On 30/01/2018 17:21, Frédéric Wang wrote:

Chromium people also had some issues when trying to ship the change but things went well at the end [5].

[5] groups.google.com/a/chromium.org/forum/#!msg/blink-dev/2iOz5-fgD8Y/GO7qLkg4BwAJ ; bugs.webkit.org/show_bug.cgi?id=5991#c20

I am told by Chromium developers that the workaround they had to introduce for smoothscroll.js won't be necessary for WebKit, because we don't have "chrome" in the UA string. Of course that does not mean that the behavior changes won't cause any other issue...

# Frédéric Wang (16 days ago)

The new behavior is enabled for tests after trac.webkit.org/changeset/235806/webkit Essentially, this means that if you want set/get the scroll position of the test pages, you should now just use document.scrollingElement instead of document.body.

I'll wait a few days before proposing to set it to DEFAULT_EXPERIMENTAL_FEATURES_ENABLED and allow wider testing : bugs.webkit.org/show_bug.cgi?id=189472

Frédéric

# Frédéric Wang (2 days ago)

On 10/09/2018 10:41, Frédéric Wang wrote:

The new behavior is enabled for tests after trac.webkit.org/changeset/235806/webkit Essentially, this means that if you want set/get the scroll position of the test pages, you should now just use document.scrollingElement instead of document.body.

I'll wait a few days before proposing to set it to DEFAULT_EXPERIMENTAL_FEATURES_ENABLED and allow wider testing : bugs.webkit.org/show_bug.cgi?id=189472

Given the new policy for experimental features and given that the behavior has already been enabled for all tests for 2 weeks now, we should either 1) remove the flag from the experimental category and enable by default or 2) disable it for tests and enable it on a per-test basis using headers.

I'm proposing the former in bugs.webkit.org/show_bug.cgi?id=189472

Note that enabling the flag is a big behavior change that might impact users but at the same time will fix an old compatibility issue between WebKit (non-standard behavior) VS Chromium/Gecko/Edge (CSSOMView behavior).

Want more features?

Request early access to our private beta of readable email premium.