[csswg-drafts] [css-scroll-snap-2] Should scrollsnapchanging target the currently visible element during flings (#10838)

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

== [css-scroll-snap-2] Should scrollsnapchanging target the currently visible element during flings ==
The [css-scroll-snap-2 spec](https://www.w3.org/TR/css-scroll-snap-2/#eventual-snap-target) says the following about scrollsnapchanging:
> A scrolling operation might animate towards a particular position (e.g. scrollbar arrow clicks, arrow key presses, "behavior: smooth" programmatic scrolls) or might directly track a user’s input (e.g. touch scrolling, scrollbar dragging). In either case, the user agent [chooses](https://www.w3.org/TR/css-scroll-snap-1/#choosing) an eventual snap target in each axis to which the scroller will [snap](https://www.w3.org/TR/css-scroll-snap-1/#scroll-snap) after the scrolling operation reaches its intended scroll position.
>
> In the former case, the intended scroll position is the scroll animation’s target scroll offset.
>
> In the latter case, the intended scroll position is the current scroll offset as determined by the user’s input.

For the case where the user is or was interacting and initiated a fling, Chrome determines the eventual snap target which can mean that we immediately dispatch a `scrollsnapchanging` event for the location the scroll will eventually land even if it will pass over the areas which would normally snap to other elements first. This was called out in the [Scroll Snap Events article](https://developer.chrome.com/blog/scroll-snap-events#does_not_fire_all_the_snap_targets_along_the_way_to_a_new_snap_target) and is illustrated by several of the demos such as the [scrollsnapchanging](https://developer.chrome.com/blog/scroll-snap-events#scrollsnapchanging) [visualizer demo](https://codepen.io/web-dot-dev/pen/jOjaaEP).

Note that the spec text does not seem to imply this behavior - since it says in the latter case referring to cases where it "might directly track a user's input (e.g. touch scrolling, scrollbar dragging)" that it is intended to use the **current** scroll offset, so it would seem that my desired outcome might match the spec but not chrome.

I think for cases where you have clicked on an anchor link and we are executing a smooth scroll to a predetermined location, using the eventual target is a better experience than flipping through all of the snap targets as they fly by ([demo](https://codepen.io/flackr/pen/zYVyvLp)), however, during a scroll interaction having the tracked item switch from on screen (while the finger is down) to the eventual target offscreen after you lift your finger and start a fling feels unintuitive to me (e.g. fling in the previous demo or this [ruler demo](https://codepen.io/web-dot-dev/pen/LYKOOpd) for a more obvious example where it feels unintuitive).

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


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

Received on Thursday, 5 September 2024 21:06:48 UTC