[css-scroll-anchoring] Consider adding an opt-in way of avoiding scroll anchoring suppressions

[emilio]

Right now there's no way for a page to override the scroll anchoring heuristics, which seems unfortunate, since that means it's unreliable.

Maybe we should consider adding an overflow-anchor: always to force anchoring to happen regardless of the style changes that happen in the scroll container.

cc @hiikezoe @chrishtr

[hiikezoe]

That sounds promising. I would be supportive!

That being said, I do wonder most of web developers basically want to set it explicitly by default as kinda idiom, then some of them might write JS causing infinite scroll event loops unintentionally? Maybe I am worrying too much.

[SebastianZ]

This is a duplicate of #4264.

Sebastian

[SebastianZ]

Giving the use cases some more thought, this issue seems to be sufficiently different from #4264 to discuss it separately.

And I have some notes and questions:

Is avoiding scroll anchoring suppressions actually necessary? @emilio as I understand this request, you want to introduce a way to always use scroll anchoring and disregard any suppression window, correct?

From the discussions, it looks like the main issue you want to fight with this change is jumping on infinitely scrolling pages like facebook. Though reading the spec. text it seems the suppression window and suppression triggers where introduced exactly for that use case. But I don't know enough about the issue regarding scroll event listeners, so maybe I am misunderstanding something here.
Maybe it would help to outline the use case for avoiding scroll anchoring suppressions and provide an simple test case where the current algorithm fails.

And depending on the use case, it might not be necessary to introduce a new value but improve the anchor node selection algorithm instead.

If it turns out that we somehow require further control over avoiding anchoring suppressions, we should also consider whether it makes sense to add it to overflow-anchor or rather add a way to control this on the scroll container itself instead.

Sebastian

[hiikezoe]

From the discussions, it looks like the main issue you want to fight with this change is jumping on infinitely scrolling pages like facebook. Though reading the spec. text it seems the suppression window and suppression triggers where introduced exactly for that use case. But I don't know enough about the issue regarding scroll event listeners, so maybe I am misunderstanding something here. Maybe it would help to outline the use case for avoiding scroll anchoring suppressions and provide an simple test case where the current algorithm fails.

An example has been already in the wpt repository (as tentative though), infitnite-scroll-event.tentative.html.

It's a simplified test case where it was originally reported in https://bugzilla.mozilla.org/show_bug.cgi?id=1561450.

[css-meeting-bot]

The CSS Working Group just discussed [css-scroll-anchoring] Consider adding an opt-in way of avoiding scroll anchoring suppressions.

The full IRC log of that discussion

<emeyer> emilio: Scroll anchoring spec has a bunch of heuristics about when to apply or stop applying scroll anchoring
<emeyer> …We found some cases where pages rely on scroll anchoring to happen, and depending on timing of style changes, page may misbehave
<emeyer> …When you fire scroll events
<emeyer> …Seems to be no way for devs to say “I really really want scroll anchoring to happen”
<emeyer> …I think adding a way to opt into ignoring suppressions and in this scrolling, we’re going to do anchoring regardless of other things
<emeyer> …I think it’s moderately trivial to implement, but is it a good idea? Or reason it’s a bad idea?
<emeyer> astearns: Any thoughts on adding a way to require scroll anchoring?
<emeyer> (silence)
<emeyer> astearns: Shoudl we add an `always` value and see how it goes?
<flackr> q+
<emeyer> emilio: If there’s no anchor you don’t do anchoring, so maybe that name doesn’t quite make sense
<astearns> ack flackr
<emeyer> flackr: What is `always` specified on?
<emeyer> emilio: overflow-anchor works on the scroll container, I believe
<emeyer> flackr: overflow-anchor I thought is applied to any element to prevent any element within to be selected as an achor
<SebastianZ> q+
<emeyer> emilio: Right, I guess should always have an effect on non-scroll containers
<emeyer> flackr: I was wondering if `always` would be a way of saying “this is the element to which I want to anchor”
<emeyer> emilio: Then we’d need another way to specify that an anchor should never lose the anchor even if there are suppressions
<emeyer> flackr: What do you anchor to?
<emeyer> emilio: Whatever you were anchoring to before
<emeyer> …What the suppression triggers do is prevent going back
<emeyer> flackr: The suppression trigger rpevent selecting an anchor within a given subtree
<emeyer> …You need to know which element should stay in the same position after anchoring
<emeyer> emilio: I’m not proposing to change anchor selection
<emeyer> …In my head, suppression triggers don’t affect anchor selection
<emeyer> flackr: Are we talking about overflow-anchor?
<emeyer> emilio: What I’m talking about it, the spec has heuristics that don’t affect anchor selection but do affect adjustments
<emeyer> …overflow-anchor seemed an obvious property to add this exception
<emeyer> flackr: I know anchor selection is a big problem and maybe overflow-anchor: always means you must selecto something in here as the anchor
<emeyer> emilio: This seems like an orthogonal problem
<emeyer> …I’m just trying to bypass the heuristics
<astearns> ack SebastianZ
<emeyer> SebastianZ: Quick note: overflow-anchor is targeting elements while something is targeting the scroll container, os maybe it should be another property in the end
<emeyer> astearns: Let’s take this back to the issue and come up with a proposed solution that can be agreed upon there
<emeyer> …Maybe we can get this and the linked issue on a near-future call
<emeyer> astearns: That’s time; anyone who wants to stay to talk about a summer FTF, please stay on