Container Query Card — Free HTML CSS JS Snippet

Media queries ask "how wide is the viewport?" — but components don't live in viewports, they live in sidebars, grid cells, modals, and main columns of wildly different widths on the same screen. Container queries fix responsive design's original sin by letting a component ask "how wide is *my slot*?" This snippet demonstrates the complete pattern with the classic proving ground — a product card that renders three genuinely different layouts depending on the width of its container — wrapped in a drag-to-resize playground so you can watch every breakpoint fire, plus a fixed 240px column showing the identical markup adapting independently on the same page.

Two CSS lines create the containment context

Everything starts with the wrapper: .card-container { container-type: inline-size; container-name: card }. The container-type declaration establishes the element as a query container measured on its inline axis (width, in horizontal writing modes) — and critically, it applies *size containment*, meaning the container's width can no longer be influenced by its contents. That constraint is why container queries took a decade to ship: without containment, a child changing layout could change the container's size, re-triggering the query in an infinite loop. The optional container-name lets queries target this container specifically (@container card (min-width: 340px)) rather than the nearest ancestor container — essential hygiene once components nest.

Three layouts, one markup

The card's base styles define the narrow, stacked layout: media on top, tight padding, description hidden, only the first meta item visible. At @container card (min-width: 340px) the card flips to flex-direction: row — art on the left at 34% width, the description appears, and the body fills the remainder. At (min-width: 480px) the media grows to 40%, the meta list rotates from a column to an inline row revealing all three items, and padding and button sizing step up. Note what the queries change: *layout, visibility, and density* — the component's information hierarchy adapts, not just its scale. That is the design payoff of container queries: the same <article> dropped into a 240px rail renders the compact version while its sibling in a 560px main column renders the full version, with zero props, classes, or JS involved.

Fluid type with cqi units

The title uses font-size: clamp(14px, 6cqi, 19px) — cqi is a container query *unit*, 1% of the container's inline size. Between the clamp bounds, the title scales continuously with the container rather than jumping at breakpoints, which smooths the transitions between layout states. Container units (cqw, cqh, cqi, cqb, cqmin, cqmax) work anywhere lengths do and pair naturally with clamp() for per-component fluid typography — a technique impossible to express with viewport units when the same component appears at multiple sizes on one page.

The playground: pointer capture + ResizeObserver

The container queries themselves need zero JavaScript — the JS here only powers the demo apparatus. The drag grip uses the Pointer Events pattern (setPointerCapture so the drag survives the cursor leaving the grip) to set the playground's width between 230px and its parent's width. The live readout uses a ResizeObserver on the container — not on drag events — so it reports width changes from *any* cause, including window resizes, and annotates which layout tier is active. That observer pattern is also your escape hatch on the rare occasion JS needs to know about container size changes, since no "containerquery" DOM event exists.

Browser support has been universal since early 2023 (Chrome 105+, Safari 16+, Firefox 110+), making container queries safe for production today — and this component-first responsive approach is rapidly replacing viewport breakpoints as the default in design systems.