Container Queries vs Media Queries: When to Use Which

I’ve been thinking about this lately: media queries handle page-level layout changes fine, but they fall apart when the same component needs to behave differently depending on where it sits in the DOM.

That’s where container queries change the equation.

Media queries respond to the viewport. Container queries respond to the component’s container size. This matters for reusable design systems: a card component might sit in a 200px sidebar in one place and an 800px grid in another. With media queries alone, you’d need extra classes, wrapper changes, or JavaScript to handle that. Container queries let the component adapt based on its own context.

The practical rule I use: keep media queries for the page shell and major layout tiers. Use container queries inside reusable components that appear in multiple contexts. This keeps the CSS predictable without duplicating component variants.

A few real-world constraints worth knowing:
- Browser support is solid in modern browsers, but older versions still need fallbacks
- Container queries can’t replace media queries for user preferences like prefers-color-scheme or prefers-reduced-motion
- The syntax (cqw, cqh, container-type) takes a few minutes to internalize

If you’re experimenting with container query syntax, it helps to generate query blocks and paste them directly into your components instead of hand-writing each one. Testing a few variations is faster than guessing values in the editor.

Comments

[a-dev]

Your formatting looks like you want to create a skill for AI 🙂
If so, I’d strongly advise adding a requirement to include the container name.
For example:

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

@container card-list (min-width: 32rem) {
  .card {
    grid-template-columns: 12rem 1fr;
  }
}

It prevents a component from accidentally responding to the wrong ancestor later when the layout gets refactored (what will definitely happen 🙄 )

[Robert Wallace]

Yes, you called it — container-name definitely belongs in the “skills for AI” checklist 😂

But yeah, that’s the real hidden cost of skipping it. The moment that card ends up in a sidebar and a main grid, you’re suddenly debugging why two unrelated layouts are both triggering the same container rule.

Naming it turns the @container block from “guess what this is for” into “oh right, this is the card list.” Worth the two extra seconds upfront.