Why can a reusable card component not be made truly responsive with CSS @media queries alone, and what do container queries change?

## The mismatch between viewport and component A CSS media query answers questions about the **viewport** — the window's width and height, its orientation, resolution, and the user's stated preferences. That model fit an era when a page was a single design that reflowed as a whole: the layout changed at 768px and every part of it changed at the same moment. Component-based UIs broke the assumption. A "product card" is authored once and then dropped into a wide main column on one page, a 280px sidebar on another, a three-across grid on a third, and a modal on a fourth. Whether the card should put its image beside the text or above it depends on how much inline space it was handed — and the viewport says nothing about that. On a 1400px desktop the sidebar card has 280px to work with, but a `@media (min-width: 900px)` rule fires anyway and gives it a two-column layout that immediately overflows. The classic workarounds all leak layout knowledge out of the component: - modifier classes such as `card--compact` that the **page** has to remember to apply; - placement-coupled overrides like `.sidebar .card { … }`, which break the first time the card moves; - a script that measures the box after layout and re-adds a class. Each one is a maintenance tax, and each one is wrong again as soon as somebody uses the component somewhere new. ## What a container query does instead A container query evaluates against an **ancestor element** rather than the viewport. Two pieces are required. First, some ancestor must opt in to being a query container: ```css .card-wrapper { container-type: inline-size; } ``` Second, the component's own rules are wrapped in `@container`: ```css .card { display: grid; gap: 1rem; } @container (min-width: 400px) { .card { grid-template-columns: 8rem 1fr; } } ``` An unnamed `@container` rule resolves against the **nearest ancestor query container** of each matched element. So the very same `.card` rule produces a stacked layout inside a 280px sidebar wrapper and a two-column layout inside a 900px main-column wrapper, with no page-level cooperation at all. Conditions use the same comparison vocabulary as media queries, including range syntax: `@container (width >= 400px)` is equivalent to the `min-width` form above. CSS also provides container-relative length units so a component can size type and spacing against its container rather than the window; they are a separate topic, but they exist for exactly this reason. ## The opt-in is deliberate `container-type` defaults to `normal`, which means no element is a size query container until you say so. That is not an oversight. Making an element a size query container applies **containment** to it — the browser gets a promise that the element's contents cannot influence its size in the queried axis, which is what makes the query resolvable without circularity. You would not want that applied to every element on the page, and you would not want the layout side effects either. ## Why the card cannot be its own container If `.card` both declares `container-type` and is the target of `@container`, nothing happens. The rule matches against the element's **ancestor** container, never itself — otherwise a rule could change the very width it was querying and loop forever. In practice this is the single most common beginner mistake: put `container-type` on a wrapper element and style the children. ```css /* wrong: the card can never match its own query */ .card { container-type: inline-size; } @container (min-width: 400px) { .card { … } } /* right: wrapper is the container, card is the queried subject */ .card-wrapper { container-type: inline-size; } @container (min-width: 400px) { .card { … } } ``` ## What media queries still own Container queries do not retire media queries. Anything that is genuinely a property of the output device or the user remains a media query: the page shell and overall page composition, `print`, resolution, `orientation`, and user preferences such as colour-scheme or reduced-motion. A good rule of thumb is that media queries decide the **page**, container queries decide the **component**. ## Practical notes Container queries shipped in Chrome 105, Safari 16 and Firefox 110, so as of 2026 they are broadly available and no longer need a fallback in most products. When you do need one, the graceful path is to write the narrow, single-column layout as the base styles and let the `@container` block be pure enhancement — a browser that ignores the at-rule then renders the compact form, which is usually acceptable rather than broken.