Overflow Recovery with position-try-fallbacks

The Problem

A tooltip anchored to a button at the top of the viewport tries to open above the button. But there's no room above — the tooltip would overflow the viewport top. Without a fallback, the tooltip clips and becomes unreadable.

position-try-fallbacks is the native CSS solution.

Built-in keywords

.tooltip {
  position: absolute;
  position-anchor: --x;
  position-area: top;
  position-try-fallbacks: flip-block;
}

When the browser detects the target would overflow:

1. flip-block — try the opposite side along the block axis (vertical in horizontal-LTR). top becomes bottom, bottom-end becomes top-end, etc.
2. flip-inline — try the opposite side along the inline axis (horizontal). left becomes right, top-start becomes top-end.
3. flip-block flip-inline — both axes at once. bottom-end becomes top-start.

Listing multiple fallbacks

.tooltip {
  position-try-fallbacks: flip-block, flip-inline, flip-block flip-inline;
}

The browser tries each in order. The first one that fits without overflow wins. If none fit, the original placement is used (and the target overflows — that's just unavoidable in some viewport sizes).

Named @position-try rules

For complex fallback strategies, define named rules with @position-try:

@position-try --top-with-arrow {
  position-area: top;
  margin-bottom: 8px;
  --arrow-direction: down;
}

@position-try --bottom-with-arrow {
  position-area: bottom;
  margin-top: 8px;
  --arrow-direction: up;
}

.tooltip {
  position-anchor: --x;
  position-try-fallbacks: --top-with-arrow, --bottom-with-arrow;
}

The --arrow-direction custom property changes per fallback, letting you flip the arrow CSS too. This is the cleanest way to keep the arrow consistent with the actual placement.

Browser support for @position-try

Built-in keywords (flip-block etc.) work in Chrome 125+, Edge 125+, and Safari 26+. Named @position-try rules are slightly newer and shipped in Chrome 128+. Use keywords for now; add named rules as a progressive enhancement.