- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 13 May 2026 16:25:20 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-contain] `scroll-state(stuck)` CQs can easily cause flickering that is very hard to work around``. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> lea: similar in :hover it's usually an author mistake<br> <TabAtkins> lea: but here, i spent a few hours trying to work around it, and couldn't find a good one<br> <TabAtkins> lea: all the workarounds only somewhat work, or they fix in only one direction, etc<br> <flackr> q+<br> <kizu> q+<br> <TabAtkins> bramus: this def reminded me of :hover, but also scroll-driven animations<br> <TabAtkins> bramus: if your animation affects layout, it can change your animation progress<br> <TabAtkins> bramus: so this seems to be working as intended, stuff recalcs<br> <TabAtkins> bramus: Tab chimed in tho that there might be a spec fix<br> <lea> q?<br> <lea> scribe+<br> <lea> q+<br> <lea> TabAtkins: in Lea's case, turning off scroll anchoring helps, when it gets smaller it shifts up and we adjust the scroll position, disabling scroll anchoring does fix it for this particular case<br> <lea> TabAtkins: it doesn't fix it in general. E.g. if you move the headings to the bottom and have them be bottom sticky you get the same issue for the same reason and overflow-anchor won't fix it<br> <lea> TabAtkins: and that one is actually unsolvable, no way around it<br> <lea> TabAtkins: I don't know for sure how we want to solve this. My idea is similar to contain-intrinsic-size to have a "last remembered size"<br> <lea> TabAtkins: we can do something similar here in theory, have them remember their last geometry while they are stuck<br> <lea> TabAtkins: we just layout as normal and just project the new thing so you have no movement in the page when something becomes sticky<br> <lea> TabAtkins: because this is fundamentally a circular geometry problem<br> <lea> TabAtkins: don't see a way around it without it doing something like that<br> <astearns> ack flackr<br> <TabAtkins> flackr: i'm concerned about "last stuck size" being stale<br> <TabAtkins> flackr: if anything changes about the page while stuck, your unstuck bounds could be different<br> <lea> TabAtkins: I presumably would forget it if the containing block changes<br> <TabAtkins> flackr: one alt is to treat this like size cqs, where we force layout containment, so style change can't cause the layout change. but that makes it harder to do some of these use cases<br> <astearns> ack kizu<br> <TabAtkins> kizu: +1 to try and solve this. i hit this exact case<br> <TabAtkins> kizu: the workaround was solely to use transforms. pretty awkward but it works<br> <TabAtkins> kizu: if we were to solve it, containment woudl be one way. remembering previous size might be good to ahve in general, for other use-cases<br> <TabAtkins> kizu: various reasons to want to render something twice to compute some stuff<br> <TabAtkins> kizu: so there are many use-cases that could benefit from this idea<br> <astearns> q+<br> <miriam> q+<br> <TabAtkins> kizu: for this specific case, maybe containment would be a good thing to mention in the specs, at least<br> <TabAtkins> (size containment, in particular, being the most relevant one)<br> <TabAtkins> kizu: so you want a fixed heading, etc<br> <astearns> ack lea<br> <TabAtkins> lea: one thing i forgot to mention is a particular argument is "dont' do that"<br> <TabAtkins> lea: dont' think that's viable, so many use-cases want to affect the box model. basic common use-case is to make the element smaller and more discrete, now that it's taking up viewport space<br> <TabAtkins> lea: also block size containment is more diffficult for authors than inline<br> <TabAtkins> lea: unless maybe it's magic and only triggers when stuck, that's just what TAb is discussing<br> <TabAtkins> lea: also, it seems like stuck queries are on the stuck element, while the other queries are on the scroller<br> <bramus> Multiple elements can be stuck at the same time, though<br> <TabAtkins> lea: would it make sense to put the stuck query on the ancestor? then you could style the element itself that's stuck<br> <TabAtkins> yeah that's what i was gonna say too, doesn't work<br> <futhark> q+<br> <TabAtkins> astearns: we shoudl probably come u pwith something for this particular problem. wary of making a more general mechanism without motivating use-cases. not against it, it's just big and needs justification<br> <astearns> ack astearns<br> <astearns> ack miriam<br> <TabAtkins> miriam: i think i mostly agree with lea's points<br> <TabAtkins> miriam: to me it seems like more isolation/restrictions is more damaging to the use-cases than TAb's proposal of remembering unstuck size<br> <TabAtkins> miriam: that's probably what i expected the behavior to be, actually<br> <astearns> ack futhark<br> <TabAtkins> futhark: commenting on why we're querying the stuck element, not the scorller<br> <flackr> q+<br> <TabAtkins> futhark: you want to know which element is stuck, can have multiple<br> <TabAtkins> futhark: so what's causing the issue is that the layout changes and can affect the stickiness<br> <TabAtkins> futhark: so remembering the size so nothing changes does sound like a good thing<br> <astearns> ack flackr<br> <TabAtkins> (i propose we take back to the issue for details)<br> <TabAtkins> flackr: i am concerned that just "remember last size" is easily stale and has corner cases<br> <TabAtkins> flackr: if you change content, last size is now invalid<br> <TabAtkins> flackr: if you re-resolve, you have the double computation problem<br> <TabAtkins> flackr: for each sticky query you'd need to compute both stuck and unstuck size<br> <lea> Transforms are really not a good option here<br> <kizu> Certain authors will render two elements, hide one of them, measure it with SDA, and apply the value to an absolutely-positioned one, just saying :D<br> <TabAtkins> flackr: transforms are always okay because they dont' change the layout box. it's not you should never change the size, just you shoudl never change the layout constraints that make it stuck<br> <lea> Try to implement the example I sent with transforms<br> <TabAtkins> flackr: i'm inclined to say that some of these cases are dev error<br> <TabAtkins> flackr: i think the default scroll anchoring we're doing now is clearly wrong, maybe we can fix that<br> <smfr> q+<br> <astearns> ack smfr<br> <lea> q+<br> <TabAtkins> (i think fixing scroll-anchoring, to make the common top-stuck case work, is gonna be a nice 80% solution for now)<br> <lea> smfr: this was included in the OP as one of the workarounds<br> <bramus> (or a new `position: fixed-like-sticky` 😬<br> <TabAtkins> smfr: one way to fix is to put an element between the sticky and its contnets<br> <TabAtkins> smfr: fr4om the author, or a pseudo<br> <futhark> q+<br> <TabAtkins> smfr: and in the stuck state they could change the height of the wrapper...<br> <TabAtkins> smfr: maybe tricky with hit testing, etc. but a possibility<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <astearns> ack lea<br> <TabAtkins> lea: re: using transforms, if you do it in practice for the example i shaed, it doesn't really work<br> <ydaniv> what smfr suggested, like a pseudo layout box wrapper is very interesting!<br> <smfr> transforms will squish text<br> <astearns> kizu also said that transforms aren’t a great solution, I think<br> <kizu> I meant transform on an inner element, with the outer staying the same<br> <TabAtkins> lea: [lists squishy problems with transforms]<br> <TabAtkins> lea: the additional element solution (counting as removed height) is an example in the OP. there's downsides listed there<br> <TabAtkins> lea: it affects vertical space when scrolling back, hard to find a good height, have to set pointer-events:none, etc<br> <TabAtkins> lea: currently it also eats ::before/after<br> <TabAtkins> lea: and i push back on this being a dev error, i wrote a common case and then spent errors trying to fix<br> <TabAtkins> lea: in terms of "last remembered", wonder if it could help to specify what size is remembered... attach height to a name, use that explicitly<br> <TabAtkins> lea: might solve issues with us having to solve this implicitly<br> <kizu> `will-not-change: height padding`<br> <TabAtkins> futhark: similar concerns to Lea about wrapper elements<br> <TabAtkins> astearns: okay, take back to the issue. sounds like we want a solution to the problem<br> <TabAtkins> astearns: some concerns that a solution might have weird side effects, so let's work thru what we could possibly do.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13898#issuecomment-4443147937 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 13 May 2026 16:25:21 UTC