- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 02 Apr 2026 17:08:09 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-2] scoped VT: we should apply content-visibility: hidden for the duration of capture`. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> vmpstr: for scoped vt, there's a state between starting a transition and when the callback is finished running, where we "freeze the rendering"<br> <TabAtkins> vmpstr: for any VT we dont' update the visual state, scoped just is a bit different because the rest of the page is still updating<br> <TabAtkins> vmpstr: we want to minimize element size changes<br> <TabAtkins> vmpstr: meaning we dont' want to gutter or clip the frozen paint when possible<br> <TabAtkins> vmpstr: one way to make that happens is c-v:hidden, maybe with c-i-s:auto<br> <TabAtkins> vmpstr: so the contents can change without moving the box<br> <TabAtkins> vmpstr: this would just be for the duration of this frozen-paint state<br> <TabAtkins> vmpstr: probably also more performance as you can skip layout in the subtree<br> <TabAtkins> astearns: wondering about side effects we ahven't considered in applying these<br> <TabAtkins> astearns: wonder if applying these automatically will change the rendering in a way the author didnt' expect<br> <TabAtkins> vmpstr: it's a state where visually we display the last visuals of the element, at the time you call sVT()<br> <TabAtkins> vmpstr: the author may change the contents of the element and we're waiting for them to finish<br> <TabAtkins> vmpstr: so I think the ship of visual changes has sailed<br> <TabAtkins> vmpstr: might as well just keep the size the same as what it was<br> <emilio> q+<br> <TabAtkins> TabAtkins: only thing I can think of is child margins escaping the element, now blocked. is that already prevented?<br> <astearns> ack emilio<br> <TabAtkins> vmpstr: good q will check<br> <TabAtkins> emilio: the VT starting already forces a lot of containment, probably okay<br> <TabAtkins> emilio: c-i-s:auto doesn't that require c-v:auto anyway?<br> <TabAtkins> vmpstr: I think you're right. I think we can say it's effectively what the auto size would be.<br> <TabAtkins> vmpstr: you just get size containment and we want to make sure it doesn't collapse the element to zero size<br> <TabAtkins> vmpstr: maybe details as described aren't quite right<br> <TabAtkins> emilio: yeah I get the spirit<br> <TabAtkins> emilio: again, doing it by changing computed values is weird. maybe should just say it's magic<br> <TabAtkins> TabAtkins: think magic is fine here<br> <astearns> +1 to describing the effect outside setting computed values<br> <TabAtkins> emilio: don't think you need c-v:hidden in the spec<br> <TabAtkins> emilio: can just say "apply size containment with size fo X" found at capture time<br> <TabAtkins> vmpstr: so the effects of these properties, without these properties<br> <TabAtkins> emilio: yeah, c-v has other side effects, it pauses animations etc<br> <TabAtkins> astearns: so just describe what you need rather than abstracting by using property values<br> <TabAtkins> emilio: yeah like probably don';t want to make web-observable animation changes, etc<br> <TabAtkins> vmpstr: my worry is, we want the optimization of not updating the rendering in the subtree, and we've already done that work in c-v:hidden, don't want to pick and choose effects to apply. might be subtle reasons c-v:hidden is doing that<br> <TabAtkins> emilio: sure... thought you were mainly just looking to not collapse the element<br> <TabAtkins> vmpstr: yes primary, but secondary is perf, don't want to downplay it<br> <TabAtkins> emilio: hm then I think it's more complicated<br> <TabAtkins> emilio: guess we need to look at c-v:hidden and see if you're fine with all the effects it triggers<br> <TabAtkins> emilio: like firing animations events due to the animations stopping would be confusing<br> <TabAtkins> vmpstr: happy to go back to the issue and audit c-v:hidden precisely<br> <TabAtkins> vmpstr: i'll bring that back next time<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13428#issuecomment-4179236811 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 2 April 2026 17:08:10 UTC