Container queries are finally here! Now available behind a flag in the latest version of Chrome Canary, you can go ahead and experiment to your heart’s content. Oh, and if you’re not familiar with container queries then check out this post by Ethan Marcotte about why they’re so dang important.
Ahmad Shadeed described his excitement and showcased a ton of great use cases for problems that container queries solves:
I haven’t been more excited for a CSS feature like I’m now in the past six years I spent as a front-end developer. The prototype of container queries is now available behind a flag in Chrome Canary. Thanks to efforts from smart people like Miriam Suzanne and other folks.
I remember seeing a lot of jokes about the support for CSS container queries, but they are finally there.
Once you’ve activated the feature in chrome://flags
you can then begin to write code like this:
.parent {
container: layout inline-size;
}
@container (min-width: 400px) {
.child {
display: flex;
flex-wrap: wrap;
}
}
First off, you need to tell the parent component that a child needs to change size (that’s the container: layout inline-size
part). Next, you can use a new kind of query called @container
which will detect when the parent of an element changes width.
Andy Bell also made a bunch of great examples when he argued that we often need elements to change based on the size of the parent element more so than the width of the browser window, especially when it comes to typography:
Most importantly with container queries, we can set typography contextually! This for me is the most needed feature in design system implementations and why I constantly wish we had container queries. We can respond with media queries and set font sizes etc that way, but when you have no idea where an element will end up, this isn’t an ideal approach. Now we have container queries, we can make type adjustments that actually make sense a lot easier than before.
This post reminds me that Miriam Suzanne made an excellent proposal where you can read more about how container queries were designed and all the various snaffus and problems that came up along the way. It’s so neat to see a document like this that shows CSS being improved in public.
Personally, I believe this is the biggest improvement to CSS since Grid. It opens up all sorts of elegant solutions to problems we work around on a daily basis. I hit a snag just the other day when I wanted to set the type of an element in a sidebar depending on the width of the element wrapping it. And gah — it just wasn’t possible without introducing a bunch of weird hacks!
Container queries aren’t just some far-flung pipe dream now. They’re here to stay.
Hello CSS Container Queries!
(I’ll see myself out)
I wouldn’t be surprised if in a few years the general convention is to use container queries, rather than media queries, for most responsive styles. Most media queries are really just attempting to perform the function that container queries would, resizing or changing the layout of elements when there isn’t enough space in their container.
I’ve not researched this yet, but does anyone know if we’ll get a unit similar to
vw
/vh
, but for containers?vw for containers is already there and is called %
vh is more complicated indeed
Mentioned in one of the linked articles https://github.com/w3c/csswg-drafts/issues/5888
@Ryo, true to ask extent of the target element being styled is a direct descendent. However, like
vw
references the viewport… regardless of depth in the DOM. Ideally, there would be a unit that references the container.Now the problem is we’ll still have to write css for all the people who don’t update their stuff for the next 10 years, even though container queries really could otherwise replace the vast majority of media queries (which are 99% window size queries by my experience)
Wow, I believe this is a very strong enhancement and we can build great things. The idea, that I can reuse the exact same component in different contexts thrives me (like in a sidebar or in the main pane).