- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Wed, 11 Nov 2020 23:29:16 +0000
- To: public-css-archive@w3.org
Yeah, this is all about overlarge-area snapping, and it makes a ton of sense; our current behavior, I'd argue, is pretty hostile. Maybe we should just make it *always* the behavior for overlarge elements, rather than forcing people to recognize when it might matter and remember to apply the nearest-edge value? (And part of the reason for the overlarge-area behavior is precisely because authors *can't* always predict whether an element will be larger than the viewport or not.) I also think that we *don't* have a good reason to want the "nearest-edge" behavior for *non*-overly-large elements. If a small element was given "scroll-snap-align: nearest-edge", then it would snap its top edge to the top of the screen *and* its bottom edge to the bottom fo the screen, and I think that's usually not what's doing to be desired here. ---- As an aside, @majid, the codepen in the OP is showing off some examples that are actually trapping my arrow-based scrolls at times. In particular, the first example reproducibly traps me on element 2 when I'm arrow-scrolling down to it; I can arrow back up, but can't arrow down any further until I adjust the scroll some other way first, like clicking down on my scroll wheel. PgDn scrolling continues to work, tho. I get similar trapping on the sideways examples, tho for some of them its element 3 that traps me. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5123#issuecomment-725720288 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 23:29:18 UTC