Re: [csswg-drafts] [css-scroll-anchoring-1] Anchor selection should prefer 'active' nodes (#5018)

> 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

-- 
GitHub Notification of comment by vmpstr
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5018#issuecomment-621877012 using your GitHub account

Received on Thursday, 30 April 2020 14:10:02 UTC