Tooltips ohne JavaScript: Popover API & CSS-Anchor

Du übernimmst das Relaunch-Projekt eines Bestandskunden und schaust dir an, was im alten Theme steckt. Für das Navigationsmenü lädt die Seite eine Dropdown-Bibliothek, für die kleinen Info-Tooltips an den Formularfeldern eine zweite, für das Cookie-Overlay eine dritte. Drei JavaScript-Pakete, zusammen deutlich über hundert Kilobyte, dazu regelmäßige Update-Meldungen und bei jedem npm-Audit ein paar neue Warnungen. Alles nur, um ein paar Elemente an der richtigen Stelle einzublenden.

Dieses Muster war jahrelang Standard. Seit 2026 ist es überholt. Mit der Popover API und CSS Anchor Positioning kann der Browser genau diese Aufgaben selbst – ohne eine einzige Zeile Framework-Code. Beide Bausteine haben in aktuellen Browsern den Baseline-Status erreicht, und zusammen ersetzen sie einen Großteil dessen, wofür Agenturen bisher Bibliotheken wie Floating UI (früher Popper.js) oder diverse Dropdown-Scripts eingebunden haben. Dieser Beitrag zeigt dir, wie das konkret funktioniert, wo die Grenzen liegen und warum sich der Umstieg gerade für kleine Agenturen lohnt.

Tooltips ohne JavaScript: warum der Browser das jetzt selbst kann

Zwei getrennte Probleme machten Overlays bisher kompliziert. Erstens: Ein Element wie ein Menü oder ein Dialog muss über allem anderen liegen, zuverlässig, ohne dass z-index-Kämpfe und overflow: hidden einer Elternbox dazwischenfunken. Zweitens: Das Element muss sich relativ zu einem Auslöser positionieren – der Tooltip über dem Icon, das Menü unter dem Button – und dabei merken, wenn am Bildschirmrand kein Platz ist, um nach oben statt nach unten zu klappen.

Für das erste Problem gibt es die Popover API, für das zweite CSS Anchor Positioning. Lange brauchte man für beides JavaScript, das bei jedem Scroll- und Resize-Vorgang nachrechnet. Genau diese Rechenarbeit übernimmt jetzt der Browser nativ – performanter, als es eine Bibliothek im Hauptthread je könnte, und ohne zusätzliches Gewicht im Bundle.

Die Popover API: Overlays auf Knopfdruck

Die Popover API macht aus beliebigem HTML ein Overlay, das der Browser in einer eigenen obersten Ebene, dem sogenannten Top Layer, darstellt. Das Grundgerüst ist bewusst schlicht:

<button popovertarget="menu">Menü</button>

<div id="menu" popover>
  <a href="/leistungen">Leistungen</a>
  <a href="/referenzen">Referenzen</a>
  <a href="/kontakt">Kontakt</a>
</div>

Das Attribut popover am Container und das passende popovertarget am Button genügen. Der Browser erledigt den Rest: Ein Klick öffnet und schließt das Overlay, ein Klick daneben schließt es wieder (das sogenannte Light Dismiss), und die Esc-Taste funktioniert ebenfalls. Weil das Element im Top Layer liegt, überlagert es verlässlich alles andere auf der Seite – unabhängig davon, in welcher verschachtelten Box es im Markup steht.

Für das Styling stehen eigene CSS-Haken bereit. Über die Pseudoklasse :popover-open gestaltest du den geöffneten Zustand, über das Pseudoelement ::backdrop einen abdunkelnden Hintergrund hinter einem modalen Overlay:

#menu:popover-open {
  display: flex;
  flex-direction: column;
}

#menu::backdrop {
  background: rgb(0 0 0 / 0.4);
}

Standardmäßig ist ein Popover vom Typ auto: Es schließt sich bei Klick daneben und erlaubt immer nur ein offenes Popover derselben Gruppe. Brauchst du ein Overlay, das bewusst offen bleibt, bis der Nutzer es aktiv schließt – etwa eine Benachrichtigung –, nutzt du popover="manual".

CSS Anchor Positioning: alles an seinem Platz

Die Popover API zeigt ein Overlay an, kümmert sich aber nicht darum, wo es erscheint. Genau hier setzt CSS Anchor Positioning an. Du bestimmst ein Element zum Anker und hängst ein anderes daran auf:

.menu-button {
  anchor-name: --menu-anchor;
}

#menu {
  position: fixed;
  position-anchor: --menu-anchor;
  position-area: bottom center;
}

anchor-name registriert den Button als Ankerpunkt, position-anchor verbindet das Menü damit, und position-area legt die Lage fest – hier unterhalb und zentriert. Statt Pixelwerte auszurechnen, beschreibst du die Beziehung, und der Browser platziert das Element passend, auch wenn sich die Position des Ankers beim Scrollen ändert.

Der entscheidende Komfort kommt mit der automatischen Ausweichlogik. Ist am gewünschten Platz kein Raum – der Tooltip würde unten aus dem Viewport ragen –, klappt der Browser ihn auf Wunsch selbstständig um:

#menu {
  position-anchor: --menu-anchor;
  position-area: bottom center;
  position-try-fallbacks: flip-block, flip-inline;
}

position-try-fallbacks nennt die erlaubten Ausweichrichtungen. flip-block dreht die Platzierung bei Platzmangel von unten nach oben, flip-inline entsprechend seitlich. Das ist exakt die Logik, für die man früher eine Positionierungsbibliothek gebraucht hat – jetzt sind es drei Zeilen CSS.

