CSS Anchor Positioning: Mehrere Fallback-Positionen verketten

1. Anchor Positioning in Kürze: anchor-name, anchor() und position-anchor

CSS Anchor Positioning koppelt ein positioniertes Element an ein beliebiges anderes Element im Dokument, den sogenannten Anker. Der Anker bekommt einen anchor-name wie --trigger, das positionierte Element referenziert ihn über position-anchor und kann dann mit inset-area beziehungsweise der neueren Eigenschaft position-area relativ zum Anker platziert werden, etwa oberhalb, unterhalb oder seitlich davon.

Der entscheidende Unterschied zu klassischer absoluter Positionierung ist, dass der Browser die Beziehung zwischen Anker und positioniertem Element bei jedem Layout-Durchlauf neu auswertet. Bibliotheken wie Floating UI mussten dafür bislang getBoundingClientRect() aufrufen und auf Scroll- sowie Resize-Events lauschen. Mit nativem Anchor Positioning übernimmt die Rendering-Engine diese Berechnung direkt im Layout-Schritt, was Jank durch verspätete JavaScript-Neuberechnungen vermeidet.

2. Warum eine einzelne Fallback-Position selten reicht

Ein Tooltip, das standardmäßig unterhalb seines Ankers erscheint, funktioniert gut, solange der Anker in der oberen Bildschirmhälfte liegt. Steht derselbe Button aber am unteren Rand des Viewports, ragt das Tooltip über den sichtbaren Bereich hinaus oder wird vom Browser abgeschnitten. Eine einzige feste Position deckt also nur einen Teil der möglichen Anker-Positionen im Viewport ab.

Klassisch wurde dieses Problem mit JavaScript gelöst, das die verfügbare Fläche in alle vier Richtungen misst und die Position dynamisch umschaltet. Das funktioniert, bringt aber zusätzlichen Code, zusätzliche Event-Listener und eine Fehlerquelle mehr in jedes Projekt. CSS Anchor Positioning löst genau dieses Problem deklarativ: Statt eine Position hart zu programmieren, beschreibt man eine geordnete Liste von Alternativen, und der Browser wählt selbst die erste passende aus.

3. position-try-fallbacks als geordnete Liste verstehen

Die Eigenschaft position-try-fallbacks akzeptiert eine kommagetrennte Liste von Alternativen. Jeder Eintrag kann eine eingebaute Kurzform wie flip-block, flip-inline oder flip-start sein, ein fertiger position-area-Wert wie bottom span-right, oder der Name einer selbst definierten @position-try-Regel. Der Browser probiert die Liste von links nach rechts durch und verwendet die erste Alternative, bei der das Element vollständig innerhalb des relevanten Containing Blocks Platz findet.

Das Kurzform-Property position-try kombiniert position-try-order und position-try-fallbacks in einer Zeile, ähnlich wie font mehrere Schrift-Eigenschaften bündelt. Für die meisten Projekte reicht die Langform mit position-try-fallbacks aus, weil sie in Kombination mit der Basisposition, die auf dem Element selbst über position-area gesetzt wird, klar erkennbar bleibt, welche Position die bevorzugte ist und welche nur Ausweichlösungen sind.

4. Wie die Rendering-Engine die Reihenfolge auswertet

Die Auswertung folgt strikt der aufgeschriebenen Reihenfolge: Die Basis-Position aus position-area gilt als erster Versuch, danach folgen die Einträge aus position-try-fallbacks in genau der Reihenfolge, in der sie notiert sind. Sobald eine Position ohne Überlauf über den Containing Block passt, stoppt die Suche dort. Das bedeutet in der Praxis: Die gewünschte Standardposition gehört an den Anfang, robuste, aber optisch weniger elegante Ausweichpositionen ans Ende der Kette.

Passt am Ende keine einzige Alternative perfekt, entscheidet die Eigenschaft position-try-order mit Werten wie most-width oder most-height, welche der geprüften Positionen den meisten verfügbaren Platz bietet, und wählt diese als letzten, pragmatischen Kompromiss. Diese zweistufige Logik, zuerst eine perfekt passende Position suchen und erst danach nach der geräumigsten Alternative greifen, verhindert, dass ein Tooltip in einem sehr engen Viewport komplett unsichtbar bleibt.

5. Ein Tooltip mit vier verketteten Fallback-Positionen

In der Praxis reichen meist drei bis vier Alternativen aus, um alle vier Bildschirmränder sauber abzudecken. Das folgende Beispiel zeigt ein Tooltip, das standardmäßig oberhalb seines Ankers erscheint, bei zu wenig Platz nach unten wechselt, danach nach rechts und als letzten Ausweg nach links ausweicht, jeweils mit einem kleinen Sicherheitsabstand über anchor-size().

Wichtig ist, dass jede Alternative in der Kette denselben position-anchor nutzt, aber eine andere position-area oder eine benannte @position-try-Regel mit eigenem Innenabstand referenziert. So bleibt die Beziehung zum Anker über alle vier möglichen Positionen hinweg konsistent, während nur die räumliche Ausrichtung variiert.

.trigger {
  anchor-name: --info-trigger;
}

@position-try --tooltip-right {
  position-area: right;
  margin-inline-start: 0.5rem;
}

@position-try --tooltip-left {
  position-area: left;
  margin-inline-end: 0.5rem;
}

