A CSS @container (min-width: 400px) block never applies even though the element is clearly wider than 400px on screen. What are the likely causes?

## Why this fails silently A container query that cannot resolve does not error, does not warn, and does not fall back — the block simply never matches. That makes it a debugging exercise rather than a syntax fix, and the causes are a short, memorable list. ## 1. No ancestor is a query container `container-type` defaults to `normal`, meaning "not a size query container". If nothing above the element opts in, there is nothing to query. ```css /* nothing here is a container */ @container (min-width: 400px) { .card { … } } /* never matches */ ``` Related near-miss: `contain: layout` or `contain: content` on an ancestor does **not** make it a query container. Only `container-type` (or the `container` shorthand) does. Assigning `container-name` alone does not either — a name without a type is just a label on a non-container. ## 2. The element is trying to query itself This is the most common cause in real code: ```css .card { container-type: inline-size; } @container (min-width: 400px) { .card { display: grid; } } ``` An element is never matched by a query against the container it *is*. The specification excludes it deliberately: if the rule could change the element's own width, the query condition would depend on its own result. The fix is structural — move `container-type` to a wrapper: ```css .card-slot { container-type: inline-size; } @container (min-width: 400px) { .card { display: grid; } } ``` If the component owns its own markup, this means adding a wrapper element, which is exactly why component libraries ship a slot element around each card. ## 3. The name matches nothing ```css .card-slot { container: card / inline-size; } @container cards (min-width: 400px) { … } /* typo: cards vs card */ ``` A named query that finds no ancestor with that `container-name` never matches. Container names are case-sensitive idents, and there is no diagnostic. This also happens after a refactor renames the wrapper but not the queries. ## 4. A nearer container is shadowing the intended one An unnamed `@container` resolves against the **nearest** ancestor query container. In a nested layout, the nearest is often not the one you were reasoning about: ```css .region { container-type: inline-size; } /* the wide one you meant */ .card-slot { container-type: inline-size; } /* the narrow one that wins */ ``` The card's unnamed query measures `.card-slot`, which may be 280px even though `.region` is 900px. The fix is to name the containers and query the intended one explicitly, or to remove the intermediate container if it was not needed. ## 5. Querying an axis the container does not expose `container-type: inline-size` makes only the inline axis queryable. A `min-height` or `height` condition against it cannot be evaluated and therefore never matches: ```css .panel { container-type: inline-size; } @container (min-height: 300px) { … } /* never matches */ ``` Querying block size requires `container-type: size`, which contains both axes — and that is only safe when the container has a definite height. Adding it to an auto-height wrapper collapses the wrapper to zero height, at which point the height query still fails, now for a different reason. ## 6. The container really is narrow The element on screen looking wide is not proof that the *container* is wide. Two cases recur: - The container shrink-wrapped. Under inline-size containment the container's intrinsic inline size is computed as if it had no content, so a float, inline-block, `fit-content` box, or content-sized grid or flex item collapses. The children still paint at their own width and overflow, so the page looks fine while the container measures nearly zero. - The content overflows a genuinely narrow container. Same visual, same wrong conclusion. ```css .card-slot { display: inline-block; /* was sized by its content */ container-type: inline-size; /* now measures ~0 */ } ``` Give the container a definite inline size, or move `container-type` onto a block-level ancestor that is parent-sized. ## A working diagnostic order 1. Inspect the intended container and confirm a `container-type` in its computed styles. 2. Confirm the styled element is a **descendant** of it, not the container itself. 3. If the query is named, confirm the ident matches exactly. 4. Walk up from the styled element and find the *first* container — that is the one an unnamed query uses. 5. Check the queried axis against the declared `container-type`. 6. Measure the container's own box, not the content inside it. Browser devtools mark query containers in the elements panel and show which container a `@container` rule resolved against, which collapses most of this list to a single look.