CSS Container Queries: The Layout Revolution You Missed

• Container queries respond to parent element width, not viewport, fixing responsive components in varied layout contexts.

• Declare container with container-type: inline-size, then use @container rules instead of media queries for adaptability.

• New units (cqw, cqh, cqi, cqb) enable typography and sizing that scales with container dimensions automatically.

• Use cases include responsive navigation, dashboard widgets, product grids, and embedded article components without JavaScript.

• All modern browsers support container queries; legacy browser support is minimal and shrinking.

Media queries respond to the viewport. Container queries respond to the parent element. This distinction sounds minor but fundamentally changes how you build responsive components. If you're still using only media queries in 2026, you're making layouts harder than they need to be.

The Problem Container Queries Solve

Imagine a product card component. On a wide page, it shows an image beside text. On a narrow page, it stacks vertically. With media queries, this works fine - until you put the same card in a sidebar. Now the page is wide (so media queries keep the horizontal layout) but the sidebar is narrow (so the card should stack). The card doesn't know it's in a sidebar. It only knows the viewport width.

Container queries fix this. The card adapts based on its container's width, not the viewport. In a wide container, horizontal layout. In a narrow container, stacked. Same component, same code, correct behavior everywhere.

Basic Syntax

First, declare a container:

.card-wrapper {
  container-type: inline-size;
  container-name: card;
}

Then write container queries instead of media queries:

/* Default: stacked layout */
.card {
  display: flex;
  flex-direction: column;
}

/* When container is wider than 400px: horizontal layout */
@container card (min-width: 400px) {
  .card {
    flex-direction: row;
    gap: 1rem;
  }
  .card-image {
    width: 40%;
  }
}

The component now adapts to wherever it's placed. Drop it in a full-width section, a sidebar, a modal, a grid column - it always looks right.

Container Query Units

Container queries come with new units:

• cqw - 1% of the container's width

• cqh - 1% of the container's height

• cqi - 1% of the container's inline size

• cqb - 1% of the container's block size

These are useful for typography that scales with its container:

.card-title {
  font-size: clamp(1rem, 4cqi, 2rem);
}

The title scales with the container width, bounded by minimum and maximum sizes. No JavaScript needed.

Practical Use Cases

Navigation components: Full horizontal nav in wide containers, hamburger menu in narrow ones. Without container queries, responsive nav is tied to viewport breakpoints, which breaks when nav appears in different layout contexts.

Dashboard widgets: Cards that show full detail in large grid cells and compact summaries in small cells. One component, zero JavaScript, fully responsive.

E-commerce product grids: Product cards that adjust their internal layout based on the grid column width, not the page width. Switch from 4-column to 2-column grid and the cards adapt automatically.

Article layouts: Embedded components (image galleries, code blocks, callout boxes) that respond to the article column width. Especially useful when the same article renders at different widths (blog page vs. AMP vs. email).

Browser Support in 2026

Container queries are supported in all modern browsers. Chrome, Firefox, Safari, and Edge all ship full support. The only holdout is older browsers that haven't auto-updated, which is a shrinking percentage.

If you need to support very old browsers, container queries degrade gracefully. The default styles (outside the @container rule) apply as fallback. The component works, it just doesn't adapt to container size.

Combining with Media Queries

Container queries don't replace media queries. They serve different purposes:

• Media queries: Page-level layout decisions (grid columns, sidebar visibility, navigation style)

• Container queries: Component-level layout decisions (card layout, widget density, text wrapping)

Use media queries for the page skeleton and container queries for the components within it. This separation makes components truly portable across different page layouts.

The Mental Model Shift

The old model: components are styled for the page, then override styles at different viewport widths.

The new model: components are self-contained and adapt to whatever space they're given.

This aligns with how design systems work. A button component in Figma doesn't know what page it'll be on. It has its own rules for different sizes. Container queries let your CSS work the same way.

Getting Started

Pick one component in your project that appears in multiple layout contexts. Add container-type: inline-size to its wrapper. Convert its media queries to container queries. See how it behaves in different containers.

Once you feel the difference, you'll want to convert everything. Start gradually - components that live in one fixed-width context don't need container queries. Focus on the ones that move between layout contexts.

RAXXO Studio's component system uses modern CSS patterns. See it at studio.raxxo.shop.