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

Re: [csswg-drafts] [css-scroll-snap] Snap direction needed for snap-overflow (#5123)

From: Majid Valipour via GitHub <sysbot+gh@w3.org>
Date: Wed, 11 Nov 2020 21:52:35 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-725681586-1605131554-sysbot+gh@w3.org>
/cc @flackr 

I don't fully understand how this relates to "larger than the viewport".

> To clarify, I would like to:
> * Snap to top when a user scrolls down
> * Snap to bottom to user scroll up

So if I read this correctly the desire is to have more control over which snap alignment the browser selects. In particular, you want to ensure the alignment in the direction of user scroll is selected (or preferred?).

That is a reasonable thing to have IMO.

Some notes:
 -  I don't think this maps to the `nearest-edge` as @fantasai  is suggesting. It is more like `edge-in-the-scroll-direction`
 - The term scroll direction is fuzzy. For example what is the scroll direction if user scroll down a lot and up a little bit in the same gesture? Chromium has some heuristic to infer a direction but not every scroll gesture has a direction. So I take it you want these new behavior to apply to gesture with direction.
 - FWIW, in chromium we do prefer the snap point in the scroll direction for subset of scroll gestures (those with clear direction) but there may be bugs and does not apply if we don't consider it directional. ([details](https://source.chromium.org/chromium/chromium/src/+/master:cc/input/snap_selection_strategy.h;l=142))
 - This is minor but in my mind this falls more into [6.2 choosing snap position](https://drafts.csswg.org/css-scroll-snap/#choosing). In that we have a **preference** for a particular selection as opposed to restricting **valid** snap positions. My mental model has been that `scroll-snap-align` defined what is valid. So it feels to me that we should not use `scroll-snap-align` property and instead add a new one similar to what we did with `scroll-snap-stop`.
 - Also what is considered *valid* snap position currently does not depend on scroll gesture which means it can be pre-calculated and cached to be used across multiple scroll gesture (which Chromium does). At the moment only the position selection algorithm depends on the particular scroll gesture (position, direction etc.). I think we should keep it that way


In any case flackr@ is the right person to look into this and give further implementation advice from Chromium side.

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

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 11 November 2020 21:52:37 UTC

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