Here's a recent article by Josh W Comeau that explains how this keyword is instrumental to using container queries: https://www.joshwcomeau.com/css/container-queries-introducti...
That was a valuable read, thanks.
This is one of those features that I suspect would be incredibly useful for some of my applications but I just can’t quite see it yet. Maybe a page of real world examples might help, if anyone has any?
This page got me a bit closer I think: https://css-tricks.com/almanac/properties/c/contain/
I found a probably unintended use in making it easy to ensure clipping worked right.
The intended use of course is ensuring that the content in container does not need complex compositing outside its rectangle.
This optimization is pretty massive if used right. It means that you can draw this component directly on the pixel buffer of its parent instead of on a separate buffer of growable size that needs to then be copied over. Or if the browser renders things in order (to maintain a single buffer), this operation could be safely parallelized.
a fun fact, `contain: paint` dosn't contain box-shadow or filters like drop-shadow or blur, so that's not strictly true.
So text won’t visually bleed out but the texts box shadow still will? I’m guessing there’s a reason to why this is but it’s a bit strange.
This is great, thanks!
As someone that has been working with css for over a decade, I was surprised to find out about the contain property, as I had never known about it and it seems extremely useful for hinting to the browser of optimizing DOM operations.
If anyone with experience writing DOM/layout code for browsers knows anything about whether these optimizations are indeed used/meaningful, that would be stellar!
TimesNewMe linked https://www.joshwcomeau.com/css/container-queries-introducti... upthread.
(I've got that and your link open but haven't read either yet, more coffee first, just wanted to make sure you didn't miss the other user's link :)
Does anyone know if `contain` can increase paint performance of a webpage meaningfully? It seems like it can prevent unnecessary calls, but I'm wondering if there's any reasonable impact it gives.
You'd want to benchmark this yourself, and assume that the impact will probably decrease as browsers progress, but I believe that for very large trees (tables, etc) it can have a fair impact. That said, I'm guessing paints aren't what are usually slowing your page down.
A quick way to validate that is to open up the devtools and run a performance trace. Watch for paint events vs JS code execution and such.
Probably. I've encountered a case where setting `contain` for unrelated reasons noticeably decreased the GPU memory use as reported by the browser: https://phabricator.wikimedia.org/T373066#10096943 (search for "As a bonus"). Wikipedia is pretty light, so in absolute terms it wasn't really meaningful, but I could see that on a more complex site.
As someone who occasionally works with front-end, the massive difference the various values of contain makes feels overly complex. Will be a tough one memorizing.
If someone can build an app (or an AI) that knows when to use the hundreds of different CSS keywords to optimize painting that would be great!
This could have worked magic when we used to develop and design many embeddable widgets—the days of `!important` at the end of each line.
Today, someone can become pretty good with CSS without ever considering how the Box Model will impact a container/wrapper.
It won't override global scope, it's just a hint the layout engine that your container's paint and/or size won't change, and thus it can optimise it's performance.
Wholly agree with your second point, it's something I see from a lot of junior devs. They just reach straight for flex/grid, and tbh I don't blame them. They are more predictable layout algorithms that are largely unshackled from legacy layout decisions.
[dead]