Container queries are quietly becoming the default — and the holdouts are running out of excuses
Container queries shipped in every major browser in February 2023. Three years in, the share of new CSS that reaches for @container instead of @media for component-level responsive behavior is finally crossing the 50% line in component libraries we've audited. The change is happening quietly because the migration is incremental — most teams haven't replaced their existing media queries; they're just writing the new ones differently. But the language of frontend layout is shifting under our feet, and the holdout patterns are getting harder to defend.
Why the old default was wrong
Viewport media queries assume a component knows where it lives on the page. They worked when most websites had one consistent layout — a single content column that occupied roughly the full viewport width — and a sidebar that lived in the same relative position on every page. That world dissolved the first time someone built a card component that needed to render at full width on its own page, at half width inside a two-column grid, and at quarter width inside a four-column dashboard tile. The viewport hadn't changed. The container had. Media queries had no way to know.
The workaround for a decade was per-page CSS or modifier classes — .card--compact, .card--wide, .card--dashboard — toggled by the parent that knew the available space. Container queries finally let the card answer for itself: if I have less than 320px to work with, stack vertically; if I have more than 480px, lay out horizontally with the image floated left.
What the migration actually looks like
In practice, teams aren't doing big-bang rewrites. The migration we're seeing on real codebases is shaped like this: page-level layout (which sections appear, how the nav collapses) stays in viewport media queries. Component-level layout (how a card or a stat block or a navigation list internally arranges itself) moves to container queries. The dividing line is "would this rule break if I moved this component to a different page or column width?" If yes, it's component-level and should be a container query. If no, it's page-level and can stay viewport-driven.
The mechanical migration is small. Declare a containment context: .card-wrapper { container-type: inline-size; }. Replace the viewport check: @media (min-width: 480px) becomes @container (min-width: 480px). That's it for the simple case. The rest of the rules inside the block stay identical.
The holdout patterns
Three patterns are keeping the migration slower than it could be. First, the SCSS-mixin-based responsive system: most teams have a @include respond-to(tablet) mixin that expands to a media query, and replacing it requires touching the design-system library, not just the component. Second, the JS-conditional pattern: components that read window.matchMedia at runtime to switch behavior — those can't migrate to a CSS-only solution and either need a ResizeObserver wrapper or a refactor toward CSS-only responsive behavior. Third, the layered-design-tokens pattern, where breakpoint tokens (--breakpoint-md: 768px) are referenced throughout — container queries technically support custom-property breakpoints via style() queries, but adoption there is much earlier.
None of these are blockers. They're inertia, and inertia gets ground down a component at a time. The teams shipping new design systems in 2026 are almost all container-query-first; the teams maintaining design systems from 2018-2022 are doing the slower migration.
The deeper shift
There's a quieter philosophical change worth naming. Viewport-driven responsive design implicitly assumes the page is the unit of design. Container-driven responsive design treats the component as the unit, with the page as a composition of components that each adapt to their slot. That second model is closer to how design systems describe themselves on Figma boards and Storybook pages, and farther from how 2010s-era HTML/CSS actually worked. The language is finally catching up to how the discipline thinks. The teams that internalize the shift earliest end up with component libraries that genuinely work across more contexts; the ones that hold on to viewport-only responsiveness keep building libraries that need a special "in dashboard" variant of every card.
If you haven't started the migration, the lowest-cost first step is one component. Pick the most-reused card in your design system, declare a containment context on its wrapper, and convert one media query inside it to a container query. Twenty minutes of work, and you'll have a sense of whether the mental model fits how your team thinks. In most cases it does, and the rest of the system follows naturally over a few quarters.