CSS Anchor Positioning ist überall angekommen. Das kannst du jetzt löschen.

Bundlephobia sagt, @floating-ui/react sei 90,1 kB minifiziert, 30,8 kB gzippt. Das ist das Paket, das viele Designsysteme hereinziehen, damit ein Tooltip über einem Button sitzen kann, ohne vom Bildschirm zu fallen.

Ich habe diesen Tooltip letzten Monat in CSS nachgebaut. Nicht auf einer Kundenseite, sondern in einer HTML-Datei ohne Build-Schritt. Vierzehn Zeilen. Überhaupt kein JavaScript.

Möglich ist das plötzlich wegen CSS Anchor Positioning, das Firefox 147 am 13. Januar 2026 ohne Flag ausgeliefert hat. Das war die letzte Engine, die noch fehlte. Der Januar-Überblick von web.dev nannte es im selben Monat Baseline Newly available.

Dann habe ich vor dem Schreiben dieses Textes das Baseline-Dashboard geprüft, und dort steht Limited availability. Was nervig ist und zugleich das Nützlichste in diesem ganzen Beitrag, also fangen wir damit an.

Was tatsächlich ausgeliefert wurde, und wann

Chrome hat den Kern von Anchor Positioning in Chrome 125 ausgeliefert, im Mai 2024. Safari folgte in Safari 26. Firefox 147 hat es am 13. Januar 2026 standardmäßig eingeschaltet und im selben Release den Ausrichtungswert anchor-center sowie position-anchor: none ergänzt, laut den Entwickler-Release-Notes zu Firefox 147 auf MDN.

Drei Engines, vollständig genug für eine Ankündigung. Also hat web.dev es in seinem Januar-Beitrag 2026 als Baseline Newly available beschrieben.

Aber das web-features-Projekt, das Baseline tatsächlich berechnet, führt das zusammengesetzte Feature anchor-positioning weiterhin als limited. Frag api.webstatus.dev/v1/features/anchor-positioning selbst ab, und du siehst "baseline": {"status": "limited"}. Es gibt ein offenes Issue im web-features-Repo, #3558, das genau das argumentiert: Das Feature ist in allen drei Engines gelandet und trägt weiterhin genug Fehler und Spezifikationsbewegung, dass ein Umschalten auf Baseline überzeichnet, wie sicher es ist. Ein Kommentator hat es als in der Beta beschrieben und gefragt, welcher Status zwischen "überall ausgeliefert" und "tatsächlich bereit" existiert.

Die Teile, die unstrittig Baseline Newly available sind, sind die Einzelstücke: anchor-name, position-area, @position-try und Freunde haben jeweils ihr eigenes Datum vom 13. Januar 2026. Das Dachfeature hat es nicht, weil sich Teile davon danach weiterbewegt haben. Der Initialwert von position-anchor wurde in Chrome 151, Firefox 151 und Safari 27 zu normal, und das ist März 2026, mehr als zwei Monate nach den "es ist Baseline"-Schlagzeilen.

Und hier ist der Teil, den Leute überspringen. Newly available ist nicht Widely available. Baseline schiebt ein Feature 30 Monate nach der letzten Engine von Newly auf Widely available. Für Anchor Positioning ist das grob Juli 2028. Widely available ist die Schwelle, ab der du aufhören kannst, darüber nachzudenken. Newly available heißt, dass jeder aktuelle Browser es hat und alles Ältere nicht. Wenn dein Analytics einen nennenswerten Anteil Besucher auf einem Safari von 2024 zeigt, ist Anchor Positioning für dich eine progressive Verbesserung und kein Fundament.

Die ganze API sind sechs Eigenschaften und zwei Funktionen

Du markierst ein Element als Anker mit anchor-name: --irgendwas. Du hängst ein positioniertes Element daran mit position-anchor: --irgendwas. Du platzierst es mit position-area, das den Raum um den Anker in ein Neun-Zellen-Raster schneidet und dich top, bottom span-right, block-start span-inline-end und so weiter sagen lässt.

Wenn das Raster zu grob ist, gibt dir anchor() die rohen Kanten: top: anchor(bottom) heißt "meine Oberkante sitzt auf der Unterkante meines Ankers". anchor-size() macht dasselbe für Maße, width: anchor-size(width) macht ein Dropdown also genau so breit wie der Button, der es geöffnet hat. Diese eine Zeile ersetzt schon ein gutes Stück der size-Middleware von Floating UI.

