Building a container-query-driven card component

WHAT THIS TESTS: This evaluates whether you can architect a reusable component whose layout depends on its allotted space, including correct container declaration, naming, and unit choices.

A GOOD ANSWER COVERS: First, separate the container from the styled element. Give the card a wrapper and set container-type: inline-size on the wrapper so its inline width can be queried; add container-name: card to address it unambiguously. The card's own markup, the image, title, and body, sits inside the wrapper. Next, define the default, narrow layout on the card as a single stacked column. Then write @container card (min-width: 400px) { .card { display: grid; grid-template-columns: 140px 1fr; align-items: start; } } so that when the wrapper is at least 400px wide the card becomes side-by-side. Because the query reads the wrapper, the same component adapts in a sidebar or a main column with no viewport awareness. Optionally use container query units such as cqi for fluid padding and font sizes that scale with the container.

COMMON WRONG ANSWERS: Setting container-type on the card itself and then restyling that card, which the spec disallows because it would loop. Reaching for viewport media queries, which cannot tell whether the card is in a wide or narrow slot. Forgetting container-name and having generic @container rules collide. Omitting a sensible default for unsupported browsers.

LIKELY FOLLOW-UPS: How do cqi, cqw, and cqb units behave. Why might you choose size over inline-size and what constraint does that add. How do you progressively enhance with @supports.

ONE CONCRETE EXAMPLE: A .card-host with container-type: inline-size and container-name: card wraps every card. In a 280px sidebar the card stays stacked; dragged into a 700px main column the @container rule fires and it flips to an image-left, text-right grid, all driven by the wrapper width rather than the screen.