Container Query Length Units

The plain-language idea

vw and vh size something relative to the viewport — 5vw is always 5% of the browser window's width, no matter what element it's applied to. Container query units do the same job, but relative to a query container instead of the viewport: 1cqi is 1% of the nearest queryable ancestor's inline size (its width, in a normal horizontal writing mode), not 1% of the screen.

That distinction matters because a component doesn't live in the viewport, it lives inside whatever wraps it. A card in a 300px sidebar and the same card in a 900px content column both see the same viewport width, but very different amounts of actual space. A unit tied to the viewport can't tell them apart; a unit tied to the container can, because it's measuring the thing that actually constrains the component's layout.

The full set mirrors the viewport units it's modeled on:

• cqw — 1% of the container's width
• cqh — 1% of the container's height
• cqi — 1% of the container's inline size (width, in most writing modes — this is the one to prefer, since it stays correct if the writing mode changes)
• cqb — 1% of the container's block size (height, in most writing modes)
• cqmin — 1% of whichever of the container's width/height is smaller
• cqmax — 1% of whichever is larger

They only resolve to a number inside an element that has a queryable container in its ancestry (something with container-type set) — used outside of one, they don't have a container to measure and fall back to their initial value.

See it in a real thing: a heading that scales with its card, not the screen

.card-container {
  container-type: inline-size;
}

.card-heading {
  /* Scales continuously with the container's width, with sane floor/ceiling */
  font-size: clamp(1rem, 0.75rem + 2cqi, 1.75rem);
}

@container (min-width: 480px) {
  .card-heading {
    font-weight: 700;
  }
}

clamp(1rem, 0.75rem + 2cqi, 1.75rem) reads the same way any clamp() does — a minimum, a preferred value, a maximum — except the "preferred" term is driven by the container's width instead of the viewport's. As the card's container grows from 300px to 600px, the heading grows smoothly across that entire range, not just at the one breakpoint the @container rule defines. That's the piece discrete @container breakpoints alone can't give you: a breakpoint is a jump at one width; a container query unit is a continuous function of width. The two compose naturally — use @container for structural changes (stack to row, hide an element) and container query units for the smooth scaling in between those structural jumps.

What people usually miss

Watch out

• The unit only resolves inside a container's descendant tree. An element needs a queryable ancestor (container-type set somewhere above it) for cqi and friends to mean anything — used on an element with no such ancestor, the unit doesn't error, it just resolves against the initial containment context, which usually isn't what was intended.
• cqi/cqb are the safer default over cqw/cqh, for the same reason inline-size is generally preferable to width elsewhere in modern CSS — they track the container's logical axes, so they keep working correctly if the writing mode or text direction changes, where the physical units wouldn't.
• These units are the newer, less battle-tested half of the container query story. Basic container query support (container-type and @container for layout) is solid enough to rely on as a primary tool now; the length units specifically are a more recent addition and worth an @supports (container-type: inline-size) check (which covers the whole container-query feature set, units included) if a product still needs to support meaningfully old browsers.
• A raw 2cqi with no clamp() around it has no floor or ceiling. Left alone, text sized purely in container query units can shrink to unreadably small in a narrow container or balloon oversized in a very wide one — pairing it with clamp() (as in the example above) is the practical pattern, not using the raw unit alone.

Why this matters in interviews

"How would you make a component's text scale smoothly with the space it's given, not just jump at a breakpoint?" tests whether a candidate knows container query units exist at all, since the instinctive answer without them is usually a pile of extra @container breakpoints trying to approximate what one clamp() with cqi does natively.