Kollisionsbehandlung ist position-try-fallbacks, eine kommagetrennte Liste alternativer Platzierungen, die der Browser der Reihe nach probiert, wenn die aktuelle überläuft. flip-block, flip-inline und flip-start decken das meiste ab, oder du definierst eigene mit der At-Regel @position-try. position-try-order lässt dich Fallbacks nach verfügbarem Platz statt nach Listenreihenfolge sortieren. position-visibility blendet das positionierte Element aus, wenn sein Anker aus dem Sichtbereich scrollt, und genau das baut sonst jeder mit IntersectionObserver von Hand.

Und anchor-scope verhindert, dass Ankernamen zwischen wiederholten Komponenten auslaufen, was in dem Moment zählt, in dem du einen Tooltip in einer Liste renderst.

Das ist die gesamte Oberfläche. Sechs Eigenschaften, zwei Funktionen, eine At-Regel.

Ein Tooltip in vierzehn Zeilen

<button class="save-btn">Speichern</button>
<span class="save-tip" role="tooltip">Speichert in deine Entwürfe</span>

.save-btn { anchor-name: --save-btn; }

.save-tip {
  position: absolute;
  position-anchor: --save-btn;
  position-area: top;
  margin-bottom: 6px;
  opacity: 0;
  transition: opacity .15s;
  pointer-events: none;
}

.save-btn:hover + .save-tip,
.save-btn:focus-visible + .save-tip { opacity: 1; }

Das war's. Kein computePosition, kein autoUpdate, keine Aufräumfunktion beim Unmount. Der Browser rechnet die Position beim Scrollen und beim Größenändern neu, weil es Layout ist und kein Abonnement.

Der Tooltip lebt hier weiterhin im normalen Dokumentfluss, was heißt, dass er von einem Vorfahren mit overflow: hidden abgeschnitten werden kann und den üblichen Stacking-Regeln folgt. Das ist das alte Problem, und genau das behebt die Popover-API.

Ein Dropdown, das umklappt, wenn der Platz ausgeht

Anchor Positioning und die Popover-API sind zwei Hälften einer Sache, und sie sind nah genug beieinander gelandet, um als ein Werkzeug behandelt zu werden. Popover ist seit dem 27. Januar 2025 Baseline Newly available, als iOS Safari 18.3 den Satz vervollständigt hat. Es gibt dir den Top Layer, also keine z-index-Kämpfe und kein Abschneiden, dazu Light Dismiss bei Klick nach außen und bei Escape, dazu Fokusbehandlung. All das war früher irgendwessen 200-Zeilen-Hook.

<button id="acct-btn" popovertarget="acct-menu">Konto</button>
<div id="acct-menu" popover>
  <a href="/settings">Einstellungen</a>
  <a href="/billing">Abrechnung</a>
</div>

#acct-btn { anchor-name: --acct-btn; }

#acct-menu {
  position-anchor: --acct-btn;
  position-area: bottom span-right;
  margin-top: 4px;
  width: anchor-size(width);
  position-try-fallbacks: flip-block, flip-inline, flip-block flip-inline;
  position-visibility: anchors-visible;
}

Das User-Agent-Stylesheet setzt bei offenen Popovers bereits position: fixed, du fügst es also nicht hinzu. popovertarget am Button verdrahtet Öffnen und Schließen mit null JavaScript. position-try-fallbacks klappt das Menü über den Button, wenn darunter kein Platz ist, dann auf die andere Seite, dann beides. position-visibility: anchors-visible blendet das Menü aus, wenn du den Button bei offenem Menü aus dem Sichtbereich scrollst.

Zähl das JavaScript. Es gibt keins.

Was die Bibliotheken tatsächlich wiegen

Zahlen von Bundlephobia, beim Schreiben geprüft, jeweils minifiziert und minifiziert plus gzippt:

• @floating-ui/dom 1.8.0: 21,3 kB, 8,2 kB gzippt
• @floating-ui/react: 90,1 kB, 30,8 kB gzippt
• @popperjs/core 2.11.8: 20,0 kB, 14,5 kB gzippt
• tippy.js 6.3.7: 42,6 kB, 14,4 kB gzippt, und es hängt obendrein an Popper
• popper.js 1.16.1: 20,7 kB, 7,3 kB gzippt

