6 ms·

I don't understand why the browser can't infer this from existing knowledge. If it doesn't have any absolutely positioned or floating child elements, wouldn't t

I don't understand why the browser can't infer this from existing knowledge. If it doesn't have any absolutely positioned or floating child elements, wouldn't that imply contain: content? And if you add overflow: auto or hidden, wouldn't that infer to contain: strict? 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.

deleted 7y ago
[deleted]
gluxon 7y ago
> If it doesn't have any absolutely positioned or floating child elements, wouldn't that imply contain: content? 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.)
- vincentriemer 7y ago
  overflow: hidden/auto does not guarantee that children won't be painted outside of the element's bounds, even if it has a fixed width & height: https://codepen.io/vincentriemer/pen/WNvwpvQ https://codepen.io/vincentriemer/pen/WNvwpvQ If you add contain: strict to the container in the above example you'll see that it then successfully clips the child div.
frivoal 7y ago
> 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.
kevingadd 7y ago
An important detail is that browsers can infer some of this, but that doesn't mean it's guaranteed to work. You're relying on heuristics and browser internals and the gap between 'it was inferred' and 'it wasn't inferred' can be multiple milliseconds of layout time. It's quite easy for someone to accidentally break the inferred optimization by changing a CSS style or adding some new HTML if the side effect is invisible. Contain gives you something approximating a guarantee and you also know the exact effect of the attribute.

deleted 7y ago

[deleted]

gluxon 7y ago

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

vincentriemer 7y ago
overflow: hidden/auto does not guarantee that children won't be painted outside of the element's bounds, even if it has a fixed width & height: https://codepen.io/vincentriemer/pen/WNvwpvQ https://codepen.io/vincentriemer/pen/WNvwpvQ If you add contain: strict to the container in the above example you'll see that it then successfully clips the child div.

frivoal 7y ago

> 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.

kevingadd 7y ago

An important detail is that browsers can infer some of this, but that doesn't mean it's guaranteed to work. You're relying on heuristics and browser internals and the gap between 'it was inferred' and 'it wasn't inferred' can be multiple milliseconds of layout time. It's quite easy for someone to accidentally break the inferred optimization by changing a CSS style or adding some new HTML if the side effect is invisible. Contain gives you something approximating a guarantee and you also know the exact effect of the attribute.