Container Queries

## The three pieces A working container query always has three parts: an element that opts in as a container, an optional name for it, and an `@container` rule whose selectors target that container's descendants. ```css /* 1 + 2: the wrapper opts in and takes a name */ .card-slot { container-type: inline-size; container-name: card; } /* 3: the component's rules, conditional on the container's width */ @container card (min-width: 400px) { .card { grid-template-columns: 8rem 1fr; } } ``` The shorthand collapses the first two declarations, with the name before the slash and the type after it: ```css .card-slot { container: card / inline-size; } ``` The order matters and is easy to invert from memory — it is `name / type`, matching the way `@container <name> (<condition>)` reads. ## container-type: what to pass - `inline-size` — queryable on the inline axis (width in a horizontal writing mode). This is what you want almost always. - `size` — queryable on both axes; only sound when the element has a definite size in both, otherwise it collapses. - `normal` — the default; not a size query container. ## The name is optional Without a name, `@container (min-width: 400px)` resolves against the **nearest ancestor query container** of each element the inner selectors match. That is usually what you want, and unnamed queries keep components portable — the component does not need to know what its slot is called. Names earn their keep when containers nest. Consider a card container inside a page-region container: an unnamed query inside the card will always hit the card. If a rule needs the outer region's width, name the containers and query the outer one explicitly: ```css .region { container: layout-region / inline-size; } .card-slot { container: card / inline-size; } @container layout-region (min-width: 60rem) { … } /* skips past the card */ ``` A container may carry several names (`container-name: card sidebar-slot;`), which lets one element answer to more than one query vocabulary. ## Writing the condition The condition grammar mirrors media queries. Both of these are the same query: ```css @container card (min-width: 400px) { … } @container card (width >= 400px) { … } ``` Range syntax also supports two-sided ranges — `@container card (400px <= width < 700px)` — and conditions combine with `and`, `or` and `not`, plus parentheses for grouping. Because the queried axis is inline under `container-type: inline-size`, height-based conditions such as `min-height` will not match; those require `container-type: size` on a container with a definite height. Inside a container query you can also use container-relative length units, which resolve against the query container rather than the viewport; they are a topic of their own but they pair naturally with these rules. ## The direction of application This is the part that trips people up. The block styles **descendants of the container**, not the container. This does not work: ```css /* broken: .card is the container and can never match its own query */ .card { container-type: inline-size; } @container (min-width: 400px) { .card { grid-template-columns: 8rem 1fr; } } ``` An element matching its own size query would create a circular dependency — the rule could change the width the query just measured — so the specification simply excludes it. The fix is structural: keep a wrapper as the container and style the component inside it. ```html <div class="card-slot"> <article class="card"> … </article> </div> ``` In practice, most component libraries add exactly one wrapper element per placement slot for this reason, and the component itself carries only `@container` rules — which is what makes it portable across pages. ## Feature detection If you need to branch on support, `@supports (container-type: inline-size) { … }` is the correct test. In most products this is no longer necessary; the usual approach is to write the narrow layout as the base styles so an unsupporting browser simply keeps it.