5 ms·

> If it doesn't have any absolutely positioned or floating child elements, wouldn't that imply contain: content? Not just children, but descendants at arbitrar

> If it doesn't have any absolutely positioned or floating child elements, wouldn't that imply contain: content? 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.

randomfool 7y ago
Also it may be difficult to annotate all of the descendants appropriately and to audit them to ensure performance. I’m in favor of browsers inferring whatever they can, but when it comes to critical performance sections I want to be explicit.
_bxg1 7y ago
And then there's another layer of complication when you assume that any and all styles can change at any time. A big part of "contain"s use-case is when you can guarantee that your JS will never apply certain styles to certain elements. There's no way the browser could ever verify that.
- frivoal 7y ago
  > when you can guarantee that your JS will never apply certain styles to certain elements 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.
  - _bxg1 7y ago
    True, but the things it prevents you from doing are virtually never something you would want to prevent via a mechanism like this. You'd want to catch them higher up. I don't think it would really be helpful as a constraints system.

randomfool 7y ago

Also it may be difficult to annotate all of the descendants appropriately and to audit them to ensure performance. I’m in favor of browsers inferring whatever they can, but when it comes to critical performance sections I want to be explicit.

_bxg1 7y ago

And then there's another layer of complication when you assume that any and all styles can change at any time. A big part of "contain"s use-case is when you can guarantee that your JS will never apply certain styles to certain elements. There's no way the browser could ever verify that.

frivoal 7y ago
> when you can guarantee that your JS will never apply certain styles to certain elements 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.
- _bxg1 7y ago
  True, but the things it prevents you from doing are virtually never something you would want to prevent via a mechanism like this. You'd want to catch them higher up. I don't think it would really be helpful as a constraints system.