...right, but in the meantime that container *itself* is now large enough to trigger a CQ, but the subtree hasn't been recalculated to obey the new CQ styles. Which is the original problem I was talking about. Right? Or am I missing something?

Still missing. Don't need to resolve the styles of descendants until after you have done the layout. Think about it as a sequence of styling(root)-layout(root)-styling(subtree)-layout(subtree) where u only do styling once per element but it might be after the layout of a parent.

So that assumes paint it held until after the layout(subtree) tho, right? With RO timing, you don't get that; you do a layout(root), then paint, *then* RO fires and lets you figure out you need to restyle children. That's the delay I'm talking about. Right?

Yes, all elements need a layout before paint. Seems to be the case always, not just here. If I understand your delay idea, you'd also do a layout of the children the first time, just with the wrong styles. Doubly as costly, right?

Yeah, that's what happens today with "container queries via RO".

Oh yeah, totally: RO-based queries do waste a layout and a paint each time. With proper containment that layout being wasted is only the subtree but still. Flash of unstyled content and way more cpu used. This is not required if u do your styling inside your layout for subtrees.

Right, so bringing that back around to my original tweet: avoiding that wasted effort means you still need magic, above and beyond the functionality you get from RO + containment.

If you call staged layout magic, then yes 👍

Is it more than you can do with existing platform primitives? Then yeah, it's magic by definition.

Sure, it's a new platform primitive, and one whose exposure to JS would break run-to-completion semantics, but which can be exposed to CSS. Calling new platform primitives that you don't like "magic" doesn't seem helpful here.