[css-scroll-snap-2] Standardize snap point selection with multiple aligned boxes

[flackr]

The proposed snap events and styling in css-scroll-snap-2 expose the concept of snapped targets. Today, the developer can tell which element a browser is "snapped to" by moving them and seeing which one re-snapping after layout changes follows. The spec says the following about multiple snap aligned elements:

If multiple boxes were snapped before and their snap positions no longer coincide, then if one of them is focused or targeted, the scroll container must re-snap to that one and otherwise which one to re-snap to is UA-defined. (The UA may, for example, track which element is snapped as layout shifts align and de-align the snap positions of other elements.)

TLDR,

• Outside of focus or a target, the specific snapped element is not defined.
• When you have focus and target it's not defined which one takes precedence.
• Doesn't say which axis alignment to prefer if there is a different target in each axis.

Bringing this back to exposing the snap target, we have a two options:

1. Treat all elements which are visually aligned as snapped.
2. Standardize and expose the actually selected snap area in each axis.

Option 1 is relatively simple to understand, though requires extra work to compute (as it's not what's tracked internally) and may not be very useful. E.g. imagine a 2d grid of elements with snap-align: center, every element along the horizontal and vertical line through the center is snapped.

Option 2 would be more efficient to implement, as it is what the browser must already track internally, and if we are able to standardize on the snap point selection with multiple currently snap aligned elements would allow developers to know the element which will be tracked through layout shifts.

I propose we go with option 2, and update css-scroll-snap-1 4.1.3. Re-snapping After Layout Changes to always define an exact target in each axis. My proposal would be the following:

1. Let inline be the set of boxes currently aligned on the inline axis.
2. Let block be the set of boxes currently aligned on the block axis.
3. If there is a focused element in either / both lists, remove all other elements from the list.
4. If there is a targeted element in either / both lists, remove all other elements from the list.
5. Remove any items from the block and inline lists which contain (nest) inner items in those lists. I.e. prefer snapping to innermost elements when nesting snap areas.
6. If inline and block have elements in common, filter both lists to those elements they have in common.
7. Select the first element in tree order from each of the block and inline list as the snapped target in each axis.
8. When re-snapping, prefer to follow the axis that has the focused element, then the one which has the targeted element, then the block axis.

[argyleink]

Agree, option 2. It's the interface I'm lookin for in my snap experiences

[fantasai]

I think your proposal seems to make sense. :) The one bit I might change is to maybe flip the order of 5 & 6. (I'm not entirely sure about 5, I haven't thought through it thoroughly, but it seems to make sense.)

Wrt the spec, my suggestion would be to adopt your suggestion to prioritize focused over targetted, and otherwise inline your suggested behavior as a non-normative example. And then after we've got some experience with it and are feeling confident it's the right algorithm, encode it normatively in the spec.

[flackr]

I think your proposal seems to make sense. :)

Thanks for reviewing!

The one bit I might change is to maybe flip the order of 5 & 6.

Yes, I debated the order here as well. I think that 5 makes sense to happen first but haven't worked through specific cases where they'd produce different answers yet.

(I'm not entirely sure about 5, I haven't thought through it thoroughly, but it seems to make sense.)

If you have a large snap area, you want to prefer the inner item that's snapped to. This should play well with the algorithm we define for nested snap point selection in #9187 which tries to clearly snap to inner items.

E.g. consider when you're in a valid snap position for inner and outer below:

 -----------
|   outer   |
|           |
|           |
|           |
|           |
|  -------  |
| | inner | |
| |       | |
| |       | |
|  -------  |
|           |
|           |
|           |
 -----------

If inner is in a valid snap position then it is a more reasonable current target than outer.

[css-meeting-bot]

The CSS Working Group just discussed [css-scroll-snap-2] Standardize snap point selection with multiple aligned boxes, and agreed to the following:

• RESOLVED: Specify the whole list in this order as normative behavior

The full IRC log of that discussion