Ich will hier vorsichtig sein, denn genau hier fangen solche Beiträge normalerweise an zu lügen. Niemands Bundle schrumpft um 30,8 kB, wenn er Floating UI löscht, weil Tree Shaking die nie importierten Teile längst entfernt hat und weil die Komponentenbibliothek obendrauf ohnehin die größere Zahl ist. Was du tatsächlich sparst, liegt je nachdem, wie viel von der API du benutzt hast, zwischen 3 und 15 kB gzippt.

Die Größe ist nicht wirklich der Punkt. Der Punkt ist eine Abhängigkeit weniger in einem Baum, den du gepatcht halten musst. Tippy zieht Popper, Popper ist im Wartungsmodus, und jedes transitive Paket ist eine Zeile in deiner Lockfile, die jemand kompromittieren kann. Darüber habe ich in Your Website Is One Compromised npm Package Away From Disaster geschrieben, und es ist dasselbe Argument wie beim CSS: Was du gelöscht hast, kann nicht kaputtgehen. Gleiche Form wie Every JavaScript Animation Library You Can Replace With 3 Lines of CSS und 10 Figma Plugins You Don't Need If You Just Learn These CSS Tricks. Die Plattform absorbiert immer weiter die Schicht über sich, und die meisten Teams merken es zwei Jahre zu spät.

Wo die Bibliotheken weiterhin gewinnen

Virtuelle Elemente. Floating UI kann sich an ein simples Rechteck hängen, das du erfindest: eine Mauskoordinate, einen Textauswahlbereich, eine Stelle auf einem Canvas. CSS Anchor Positioning braucht ein echtes DOM-Element mit anchor-name daran. Kontextmenüs, die dem Cursor folgen, Auswahl-Werkzeugleisten, Diagramm-Tooltips, die einem Datenpunkt folgen: Für nichts davon gibt es ein Element zum Ankern. Behalt die Bibliothek.

Hover-Auslöser bei Popovers. Die Popover-API öffnet beim Klick. Es gibt keinen deklarativen Hover-Auslöser mit browserübergreifender Unterstützung: Das interestfor-Attribut, das dir einen gäbe, gibt es ab Chrome 142, ohne jede Unterstützung in Firefox oder Safari. Das :hover-Beispiel oben funktioniert, weil dieser Tooltip kein Popover ist. In dem Moment, in dem du ein hover-ausgelöstes Element im Top Layer willst, bist du zurück bei JavaScript.

Komplexe Kollisionsstrategien. position-try-fallbacks gibt dir eine geordnete Liste diskreter Platzierungen. Floating UIs shift-Middleware schiebt ein Element kontinuierlich entlang einer Achse, um es im Blick zu halten, und das ist ein anderes Verhalten und oft das schönere. Ein CSS-Äquivalent gibt es nicht.

Framework-Integration. @floating-ui/react ist vor allem deswegen 30,8 kB gzippt, weil es keine Positionierungsbibliothek ist, sondern eine Positionierungsbibliothek plus Fokusverwaltung, Roving Tabindex, Typeahead, Dismiss-Behandlung und ARIA-Verdrahtung. Popover deckt einen Teil davon ab. Nicht alles.

Die Eigenheiten, die niemand in die Blogbeiträge schreibt

Bestehensquoten der Web Platform Tests auf Stable, aus der webstatus.dev-API: Chrome 93,9%, Safari 87,0%, Firefox 84,0%. Chrome auf Android: 67,9%. Auf diese letzte Zahl würde ich starren, denn auf den meisten Seiten, die ich anschaue, ist mobiles Chrome der größte einzelne Traffic-Anteil. "Es funktioniert in Chrome" und "es funktioniert in Chrome auf einem Handy" sind hier nicht dieselbe Aussage.

Konkrete Dinge, die mich gebissen haben oder vor denen die Kompatibilitätsdaten warnen:

Einzelne Schlüsselwortwerte für position-area sind neuer als das Feature. top, bottom, left, right, block-start und block-end als eigenständige Werte kamen erst in Chrome 144 und Firefox 148, Anfang 2026. Die span-*-Formen gehen zurück bis Chrome 129 und Firefox 147. Das Tooltip-Beispiel oben braucht also Firefox 148, nicht 147, obwohl Anchor Positioning in 147 "ausgeliefert" wurde.

