Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

scroll snap duration #11880

Open
valler opened this issue Mar 9, 2025 · 0 comments
Open

scroll snap duration #11880

valler opened this issue Mar 9, 2025 · 0 comments

Comments

@valler
Copy link

valler commented Mar 9, 2025

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: #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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant