CSS Container Query Interview Questions: Containment, Named Containers, and Fallbacks

A card sits in a narrow sidebar and a wide main column on the same desktop viewport. A media query sees the same viewport in both places; a container query can let the card adapt to the width of its own layout context. The CSS container query interview question is not “Can you remember @container?” It is “Which ancestor is queried, what containment did you create, and what remains usable when the query is unsupported or cannot match?”

The mechanics here follow the current MDN container-query guide, container-type reference, and @container reference. The sidebar/main-panel fixture and test matrix are original interview exercises, not candidate reports.

What problem do container queries solve?

Media queries react to a viewport or device feature. That is useful for page-level layout, but a reusable card can be narrow in a sidebar even when the viewport is large. A component that changes based only on viewport width can accidentally use its wide layout in a 260-pixel slot. A size container query reacts to an eligible ancestor's dimensions, so the card can respond to the space it actually receives.

This does not mean container queries replace media queries. A page may use media queries to change the overall grid and container queries to adapt a component inside each grid area. The interview answer should name the layout boundary: which element owns the space, and which descendant changes. Without that boundary, @container becomes another unexplained magic breakpoint.

The key limitation is that the query styles descendants of the query container, not normally the container element itself based on its own size. Put container-type on a wrapper around the card, then write a query that styles the card. If you put both the query and target on the same element and expect it to style itself by its width, diagnose the ancestor relationship before changing breakpoint numbers.

What containment must you establish?

A size query needs an eligible query container. For a typical horizontally resizing card region, container-type: inline-size is often the narrowest useful declaration. MDN says it allows queries of the inline dimension and applies layout, style, and inline-size containment. container-type: size permits both inline and block dimension queries but imposes size containment in both dimensions. That can affect how the element contributes intrinsic size to its parent, so do not reach for it when only width matters.

container-type: normal is the default. MDN notes it is not a query container for size queries, though it can participate in name-only or style queries under the relevant rules. That distinction matters: “normal means no container queries of any kind” is too broad. If the task is a width breakpoint, it needs the appropriate size-query context. If the task is a style or name-only query, inspect those separate semantics instead of assuming width behavior.

Here is a compact starting point for the fixture:

.card-slot {
  container: card-slot / inline-size;
}

.feature-card {
  display: block; /* usable narrow baseline */
}

@container card-slot (min-width: 36rem) {
  .feature-card {
    display: grid;
    grid-template-columns: 12rem minmax(0, 1fr);
    gap: 1rem;
  }
}

The name in the container shorthand and in the query must agree. The actual threshold is a design decision, not a standards fact; 36rem is simply a testable point for this card. Keep the default card readable below that width or when queries are unavailable. The image must have a sensible size, the text column must be allowed to shrink with minmax(0, 1fr), and long unbroken content still needs wrapping rules.

Which ancestor answers an unnamed or named query?

For an unnamed size query, the browser uses an eligible ancestor in the element's ancestor chain, typically the nearest one that can answer the query. That can surprise a candidate who assumes the page-level wrapper always wins. If a nested sidebar container is closer to the card than a page container, the sidebar's width drives the card. Inspect the DOM ancestry and computed container-type, then measure the element that is actually queried.

Named containers make the intention clearer. container-name: card-slot or container: card-slot / inline-size lets @container card-slot (...) target a matching named context in the ancestor chain. Names help in a layout with nested containers, but they do not make the viewport or a non-ancestor into a valid source. If an element has no matching eligible ancestor, the size query will not produce the desired conditional styling. A misleading name on the target element itself also does not fix the descendant rule.

A diagnostic exercise uses this tree: Page is 1100 pixels wide; Sidebar inside it is 280; a Card is inside Sidebar. Both Page and Sidebar are configured as inline-size containers. An unnamed query at 600 pixels should follow the nearer Sidebar and stay in the narrow style, despite the wide Page. A named query for Page may be used when the product truly wants the outer context. But ask whether the card should know about Page at all; often the nearer component slot is the better design.

How do you debug a query that never applies?

First inspect the target selector and the DOM. Is the styled element a descendant of the declared container? Is the intended wrapper an ancestor rather than a sibling? If the relationship is wrong, changing width values cannot repair it. Next inspect the computed container-type and container-name; a class on the wrong element, a later shorthand that resets a name, or an unexpected nested container can change which box is queried.

