| > `contain: layout` means that its internal layout is not affected by anything outside. The other way around: * normally, a float can poke out of its parent div, and affect stuff around * an absolutely positioned element can poke out of its parent, and if a further ancestor is overflow:auto and the absolutely positioned thing goes far enough, it could trigger scrollbars, whose appearance could cause a relayout * margins of children can collapse with the margins of parents (recursively), and affect the layout of ancestors * there are more like that > `contain: paint` means descendants cannot display outside the element's bounds. Isn't this already given by `overflow: hidden`? Almost: `overflow:hidden` actually makes the element programatically scrollable. It doesn't discard everything that sticks out, because you might just start scrolling using JS, so the browser needs to keep a buffer with the out -of-view stuff ready, just in case, even if it's unlikely. Or maybe it'll optimize a bit more, and create these buffers on demand, but it still needs to have facilities to keep track of which buffers it has, which it could create, what font would need to be downloaded to render the out-of-view part… > If these properties disagree, who wins? contain wins. The point of contain is that if it's on, the behavior is guarateed, and the browser doesn't need to check a dozen properties on an arbitrary number of elements before knowing if certain optimizations are safe to do. So if it's on, it's on, and there's no way to break out. > `contain: size` means that the element's size does not depend on its children. Isn't this already given by height, width, etc? * there's an etc here, and it turns out that there a few more properties than you'd expect that need to be checked. Doable, but checking 13 properties takes more time than checking 1, and we're trying to turn on optimizations. Expensive checks before you can optimize can make the optimization not worth pursuing. * There are cases where even with `width` set to something other than a fixed size, the width of the parent doesn't depend on children. But checking if you're in one of these cases can be complicated, if it isn't being guaranteed by something like contain. |
Regarding `overflow: paint`:
In <https://www.w3.org/TR/css-contain-1/#containment-paint> it says:
> ... This does not include the creation of any mechanism to access or indicate the presence of the clipped content; nor does it inhibit the creation of any such mechanism through other properties, such as overflow, resize, or text-overflow. This is as if overflow: visible was changed to overflow: clip at used value.
That seems to imply that `overflow: hidden` could still be used with `contain: size` to "access" clipped content. And still I don't see how the optimizations they list are not available with `overflow`.
BTW, I think it's unfortunate that the MDN article introduces `contain` as if it were a hint...
> This information is something that is usually known, and in fact quite obvious, to the web developer creating the page. However browsers cannot guess at your intent ...
... when actually it modifies layout and display behavior, overriding other properties.