[css-scroll-anchoring-1] Anchor selection should prefer 'active' nodes

[vmpstr]

Anchor selection algorithm only considers the DOM relationship of the nodes and their visibility in the scroller.

There are some situations where scroll initiated by a user-agent algorithm, such as find-in-page, causes us to select a suboptimal scroll anchor which pushes the find-in-page match outside of the viewport.

This situation is possible if there is, for example, an intersection observer, which sizes on-screen elements differently from off-screen elements. When find-in-page match is scrolled to the center, we can pick a scroll anchor near the top of the viewport and after resizing and adjusting the scroll position end up in a situations where the find-in-page match is not visible.

One way to fix this is to prefer certain nodes in the anchor selection algorithm. Some potential interesting nodes (in no particular order) are the following:

• Find-in-page active match
• An element which was the target of scrollIntoView() "recently" (since the last anchoring adjustment?)
• An element with focus
• An element containing user selection

(These should only be selected if they are at least partially visible, and are a descendant of the scroller, of course)

There may be more interesting nodes, or maybe some of the ones I listed are not as interesting, but I think the user-agents can use information other than DOM structure to select a nicer anchor

Any thoughts?

[chrishtr]

Another interesting "node" is an editing or selection caret.

[flackr]

Maybe more generally we should maintain a concept of the active node which is updated by a variety of activities such as the ones proposed above.

Some other potential activities:

• hover - could avoid buttons sliding out from under your mouse.
• click / tap - same idea as hover, anchoring something you are interacting with so that further interactions are not disrupted.

One thing to be careful of though is that we don't interfere with draggable interfaces. I.e. imagine a scrollable list where you can drag items to reorder - we wouldn't want dragging an item to try to keep that node anchored in the scroller as it would no longer be connected to your cursor / finger.

[emilio]

In Gecko we use the concept of "active" node, to some extent, as in, where does focus navigation, start from or such, and it is the selection position of either the focused element (if it owns a selection) or the per-document selection otherwise. We move that when you click on the page for example.

So for example if you click on the text of @chrishtr's comment and then tab from there you go to the starting point.

It'd be nice not to invent more complex concepts for something like this, but I don't know what other browsers do for tab navigation for example.

[vmpstr]

One thing to be careful of though is that we don't interfere with draggable interfaces. I.e. imagine a scrollable list where you can drag items to reorder - we wouldn't want dragging an item to try to keep that node anchored in the scroller as it would no longer be connected to your cursor / finger.

If I understand correctly, then this could already be a problem since the current anchor selection could select a node that is being dragged, right? It's just not as predictable

It'd be nice not to invent more complex concepts for something like this, but I don't know what other browsers do for tab navigation for example.

I agree. I think Blink has similar behavior, but I couldn't say exactly when this "active" node is updated. For example, there would presumably be competing information. I think all three of the following are possible at the same time:

• Element has focus
• Find-in-page is highlighting a current match
• User has some text selected somewhere

I think these should all be considered by the anchor selection, but it needs to have some notion of priority. As an example, input with focus could take priority to ensure that the user consistently sees where the focus is (this would handle the editing caret case too, right?). After that, find-in-page match is probably most important since it is highlighting something the user explicitly looked for. Then, user selection or selection caret since that's also user provided feedback and the text was interesting in some way.

I'm less convinced of something like hover unless maybe the element has an onhover effect, since I know personally my mouse is usually nowhere specific as I scroll the page around, so anchoring to the element under my mouse would not be a good signal. Click / tap, however, are good indicators that the user wants that element to stay where it is.

To make progress here, is it reasonable for us to come up with a small set of initial preferred candidates for anchor selection, and put in the language and terminology in the spec to allow for this? As we find more compelling cases, I think we would be able to augment the initial set with more elements easily. If so, what are the opinions on which elements should be a part of the initial set? I think find-in-page and focused elements are my primary candidates

[vmpstr]

#5050 is my attempt at the language to capture this. Please let me know if that looks reasonable

[vmpstr]

Closed via #5050
Let's file new issues for new priority anchors

[emilio]

Should we also prioritize text selection? Seems equally desired to an insertion caret, IMHO.

[vmpstr]

I think that's reasonable. I believe Gecko supports multiple disjoint selections, so perhaps the first visible one or something like that? Also, where would the priority of this fall? Maybe between focus and find-in-page is good

---

I feel like we need to define some criteria for inclusion as well. In other words, presumably a list of uniquely identifiable elements that make good anchor candidates is fairly large. I propose the two steps for including one should be:

1. Identify the use-cases that the anchor might solve (or a reasonable argument for it)
2. Identify the relative priority of the anchor relative to other ones (with some justification)