Re: [csswg-drafts] [css-contain] `scroll-state(stuck)` CQs can easily cause flickering that is very hard to work around (#13898)

> You're right that this is a core use-case. I'm curious how we haven't heard more complaints about it! (I'm pinging internally to make sure I'm not missing some easy solution that people are already using.)

If we're not missing some easy solution, I'd wager it's a combination of: (a) the feature is very new and (b) the issue is only noticeable in some cases, when scrolling relatively slowly. It seems it's _particularly bad_ with `font-size` and `padding-block`, e.g. [`border-bottom` seems to work fine even when substantial](https://codepen.io/leaverou/pen/ogYLZwX).

> Assuming we're not missing anything, though, I think the only solution is to go in the same direction as [`contain-intrinsic-size:auto`](https://drafts.csswg.org/css-sizing-4/#last-remembered) and give an element the ability to have a "last remembered unstuck size", and use _that_ size for its static geometry when it becomes stuck (while still laying out normally for the purpose of its shifted paint).

I think that makes sense. Then we could even have `cq*` units refer to _that_ size.

But if we do that, doesn't that address the circularity that forced us to use a CQ in the first place? Then we could even give authors the `:stuck` pseudo-class they _actually_ want…

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


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

Received on Monday, 11 May 2026 23:34:03 UTC