[css-scroll-snap] Allow control over snap smoothness for art-direction

[johannesodland]

The scroll snap module does not specify the physics or animations used when enforcing snap positions. This is intentionally left for the UA to decide. (https://drafts.csswg.org/css-scroll-snap-1/)

The snapping experience then differs between browsers. Full screen snapping (i.e. https://www.nrk.no/hvis-insektene-forsvinner-1.15029017) feels slow and smooth in desktop Chrome, while it snaps hard and fast in iOS Safari.

Content creators would benefit from more control over the snapping experience. Some content would benefit from sharp and hard snaps, while some content would benefit from smoother and slower animations.

Could more control be exposed through a property such as scroll-snap-smoothness?

[tabatkins]

Not letting authors control the scrolling/snapping behavior is currently an intentional choice in the spec - having pages scroll with different physics on a single device is often very disorienting for users. (This is one of the reasons why we did scroll-snap in the first place: so authors would stop using custom-scroll JS to get this behavior, and unwittingly give users unfamiliar scrolling physics!)

Can you elaborate on what sort of content-based distinction you're thinking of? I think it would need to be a pretty important distinction to override the user-based restrictions we currently specify.

[johannesodland]

I support the intentions of the spec. Leaving the scroll snapping implementation to the browser yields a far better experience. Implementing a good scroll snapping experience in JS taking into account all the different systems and devices is all but impossible. This is the very reason that we now use CSS scroll snap.

Even though the scroll snapping implementation now is left to the UA, some parameters are exposed to authors. The spec already exposes parameters such as alignment and type.

I think it is worth exploring whether more parameters could be exposed to give authors more control over the user experience, in particular the "smoothness" (for lack of a better word).

I have created a code pen to illustrate: https://codepen.io/johannesodland/pen/abNyvZV

The code-pen contains a scroll container with 5 sections. When the user scrolls and releases, browsers implement snapping very differently. Below is a screen recording of the same test page in two browsers on the same operating system. I scroll to the middle of the next section and then 'release':

One browser snaps into place in less than 100ms, while one use more than 660ms. This constitutes a very different feeling.

Where authors would fine tune transition easing and timing to get the right feeling, they have no way to control timing aspects of scroll snapping.

A common feedback when using scroll snapping (particularly for large containers) is that it doesn't feel right. That the "animation" is too fast or too slow depending on the system and browser that is used.

I don't have any solutions, but I wish we could explore if it's possible to leave some control to authors. The smoothness, the underlying easing and timing are essential to the feeling and to the user experience.

[guidobouman]

Okay, let's take the perspective from a user: Persona #1: Has always used apple devices, no external devices, and uses Safari as its browser of choice. Persona #2: Windows user, uses a mouse, uses Chrome and / or Internet Explorer, not knowing the difference.

What would the experience for both users be when they use your site vs any other website or scrolling application on their platform?

The current setup lets persona #1 have the same scroll (touchscreen and touchpad) experience regardless of device, application or website. While persona #2 has the same experience with his mouse in either browser.

This all starts to fall apart when you modify scroll behaviour for your website or application. It goes directly against Apple (and any other platform for that matter) UX guidelines.

[johannesodland]

Sorry for the late answer.

I see the argument, and agree with the Priority of Constituencies. You might be right.

[brunostasse]

I think there are two elements which define the snapping mechanism: the easing curve and the duration of the snap, a bit like with CSS transitions (although this is probably much more complex here because it has to take into account the momentum due to the scroll gesture).

While it makes sense to allow browsers and OSs to have a specific easing curve which one shouldn't be able to opt out of, I don't think it makes sense for the duration of the snap. The "snap" effect is used in a lot of situations on mobile OSs, and the snap feeling is not always the same, because depending on the context it needs to be different.

I have two situations in mind:

• On iOS, on the home screen, the snapping between the different panels is quite fast, which allow to interact quickly with the panel after the snap; this is the same on macOS when switching between spaces.
• On iOS, in the Apple Store app (an official Apple app), there is a carousel with your apple devices, and the snapping there is slower, and feels smoother. This is the same in a lot of other apps, like the carousel in the Facebook app.

So we see different snapping mechanism on the same OS in native apps, and in the meantime with CSS scroll-snap we only have one mechanism, which vary in feeling between browsers and OSs, and therefore creates inconsistent experiences, and prevents certain use cases.

If we can't have control over the easing curve, I think we should have some over the duration, and at least be offered choices, consistent across browsers and OSs.

[johannesodland]

See also https://github.com/w3c/csswg-drafts/issues/8549