- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 15 Jul 2026 16:33:51 +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`, and agreed to the following: * ``RESOLVED: Behave as `contain: size` + `contain-intrinsic-size: auto` for the duration of scoped view transition capture + change callback`` <details><summary>The full IRC log of that discussion</summary> <emilio> vmpstr: we initially proposed to add `content-visibility: hidden` for the view transition capture<br> <emilio> ... emilio raised some issues<br> <emilio> ... did some research, for the most part I think everything is fine except the accessibility tree would be removed<br> <emilio> ... I'd like to change the proposal to instead say that we apply `content-visibility: auto` except we also consider that element to be offscreen<br> <emilio> ... which means it'll remain in the a11y tree, we can apply `contain-intrinsic-size: auto`<br> <emilio> ... and that's about it, everything else that `content-visibility: auto` would do seems fine<br> <emilio> q+<br> <emilio> astearns: how long does the capture frame take?<br> <another-astearns> ack fantasai<br> <emilio> vmpstr: the dom callback is async but the capture is a frame or two<br> <flackr> q+<br> <emilio> vmpstr: typical case would be 16/30ms<br> <another-astearns> ack emilio<br> <fantasai> emilio: Can you remind me why do we want to do this?<br> <fantasai> ... If it's just to prevent authoring mistakes with the DOM changes, that's fine maybe<br> <fantasai> ... But it feels both pretty special-casey, and, the content-visiblity: auto behavior seems weird<br> <fantasai> ... If you transition something where you have [?] suddenly it feels really different<br> <fantasai> ... That doesn't seem uncommon to do<br> <emilio> vmpstr: the intent is to prevent size / layout changes of partial updates to be visible outside of the participating scope<br> <emilio> ... if your callback changes the size of some element inside it'll affect content outside<br> <emilio> ... you're right that focus would make the behavior different<br> <fantasai> emilio: In DOM callback, you make a bunch of DOM mutations that trigger relayout outside your subtree<br> <fantasai> ... I thought ?? would take care of it?<br> <fantasai> [missed]<br> <another-astearns> s/??/contain:size/<br> <fantasai> emilio: Seems like something like contain:size would be needed<br> <fantasai> ??: You can definitely contain the intrinsic size with contain-intrinsic-size: auto;<br> <emilio> vmpstr: I think you definitely can apply contain: size with contain-intrinsic-size: auto<br> <emilio> chrishtr: doesn't that amount to the same thing as content-visibility: auto?<br> <fantasai> chrishtr: content-visibility: auto would take care of it, the point is to avoid doing layout<br> <emilio> vmpstr: the exception is that you can apply that regardless of content-visibility: auto<br> <emilio> flackr: if it's focused you don't want to start changing size<br> <emilio> vmpstr: the unfortunate thing is you don't get the optimizations of not doing rendering<br> <emilio> chrishtr: the proposal is to apply contain: size even if it had these overrides<br> <emilio> vmpstr: so both contain-intrinsic-size: auto + contain: size<br> <emilio> flackr: visually content is not going to change until v-t starts?<br> <emilio> vmpstr: right<br> <emilio> chrishtr: if we do these two things then we can do these optimizations?<br> <emilio> vmpstr: there's implications for animations starting or not starting<br> <astearns> q+<br> <emilio> ... the reason I wanted content-visibility is that if you want the rendering optimizations there's a bunch of the small things you need to consider<br> <emilio> ... you'd need to consider all the same cases as content-visiblity<br> <emilio> ... I'd like contain: size, but I don't think it'd be possible to do the optimizations then<br> <emilio> chrishtr: but doesn't that amount to content-visibility: hidden then?<br> <emilio> vmpstr: no, because the content would remain in the a11y tree<br> <emilio> ack flackr<br> <emilio> ack astearns<br> <emilio> astearns: since we don't have exactly the switch you need... can we define this as "this is what should happen in this duration"<br> <emilio> ... don't try to express it as css<br> <emilio> q+<br> <emilio> ... I think we're going to play whack-a-mole for this weird case<br> <emilio> vmpstr: I think we can start with `contain: size` + `contain-intrinsic-size: auto`<br> <flackr> +1<br> <emilio> ... that'd solve the immediate problem, then revise if we need rendering optimizations<br> <astearns> ack emilio<br> <emilio> +1 to vmpstr, it seems content-visibility: auto would have some side effects that might be hard to reason about<br> <emilio> PROPOSED: Use `contain: size` + `contain-intrinsic-size: auto` for the duration of scoped view transition capture + change callback<br> <emilio> chrishtr: and we'll come back to the group if we missed something?<br> <emilio> vmpstr: we need to do those for sure, we might need other stuff for rendering optimizations<br> <emilio> vmpstr: do we plan to do this via magic rather than changing the computed style right?<br> <emilio> emilio: we have some magic that changes `contain`s used value so seems ok<br> <emilio> PROPOSED: Behave as `contain: size` + `contain-intrinsic-size: auto` for the duration of scoped view transition capture + change callback<br> <emilio> RESOLVED: Behave as `contain: size` + `contain-intrinsic-size: auto` for the duration of scoped view transition capture + change callback<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-4982981137 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 15 July 2026 16:33:52 UTC