Ein praktischer Zusatz: Wird ein Popover über ein popovertarget-Button geöffnet, setzt der Browser den auslösenden Button automatisch als impliziten Anker. In vielen Fällen kannst du dir das anchor-name damit sogar sparen. Für wiederverwendbare Komponenten fährst du mit einem explizit benannten Anker aber robuster.

Wie viel Bibliothek du dir wirklich sparst

Für ein typisches Kundenprojekt summiert sich das. Ein Navigations-Dropdown, Formular-Tooltips, ein Bestätigungsdialog und ein kleines Benachrichtigungs-Overlay liefen bisher oft über zwei bis drei externe Pakete. Mit Popover und Anchor Positioning decken HTML und CSS diese Fälle ab. Das bedeutet weniger Kilobyte im Bundle, einen schnelleren ersten Seitenaufbau und bessere Werte bei den Core Web Vitals – der Browser positioniert im Kompositor statt im blockierenden Hauptthread.

Mindestens ebenso wertvoll ist der Wegfall der Wartungslast. Jede eingebundene Bibliothek ist eine Abhängigkeit, die aktualisiert werden will, deren Breaking Changes du nachziehen musst und die bei einem Supply-Chain-Angriff über npm zur Einfallstür werden kann. Native Browser-Features haben diese Angriffsfläche nicht und veralten nicht. Das Thema reiht sich damit in die größere Entwicklung ein, bei der moderne CSS-Features immer mehr JavaScript überflüssig machen – vom Karussell bis zu Scroll-Animationen.

Browser-Unterstützung: der Stand Ende 2026

Hier lohnt der genaue Blick, weil beide Features unterschiedlich weit sind. Die Popover API ist seit Januar 2025 Baseline und wird in allen aktuellen Versionen von Chrome, Edge, Firefox und Safari unterstützt – sie ist inzwischen breit angekommen und produktiv einsetzbar.

CSS Anchor Positioning ist jünger. Chrome und Edge führten es im Mai 2024 ein, Safari zog mit Version 26 im September 2025 nach, und mit Firefox 147 im Januar 2026 erreichte das Feature den Status „Baseline Newly available" – es wird also seither von allen gängigen Browser-Engines unterstützt. „Newly available" heißt aber auch: Ältere Browserversionen, die bei manchen Nutzern noch laufen, kennen es nicht. Für Projekte mit breitem Publikum gehört deshalb eine saubere Rückfallebene dazu.

Das löst du mit Feature Detection in CSS. Den Grundzustand baust du so, dass er auch ohne Anchor Positioning funktioniert, und schaltest die native Variante nur dort frei, wo der Browser sie beherrscht:

/* Rückfall: klassische Positionierung */
#menu { position: absolute; top: 100%; left: 0; }

@supports (anchor-name: --x) {
  #menu {
    position-anchor: --menu-anchor;
    position-area: bottom center;
    position-try-fallbacks: flip-block;
  }
}

So bekommt jeder Nutzer ein funktionierendes Overlay, und moderne Browser obendrauf die elegante, selbstausweichende Positionierung. Welche Features du ohne solche Hilfskonstruktion flächendeckend einsetzen kannst, ordnet der Beitrag zu Baseline 2026 ein.

Wo die nativen Features aufhören

Bei aller Begeisterung gehört die ehrliche Grenze dazu, damit du im Kundenprojekt keine böse Überraschung erlebst. Popover und Anchor Positioning lösen das Darstellen und Positionieren – nicht die komplette Barrierefreiheit. Der Browser bringt zwar Top Layer, Light Dismiss und Esc-Handling mit, aber die passenden ARIA-Rollen und Beschriftungen musst du weiterhin selbst vergeben. Ein echtes, tastaturbedienbares Auswahlmenü mit Pfeiltasten-Navigation entsteht nicht automatisch; dafür braucht es nach wie vor etwas eigene Logik. Und ein barrierefreier Tooltip will korrekt per aria-describedby mit seinem Auslöser verknüpft und sowohl bei Hover als auch bei Fokus erreichbar sein.

Die Faustregel für die Praxis: Für Menüs, Tooltips, Popovers und einfache Dialoge sind die nativen Bausteine 2026 die erste Wahl – schlank, schnell und wartungsarm. Für hochkomplexe, voll zugängliche Widgets wie eine Combobox mit Autovervollständigung kann eine spezialisierte, gut gepflegte Komponente weiterhin sinnvoll sein. Der Unterschied ist, dass du diese Entscheidung jetzt bewusst triffst – und nicht reflexartig für jedes kleine Overlay eine Bibliothek lädst.

Fazit

Tooltips, Dropdowns und Dialoge ohne JavaScript-Bibliothek sind 2026 kein Experiment mehr, sondern solides Handwerk. Die Popover API übernimmt das zuverlässige Einblenden im Top Layer, CSS Anchor Positioning die Positionierung samt automatischer Ausweichlogik. Zusammen sparen sie im typischen Kundenprojekt mehrere Abhängigkeiten, Kilobyte und laufende Update-Arbeit. Achte auf eine Rückfallebene per @supports, weil Anchor Positioning erst seit Anfang 2026 flächendeckend unterstützt wird, und denk daran, dass die Features das Aussehen lösen, nicht die vollständige Barrierefreiheit. Wer das im Hinterkopf behält, baut schlankere, schnellere und langlebigere Websites – und genau das ist der Vorteil, den eine kleine Agentur ihren Kunden gut verkaufen kann.