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

The CSS Working Group just discussed `re-snapping after layout with animations`, and agreed to the following:

* `RESOLVED: Require smooth scrolling behavior when there is a new snap, but let UA decide when it's re-snapping to the same element.`

<details><summary>The full IRC log of that discussion</summary>
&lt;heycam> Topic: re-snapping after layout with animations<br>
&lt;heycam> github: https://github.com/w3c/csswg-drafts/issues/4609<br>
&lt;heycam> fantasai: re-snapping can be triggered in different cases<br>
&lt;heycam> ... if you're snapped to an element, and the layout change<br>
&lt;heycam> ... another one is a new snap position exists, or now you're in range of a snap position and you weren't before<br>
&lt;heycam> ... scrolling is sometimes animated, sometimes not<br>
&lt;heycam> ... there's a scroll-beahvior property that controls programmatic scroll animations<br>
&lt;heycam> ... majid is saying that the scroll-behavior should probably also control the prgorammatic scroll behavior that's triggered by scroll snapping<br>
&lt;heycam> ... and you might want to treat re-snapping to same elemetn differently from "not snapped, but not you're going to snap"<br>
&lt;heycam> ... one proposal is to define that the snapped to a new element case be treated scrolling wise as the same as scrollIntoView() or focus()<br>
&lt;heycam> ... and then therefore define that this should be subject to scroll-behavior<br>
&lt;heycam> .. .the other thing w could do is to allow the UA do something different for the re-snap case<br>
&lt;heycam> ... but in the case where you weren't snapped before, those cases should be animated in the same way scrollIntoView animates, and thus be subject to scroll-behavior<br>
&lt;heycam> myles: why standardize this at all? why not say nothing?<br>
&lt;heycam> TabAtkins: because Majid finds that the smooth scrolling behavior for the new snap position seems reasonable for the author to want to depend on<br>
&lt;heycam> ... for the same reason scrolling to random things from JS be guaranteed smooth<br>
&lt;heycam> fantasai: also clarifies interaction with scroll-behaviior<br>
&lt;heycam> myles: how about the re-snapping behavior?<br>
&lt;heycam> fantasai: I think we want to say something about it to make sure it's seen as distinct<br>
&lt;heycam> ... we need to distinguish the re-snap case to be UA dependent so that scroll-behavior is not required to affect it<br>
&lt;tantek_> as a user I may want a more responsive UI and set all the scroll behaviors to 'instant'<br>
&lt;tantek_> like I want a way to turn-off cheesy animations<br>
&lt;heycam> fantasai: don't feel the need to require not animating in that case, but should suggest it's possible<br>
&lt;heycam> ... the goal of this re-snapping is to make the user feel that the layout changed but I didn't scroll<br>
&lt;heycam> ... you don't want to animate to get back to where you were<br>
&lt;heycam> myles: I think it depends how much of the viewport space the element takes up<br>
&lt;heycam> ... if it's a small element, having most of what the user see jump to a different position would look jarring, but if the element covers most of the viewport, then jumping makes more sense<br>
&lt;heycam> TabAtkins: that's reaosnable<br>
&lt;heycam> ... as long as we distinguish it so that these cases are separate<br>
&lt;fantasai> s/more sense/more sense. So would prefer may rather than should/<br>
&lt;heycam> RESOLVED: Require smooth scrolling behavior when there is a new snap, but let UA decide when it's re-snapping to the same element.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4609#issuecomment-577230692 using your GitHub account

Received on Wednesday, 22 January 2020 15:08:30 UTC