Anchor-based scrolling should be customizable like script-based scrolling is

[scottjehl]

We have an overflow region using snap points, and a separate list of links that can jump to various elements IDs within in that region, much like a common carousel with a thumbnail navigation.

Simply clicking a link to "#foo" will immediately jump-scroll to the element with an ID of foo as expected, but it would be nice if that jump was animated using the same easing as the snap points use while scrolling the region.

[tabatkins]

This is somewhere between a quality-of-implementation issue and something to do with a smooth-scroll CSS property. Neither of those have anything to do with scroll-snapping, however; as long as the endpoint is indeed a snap-point (or, if you're using proximity points, is far enough away that it doesn't need to snap), this spec has nothing to do with how you scroll between spots. (And no existing spec covers that either - the closest is the ScrollOptions argument to the explicit scroll*() APIs. We don't currently have controls for manipulating how "normal" scrolls work (like anchor-scrolling, which is a special-case of just dragging the scrollbar).

[jonjohnjohnson]

@tabatkins would it be out of scope to enforce/recommend that the timing functions used for "smooth" & "snap" scrolling be the same? As an example, in safari, I'd like to be able to use both to access this side menu... http://output.jsbin.com/xirowix

[tabatkins]

I'm not sure what you mean by that, and I don't have Safari available to view whatever you're attempting to show at the link.

[jonjohnjohnson]

Would it be within the groups authority to say that the timing (easing/linear) of how a link is scrolled to from scroll-behavior set to smooth be the same timing as how a snap position within a snapport scrolls?

[tabatkins]

We don't dictate how browsers should scroll between snap positions, tho; the only requirement is on where the scroll should end.

[jonjohnjohnson]

I know, as of now, that where a scroll ends is the only thing dictated. And sorry if I'm being bothersome here, but I'm not asking that the way scrolling behaves be dictated. I'm only asking if it would/could be beneficial that a browser scrolls with the same "easing" for snap scrolling and smooth scrolling. Also, the example link works in chrome canary, just not with as much grace. http://output.jsbin.com/xirowix

[tabatkins]

I'm still not sure what you mean by a "snap scroll". :( Snapping has nothing to do with determining how the scroll works; however you happen to do scrolling, scroll-snap just adjusts where the scroll is allowed to end. It's not an independent type of scrolling.

[jonjohnjohnson]

When I said "snap scroll", I meant that when I see how the scrolling behaves, in it's duration and timing function, it is different on release of the users gesture in how it "animates" to the snap position than how a scroll behaves in that same scrollport when programmatically manipulating the scroll position with "smooth" being set. Maybe I am seeing something, but it definitely doesn't offer the same scrolling feeling/visual, in chrome and firefox, and possibly safari, which supports scroll-snap but is currently implementing smooth scrolling behavior @fred-wang.

So it seems these two ways that the browser manipulates scrolling are handled independent in some ways. And my question is simply, would it be beneficial if those different browser scroll manipulations exhibit the same "feel". Not saying the spec should say that a scroll should take 200ms and use a quadratic ease in and out. Because I would like to be able to use both the features afforded by scroll-snap from a users scrolling as well as a programmatic scrollTo() method on the same scrollport, and give the user the same "feel" of the interface wether they scrolled or clicked a button.

My example, http://output.jsbin.com/xirowix, when viewed in chrome now, allows horizontal scrolling by the user to open and close a menu which will snap between end positions. It generally feels nice. But it also affords a click of the text "menu" to programmatically change the scroll position, and uses scroll-behavior: smooth, though the visual "feels" different to the degree that something feels off or possibly broken to the user.

There are independent scrolling mechanisms here, wondering if they shouldn't be noticeably independent. In at least chrome, firefox, and we'll see about safari. When building touch event versions of this type of ui, you surely make sure that draggin/scrolling will give the same "feel" as tapping http://output.jsbin.com/micaz/.

Here is a link to a video showing the differences -> http://cl.ly/1S0P472I203S

[inoas]

smooth scroll property is one thing that could take some more fine grained values but often the bigger issue is having overlay elements and wanting to have more control on relative positions to scroll to on anchor clicks. I spend literally 1 day or so with those issues lately.

As for smooth scroll I noticed with increased content height there should be ways to have fixed scrolling times and scrolling times relative to content height (and width for h-scrolling?)

[jonjohnjohnson]

@inoas Overlays? #2929 Relative position scrolls? #2428

I wouldn't guess the group needs to enforce strict scrolling durations between different scrolling lengths.

But I feel like I might be taking crazy pills if I'm the only one who sees the different scrolling effects (specifically timing function wise) in my example, between what happens after the users gesture to finish reaching the scroll snap point and the use of smooth when programmatically scrolling whether from a scrollTo method or scroll-behavior: smooth on a jumplink. And I think having browsers at least make those scrolling operations consistent would be worthwhile.

[tabatkins]

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.

[jonjohnjohnson]

@tabatkins thanks for taking the time to respond. And if the stance is to not suggest or dictate that browsers handle the scrolling the same between the two scenarios, that is ok by me, I'm just glad to be on the same page here and have an answer. Sorry that my language/examples weren't very self-explanatory. I didn't want to use the noun "scroll-snap" to confuse what is the module and properties, when I was talking about the scrolling function that happened on release of a scroll interaction in a snapport, so I said "snap scroll".

IMHO definitely think the smooth scrolling is not natural-looking for it's use case. Here is a link http://output.jsbin.com/micaz/ to a js implementation of what many native apps create for both "swiping" inertial movement as well as "tappable" execution of that movement. They both feel natural and they use the same/consistent "timing function". Try swiping (it uses hammer.js to consolidate pointers across envs) horizontally or vertically on the red block. Try tapping on the red block. This exhibits a different set of behaviors than the less idea inconsistencies from what we see in the native scrolling solution.

I'll bring this up to individual browsers, because from what I remember firefox uses quite a linear function for smooth scrolling and is the most "jarring" in this case. I'm only putting a dog in this fight because scrolling seems to be a more efficient alternative to transforms and custom scroll/touch event javascript for this type of ui. I think consistency would help us here.

Also, the original topic of this thread wasn't exactly where this ended, so I hope my derailing hasn't prematurely closed the issue, though I see the original topic as just as equally a no-go.