[csswg-drafts] scroll snap duration (#11880)

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

== scroll snap duration ==
I'm facing the problem that scroll snapping in practice potentially takes "forever" to finish for certain scenarios and I think the CSS spec should provide a solution to it.

From the spec (CSS Scroll Snap Module Level 1):

    The CSS Scroll Snap Module intentionally does not specify nor mandate any precise animations or physics used to enforce snap positions; this is left up to the user agent.

Now, consider the following:

Given the way browsers currently implement smooth scrolling and snapping, it takes about 1 to 1.5 seconds on a mobile device for a full page scroll snap along the longer axis, depending on browser and size/distance. Any scroll gesture that is made after an initial scroll, before the browser finished the current one, behaves as a "continuation" of it. This forces the user to wait for up to those 1.5 seconds, before one can interact with another scroll port, specifically a nested/overlapping one. Said differently: A browser will only scroll one port at a time and won't cancel an ongoing scroll for another one.

Nested scroll ports don't seem like an unusual design pattern. Imagine a series of viewport filling carousels (with different numbers of items, not a grid). Now imagine having to wait for 1.5 seconds each time you're moving from one carousel to another.

Plus, **there is no reliable workaround**, since, especially on mobile, scrolling triggers effects that users may rely on and can not be implemented in JS (showing/hiding browser UI - which in turn get's not only triggered by scroll, but also page life cycle events etc.). Even without these effects, since scroll events can't be canceled, the only workaround would be to fully implement a custom scroll/swipe snap solution, starting from scroll detection and potentially also page lifecycle state.

Maybe related: https://github.com/w3c/csswg-drafts/issues/11096 - since a predefined duration would practically mean some sort of animation or transition, instead of dynamics/physics - but personally I only care about the "fast enough" for acceptable UX here, not the how.


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


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

Received on Sunday, 9 March 2025 22:35:23 UTC