[csswg-drafts] [css-scroll-snap-2] Standardize snap point selection with multiple aligned boxes (#9622)

flackr has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-scroll-snap-2] Standardize snap point selection with multiple aligned boxes ==
The proposed [snap events](https://drafts.csswg.org/css-scroll-snap-2/#snap-events) and [styling](https://drafts.csswg.org/css-scroll-snap-2/#snapped) 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](https://drafts.csswg.org/css-scroll-snap-1/#re-snap) 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](https://drafts.csswg.org/css-scroll-snap-1/#re-snap) 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. If inline and block have elements in common, filter both lists to those elements they have in common.
6. Select the first element in [tree order](https://dom.spec.whatwg.org/#concept-tree-order) from each of the block and inline list as the snapped target in each axis.
7. 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.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9622 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 22 November 2023 15:23:36 UTC