Re: [csswg-drafts] Anchor-based scrolling should be customizable like script-based scrolling is

Ah, I see what you're saying now. I didn't realize I had to swipe and click the bottom button; the example wasn't very self-explanatory. ^_^

So the difference here is *mainly* because the swiping scroll that ends on a snap point (what you're calling a "snap scroll") is *started* with the momentum of the swipe itself; this momentum is then decayed at a special controlled rate to make the swipe end right at the snap point.  The "smooth" scroll from pressing the button doesn't have any momentum information from the user, so it just uses whatever curve the browser defaults to for doing smooth scrolling.

These are two fundamentally different things, with different starting points.  If you swipe with different speeds, you'll see the animation play out slightly differently.

There is a *bit* of "gratuitous" difference that's not strictly necessary; the swiped animation does an exponential-ish decay to adjust the swiped momentum so it lands in the correct place; this is because the math ends up easy if you do that.  The smooth-scroll is using some built-in velocity curve that does not have the same shape as an exponential decay; I'm not experienced enough to recognize the curve on sight, but I suspect it's just an ease-in-out or something.  This is *also* because the math is easy that way; the velocity just falls out of the curve and is appropriate regardless of how far it needs to scroll. (Or I think I recall that they might bezier-curve up to some max velocity over a certain time, then scroll at that speed until near the end, when they bezier-curve back down. Still a matter of making things easier to compute.)

In addition to the math being easier in each instance, it's just more *natural-looking* in each case. The exponential-decay of a swipe scroll "feels" like friction slowing it to a stop, which plays well with our physical intuitions around swiping.  The bezier-timing-function approach of smooth scrolling gives you a small noticeable ramp-up and ramp-down that doesn't distract or feel "slow", but still lets you know a scroll is happening; it wouldn't look or feel the same if they simulated a sudden touch-less momentum fling, which starts very abruptly, or did an exponential ramp-up, which feels slow. 

This is why we allow a lot of freedom in how browsers do scrolling, because it's a complicated UI problem.  You're free to raise these sort of user-experience issues to the individual browsers, suggesting that they do something to make these two experiences feel a little more consistent, but we're unlikely to mandate anything at the spec level for this.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/157#issuecomment-411118250 using your GitHub account

Received on Tuesday, 7 August 2018 16:27:18 UTC