I’ll admit, when container queries first shipped again in 2022, I didn’t actually listen. I imply, why container dimension queries after we have already got media queries? Why container fashion queries when customized properties inherit anyway (they don’t work with customary properties… but)? Their use circumstances appeared like edge circumstances to me, enabling us to do issues that we may already do however another way.
Right here’s a container dimension queries demo by Kevin Powell. As a be aware, all main browsers help dimension queries within the following demo, however different demos on this article might require the most recent Chrome.
Container fashion queries (with the brand new vary syntax) demo by, uh, me:
And extra not too long ago, we’ve seen a pair extra kinds of container queries pop up.
Container Scroll-State Queries
Container scroll-state queries got here together with their distinctive capabilities — the flexibility to search out out whether or not a container is scrollable, or is scroll-snapped to a scroll goal, or has place: sticky and is ‘caught.’ Actually, as I’m scripting this, Chrome introduced scrolled help, which is a bit completely different to scrollable.
Container scroll-state queries demo by our very personal Geoff Graham:
And that’s not all we’ve bought…
Anchored container queries
The newest container question function is anchored container queries, which allow us to question fallback positions. Think about that you simply anchor-position a tooltip caret to the left facet of a tooltip, however then there’s no room to show the tooltip, so that you flip it to the alternative facet of no matter triggers it utilizing position-try-fallbacks: flip-inline. Effectively, an anchored container question can detect when the tooltip place is flipped in order that we will additionally flip the tooltip caret to the alternative facet of the tooltip.
What else?
So, it bought me pondering, how far can we actually go along with container queries? There are dozens of media queries now, so what if there have been dozens of container queries as properly? What may we use them for?
Get any computed worth
Just lately I used to be exploring the present and future strategies of getting the worth of a CSS property and utilizing it with one other property, and as you’ll be able to think about, container dimension queries have been talked about since they unlock container question items. I imply, have you ever ever added a wrapper aspect or outlined an present one as a container simply to entry container question items?
{
/* Gimme container question items! */
container-type: inline-size;
{
width: 100cqi;
}
} Now, I don’t love container queries as a way of getting values as a result of the syntax is usually a bit long-winded for that (longer than the instance above, and dimension queries specifically are a bit quirky), however the truth that we will use them to perform a little greater than querying is testomony to how versatile they’re as a function. As a substitute, I steered a CSS operate known as compute(), the place in case you needed the peak of one thing (or the “one thing” of something), we may steal it from one other aspect like this:
{
{
/* Computed peak of */
property: compute(peak, self);
/* Computed peak of the father or mother */
property: compute(peak, inherit);
/* Computed peak of #abc aspect */
property: compute(peak, #abc);
}
} This could save us from having to implement a container dimension question simply to make use of its container question items, and would additionally apply to all properties. Apart from, a container dimension question wouldn’t assist us to accumulate the un-computed declared worth that we truly typed out. For that, the inherit() operate has been proposed and Roma even exhibits us methods to use it in Chrome Canary.
So as to add, I actually just like the key phrase method and would like to see extra key phrases like currentColor (e.g., currentBackgroundColor has been proposed).
Nonetheless, if container queries may very well be prolonged to get the worth of any CSS property, I undoubtedly wouldn’t say no to that! The flexibleness to go properties/values between components is method too engaging.
Question any CSS property
This function has truly been on the slate since container fashion queries have been first proposed, however there’s no telling when it’ll arrive. This container fashion question improve will allow us to question the (un-computed/declared) worth of any CSS property as an alternative of simply customized properties (though you received’t be capable to ‘get’ and use these values, at the least so far as I do know).
Any CSS property? Uh, doesn’t that make the entire different container queries redundant? Not fairly, no.
Container scroll-state queries detect snapping and stickiness, for which there are not any pseudo-classes — however perhaps there must be? In addition they detect scrollability, since, for instance, overflow: scroll and overflow: seen doesn’t imply that the content material is definitely overflowing, solely that we’re allowed to scroll the container if it does. Lastly, anchored container queries don’t question the position-try-fallbacks worth, they detect when, for instance, the position-area is flipped.
So, you understand, they do a complete bunch of stuff, and that’s why this improve for container fashion queries received’t exchange them. In reality, I can completely see dozens of latest container question options hitting the net throughout the subsequent few years.
So, what else may container queries do?
Earlier than container queries have been even a factor, nice concepts have been being put ahead. After all, a few of them truly turned container queries whereas others are nonetheless simply that — nice concepts that haven’t gone anyplace (once more…but?).
I’m assured that we’ll see these concepts realized sooner or later, both as container queries or as another syntax. Heck, because it’s December, I’ll make it my prediction for 2026: container queries will rule 2026.
What else do you need container queries to do?