<dael> flackr: The spec says that when there's multiple boxes that are currently in a valid snap position, other than preferring targetted the browser can pick any box. I feel this makes spec things like snap events harder and I'd like to normativelly define in these cases
<TabAtkins> +1 to this proposal, and specifically the exact proposed list. I think flackr's example for keeping 5 and 6 in the current order makes sense
<dael> flackr: Proposed a specific algo here that preserves the intern for focused elements but then items that are aligned in both axis, inner elements.
<florian> q+
<dael> flackr: Basically, trying to provide a standard answer for what is the snaped item.
<astearns> ack florian
<dael> florian: Here too I think good to have specific behavior encoded. Proposal here, are the rules because they make sense or is it having observed people in these cases this works better
<fantasai> TabAtkins, flackr's example isn't about the ordering, just about whether 5 makes sense as a rule
<dael> flackr: Constructed rules to what I think makes sense
<dael> florian: Okay. Doesn't mean I object. But b/c we're not spec we may have browser differences so it gives us room to pick a good one. I'm not sure if it's easy to find use cases that dpend on this, but would be good
<TabAtkins> disagree, I think it's a good example of why you *should* eliminate the large element from being the snap target before you discover there's an overlap in the axises
<dael> flackr: if it helps, Chrome is semi-random b/c depends on construction order
<dael> florian: How would we go about finding live use cases that fall into this
<dael> flackr: Only way you can observe which item is snapped is by which item is snapped when you change layout. Only way authors could do this today is scroll changes but relying on multiple aligned items
<dael> florian: I guess you won't break much if you change
<dael> flackr: It's a bit of an edge case
<dael> astearns: Talk in IRC about oder of step 5 and 6
<dael> fantasai: Step 5 is inner vs outer and 6 is about if you happen to have snap positions in two axis that come from same element you want that element rather than snap in one axis
<dael> flackr: Yes, if you have a 2d you want something that aligns in box axis.
<dael> fantasai: If you have a 9 grid you care about the one in the middle. Okay
<dael> flackr: As I mentioned, 5 might not be necessary. If you have inner area aligned it could make snap not valid for the outer area
<dael> flackr: no strong feelings about which one goes first
<TabAtkins> I have medium-strong feelings that the current order is best.
<dael> flackr: Sorry, i do. I posted an example. You have an inner item aligned. Technically both boxes in my diagram are snap for inner and outer. You probably want the aligned
<dael> fantasai: But if they're aligned in both axis you skip set 6
<dael> TabAtkins: If you take same case but more inner one inside a bit, it does argue better behavior is block axis to take the inner so you don't want it eliminated by match checking
<dael> florian: I agree
<dael> flackr: Agree with that
<dael> fantasai: Okay
<dael> astearns: Consensus on ordering. How much of this do we make normative?
<dael> astearns: With my chair hat off, I'm in favor of spec the whole thing. Otherwise we may not find issues if people don'timpl whole list
<dael> flackr: My preference as well. And impact is subtle. Only observable today is what is aligned after layout change
<dael> florian: I don't think there's complexity to give variance to browsers. Have a precise behavior seems good for complex demos
<dael> fantasai: Where are snapping events defined?
<dael> flackr: scroll snap 2
<dael> fantasai: They're not published so should do something about that. This becomes more critical for level 2
<dael> astearns: fantasai are you okay spec the whole list as normative?
<dael> fantasai: Okay with that. Could mark as at risk for L1, but should write it all out
<dael> astearns: Prop: Specify the whole list in this order as normative behavior
<dael> flackr: I think it's not too hard to test. I'll help
<dael> astearns: Obj?
<dael> RESOLVED: Specify the whole list in this order as normative behavior
<dael> fantasai: What should we do about scroll snap L2 draft? It's just an ED
<dael> astearns: Is it ready for FPWD?
<dael> fantasai: Don't know
<dael> flackr: Have a PR in progress to add detail about event timing. This issue is in support of changing the targets of snap events to be a single element in each axis
<dael> flackr: I guess that's to say I don't know
<dael> florian: Land the PR and then publish?
<dael> flackr: I think finishing the inflight PR would make sense
<dael> astearns: fantasai, how about you open an issue saying we should have a FPWD for L2 and people can comment and get focus