Re: [webkit-dev] What to do about scroll anchoring?

2019-09-29 Thread Simon Fraser

> 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?

2019-09-29 Thread L. David Baron
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?

2019-09-29 Thread L. David Baron
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?

2019-09-27 Thread Emilio Cobos Álvarez

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