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

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, 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

Here is a link to a video showing the differences ->

GitHub Notification of comment by jonjohnjohnson
Please view or discuss this issue at using your GitHub account

Received on Tuesday, 7 August 2018 01:36:00 UTC