Container Query Hover Affordances: When Narrow Means Persistent, Not Hidden

Hover-to-reveal is a space trade: you buy a calmer default view by putting a function behind a pointer gesture. That trade is worth making in a wide card, where the hidden panel has somewhere to expand into and the resting layout genuinely benefits from the quiet. It is a bad trade in a 300px column, where the revealed panel would cover most of the content it describes, and it is no trade at all on a touchscreen, where the gesture that pays for it does not exist. This page is about making the affordance itself — not merely its size — a function of the container: a wide instance reveals a detail panel on hover, while the narrow instance of the same component ships a persistent control instead. It belongs to the container-aware motion section, and it is the point where container queries stop adjusting motion and start adjusting interaction design.

Why the container is the right signal, and what it cannot tell you

The decision "should this be hidden behind hover?" depends on two independent facts. One is whether there is physical room for a reveal that does not destroy the resting layout — a question about the component's box, which @container answers exactly. The other is whether the user's input device can hover at all — a question about hardware, which @container cannot answer and must not be asked to. Conflating them is the classic mistake, and it survives from the media-query era: authors treat "narrow" as a proxy for "touch", which was never reliable and is now plainly wrong in both directions. A 1200px touchscreen kiosk is wide and cannot hover; a 280px sidebar on a desktop is narrow and can.

So the two conditions get expressed with the two features that actually describe them. @container (min-width: …) decides whether there is space for a reveal. @media (hover: hover) and (pointer: fine) decides whether a reveal can be operated — the semantics of those features, including why any-hover behaves differently on hybrid devices, are covered in pointer and hover media queries. Only where both are true does hiding become defensible.

The alternative implementation is a script that measures the element and toggles a class. It works, but it puts a functional affordance — whether a control exists in the resting state — behind JavaScript execution and a layout measurement, which means the component has a visibly wrong first paint and a hard dependency on a bundle for something the browser can decide during style computation. The CSS version has neither.

There is one genuine cost to the CSS approach: both variants exist in the DOM at all times, so you cannot use the query to remove markup, only to restyle it. That is usually fine and occasionally a constraint — if the wide and narrow affordances need different accessible names or different roles, CSS cannot get you there, and a component that truly needs two different accessibility trees needs two different components.

Complete working implementation

The tile below is one component with one set of markup. Above 340px of container width, a summary overlay is parked below the artwork and slides up on hover or focus. Below 340px, that overlay rule never matches, so the summary is simply a paragraph in normal flow and the call-to-action is a permanently visible, comfortably tappable pill.

<div class="frame">
  <article class="tile">
    <div class="tile__art"><span class="tile__initials">KV</span>
      <div class="tile__overlay">
        <p class="tile__summary">Twelve tracks recorded live in a single afternoon.</p>
      </div>
    </div>
    <div class="tile__foot">
      <h3 class="tile__title">Kestrel Valley</h3>
      <a class="tile__cta" href="#">Details</a>
    </div>
  </article>
</div>

.frame { container-type: inline-size; container-name: tile; }

.tile {
  border: 1px solid var(--demo-border);
  border-radius: 12px;
  overflow: hidden;
  background: var(--demo-surface);
}

.tile__art {
  position: relative;
  display: grid;
  place-items: center;
  height: 150px;
  background: var(--demo-accent);
}
.tile__initials { font: 700 30px sans-serif; color: var(--demo-bg); }

.tile__foot {
  display: flex;
  align-items: center;
  justify-content: space-between;
  gap: .75rem;
  padding: .75rem 1rem;
}
.tile__title { margin: 0; font-size: 1rem; color: var(--demo-fg); }

/* NARROW DEFAULT — the summary sits in normal flow, the CTA is a real
   tappable target, and nothing depends on a pointer that can hover. */
.tile__summary {
  margin: 0;
  padding: .7rem 1rem;
  color: var(--demo-muted);
  font-size: .85rem;
}
.tile__cta {
  padding: .45rem .8rem;
  border: 1px solid var(--demo-accent);
  border-radius: 999px;
  color: var(--demo-accent);
  text-decoration: none;
  font-size: .82rem;
  white-space: nowrap;
}

/* WIDE — enough room to hide the summary behind a hover overlay. */
@container tile (min-width: 340px) {
  .tile__overlay {
    position: absolute;
    inset: auto 0 0 0;
    background: color-mix(in srgb, var(--demo-bg) 88%, transparent);
    transform: translateY(100%);
    transition: transform .28s cubic-bezier(.2,.8,.2,1);
  }
  .tile:hover .tile__overlay,
  .tile:focus-within .tile__overlay { transform: translateY(0); }
}

@media (prefers-reduced-motion: reduce) {
  .tile__overlay { transition: none; }
}