Then measure the query container's actual inline size, not the browser window. An element with padding, a scrollbar, or an unusual writing mode may not have the value you assumed. If the query uses min-width, check the computed width at either side of the threshold. Use developer tools to compare the narrow sidebar and wide main slot on the same viewport; that is the fastest way to prove the component is container-responsive rather than viewport-responsive.

Finally examine containment's layout impact. A wrapper that previously sized itself from its child can shrink or behave unexpectedly after you give it size containment. Inline-size containment avoids the block-axis size containment of size, but still changes sizing behavior. Provide an explicit track, width, or parent layout when the context needs one. A card that disappears due to its containing layout is not a breakpoint typo.

Observation	Likely question	Useful check
Wide card appears inside narrow sidebar	Is the query reading Page instead of Sidebar?	Inspect closest eligible ancestor and names
Query never activates	Is the target a descendant of the container?	Inspect DOM, computed type, and measured width
Card wrapper collapses after adding size	Did containment change intrinsic sizing?	Compare inline-size and parent sizing
Query works only in one slot	Does that slot have the declared name/type?	Compare computed styles across both wrappers
Card overflows despite a matching query	Is the inner grid allowed to shrink?	Test long text and minmax(0, 1fr)

This table is an original debugging aid. It gives falsifiable checks rather than promising one CSS property always solves a particular screenshot.

What fallback is worth designing?

Progressive enhancement begins with a usable base layout. The example's .feature-card { display: block; } works in a narrow slot and remains readable even if no size query matches. The container rule enhances it to a two-column layout when the slot is wide enough. A browser without the relevant feature keeps the baseline styles; do not make essential content appear only inside @container.

An @supports (container-type: inline-size) check can be useful when additional declarations must be gated, but it is not always necessary for a simple progressive style rule. The more important fallback is semantic and visual: content order, image alt text, and readable text remain intact. If product requirements mandate a close wide-layout approximation on older browsers, use a tested alternative such as a component modifier supplied by layout code, or an appropriate page-level media query with clear limitations. Do not pretend a viewport query is equivalent in a two-slot fixture.

Container query units such as cqi can scale details with a query container; MDN also documents their fallback behavior when no eligible container exists. That is a separate concern from whether an @container rule matches. Avoid sprinkling container units into the initial solution before the ancestor and breakpoint behavior is proven. A stable base font size is often easier to verify.

What would you test in an interview fixture?

Render the same card instance design in a 280-pixel sidebar and a 760-pixel main column while the viewport stays fixed. Assert that the sidebar card stacks and the main card uses two columns. Resize only the sidebar while holding the viewport constant and verify the card changes at the defined threshold. Then put a smaller nested container inside the main column and verify an unnamed query follows the nearer eligible ancestor.

For named behavior, give Page and Sidebar distinct names, then change the query name deliberately. The expected layout should change only when the named ancestor and threshold match. Remove the name and confirm the base style remains usable. Also test a very long title, a narrow image, high text zoom, and a right-to-left or vertical-writing context if the product supports them; the use of inline size rather than physical width should be intentional.

A browser test is more valuable than checking that a CSS string contains @container. The failure this interview is meant to catch is behavioral: same viewport, different component slots. Capture computed styles and screenshots at both slot widths. A good candidate can point to the queried ancestor in developer tools and explain why a different ancestor would change the result.

A concise interview answer

“I would wrap the reusable card in a slot with container-type: inline-size, keep a readable stacked base layout, and add a size query for a wide two-column version. The query styles the card because the card is a descendant of the slot. I would verify which eligible ancestor answers an unnamed query and use a name only when a specific ancestor is part of the component contract. My test puts the same card in a narrow sidebar and wide main area on one viewport, then resizes only one container. I would check intrinsic sizing and long-content overflow before calling it done.”

That answer distinguishes official CSS mechanics from a breakpoint selected for this original exercise. No candidate report is needed to establish how CSS works, and no claim is made about how often a company asks it.

Sources and further reading

• MDN: CSS container queries — size contexts, naming, shorthand, units, and fallback ideas.
• MDN: container-type — normal, inline-size, and size behavior.
• MDN: @container — query syntax and matching behavior.
• MDN: CSS containment — layout and intrinsic-sizing implications.