W3C home > Mailing lists > Public > public-css-archive@w3.org > August 2020

Re: [csswg-drafts] [css-scroll-snap] More granular control over scroll-snap-stop (#5467)

From: Johannes Odland via GitHub <sysbot+gh@w3.org>
Date: Mon, 31 Aug 2020 08:51:23 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-683653544-1598863881-sysbot+gh@w3.org>
I've built two code pen examples to illustrate the current behaviour as a starting point for the discussion. 

In these examples we use CSS Scroll Snap for "full page" scroll snapping. Each element have a height of 100vh and are of equal importance.

**scroll-snap-stop: normal;**

When set to `normal` it is easy for the user to "overshoot" when scrolling (At least in some UA implementations). The user might scroll past a few snap positions when trying to scroll to the next. On the plus side, it is easy to scroll through the container to snap points further down.

We've received feedback from users not feeling in control. 


**scroll-snap-stop: always;**

When set to `always` it is impossible to "overshoot". Scrolling stops at the snap-point. It is however difficult to scroll fast to a snap point later in the scroll container. The user has to scroll through each snap point, which can be tedious.


With the current spec authors are left to choose between two extremes with their respective tradeoffs. With `normal` it is easy to overshoot when scrolling (depending on UA implementation). With `always` it is tedious to scroll through many snap points. 

If we use physics to illustrate, we can say that the scrolling content has momentum, and that each snap point exerts a force on the content. Snap points with `normal` have a weak force that is easy to scroll by, and snap points with scroll-snap: `always` have a strong force. 

Could there be a way to give authors more granular control over how strongly the content snaps?

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

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 31 August 2020 08:51:24 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:13 UTC