When container queries didn’t yet exist and CSS developers were clamoring for them, developers went so far as to claim:
If we had container queries, most of what we write as media queries today would actually be container queries.
Like, on any given project, there would be more @container in the CSS than @media. I joined that refrain. I thought for sure it would be true, if not, more like 75%, especially considering how so many sites these days are created by composing sites through component libraries, and since components don’t know where they will be used, the CSS that style those components would use all container queries.
So, did this turn out to be true?
Anecdotally: no, not really.
Measuring usage backs that up tenfold, but that’s not fair since container queries are so relatively new, no matter how developers feel about them or use them on new projects, container queries will lag behind media queries for a very long time. Certainly the biggest two reasons for any lag in usage are:
- It’s new. It takes time for education about features to make it out to developers. Even when you know, old habits die hard.
- Browser support concern. The main one seems to be Safari 15, released as recently as 2022.
But even on new or actively developed projects where the developers know about them and the browser support choices enable usage (speaking from personal experience here, and it is polyfillable for the record), it still feels like container queries aren’t reached for all that much.
Why?!
I have a few guesses:
- Flexible layout methods that don’t need width/inline-size based queries. The fact that with CSS grid we can use keywords like
auto-fitandauto-fillto have an arbitrary number of columns steals some of the need to specify columns at breakpoints. Also sometimes you can just… let stuff wrap. - Fluid type. There are a number of ways to pull off fluid type nowdays, and that site-wide typography scaling really helps scale sites without needing breakpoints.
- Components that tend to really benefit from styling updates at certain sizes are full-width anyway. Think of site header and footer elements that tend to be full width. For them, media and container queries are interchangeable.
It’s the within-container layout shifts that seem like the most useful and common use case to me. My most common go-to example is essentially this:
.card {
container: card / inline-size;
}
.card .grid {
display: grid;
grid-template-columns: 1fr 2fr;
gap: 1rem;
@container (inline-size < 300px) {
grid-template-columns: 1fr;
}
}Code language: CSS (css)I’ve heard some interesting thoughts from others as well:
- 🔗 Each container becomes a new stacking context which can cause
z-indexside effects that you might not want. - 🔗 It sometimes requires an additional wrapping element since you can’t style what you query.
- 🔗 CSS developers are only part of a whole. If the larger team doesn’t design around the idea they may not apply.
Examples
It’s not that people aren’t using them at all. I’m using them more and more, myself. I asked folks recently if they have any examples, and got a few. Actually, the lack of responses is sort of what sparked this post.
I figured I’d post some videos of recent usage on my own project here, not all of which is live yet.
I think you’ve covered most of the reasons, with these being key:
Developers might need to explain the idea to Design team as the concept of designing based on container dimensions might not be easily conveyed in Figma, Sketch, etc.
We’re working on adding new cqs to our component library soon; as of now we only have one but it’s works great. It is for a privacy overlay on our YouTube video component. I even managed to get it working inside the ancient YUI compressor which is the default build option for our CSS files when compiling inside the platform.
I posit that while all these reasons are very true and valid, there’s also a very simple psychological reason in the mix:
My kid spends far more time and energy imagining all of the playing he might do with toys he doesn’t have than actually playing with the toys he does have.
Once container queries went from an interminably anticipated delivery to yet another item cluttering the floor, they just weren’t nearly as exciting as we’d imagined.
I only discovered container queries recently but I’ve found them very useful. One use case I encountered recently was that I wanted to display two elements side-by-side on a wide screen but not on a narrow screen. Usually you could do that with a regular media query, however in this case, the page has a side bar that can be toggled on or off that affects the available space.
With a container query, I could change the styles based on the available space, without my component having to use JavaScript to measure the width or CSS that’s tightly coupled to the sidebar.
Container queries were a holy grail for me till a rollout of a component relying on positionning / z-index (a popup with contextual help) started to explode on arrival. The cretiion of a stacking context is the worst for me : container queries should have been iso with media queries in terms of constraints. That’s not the case sadly. I really hope the spec change.
When I was working with container queries lately, I came across the problem, that when working with art directed images, the problem is, that you need to work with media queries to define the breakpoints for images. It would not be possible to use container queries on picture sources, as the browser needs to know which image to load before the layout is done in the browser. Actually, this was the problem, why I needed to switch to a media query approach.
To define the container for a current element, instead of creating a container element, you can use
:has(> .my-element). In this case, the parent element will define the container.I think the challenge for usage is mainly two-fold:
Designers, by and large, do not design components at the component level, they still tend to design things based on arbitrary break points, mostly “mobile” and “desktop”. When a designer has not specified component-level rules for how a component should behave, the developer does not have a recipe to use container queries. I have still never seen a designer deliver a design for a component based on different break points that make sense for that component independently of the layout it will be placed into. Without that, container queries are of no use.
If designers were to do #2 and deliver such component-based rules to the developers, I think #1 would solve itself.
Una Kravets tweeted asking people if they were using them about 2-3 months ago, and even with her audience, 45-50% of people said they didn’t use them because they didn’t know what they are, which… what?!
I also think we’re in the phase now where they’ll start getting used a bit more often, and as people see how others work with them, and we’ll have more blog posts and videos exploring how to use them, their usage will go up.
It’s the common “what I do now works fine, why should I bother?”, and then, as we see practical use cases for them, we start to adopt them. Most people won’t experiment with these things for the fun of it, even if some of us think they’re really cool and get all excited by them 😆
I still have not found a good use case for container queries, despite looking forward to them.
For example, we have some form inputs and want to ensure they all fit on the screen. So we settle on two different designs (compact and wide) but when it comes to implementation, we realize: If we use container queries, a small field like the street number will always switch to the compact design but this is not what we want: We want all inputs to look identical, we do not want to mix styles.
We could use a container query against the surrounding fieldset (instead of the input field itself) but then one block looks different from the other blocks, when instead we want all input fields across the page to look identical.
I am sure there are good use cases for container queries but I have not discovered them yet.
I personally have mainly been avoiding all queries lately by use of 1) grid/flex and 2) fluid type with Clamp but when I do need them, I’ll be favoring @container.