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: Guido Bouman via GitHub <sysbot+gh@w3.org>
Date: Mon, 16 Nov 2020 15:50:07 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-728147866-1605541805-sysbot+gh@w3.org>
To snap to the "nearest" or "first" edge for larger-than-viewport elements by default makes a lot of sense, if we ignore backwards compatibility. Except, this falls apart when an author provides `scroll-snap-align: end;`, what would happen then? Would `scroll-snap-align` just cease to work for those elements?

Take the most explicit values from my proposed solution: `scroll-direction-start` & `scroll-direction-end`. I can imagine a sticky header or sticky footer, depending on the direction you scroll in. Even when the elements are smaller than the viewport, the possible values still make sense.

To come back to @majido's comments:
- I think the last detected scroll direction (swipe gesture on touchpad, keyboard keys, computation scroll etc.) should be leading for this behaviour.
- And regarding the cache: As we're in a 2D space, the problem space is finite. There are two (probably precomputed) sets of possible options to switch between when the scroll direction changes. I don't think that will be the biggest performance implication, right?

---

About the aside:
The codepen examples are native scroll-snap implementations. I think an arrow navigation trap should not be intended. Browser (Chromium?) bug?



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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 16 November 2020 15:50:08 UTC

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