Skip to main content
Adzbyte
Development

Responsive Design in 2026: Container Queries Changed Everything

Adrian Saycon
Adrian Saycon
March 29, 20264 min read
Responsive Design in 2026: Container Queries Changed Everything

For over a decade, responsive design meant media queries — adjusting layouts based on the viewport width. Container queries flip that model entirely: components respond to their own container’s size, not the browser window. After using them extensively in production, I can say they’ve fundamentally changed how I think about component architecture.

The Problem With Media Queries

A card component that looks great in a 3-column grid becomes unusable in a sidebar because media queries only know about the viewport. The viewport might be 1440px wide, but the sidebar is 300px. Your media query breakpoint for “small screens” never fires, and the card renders in its wide layout crammed into a narrow space.

Container queries solve this by letting the card respond to the width of whatever container it’s placed in.

The Syntax

First, define a containment context on the parent. Then use @container rules on children:

/* Define the container */
.card-grid {
  container-type: inline-size;
  container-name: cards;
}

/* Default: stacked layout for narrow containers */
.card {
  display: grid;
  gap: 1rem;
}

.card__image {
  aspect-ratio: 16 / 9;
  width: 100%;
}

/* When the container is at least 400px wide: side-by-side */
@container cards (min-width: 400px) {
  .card {
    grid-template-columns: 200px 1fr;
  }

  .card__image {
    aspect-ratio: 1;
  }
}

/* When the container is at least 600px wide: featured layout */
@container cards (min-width: 600px) {
  .card {
    grid-template-columns: 300px 1fr;
  }

  .card__title {
    font-size: 1.5rem;
  }
}

Now this card component works correctly whether it’s in a full-width grid, a sidebar, a modal, or a dashboard widget. No media queries needed.

Container Query Units

Container queries come with their own units that are relative to the container’s dimensions:

  • 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
  • cqmin — the smaller of cqi and cqb
  • cqmax — the larger of cqi and cqb

These are incredibly useful for fluid typography and spacing within components:

.card__title {
  /* Font scales with container width, clamped between 1rem and 2rem */
  font-size: clamp(1rem, 4cqw, 2rem);
}

.card__body {
  padding: clamp(0.75rem, 3cqw, 2rem);
}

Real Example: Responsive Navigation

Navigation is a perfect container query use case. A nav bar in a wide header shows horizontal links. The same nav component in a narrow sidebar switches to vertical stacking — all without knowing about the viewport:

.nav-container {
  container-type: inline-size;
}

.nav {
  display: flex;
  flex-direction: column;
  gap: 0.5rem;
}

.nav__link {
  padding: 0.75rem 1rem;
  font-size: 0.875rem;
}

@container (min-width: 600px) {
  .nav {
    flex-direction: row;
    align-items: center;
  }

  .nav__link {
    padding: 0.5rem 1rem;
  }
}

@container (min-width: 900px) {
  .nav__link {
    font-size: 1rem;
    padding: 0.5rem 1.5rem;
  }
}

Sidebar Layout With Container Queries

Here’s a practical dashboard layout where the main content and sidebar both contain the same widget component, but it adapts to each context:

.dashboard {
  display: grid;
  grid-template-columns: 1fr 320px;
  gap: 2rem;
}

.main-content,
.sidebar {
  container-type: inline-size;
}

.widget {
  background: var(--surface);
  border-radius: 0.5rem;
  padding: 1rem;
}

.widget__chart {
  height: 150px;
}

@container (min-width: 500px) {
  .widget {
    display: grid;
    grid-template-columns: 1fr 1fr;
    gap: 1.5rem;
    padding: 1.5rem;
  }

  .widget__chart {
    height: 250px;
  }
}

@container (min-width: 700px) {
  .widget {
    grid-template-columns: 2fr 1fr 1fr;
  }
}

The widget in the main content area (wide) gets the multi-column layout. The same widget in the sidebar (narrow) stays stacked. One component, zero conditional logic.

Container Queries vs Media Queries: When to Use Each

Container queries don’t replace media queries — they complement them.

Use container queries for:

  • Component-level layout changes (cards, widgets, nav)
  • Reusable components that appear in different contexts
  • Design system components that need to be context-agnostic

Use media queries for:

  • Page-level layout shifts (switching from sidebar to stacked)
  • Viewport-dependent UI (mobile nav toggle, full-screen modals)
  • Print styles
  • User preference queries (prefers-color-scheme, prefers-reduced-motion)

Tailwind v4 Integration

Tailwind v4 has first-class container query support. Define a container with @container and use size variants:

<div class="@container">
  <div class="flex flex-col @md:flex-row @lg:grid @lg:grid-cols-3 gap-4">
    <!-- Responds to container width, not viewport -->
  </div>
</div>

The @sm, @md, @lg variants map to container widths: 320px, 448px, 512px and so on. Named containers work too: @container/sidebar with @sm/sidebar:flex-row.

Container queries have shipped in every major browser since mid-2023. There’s no reason not to use them. Once you start building components that are truly context-independent — that look correct no matter where you drop them — you won’t want to go back to viewport-based gymnastics.

Adrian Saycon

Written by

Adrian Saycon

A developer with a passion for emerging technologies, Adrian Saycon focuses on transforming the latest tech trends into great, functional products.

Discussion (0)

Sign in to join the discussion

No comments yet. Be the first to share your thoughts.