Die Werte von position-visibility wurden im Flug umbenannt. anchors-valid gibt es in Firefox 147 und Safari 26.2, aber nicht in Chrome. Safari 27 hat es zu anchor-valid und anchor-visible umbenannt, was Chrome und Firefox nicht haben. anchors-visible und no-overflow sind die beiden Werte, die alle drei unterstützen. Nimm die.

position-try-order gibt es ab Firefox 148. Nicht 147.

Das HTML-Attribut anchor existiert noch nicht. Es steckt nur in Chrome Preview hinter einem Flag. Nimm anchor-name und position-anchor im CSS.

anchor() ist in Firefox nicht animierbar. Chrome und Safari können es animieren. Firefox nicht.

Nichts davon ist ein Ausschlusskriterium. Es ist der Grund, warum ich dieses Feature nicht als fertig bezeichnen würde, und der Grund, warum das Baseline-Dashboard wohl recht hat und die Schlagzeile wohl zu früh war.

Das Muster, das das sicher macht

Schreib zuerst die langweilige Version, dann verbesser sie. @supports auf einen erfundenen Custom-Property-Namen ist der Test:

.save-tip {
  position: absolute;
  top: 100%;
  left: 0;
  margin-top: 6px;
}

@supports (anchor-name: --x) {
  .save-btn { anchor-name: --save-btn; }
  .save-tip {
    position-anchor: --save-btn;
    position-area: top;
    top: auto;
    left: auto;
    margin: 0 0 6px;
    position-try-fallbacks: flip-block;
  }
}

Alte Browser bekommen einen Tooltip, der immer unter dem Button steht und gelegentlich abgeschnitten wird. Neue Browser bekommen einen, der umklappt. Niemand bekommt ein kaputtes Layout, und niemand lädt 8 kB JavaScript, um herauszufinden, zu welcher Gruppe er gehört.

Oddbird pflegt ein Polyfill, falls du das echte Verhalten in älteren Browsern brauchst. Sei dir nur klar, was du tust: Du fügst JavaScript wieder hinzu, um das CSS nachzubilden, das dir erlauben sollte, JavaScript zu löschen. Für einen Tooltip lohnt sich dieser Tausch nicht. Liefer stattdessen die @supports-Version aus.

Was ich heute tatsächlich tun würde

Wenn du Tippy oder Popper in einem Projekt hast, lösch sie. Popper ist im Wartungsmodus, Tippy schleppt Popper mit, und die Kombination aus CSS und Popover deckt das klickausgelöste Dropdown und den Hover-Tooltip ab, die zusammen den größten Teil ihrer Nutzung ausmachen. Das ist ein echtes Aufräumen, auf derselben Liste wie alles in 10 Dinge, die du heute von deiner Website löschen kannst.

Wenn du Floating UI hast, schau dir an, wofür du es benutzt, bevor du etwas anfasst. An echten Elementen verankert, einfaches Umklappverhalten, keine virtuellen Elemente: Du kannst es rauswerfen. Cursor-folgende Menüs, Auswahl-Werkzeugleisten, Canvas-Tooltips, oder du steckst tief in den Interaktions-Hooks von @floating-ui/react: Behalt es und schau 2027 wieder hin.

Und wenn du für einen Neubau wählst, ist das dieselbe Rechnung wie die Wahl eines Stacks, der standardmäßig weniger tut, und das ist der Hauptgrund, warum Astro-Seiten die Core Web Vitals öfter bestehen als WordPress-Seiten. Weniger bewegliche Teile, weniger Dinge, die aktuell gehalten werden müssen.

Ich halte Anchor Positioning nicht für fertig. Chrome Android mit 67,9% in der Testsuite sagt, dass es das nicht ist, und dass das Baseline-Dashboard "limited" sagt, während die Blogbeiträge "Baseline" sagen, ist eine faire Zusammenfassung des Stands im September 2026. Aber hinter @supports, mit dem langweiligen Fallback darunter, gibt es keinen Grund zu warten. Der schlimmste Fall ist, dass manche Besucher einen Tooltip an einer etwas langweiligeren Position bekommen und du weniger Code ausgeliefert hast.

Wenn du jemanden willst, der durch deinen Abhängigkeitsbaum geht und dir sagt, was die Plattform still überflüssig gemacht hat, ist das eine normale Woche bei Wunderlandmedia. Bring deine Lockfile mit.