Feature detection should not set scrollLeft coordinate to a positive value

[fred-wang]

As part of Chromium web interoperability effort, we are trying to address these inconcistencies by switching to the standard "negative" type ( see https://www.chromestatus.com/feature/5759578031521792 ). In particular, we are trying to measure websites using non-standard "default" type that could potentially be broken by this behavior change. For that purpose, we analyze web pages setting scroll coordinates to positive values (when they are really expected to be nonpositive).

This library is a nice way to feature detect scroll inconsistencies between browsers but it is causing websites to trigger our use counters because of the operation definer.scrollLeft = 1;. Can you please modify it to instead rely on scrollIntoView() instead?

Here is an example:

https://people.igalia.com/fwang/scrollable-elements-in-non-default-writing-modes/scroll-coordinates-behavior.js

[othree]

I would like to upgrade the code.
But I don't think the websites already using this lib will upgrade it.
How do you solve this situation?

[fred-wang]

@othree Thanks. Right, we will need to tell websites to upgrade to the new code and that's not going to be easy, but obviously it's easier if the upstream code is fixed first. (I believe we had similar issues in the past with smoothscroll.js using document.body instead of document.documentElement to scroll the page).

[fred-wang]

@othree I've opened #7

[fred-wang]

I guess this can be closed now.