- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Mon, 16 Aug 2021 19:32:21 +0000
- To: public-css-archive@w3.org
Talked with @argyleink, @una, and @flackr today about this again. While the cyclic-ness is somewhat problematic, all the attempts to get around it are doing more harm to the proposal than good, I believe. Plus, @scroll-timeline *also* has closely-related issues. Ultimately, it's *tight* cycles (within the layout engine) that are a strict no-go; we want to *avoid* cycles that are loose enough to span a painting frame, like what `:hover` does today, but they're just *annoying* but not *killer*. So, I think we can deal with this entire bag of scrolling-related pseudos and styling by saying, essentially, that scrolling is snapshotted at the start of styling, stuck-ness or snapped-ness (or progress on a scroll timeline) is determined at that time, and then selectors are matched and styling is applied. If you do something that causes a stuck/snapped element to become unstuck/snapped, it'll show up next frame, but not affect selector resolution this frame. (To avoid a "flash of unsnapped content" effect, we can probably specify that the *first* frame does a style to figure out what is possible to stick/snap, *then* does another style to resolve the pseudos appropriately.) At worst, then, you can produce a `:hover`-equivalent cycle, which is annoying but something we can deal with. The vast majority of ordinary usage will work exactly as expected with no problems, just as usage of `:hover` is almost always okay today. @flackr believes this is fine implementation-wise. Thoughts? -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5979#issuecomment-899765136 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 16 August 2021 19:32:23 UTC