Stop Building 375px Layouts: Container Queries Are Your New Best Friend

Who This Is For

You've been writing media queries for years. You know the drill: add a breakpoint at 768px, then another at 1024px, then another for that one weird tablet. It works, but it's fragile. You're rebuilding the same component three times because it lives in a sidebar, a main column, and a footer. If that sounds familiar, this guide is for you. We're going to ditch viewport-centric thinking and embrace container queries. This isn't a theoretical exercise—it's a practical overhaul of how you build responsive components.

1. Start with Fluid Foundations

Before you touch a single container query, get your baseline right. Responsive design isn't just about breakpoints; it's about fluid grids, flexible images, and media queries working together (MDN Web Docs). Stop using fixed pixel widths for your layout. Use relative units like percentages, fr units for grid tracks, and em/rem for sizing. For images, the classic img { max-width: 100%; height: auto; } is non-negotiable. This prevents overflow and keeps media scaling with its container. If you're not doing this already, fix it first. Container queries build on a fluid foundation—they don't replace it.

2. Query the Container, Not the Viewport

Here's the core shift: instead of writing a media query that checks the viewport width, you write a container query that checks the width of a parent element. The CSS is similar: @container (min-width: 400px) { ... }. To make it work, you first designate a container with container-type: inline-size; on the parent. Then, any child can respond to that container's size. This is powerful because the same component can adapt whether it's in a narrow sidebar or a wide hero section. Container queries are Baseline Widely available, in browsers since February 2023 (MDN Web Docs @container). You can start using them today.

3. Use Container Query Units for Intrinsic Sizing

Once you have a container, you can size elements relative to it using container query length units. For example, cqw is 1% of the container's width, cqi is 1% of its inline size, and cqmin/cqmax give you the smaller or larger of the container's dimensions (MDN Web Docs container queries guide). This is great for typography and spacing that scales with the component's context. Instead of setting a font-size in viewport units (which can break zooming—you should never use viewport units alone for text; combine them with a fixed unit like calc(1.5rem + 4vw)), you can use cqw values for a truly container-aware type scale. Just remember to set a sensible min/max with clamp() to avoid extremes.

4. Design Components That Adapt, Not Pages

The real win is component-level responsiveness. Think about a card component. In a narrow sidebar, it might stack its image above the text. In a wide column, it shows the image side-by-side. With media queries, you'd have to write separate rules for each breakpoint. With container queries, you write the rules once, and the card adapts wherever it's placed. This is a huge time-saver and makes your design system genuinely modular. Start by converting your most reused components: cards, navbars, product tiles, sidebar widgets. You'll notice the difference immediately.

5. Combine with Modern CSS for Superpowers

Container queries pair beautifully with other modern CSS features. The :has() selector is Baseline Widely available since December 2023 (MDN Web Docs :has) and lets you style a container based on its contents—for example, .card:has(.featured) to give a special style to cards that contain a featured element. Subgrid is another gem, available since September 2023 (MDN Web Docs Subgrid); it lets nested grids align with their parent, which is perfect for keeping cards in a row with equal heights. These tools together let you build complex, adaptive layouts without the breakpoint spaghetti.

6. What Can Go Wrong: Over-Containerizing

The trap is to container-query everything. That leads to a mess of nested containers and unpredictable behavior. Remember the WCAG 2.1 Reflow requirement: content must not require scrolling in two dimensions at a width of 320 CSS pixels (W3C WCAG 2.1 Understanding Reflow). Container queries can help, but if you go overboard, you might create containers that are too small, forcing content to overflow. Also, don't forget that the viewport still matters for global layout. Use container queries for components, but keep media queries for the page-level structure. And test thoroughly—especially with keyboard navigation and screen readers, because a container that collapses might hide focus or content.

Sources

• MDN Web Docs - https://developer.mozilla.org/en-US/docs/Web/CSS/@container
• MDN Web Docs (container queries guide) - https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_containment/Container_queries
• MDN Web Docs (:has) - https://developer.mozilla.org/en-US/docs/Web/CSS/:has
• MDN Web Docs (Subgrid) - https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_grid_layout/Subgrid
• W3C WCAG 2.1 Understanding Reflow - https://www.w3.org/WAI/WCAG21/Understanding/reflow.html