Responsive design today is built almost entirely around media queries tied to viewport width, which works well for whole-page layout but breaks down for reusable components that might sit in a wide main content area on one page and a narrow sidebar on another. A component styled with viewport-based media queries has no way to know which context it is actually in.
Container queries, which would let an element's styles respond to the size of its containing element rather than the viewport, are still an early proposal with no shipped browser support, but the direction matters enough to our component-based way of building sites that we are following the spec discussion closely. We currently work around the gap with JavaScript-based container query polyfills on the rare project where it matters enough to justify the added complexity, but it is a stopgap, not a real solution.
It may be years before this ships broadly, but when it does, we expect it to change how we design reusable component libraries as much as flexbox changed page layout.
The specific polyfill approach we tried
On the one project where the gap mattered enough to justify the added complexity, we used a JavaScript-based polyfill that observes an element's size via the ResizeObserver API and toggles data attributes or classes based on configured size thresholds, which a component's own CSS can then key off of. It works, but it adds a runtime dependency and a small amount of unavoidable layout-shift risk during the brief window between an element's size changing and the polyfill's JavaScript reacting to it, neither of which a native browser implementation would need to worry about at all.
Why we are not reaching for this polyfill by default
Given those tradeoffs, we are deliberately not adopting this polyfill as a default part of our component library, reserving it only for the specific case where a component's context-dependent sizing need is significant enough to justify the added JavaScript dependency and its small behavioral rough edges. For most projects, we are still designing components primarily around viewport-based media queries and accepting that a genuinely context-aware, "adapts to whatever container it's placed in" component remains out of reach until real browser support exists.
What we are watching for before this becomes a default part of how we build
Once container queries ship with real, broad browser support, we expect to revisit our entire approach to building reusable components, designing them from the start to respond to their container's size rather than the viewport's, and we are already sketching out internally what that shift might look like for our current component library so the eventual transition is a deliberate migration rather than a scramble once support actually lands.