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
[1]:
https://docs.google.com/document/d/1nQAO4MYCDMn0rTkn_-WI6gjumk3Qi2Bn-MGuB3NlVxE/edit
On 9/27/19 2:23 PM, Emilio Cobos Álvarez wrote:
Hi,
(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?
Thanks,
-- Emilio
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1519644
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1561450
[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1584499
[4]: https://github.com/w3c/csswg-drafts/labels/css-scroll-anchoring-1
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
