- From: Johannes Odland via GitHub <sysbot+gh@w3.org>
- Date: Tue, 08 Sep 2020 07:08:12 +0000
- To: public-css-archive@w3.org
> I get the point now. So the request is to make the snap positions "stickier" than `normal` but not enforce to stop at them like `always` does. That's the idea. I'm not sure it's possible to do the way scroll snapping is specified, but giving authors _some_ more control would go a long way. > One thing to note here is that the spec. currently leaves the definition of the snapping mechanics undefined, meaning that UAs can implement different behaviours for the `normal` value. So it might rather be an implementation issue you're facing. It might be an implementation issue, but as the snapping mechanics are left undefined it is hard to say. It seems like the UA in the example video uses low friction for the fling, causing the natural end-point to be several pages down, past many snap points. It then follows the spec and chooses a snap point to minimize the distance between the snap point and the natural end-point. This seems correct according to the spec, but the result is that the user overshoots and does not feel in control. > I think the question here is whether you just want `normal` to be stickier or if there are use cases in which you'd want some scroll snap areas to be stickier than others (but not force snapping to happen). In the current case it would help if it was possible to make every scroll snap area stickier (increase friction for the whole scroll container). The goal is to make it easy for the user to scroll "page by page" or "scroll area by scroll area" while still being able to scroll fast through the content if needed. I can definitely see use cases where making some scroll snap areas, such as the beginning of a section, be stickier than others while not forcing snapping to happen. -- GitHub Notification of comment by johannesodland Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5467#issuecomment-688665866 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 8 September 2020 07:08:19 UTC