.tooltip {
  position: absolute;
  position-anchor: --info-trigger;
  position-area: top;              /* 1. Versuch: oberhalb des Ankers */
  margin-block-end: 0.5rem;

  position-try-fallbacks:
    flip-block,                    /* 2. Versuch: gespiegelt nach unten */
    --tooltip-right,                /* 3. Versuch: rechts vom Anker */
    --tooltip-left;                 /* 4. Versuch: links vom Anker */
  position-try-order: most-height;  /* letzter Kompromiss, falls nichts passt */
}

6. Dynamisches Verhalten beim Scrollen ohne einen einzigen Event-Listener

Der große praktische Vorteil der verketteten Fallback-Liste zeigt sich beim Scrollen: Bewegt sich der Anker näher an den Bildschirmrand, wechselt der Browser bei Bedarf automatisch zur nächsten passenden Position in der Kette, ganz ohne dass ein Scroll- oder Resize-Listener jemals ausgelöst wird. Die Neubewertung passiert im selben Layout-Schritt, der ohnehin bei jedem Scroll-Frame läuft, und ist dadurch spürbar flüssiger als eine JavaScript-Lösung, die erst asynchron auf ein Event reagiert.

Zusätzlich lässt sich mit position-visibility: no-overflow festlegen, dass das positionierte Element komplett ausgeblendet wird, sobald selbst die geräumigste Fallback-Position nicht mehr ausreicht, statt es abgeschnitten anzuzeigen. Für Tooltips ist das oft die bessere Lösung als ein sichtbares, aber halb verdecktes Element, weil ein fehlendes Tooltip weniger verwirrt als ein kaputt aussehendes.

7. Fallback-Verkettung zusammen mit dem Popover-API

Anchor Positioning entfaltet seine volle Stärke in Kombination mit dem nativen Popover-API. Ein Element mit dem Attribut popover wird beim Öffnen in die Top-Layer-Ebene des Browsers gehoben, was Stacking-Probleme mit z-index und overflow: hidden übergeordneter Container von vornherein umgeht. Die Fallback-Kette aus position-try-fallbacks funktioniert in diesem Kontext identisch, weil sie unabhängig davon arbeitet, in welcher Ebene das Element letztlich gerendert wird.

Für ein Options-Menü, das über popovertarget an einen Button gebunden ist, bedeutet das: Die gleiche Fallback-Kette wie beim einfachen Tooltip lässt sich eins zu eins übernehmen, nur dass zusätzlich popover und popovertarget für das Öffnen, Schließen und die automatische Fokus-Verwaltung sorgen. Die räumliche Positionierung und das Sichtbarkeits-Management bleiben zwei sauber getrennte Zuständigkeiten.

8. Browser-Unterstützung und eine Fallback-Strategie ohne Anchor Positioning

CSS Anchor Positioning ist eine noch junge Spezifikation und aktuell primär in Chromium-basierten Browsern vollständig implementiert, während Firefox und Safari zum Zeitpunkt dieses Artikels noch an einer Umsetzung arbeiten. Wer die Technik heute produktiv einsetzt, sollte deshalb konsequent progressive enhancement betreiben, statt sich auf flächendeckende Unterstützung zu verlassen.

Die Feature-Query @supports(anchor-name: --x) prüft, ob der Browser Anchor Positioning kennt, und liefert innerhalb des Blocks die native Lösung. Außerhalb davon greift eine einfache, statische Fallback-Position per klassischem position: absolute mit festen inset-Werten, die zwar nicht perfekt auf jede Bildschirmgröße reagiert, aber immerhin ein funktionsfähiges, wenn auch weniger elegantes Tooltip zeigt.

/* Statische Basis fuer alle Browser */
.tooltip {
  position: absolute;
  top: 100%;
  left: 0;
  margin-block-start: 0.5rem;
}

/* Verbesserte Version nur dort, wo Anchor Positioning verstanden wird */
@supports (anchor-name: --x) {
  .trigger {
    anchor-name: --info-trigger;
  }

  .tooltip {
    position-anchor: --info-trigger;
    position-area: top;
    position-try-fallbacks: flip-block, flip-inline;
  }
}

9. Praxis-Tipps für robuste, wartbare Fallback-Ketten

Drei bis vier Fallback-Positionen decken in der Praxis fast jeden Anwendungsfall ab; jede weitere Alternative macht die Kette schwerer nachvollziehbar, ohne spürbaren Zusatznutzen zu bringen. Die Reihenfolge sollte der natürlichen Lesefolge und den Nutzererwartungen entsprechen, meist oben vor unten und rechts vor links in Sprachen mit Links-nach-rechts-Leserichtung, damit die bevorzugte Position auch optisch am plausibelsten wirkt.

Die Fallback-Kette verändert ausschließlich die visuelle Position, nicht die Reihenfolge im DOM, wodurch Screenreader und Tastaturnavigation unberührt bleiben. Wichtig bleibt trotzdem, jede neue Kombination direkt an allen vier Bildschirmrändern und in engen mobilen Viewports zu testen, weil sich Fehler in der Reihenfolge oft erst dort zeigen, wo mehrere Fallbacks gleichzeitig knapp scheitern.

10. Zusammenfassung

11. FAQ: Verkettete Fallback-Positionen: Das Wichtigste auf einen Blick