The --demo-* values above are the theme variables supplied by the demo frame, so the example follows light and dark mode here. Substitute your own colour tokens when you copy it.

Notice what is not in the narrow branch: there is no @container (max-width: 339px) block anywhere. The narrow variant is the base cascade, and the wide variant is additive. That inversion is deliberate and is discussed below.

The key technique: hiding is the enhancement, showing is the default

The instinct is to write the rich version first — overlay absolutely positioned, translated out of view — and then add a max-width query that un-hides it for narrow containers. Do that and every failure mode becomes a functional one. An engine that does not support container queries ignores both blocks, leaving the summary parked at translateY(100%) under overflow: hidden, permanently invisible with no way to retrieve it. A typo in the container name produces the same result. So does a stylesheet that loads before the container's container-type is applied by a later rule.

Writing it the other way round makes every one of those failures cosmetic. If the query never matches — unsupported engine, wrong name, no container established — the reader gets a tile with a visible summary and a visible button. That is a less elegant component, not a broken one. This is the same progressive-enhancement ordering used for layout fallbacks in handling container query fallbacks for older browsers, applied to interaction instead of geometry: put the guaranteed-functional state in the cascade's base, and let the query add capability rather than restore it.

The second half of the technique is :focus-within. The reveal selector lists .tile:hover and .tile:focus-within together, so a keyboard user tabbing to a link inside the overlay brings the overlay up. Omit it and the focused control keeps its focus ring, but the ring is drawn inside a box that has been translated out of the visible area — a WCAG 2.4.11 focus-visibility failure that is invisible during mouse testing and only appears when someone actually tabs the page. The broader pattern of driving container state from descendant focus is developed in focus-within form patterns.

Variation: adding the input-capability condition

Container width and hover capability are separate axes, and on a wide touchscreen you want the narrow behaviour despite the width. Nesting the pointer media query inside the container query expresses that precisely: hide only when there is room and the pointer can hover.

@container tile (min-width: 340px) {
  /* Only devices with a hovering, precise pointer get the hidden overlay. */
  @media (hover: hover) and (pointer: fine) {
    .tile__overlay {
      position: absolute;
      inset: auto 0 0 0;
      transform: translateY(100%);
      transition: transform .28s cubic-bezier(.2, .8, .2, 1);
    }
    .tile:hover .tile__overlay,
    .tile:focus-within .tile__overlay { transform: translateY(0); }
  }
}

/* A coarse pointer keeps the persistent control, and gets a target
   large enough to hit reliably. */
@media (pointer: coarse) {
  .tile__cta { min-block-size: 44px; display: inline-flex; align-items: center; }
}

The 44px minimum is not arbitrary padding — it is the target size floor discussed in target size and pointer accessibility, and it matters most in exactly the case this page creates: a persistent control in a narrow component, where the temptation to shrink it to fit is strongest.

Browser support

Every mechanism here is broadly interoperable. Size container queries are available in Chrome and Edge 105+, Safari 16+, and Firefox 110+. :focus-within is older and universal across evergreen engines. The hover and pointer media features have shipped everywhere relevant for years. The one newer convenience is color-mix(), used for the overlay backdrop, which needs Chrome and Edge 111+, Safari 16.2+, and Firefox 113+; swap it for a plain rgb(… / .88) value if you support older builds, since it is purely cosmetic. Because the persistent variant is the cascade default, no @supports gate is required — an engine that understands none of the query syntax renders the fully usable narrow layout at every width.

FAQ

Why change the affordance instead of just shrinking the hover panel? A smaller hover panel is still a hover panel, so it still fails for touch users and still hides the function behind a pointer gesture. Below a certain width there is no room for a reveal that does not cover the content it belongs to, so the correct answer is a control that is simply always visible.

Does a container query know whether the device supports hover? No. Container queries measure space only. Pair them with the pointer and hover media features, which describe the input device, and treat the two as independent conditions that both have to be satisfied before hiding anything behind hover.

How do I keep keyboard users from losing a hover-revealed control? Add :focus-within alongside :hover on every reveal selector so tabbing into the hidden element opens the container. Without it the focused control stays inside a clipped or zero-height box and the focus indicator is invisible.

Which variant should be the default in the stylesheet? The always-visible one. Write the persistent control as the base style and add the hover reveal inside the container query, so any engine that does not evaluate the query still renders a fully functional component rather than a permanently hidden one.

Related

• Container-Aware Motion — the parent section on motion sized to the component's own box.
• Motion That Scales with Container Size — the continuous counterpart to this page's discrete switch.
• Smooth Hover Effects Without JavaScript — the hover-state craft this pattern chooses when to apply.
• Pointer and Hover Media Queries — detecting input capability as a separate axis from space.
• Building Responsive Cards with Container Queries — the cross-area layout work behind the same component.