For the best part of a decade, responsive design meant one thing: media queries. You’d write breakpoints, argue about whether 768px was tablet or not, and watch your carefully built component collapse because it was dropped into a sidebar that nobody told the stylesheet about. Container queries fix that. Properly. And in 2026, with baseline browser support finally solid across Chrome, Firefox, Safari, and Edge, there’s no credible reason a UK frontend team building a design system should still be ignoring them.
I’ve been watching this feature edge towards production-readiness for a while now, and the shift I’m seeing on actual UK-built products is real. Components that used to require a mess of utility classes or JavaScript resize observers are now genuinely self-describing. The component knows how big its container is. It responds to that. Not to the viewport. That distinction sounds small. It absolutely isn’t.
What CSS container queries actually do (and why media queries couldn’t)
The core problem with media queries is that they’re global. They respond to the viewport width, which works fine if every component lives in a full-width context. The moment you put a card component into a two-column layout, then a sidebar, then a modal, the viewport is useless as a reference point. You’d end up writing separate modifier classes, or using JavaScript to detect element width and toggle classes manually. Neither is clean.
Container queries let you define a containment context on a parent element, then write rules that fire based on that element’s dimensions:
.card-wrapper {
container-type: inline-size;
container-name: card;
}
@container card (min-width: 400px) {
.card {
display: grid;
grid-template-columns: 1fr 2fr;
}
}
The .card component now responds to how wide .card-wrapper is, regardless of what the viewport is doing. Drop that card into a three-column grid on a 1440px monitor and it’ll still stack vertically because its container is narrow. That’s component-level thinking. That’s what design systems have needed.
How this changes Figma-to-code handoff for UK product teams
The Figma-to-code workflow has always had a dirty secret: designers build components at fixed frame widths, developers then have to figure out how those components behave at every possible size and context. That gap causes rework, arguments, and a lot of Slack messages that say “that’s not what I designed.”
Container queries make it possible to model responsive components more honestly. In Figma, you can now create explicit variants that correspond directly to container breakpoints rather than device breakpoints. A card at 300px wide, a card at 500px wide, a card at 700px wide. Each maps to a container query rule. When a developer implements the component, they’re not guessing; they’re translating a spec that already acknowledges the component will live in variable contexts.
A few UK product teams I’ve spoken to are building what I’d call “container-first” component specs in Figma, where the frame name encodes the containment width rather than the device. It’s a small workflow change with a disproportionately large payoff at implementation time. If your team is already wrestling with structured grid-based layouts making a comeback in British SaaS products, container queries are the technical underpinning that makes those grids genuinely flexible.
Container query units: the bit most tutorials skip
Beyond the @container rule itself, there’s a set of container query length units that I think are criminally underused: cqi, cqb, cqw, cqh, cqmin, and cqmax. These work like viewport units, but relative to the nearest named container rather than the viewport.
cqi means “1% of the container’s inline size”. So a heading set to font-size: 5cqi will scale proportionally to its container width. That’s fluid typography without needing a clamp() calculation. It pairs brilliantly with the techniques in fluid typography using CSS clamp(), but for component-scoped scaling rather than viewport-scoped scaling.
The practical implication: a card component in a narrow sidebar gets proportionally smaller text automatically. The same component in a full-width hero context gets larger text. No extra classes, no JavaScript, no media query override spaghetti.
Browser support in 2026: the honest picture
Container queries landed in all major browsers during 2023, but I’d argue real-world adoption in UK production codebases only hit critical mass in 2025. The Can I Use data now shows global support above 93%, and the MDN Web Docs baseline classification moved to “Widely available” in late 2024. For UK-based teams building anything that doesn’t need to support IE11 (which is effectively nobody at this point, and if you’re still supporting IE11 I have questions), container queries are production-safe.
The one caveat worth mentioning: container-type: size (which establishes containment on both axes) can cause layout issues if you’re not careful about how you’re containing height. The far safer default is container-type: inline-size, which only tracks the horizontal axis. I’ve seen a few UK teams trip over this and spend an afternoon debugging a component that mysteriously collapsed to zero height. Stick to inline-size unless you specifically need both axes.
Practical patterns for UK design systems
Let me get specific about where container queries earn their place in a real design system. Three patterns I’d consider non-negotiable:
Card grids in variable contexts. A product card in an e-commerce listing should look different when it’s one of four across versus one of two. Container queries handle this without any grid-level awareness in the component itself. The component is truly portable.
Navigation components in sidebars. A lot of UK SaaS dashboards have collapsed sidebars where the navigation needs to switch from labelled icons to icon-only below a certain width. Previously this meant JavaScript, or a media query that broke the component in any non-standard layout. A container query on the sidebar parent solves it cleanly.
Data widgets in dashboard grids. If you’re building dashboards (and given the amount of UK green tech and fintech products I see coming through, a lot of teams are), a chart or stat widget needs to adapt to its grid cell. This is exactly the use case container queries were designed for. See how this applies to the broader challenges of designing data-dense dashboards that actually work for further context on component adaptability in grid systems.
What the migration path looks like
If you’re working in a codebase with existing media query-based responsive components, you don’t have to rewrite everything at once. The sensible approach is to identify components that are already “broken” in non-standard layout contexts, those are your highest-priority candidates. Wrap the component in a container context, migrate the relevant breakpoint rules to @container, test in your grid and sidebar contexts, and delete the media query rules that no longer need to exist.
Most UK teams I know are running this migration incrementally alongside new feature work rather than as a dedicated refactor sprint. That’s probably the right call. Container queries aren’t a crisis fix; they’re a quality-of-life improvement that compounds over time as more components get migrated.
The tooling support is also genuinely good now. PostCSS has stable plugins, Stylelint has linting rules for container query syntax, and if you’re using Storybook for your design system, you can set story viewport containers to simulate narrow container contexts. The workflow is mature enough to trust in production.
If your team is still debating framework choices alongside all of this, the Astro vs Next.js comparison for UK frontend developers is worth a read, since both frameworks handle container query-dependent CSS without friction, but the component model you choose affects how you structure containment contexts.
Container queries are one of those features that, once you’ve used them properly, make the old way feel genuinely primitive. They don’t replace media queries entirely (viewport-level layout decisions still belong there) but for component-level responsiveness, they’re the right tool. Time to use them.
Frequently Asked Questions
What are CSS container queries and how are they different from media queries?
CSS container queries let a component respond to the size of its parent container rather than the viewport. Media queries fire based on viewport width, which breaks down when the same component is used in different layout contexts like sidebars, modals, and full-width grids. Container queries solve that by making each component genuinely self-aware of its available space.
Are CSS container queries safe to use in production in 2026?
Yes. All major browsers including Chrome, Firefox, Safari, and Edge have supported container queries since 2023, and global browser support now sits above 93%. MDN classified them as ‘Widely available’ in late 2024, so for any UK team not supporting legacy browsers, they’re production-ready.
How do container queries affect the Figma handoff process?
They encourage designers to create component variants based on container width rather than device breakpoints, which maps directly to @container rules in code. This closes the gap between design intent and implementation, reducing the back-and-forth that typically happens when a component ends up in an unexpected layout context.
What is container-type: inline-size and should I use it instead of size?
container-type: inline-size establishes containment only on the horizontal axis, which is the safer default for most UI components. Using container-type: size establishes both axes and can cause elements to collapse to zero height if the container has no explicit height set. Stick to inline-size unless you have a specific reason to track both dimensions.
Can I use container query units like cqi for fluid typography inside components?
Yes, and they’re excellent for this. Container query units like cqi work like viewport units but relative to the nearest named container. Setting font-size: 5cqi on a heading means the text scales proportionally to its container width, giving you fluid typography at the component level without needing a clamp() calculation.