- From: Guido Bouman via GitHub <sysbot+gh@w3.org>
- Date: Mon, 16 Nov 2020 15:50:07 +0000
- To: public-css-archive@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