And, to be clear, we _can_ fix these compat issues, some way or another.

One thought is to limit the amount of scroll adjustments without user scrolling or stuff like that, which would prevent the "you get stuck on the page".

Making anchoring opt-in rather than opt-out is another option, but that defeats most of the purpose of the feature, I guess.

See also some of the Chromium docs on the compat issues they found[1] and how were they trying to fix them before adding the "layout-affecting-property changed" heuristic, which is what is on the spec right now and what they implement.

I just think that these are very hacky heuristics that are just going to bring a lot of compat pain and developer confusion.

It doesn't help that all these things can break or not depending on the speed at which the user scrolls, the amount of scroll events that the user dispatches, the timing of these events relative to other events, etc...

 -- Emilio


On 9/27/19 2:23 PM, Emilio Cobos Álvarez wrote:

(cc'ing webkit-dev@ and blink-dev@ in case they have feedback or opinions, as WebKit is the only engine which does not implement scroll anchoring, though I don't know if they plan to, and Blink is the only other engine that does implement it. Please reply to dev-platform@ though.)

TLDR: Scroll anchoring is really a mess.

I didn't do the initial implementation of the feature in Gecko, but I've done a ton of work over the last few months to fix compat issues in our implementation (see all the bugs blocking [1]).

At this point, our implementation is mostly compatible with Blink, but even with a bug-for-bug compatible implementation, we did get compat issues because of different content being served for different browsers, or because our anti-tracking protections changing the final content of the page slightly ([2] is an example of bug which only reproduces with ETP enabled only, but whose reduced test-case renders the site unusable in Chrome as well).

If you hit one of the broken cases as a user you think the browser is completely broken, and the site is just unusable.

I've fixed those by tweaking the heuristics Gecko uses. Those extra heuristics have also caused other compat issues, like [3], reported today, which will require other adjustments to the heuristics, etc...

On top of that, the spec is not in a good state, with ton of open issues without feedback from the editors [4].

So right now I'm at a stage where I think that the feature is just not worth it. It doesn't behave predictably enough for developers, and you have no guarantee of it behaving consistently unless you test a particular browser, with a particular content in a particular viewport size... That's not great given the current dominant position of Chromium-based browsers.

On top, issues with scroll anchoring are pretty hard to diagnose unless you're aware of the feature.

All in all, it doesn't seem like the kind of feature that benefits a diverse web (nor web developers for that matter), and I think we should remove the feature from Gecko.

Does anyone have strong opinions against removing scroll anchoring from Gecko, based on the above?


  -- Emilio

dev-platform mailing list
webkit-dev mailing list

Reply via email to