earlier replies
Replying to @matthewcp
I think JavaScript can have infinite loops too but not in my code of course 馃槆 馃馃馃
2
6
It is because of loops. Gonna admit, it鈥檚 a bit esoteric: Inf. loops has always been possible in JS, so RO is not adding anything new here (RO also breaks up loops across frames once detected). We don鈥檛 have cyclic dependencies in CSS and we are not gonna start adding them.
3
6
I think we could build container queries on top of CSS containment (need to separate layout-width & layout-height). That is, have container queries in stylesheets on elements with the right containment . Then able to container-query the width given contain:layout-width, etc.
6
1
16
Yup, this is what I've laid out in the past. We have all the primitives needed now. Biggest blocker in making a built-in for it is accepting that the timing might not be exact; [...]
1
4
If we rely on RO timing, then there can be frames where the container clearly matches or unmatches a CQ but the styling hasn't been adjusted, which violates CSS's statelessness that you can usually rely on. If we don't want that, we need to still have magic.
1
3
Not quite, if you have style+size containment you can decide to not compute the style of the descendants of a contained layout until it's size is known. Then there's no issue at all. I had a spec for that, should still be around.
2
3
I'm not 100% sure what you mean by this; it sounds like you're saying that style+size containment allows *any* CSS element to have this "wrong for one frame" rendering, so we shouldn't worry about it for RO?
1
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
Replying to @FremyCompany @tabatkins @DasSurma @zachleat @matthewcp
Agreed. And this does have performance overhead. But that overhead should be lower than the cost of doing a complete style and complete layout and then changing it in response to changes made in JS.

May 17, 2019 路 10:08 PM UTC

1
1
Replying to @davidbaron @FremyCompany @tabatkins @DasSurma @zachleat @matthewcp
That said, the layout ordering might actually be a little more interesting than that in that, with width-only containment, the style and layout of the subtree would need to run in the middle of the layout of its container.
1
more replies