Container Queries Unleashed Container queries allow developers to style elements based on the size of their parent container rather than the viewport, enabling more flexible and responsive UI designs. The article highlights a common pattern where a metadata column changes its layout based on available space, which is difficult to manage with traditional media queries because it requires arbitrary, fragile breakpoints. Using `@container` rules provides a cleaner, more maintainable solution by directly responding to the container's width. The most exciting thing about container queries, in my opinion, is that they expand what’s possible in terms of user interface design. They give us new options when it comes to responsive design, creating UIs that would be impractical or impossible using traditional media queries. In this post, I’ll share the most useful pattern I’ve discovered, so that you can start taking full advantage of container queries in your own work. Link to this headingThe killer pattern There’s one pattern in particular that I find myself using over and over again. Let’s look at an example, from this blog: This layout is used to display newsletter issues. On desktop, it’s a two-column layout. The email metadata on the left, the content on the right. On mobile/tablet, it collapses to a single column: This is a pretty common design pattern, and it’s easily solved using media queries, but it leads to a curious side-effect: the width of each column actually increases when the viewport shrinks below the mobile threshold. Keep your eye on the width of the left-hand column as you shrink the virtual window, using the slider: When we reach the mobile threshold, our two-column layout becomes a one-column layout, which means the metadata column actually gets bigger, expanding to fill the entire width of its container. Now, here’s where it gets tricky. I have two different layouts for the metadata column, depending on the available space: Some thoughts about passion… - From - Josh W. Comeau - Reply-To - support@joshwcomeau.com - Sent - May 21, 2026 When there’s enough room, I want to show the key/value pairs in a single row. Otherwise, the values should move to a new line. But we want to do this based on the container’s size, not the viewport’s size There isn’t a clear linear relationship between the two. Here’s the ideal behaviour. Notice how the metadata layout changes back-and-forth as the window changes size: We’re using media queries to control the “top-level” layout, flipping from two columns to one column, but we can’t really use media queries to describe how the stuff within those columns should respond dynamically. Or, well, technically we can, but it’s messy and fragile. We could do something like this: .metadata-column { / Condensed styles here / @media min-width: 35rem and max-width: 42rem , min-width: 60rem { / Sparse styles here / } } This approach combines multiple media conditions using a comma, which acts like an OR operator. We apply the “Sparse” styles if our viewport is between 35rem to 42rem, or at least 60rem. But where did these numbers come from? 35rem, 42rem, and 60rem aren’t breakpoints in our design system, they’re magic numbers. They’re the arbitrary values that happen to work given the current layout. When I’ve gone with this approach in the past, I’ve literally measured the width of the viewport at the points where I wanted it to flip. This is extremely fragile. It’ll work as long as none of the styles change, but even minor tweaks like adjusting the padding on one of the columns can cause problems. It’s easy to imagine another developer coming along in a few months and tweaking, say, the gap between the columns. All of a sudden, our calculated values are wrong, and the content starts to overflow near those arbitrary breakpoints. The developer probably won’t even notice, since the issue only happens at a narrow range of viewport widths, but some of our users will definitely notice Check out how much nicer the solution is with container queries: