Stop Designing for the Viewport: Container Queries Are the Future of CSS

There's a myth that responsive web design is about viewport sizes. You've heard it a thousand times: design for mobile, then tablet, then desktop, with breakpoints at 375px, 768px, and 1024px. That's wrong. I'm not saying those breakpoints don't exist—they're useful reference points, but the moment you treat them as the foundation of your layout, you're building for the wrong abstraction. The real unit of design is the component, not the screen. And that's why container queries are the most important CSS feature since CSS Grid.

The Viewport Is a Lie

Think about a typical page: a sidebar, a main column, a card grid. On a desktop, a card in a four-column grid might be 200px wide. On a phone, that same card might be 100% of the viewport, which could be 375px. If you've designed that card's typography and spacing using viewport breakpoints, you end up with two different designs for the same component, and you have to maintain them with media queries. That's the status quo, and it's fragile.

Google's own guidance, for example, recommends responsive design as the easiest mobile configuration, but they're talking about the page as a whole. The problem is that a component inside a sidebar doesn't care what the viewport is. It cares about how much room its container gives it. That's where container queries come in. With @container, you can respond to the size of a component's container, not the viewport. It's been Baseline Widely available since February 2023, so there's no excuse to keep ignoring it.

Why Container Queries Are a Paradigm Shift

I'm not saying media queries are useless—they're still essential for global layout changes like switching from a single column to a multi-column grid. But container queries let you build components that are genuinely context-aware. A card can have a compact layout when it's in a narrow sidebar and a spacious layout when it's in a wide content area, without you having to write a single media query. The component itself adapts based on its parent.

Here's a concrete example: imagine a product card that needs to display an image, a title, a description, and a button. In a narrow container, you might want the image on top, the title below, and the button at the bottom. In a wide container, you might want the image on the left and the text on the right. With container queries, you write the rules once, and the card adapts wherever it lives. This isn't just a convenience—it's a way to reduce the complexity of your CSS and make your design system more modular.

Container queries also bring new units: cqw, cqi, cqh, cqb, cqmin, and cqmax. These let you size elements relative to the container, not the viewport. For example, you can set a font size as a percentage of the container's inline size, which means typography scales with the component's context. This is a game-changer for fluid typography.

The Counter-Argument: Media Queries Are Good Enough

You might say, "We've been doing fine with media queries for years. Why add another layer of complexity?" I get it. The learning curve is real, and it's true that many sites don't need container queries. But the fact is that the web is becoming more component-driven. Design systems like Material Design and Apple's HIG are built on reusable components that need to work in a variety of contexts. Apple's guidelines, for instance, recommend a minimum touch target of 44 by 44 points, and Material Design suggests 48 by 48 dp. Those targets are about the component, not the viewport. If you're building a button that needs to be tappable regardless of where it appears, you need to think in terms of the component's environment.

The strongest argument against container queries is that they can be overused, leading to a bloated CSS file. That's a fair concern, but it's a discipline issue, not a technology issue. Used judiciously, container queries simplify your code by eliminating the need for a dozen media query overrides. They also make components more portable: you can drop a component into any layout and know it will adapt.

How to Start Using Container Queries Today

Here's my recommendation: start with one component. Pick something you currently style with multiple media queries, like a card or a call-to-action block, and refactor it to use container queries. You'll need to set container-type: inline-size on the parent element, and then you can write @container (min-width: 400px) { ... } inside your component's CSS. That's it. The browser does the rest.

But don't throw out media queries entirely. Use them for the page-level layout, and use container queries for the components within that layout. This hybrid approach is the best of both worlds. And remember, the viewport breakpoints you've been using—375px, 768px, 1024px—are just reference points. The real breakpoints should be determined by your content, not by the devices you're trying to target. As MDN points out, breakpoints should be added when the content demands them, not at fixed device sizes.

I'm not saying container queries are the answer to everything. They won't fix your contrast ratio, and they won't make your site accessible if you ignore WCAG. But they will make your CSS more maintainable and your components more flexible. And that's a win.

Here's the single most important thing to remember: design for the container, not the viewport. The viewport is a relic; the container is the future.

Sources

• MDN Web Docs - https://developer.mozilla.org/en-US/docs/Web/CSS/@container
• MDN Web Docs - https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_containment/Container_queries
• MDN Web Docs - https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/CSS_layout/Responsive_Design
• Google Search Central - https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing
• Apple Human Interface Guidelines - https://developer.apple.com/design/human-interface-guidelines/accessibility
• Android Developers - https://developer.android.com/guide/topics/ui/accessibility/apps