Media queries respond to the viewport, but components rarely care about the viewport; they care about the space they've actually been given inside whatever layout they've landed in. Container queries fix that mismatch, and early implementations have started showing up behind browser flags this year, which was enough for us to start testing seriously rather than waiting for full support to arrive.
Even in an early, flagged state, container queries already solve layout problems our component library has worked around with JavaScript-based resize observers for years. A card component that needs to switch from a horizontal to a stacked layout depending on the width of its parent, not the viewport, previously meant wiring up a ResizeObserver, storing the measured width in component state, and re-rendering on every change. With a container query, that same behavior is a few lines of CSS with no JavaScript involved and no re-render cost at all.
We're planning our component architecture around container queries well ahead of general availability, using feature detection to fall back to the resize-observer approach in browsers that don't support them yet. That means writing components twice, in effect, for the transition period, but it also means the codebase is ready to drop the JavaScript fallback entirely the moment support is broad enough to justify it, rather than facing a second migration project a year or two from now.
Getting the feature-detection fallback right took more care than we initially expected. `@supports` queries for container-query syntax aren't uniformly implemented across the early browser builds that support the feature at all, so a naive feature check would sometimes report support and then fail silently on the actual query syntax being used. We ended up testing against a small, real container query rather than trusting a broad feature-support flag, which reliably distinguishes "supports this specific syntax" from "claims to support container queries in general," a distinction that mattered more than we expected given how early-stage this all still is.
The team also had to unlearn some habits picked up from years of media-query-first thinking. A component author's first instinct is still to reach for a viewport breakpoint even when the actual layout decision depends on the component's container width, not the screen size, simply because that's the tool everyone has used for a decade. We started flagging this specifically in code review, asking whether a given responsive decision is really about the viewport or about the space available to the component, which has slowly retrained the habit across the team faster than documentation alone would have.
We picked our component library's card and sidebar-widget components as the first real production candidates for container queries, specifically because both already had a JavaScript-based resize-observer fallback we could compare directly against. Having a working baseline to measure the container-query version against, rather than building it in isolation, made it much easier to confirm the new approach was actually equivalent in behavior and not just superficially similar during a quick visual check.
The rough edges are real and worth naming honestly. Query syntax and browser support are still shifting, DevTools support for debugging container queries is thin compared to the mature tooling around media queries, and we've had at least one case where behavior differed subtly between two browsers implementing what's nominally the same spec. None of that has been enough to talk us out of adopting the pattern early; it's enough to keep it scoped to components where the payoff clearly outweighs the current instability, rather than rewriting the whole component library on day one.