Re: [csswg-drafts] [css-scroll-snap] Proposing `:snapped`: exposing private snapped item browser state for developers and designers (#6985)

I think there's no question that it'd be useful. The question, to me, is all about feasibility.

From the explainer:

> We are OK letting :snapped cycle like :hover, as long as it's only once per lifecycle update. We believe developers will be responsible with this, as they have with :hover.

What does that mean exactly? I suppose (especially given that @tabatkins is a co-author) that you're aware of https://wiki.csswg.org/faq#selectors-that-depend-on-layout

The `:hover` loop goes through hit-testing, and thus skipping hit-testing on relayout and waiting for most movement solves it. In particular, you don't particularly have to care that the loop is or isn't caused by using `:hover` itself. Just skip hit-testing in general when doing relayout, and you're good. Actual implementations may be more subtle, but conceptually that's sufficient, and not a source of meaningful breakage.

But snapping loops don't go through hit testing, so the thing you'd have to skip would be something else.

I presume you mean that you wouldn't resnap based on relayout, but that seems bad, at least in general. It would solve the problem, but cause other breakage.

```css
.container { scroll-snap-type: block mandatory; }
:snapped { scroll-snap-align: none; }
```

(Note: I think scrolling isn't clearly defined either as part of layout, nor as not being part of layout. Even if it isn't, the same problem with actual relayout can be created by adding something like `:snapped { margin-top: 1px; }` to the previous example.)

Without mitigation, this would generate a weird oscillating layout, when you're forced snap to something, thus making it not a snap-point, thus jump to another one (because in mandatory snapping, you always have to snap to something), and repeat.

This loop could be interrupted by just not doing snapping on re-layout and only making it kick in if there's some user interaction, but that's very explicitly against the spec (see https://drafts.csswg.org/css-scroll-snap/#re-snap), and for good reasons.

So we'd need a narrower condition for breaking the loop at one iteration. You seem to think it's doable, but it's not obvious to me how. Could you provide more details? (Also, does your answer also work for a hypothetical `:stuck` pseudo relating to `position: sticky`, as discussed in the FAQ?)

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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 31 January 2022 04:08:48 UTC