Responsive by Default: Container Queries Over Media Queries In short: A media query asks how big the window is. A shared component needs to know how much space it was given. Those are different questions, and only one of them has a useful answer. A from the library might end up in a four-column grid on a 4K dispatch monitor, squeezed into a 320px sidebar, or on a tablet on the warehouse floor. Same component, three very different amounts of room. If its layout depends on media queries, it will be wrong in at least two of those places. The media query mismatch On a 1920px monitor the media query is true, so the card lays out horizontally. Correct in the main grid. Now a feature team puts the same card in a 300px sidebar. The viewport is still 1920px, so the card still goes horizontal — inside 300px. Text overlaps, the progress bar overflows, and a horizontal scrollbar appears. The component asked "how big is the screen?" when the question it needed answered was "how much room do I have?" The old workaround was a input: Now every consumer must know which layout fits where, and must update it when their own layout changes. This is exactly the pattern Chapter 5 argued against. Container queries ask the right question tracks the inline (usually horizontal) dimension only. That is what you want almost always — requires the element to have a definite block size too, and using it by accident collapses your component to zero height. Now the card lays out correctly in a grid track, a sidebar, or a resizing split pane, without anyone telling it where it is. Note the is on , not on an inner wrapper. A container query cannot match against the element that declares the container — only against its descendants — so the host is the natural place for it, and it means the component works without an extra wrapper element. Container query units Inside a container you can size relative to the container rather than the viewport: with gives fluid type that responds to the component's own width. Keep the bounds tokenised so it stays inside the design system. Where media queries still belong Container queries do not replace media queries — they answer a different question. Question Tool --- --- How much space does this component have? What kind of device is this? Does the user prefer reduced motion? Does the user prefer dark? Page-level layout: how many columns on this screen? Printing? The rule: components use container queries; page layouts use media queries. The application decides how many columns the grid has; the card decides what to do with the column it gets. Two media queries every library component should honour: That second one is a genuine accessibility requirement, and a container query cannot express it — touch target size depends on the input device, not the available space. Logical properties While you are here, prefer logical properties. They cost nothing and they make right-to-left support close to free: For a platform that may ship in more than one locale, retrofitting this later is a large, error-prone change. Doing it from the start is a naming choice. The payoff No input. No consumer knowledge. The component adapts to what it is given, which is the CSS expression of the same principle as Chapter 5's projection slots: the library owns its own behaviour, the consumer owns the arrangement. "But I thought container queries were too new to rely on" This was a reasonable position for a while, and caution about CSS features is usually well founded — it is the class of thing that fails silently on the one browser your users have. Container queries are past that point. They have been in every major evergreen browser for years, they are part of the stable CSS Containment specification, and Angular does nothing to interfere with them under any encapsulation mode. The more interesting question is what happens if you are wrong about support, and here container queries are unusually forgiving. An unsupported block is simply ignored — so the styles outside it still apply. If you write mobile-first, as above, the fallback is the narrow layout, which is functional everywhere. Compare that with a feature like , where a lack of support leaves the layout genuinely broken. You can also state the requirement explicitly: Though in practice, writing the narrow layout as the default already gives you the graceful degradation. The comparison that actually matters is not "new versus safe" — it is what each approach costs you in a component library: Media queries input Container queries --- --- --- --- Correct in a narrow sidebar No Only if the consumer sets it Yes Correct in a resizable split pane No No — it is static Yes Consumer must know the context No Yes No Inputs added to the component 0 1, permanent 0 Breaks when the consumer changes their layout Yes Yes No Fallback if unsupported N/A N/A Narrow layout — usable The middle column is the one worth avoiding hardest. A input looks like the pragmatic compromise, but it is a permanent…