CSS Anchor Positioning: Warum Popper.js jetzt Altlast ist

Irgendwann zwischen dem dritten npm install und dem nächsten Bundle-Size-Meltdown fragt man sich: Warum brauche ich eine JavaScript-Bibliothek, nur damit ein Tooltip über einem Button erscheint?

Man braucht sie nicht mehr.

CSS Anchor Positioning ist seit Anfang 2026 Baseline, stabil in Chrome, Firefox und Safari. Die API löst genau das Problem, für das wir jahrelang Popper.js, Floating UI oder Tippy.js installiert haben: Elemente relativ zu anderen Elementen positionieren, unabhängig von der DOM-Hierarchie und davon, wo im Stacking Context sie leben.

Das eigentliche Problem

Bis jetzt war das klassische Dilemma: Ein Dropdown muss wissen, wo sein Trigger-Button auf dem Bildschirm sitzt. Auch beim Scrollen. Auch wenn das Viewport zu schmal wird und der Tooltip nach oben flippen soll. CSS konnte das nicht. Also: JavaScript holen, Event-Listener setzen, Position manuell berechnen, ResizeObserver drauf, und hoffen dass nichts flackert.

Mit Anchor Positioning löst sich das in wenige Zeilen CSS auf:

.trigger {
  anchor-name: --mein-button;
}

.tooltip {
  position: absolute;
  position-anchor: --mein-button;
  top: anchor(bottom);
  left: anchor(center);
  translate: -50% 8px;
}

Das war es. Der Tooltip klebt am Button, überall wo er gerade sitzt. Kein JavaScript. Kein Initialisierungscode. Kein Cleanup in useEffect.

@position-try: Kollisionserkennung ohne JS

Was mich am meisten überzeugt hat ist @position-try. Damit gibst du dem Browser mehrere Fallback-Positionen mit. Fliegt der Tooltip nach unten aus dem Viewport, springt er automatisch nach oben:

@position-try --flip-up {
  top: auto;
  bottom: anchor(top);
  translate: -50% -8px;
}

.tooltip {
  position-try-fallbacks: --flip-up;
}

Das war früher das Herzstück von Popper.js (die Kollisionserkennung, das automatische Flippen). Jetzt: acht Zeilen CSS, null Dependencies.

Browser-Support

Chrome 125+ und Edge: voll dabei seit Mitte 2024. Firefox hat es in Version 132 ohne Flags rausgebracht. Safari 26 unterstützt jetzt auch @position-try vollständig.

Für neue Projekte gibt es keinen echten Grund mehr, eine externe Bibliothek einzusetzen. Wer noch ältere Safari-Versionen (18.x) supporten muss, kann das als Progressive Enhancement bauen: der Tooltip funktioniert trotzdem, er flippt bei Platzmangel nur nicht automatisch.

Was das im Alltag bringt

Ich hab zwei laufende Projekte umgebaut. Floating UI raus, CSS rein. Der Unterschied im Bundle ist nicht dramatisch. Floating UI Core plus DOM sind ~14 KB minzipped. Aber das ist nicht der eigentliche Gewinn.

Der eigentliche Gewinn: eine Abhängigkeit weniger, die irgendwann outdated wird. Eine package.json-Zeile weniger, die bei einem Major-Update Inkompatibilitäten bringt. Kein Hydration-Problem mehr, weil das Positioning-JavaScript vor dem Render geladen sein muss. Der Code ist einfacher zu lesen (CSS für Layout, JavaScript für Logik).

Klar hat Floating UI mehr Features: Sub-Pixel-Präzision, Virtual Elements für Canvas oder Charts, komplexe Middleware-Ketten. Für 90% der normalen Tooltips, Dropdowns, Popovers und Context-Menus auf Websites braucht man das nicht.

Warum das wichtig ist

Anchor Positioning ist Teil eines Musters. Container Queries, :has(), @layer, @scope, Scroll-driven Animations: das Web bekommt gerade systematisch Features, die Präsentationslogik aus JavaScript zurück ins Stylesheet verschieben, wo sie hingehört.

Weniger JavaScript bedeutet schnellere Seiten, weniger Fehlerquellen, kleinere Bundles, einfacheren Code. Für Kunden heißt das bessere Core Web Vitals, für Entwickler weniger Frameworks-Overhead.

Die nächste Generation von Websites kommt mit mehr CSS und weniger Bibliotheken aus. Kein Retro-Trend, kein Vanilla-Nostalgie. CSS wird endlich erwachsen.