I like the idea of containing floats in a div easily, no more clear hacks lol. But... I must be missing something since it really seems to be these optimizations ought to already be possible.
I like the idea of containing floats in a div easily, no more clear hacks lol. But... I must be missing something since it really seems to be these optimizations ought to already be possible.
Not just children, but descendants at arbitrary depth. Also no relative positioning, negative margins making anything stick out, no transforms, no shadow with a radius large enough to poke out of its parents...
> And if you add overflow: auto or hidden, wouldn't that infer to contain: strict?
No, you also need to make sure that the size of the parent element is not influenced (horizontally or vertically) by the size of any descendant.
Well, some of these are allowable if the effects don't poke out of the particular element you're interested in.
Effectively, this is all stuff the browser could check before turning on an optimization that depends on these conditions being verified, but due to the number of things you need to check on a tree of arbitrary depth, the verification would cost more than the saving you'd get by applying the optimization. So browsers don't do it.
css-contain gives you a mode where there's nothing to check, because the basic rules of layout/painting/sizing are changed so that things can never leak up if you've turned on the relevant type of containment.
I’m in favor of browsers inferring whatever they can, but when it comes to critical performance sections I want to be explicit.
It goes further than that: using contain means that even if you tried applying these styles that would break optimizations, the browsers will not obey you. css-contain isn't just a hint to the browser that you're not screwing things up, it's a mode switch that prevents you from doing so.
I think the goal is to avoid analyzing child elements at all. So you can layout a given set of children at one layer of the DOM tree at once rather than having to dig deeper into one node to know where to put its sibling.
> And if you add overflow: auto or hidden, wouldn't that infer to contain: strict?
I think browsers would only be able to reasonable infer "contain: strict" on elements with both overflow auto/hidden and fixed width/height.
I'm guessing that "contain: strict" would allow you to avoid defining fixed height and width then? (That was just my first guess. There may be other reasons.)
If you add contain: strict to the container in the above example you'll see that it then successfully clips the child div.
Contain gives you something approximating a guarantee and you also know the exact effect of the attribute.