Responsive design has been stuck on one flawed assumption since media queries were invented: that a component should look different based on the size of the browser window, not the size of the space it’s actually sitting in. Container queries finally fix that, and it’s a bigger deal for how we build component-based UIs than most of the discourse around it suggests.
The problem media queries never actually solved
A card component in a three-column grid needs to look different than the same card component full-width in a sidebar - but with media queries, both instances only know the browser window’s width, not their own. The workaround has always been writing brittle, context-specific CSS for every place a component might be reused, or building multiple variants of the same component for different layout contexts. Neither is genuinely reusable, which defeats the purpose of component-based design in the first place.
What container queries actually let you do
A component can now respond to the width of its own container, not the viewport - so a card component adjusts its own internal layout based on how much space it’s actually been given, whether that’s a third of a wide desktop layout or the full width of a narrow sidebar, using the exact same component code. This is the property that finally makes truly reusable, self-contained components possible: a component’s internal responsive behavior is now genuinely a property of the component, not something that has to be re-derived at every place it’s dropped into a page.
Where this changes how we actually build design systems
- Components stop needing “compact” and “expanded” variants maintained separately. One component definition handles both, responding to its container automatically - less duplicated code, one source of truth to maintain and test.
- Dashboard and grid-heavy layouts get dramatically simpler. Widgets that need to work in a 2-column, 3-column, or full-width grid position - extremely common in SaaS dashboards - no longer need layout-aware JavaScript or a proliferation of CSS classes tied to grid position.
- Design system components become genuinely portable across contexts a design team didn’t explicitly plan for, because the component’s responsiveness is self-contained rather than dependent on knowing where it’ll be placed.
Where we’re still cautious
Container queries are well-supported in modern browsers now, but “modern browsers” still isn’t universal, and for products with a meaningful legacy browser audience, this needs a real compatibility check, not an assumption. The other practical consideration: container queries add a genuine new layer of responsive complexity - components can now respond to both viewport (media queries) and container (container queries) simultaneously, and without discipline that can produce CSS that’s harder to reason about, not easier. We treat container queries as the default tool for component-internal responsiveness and reserve media queries for genuinely page-level, layout-shell decisions - that separation keeps the mental model clean.
What this means practically for a rebuild or new build
If you’re building a new design system or component library now, container queries should be the default approach for any component meant to be reused across multiple layout contexts - it’s a meaningfully better default than the media-query workarounds teams have been living with for a decade. We don’t recommend retrofitting an entire existing component library purely to adopt this pattern; it’s highest-value for new components and genuinely earns a rebuild when an existing component’s layout-context brittleness is already causing real maintenance pain.
We build this into every design system we’re starting fresh today. If your component library is fighting you every time a component needs to work in a new layout context, get in touch and we’ll take a look at what’s actually happening under the hood.