[csswg-drafts] [css-scroll-snap-1] re-snapping after layout with animations (#4609)

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

== [css-scroll-snap-1] re-snapping after layout with animations ==
## Context 
The specification requires the browsers to re-snap after any content/layout changes. It also prefers re-snapping to the same element as before but if that element never existed or no longer exists then snapping to a new element is done.

We have been implementing this in Chrome and noticed an interesting implication of this: if one adds a single snap area to an existing snap container with no snap area, the container has to snap to the area. 

This introduces an interesting new way to do "scroll-into-view" effects using only css. For example see this [demo](https://snap.glitch.me/scroll-to-snap.html) where I make the `:active` element to be a snap area which forces its ancestor scroller to re-snap which centers the element. I think this is interesting usecase of scroll-snap. However one limitation of this is that at the moment these re-snapping effects are not necessarily animated so the re-snap is jarring. Also webdevs don't have any control on such animations if we add them. I like to see if we can rectify this by making it animated but also exposing more control over such snap animations to web-devs.

## Current Chrome Behavior

In Chrome we have decided to not animate layout-induced re-snapping in general. I think this makes sense in most re-snapping cases where we are *re-snapping to the same element* and the scroll snapping effect should not really be noticed by the user.  But when we are *re-snapping to a different element* I think we should consider allowing animations.

The specification leaves it up to user agent whether to animate or not animate any particular snap operations. So we could just animate these in Chrome and I plan to experiment with this. At the same time I think it makes sense to give web authors control on the animation aspect of scroll-snapping since in some usecases they may not want any animations. Below I suggest one proposal to do this.

## Proposal

We already have [scroll-behavior](https://drafts.csswg.org/cssom-view/#propdef-scroll-behavior) to control programmatic scroll animations. So a simple solution is to have its definition expanded to control any scroll snap animation as a result of  CSSOM scrolling APIs or *re-snapping*.

So the proposal suggestion has two parts:

A) Continue to leave animation decision up to user-agent but add a note that suggest user agent should consider animating when re-snap to different element.

B) Specify that `scroll-behavior` controls any scroll-snap animations that are not initiated by user. (This includes any CSSOM scrolling APIs that snap which I think they already did, and more importantly any animations that is introduced due to re-snapping)

Here is btw is the current wording for `scroll-behavior`:

> The scroll-behavior property specifies the scrolling behavior for a scrolling box, when scrolling happens due to navigation or CSSOM scrolling APIs. Any other scrolls, e.g. those that are performed by the user, are not affected by this property. When this property is specified on the root element, it applies to the viewport instead.







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

Received on Monday, 16 December 2019 20:26:12 UTC