Re: [webkit-dev] What to do about scroll anchoring?
> On Sep 27, 2019, at 10:08 PM, Emilio Cobos Álvarez wrote: > > 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… I expressed my main issue with scroll anchoring at the F2F, which is that it’s an on-by-default behavior that is making up for bad web authoring, and is harmful if only implemented by a subset of browsers. I would support removing it entirely, or having it be opt-in. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] What to do about scroll anchoring?
On Friday 2019-09-27 14:23 +0200, Emilio Cobos Álvarez wrote: > Does anyone have strong opinions against removing scroll anchoring from > Gecko, based on the above? It seems pretty sad, since I think it's a very useful feature for a large class of pages -- particularly pages that are more "documents" than "applications". I wonder if it would be possible to disable the feature under certain conditions, for example: * the page uses APIs that initiate scrolling from script, or * the page has handlers for scroll events, or * the page does both of the above but leave the feature enabled for pages that don't do these things. Based on what I've heard it seems like many of the cases where pages are really broken involve some of those, although I haven't gone through the bug lists. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] What to do about scroll anchoring?
On Sunday 2019-09-29 10:54 +1000, Cameron McCormack wrote: > How useful is scroll anchoring outside of the two cases mentioned in > https://drafts.csswg.org/css-scroll-anchoring/#intro i.e. images loading and > ad iframes being inserted? Would it be feasible to make scroll anchoring a > much less general mechanism, and to scope it down to handling these specific > cases? I think it's also quite useful for horizontal resizes of the browser window (which can include device rotation on mobile, window resizing/maximization on desktop, and also hiding/showing of browser sidebar UI). -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] What to do about scroll anchoring?
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-platf...@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] What to do about scroll anchoring?
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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
