[csswg-drafts] [css-scroll-snap-2] How should competing scroll-start-targets be resolved? (#10774)

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

== [css-scroll-snap-2] How should competing scroll-start-targets be resolved? ==
The scroll snap 2 [spec](https://drafts.csswg.org/css-scroll-snap-2/#scroll-start-target) says that when there are multiple elements that could be scroll-start-targets for a scroll container "user-agents should select the one which comes first in [tree order](https://dom.spec.whatwg.org/#concept-tree-order)".
This feels like a simple solution that meets the needs of scroll-start-target use cases. It's perhaps also a natural solution as it's somewhat similar to the css-scroll-snap spec's precedent of falling back on tree order when [selecting between multiple aligned snap areas](https://drafts.csswg.org/css-scroll-snap/#multiple-aligned-snap-areas).

Alternatively, we could compute the intersection of all relevant scroll-start-targets ([suggested](https://github.com/w3c/csswg-drafts/issues/8832#issuecomment-1548232540) by @flackr ). We could compute the relevant [scroll-into-view positions](https://drafts.csswg.org/cssom-view-1/#determine-the-scroll-into-view-position) (or some other method) of all the scroll-start-targets and then use the average along each axis. Since this could result in none of the scroll-start-targets ending up in the scrollport, we would handle this case by falling back to the first in tree order.

I propose we stick with what is currently spec'd as the use cases for scroll-start-target that I can think of (e.g. carousels, drop-down menu starting at an arbitrary item) really only intend scroll to a single target, not some average of multiple targets.

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


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

Received on Friday, 23 August 2024 19:14:55 UTC