alle beiträge

Popover und Anchor Positioning: Kleine Oberflächen, weniger Sonderlösungen

Was der Browser bei schwebenden Hinweisen inzwischen übernimmt und warum Positionierung, Bedienung und Semantik trotzdem eigene Entscheidungen bleiben.

Ein kleiner Hinweis neben einem Button klingt nach einer einfachen Aufgabe. Bis der Button am unteren Bildschirmrand steht, ein Container den Hinweis abschneidet oder die mobile Ansicht dazukommt. Plötzlich besteht die kleine Komponente aus Messungen, Event-Listenern und Ausnahmen.

Deshalb interessieren mich Popover und CSS Anchor Positioning. Sie verschieben einen Teil dieser Arbeit in den Browser. Für mich ist das eine der angenehmsten Entwicklungen im modernen CSS: Ich kann das gewünschte Verhalten beschreiben und muss weniger Geometrie selbst berechnen.

Die beiden Funktionen gehören allerdings nicht in denselben gedanklichen Topf. Ich würde sie bei einer Umsetzung immer getrennt betrachten und testen.

Öffnen ist etwas anderes als Positionieren

Ein Element mit popover="auto" kann über einen Button geöffnet werden. Der Browser zeigt es im Top Layer an; übliche Probleme mit abschneidenden Elterncontainern werden damit vermieden. Automatische Popover lassen sich auch per Escape oder durch einen Klick außerhalb schließen. Sie sind nicht modal. MDN: Popover API

Anchor Positioning beantwortet eine andere Frage: Wo soll dieses Element relativ zu seinem Bezugselement stehen? Dafür werden ein Anker und eine Position beschrieben. Popover können dabei auch eine implizite Verbindung zu ihrem auslösenden Button nutzen. Für das folgende Beispiel wähle ich einen expliziten Ankernamen, damit die Beziehung sichtbar bleibt. MDN: CSS Anchor Positioning verwenden

Beispiel
html
<button class="info-trigger" popovertarget="info">  Hinweis anzeigen</button><div id="info" popover="auto">  Diese Einstellung gilt nur für die Vorschau.</div>
Beispiel
css
#info {  max-inline-size: min(22rem, calc(100vw - 2rem));  padding: 1rem;}
@supports (anchor-name: --info) and (position-area: block-end) { .info-trigger { anchor-name: --info; }
#info { position: fixed; position-anchor: --info; inset: auto; margin: 0.5rem; position-area: block-end; position-try-fallbacks: flip-block; }}

Das Beispiel setzt Unterstützung für die Popover API voraus. Fehlt nur Anchor Positioning, bleibt die Standardplatzierung des Popovers erhalten. Fehlt auch die Popover API, brauche ich eine gesonderte Lösung, etwa dauerhaft sichtbaren Hilfetext und einen ausgeblendeten, funktionslosen Auslöser. @supports allein ersetzt diese Entscheidung nicht.

Der Rand ist der eigentliche Test

Mit position-try-fallbacks lassen sich alternative Positionen angeben. flip-block erlaubt im Beispiel einen Wechsel auf die andere Seite entlang der Blockachse, wenn die ursprüngliche Position nicht passt. Das ist hilfreich, aber kein Ersatz für Tests mit langem Text und engem Viewport. MDN: Alternative Positionen und Überlauf

Genau solche Situationen möchte ich in kleinen Experimenten sichtbar machen. Bei Anchor notes lässt sich die Beziehung zwischen Auslöser und Hinweis unmittelbar ausprobieren. Mich interessiert dabei weniger der perfekte Screenshot als das Verhalten an den Stellen, an denen ein Layout unbequem wird.

Ein Popover ist noch keine fertige Komponente

Für einen zusätzlichen Hinweis finde ich dieses Muster passend. Eine wichtige Bestätigung, die die weitere Arbeit unterbrechen muss, ist dagegen eine andere Interaktion. Dafür würde ich einen modalen Dialog prüfen: showModal() macht den übrigen Dokumentinhalt inaktiv. MDN: Das dialog-Element

Ebenso wird aus einer schwebenden Liste nicht allein durch das Popover-Attribut ein zugängliches Menü. Beschriftung, sinnvolle Elemente und Tastaturbedienung müssen zur konkreten Aufgabe passen. Einen klickbaren Hinweis würde ich außerdem nicht beiläufig als Tooltip bezeichnen.

Mein Ansatz wäre deshalb: erst eine klare Aufgabe, dann das passende native Verhalten, danach die Gestaltung. Für komplexe Auswahlfelder oder verschachtelte Menüs kann eine etablierte Komponentenbibliothek weiterhin sinnvoll sein. Bei einem kleinen Hinweis möchte ich aber zuerst prüfen, wie weit ich mit HTML und CSS komme. Weniger eigener Code ist besonders dann ein Gewinn, wenn seine Aufgaben tatsächlich vom Browser übernommen werden.