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.