No, I'm saying there's no need for frame delay if you have both size and style containment. You just don't compute the style of the subtree of an element that is a layout container until after you have layouted it, because you can do that without any info from its children.
2
1
...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?
1
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.
2
1
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?
1
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?
1
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.
1
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.
1
1
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.
May 17, 2019 · 10:44 PM UTC
2
1