Tooltips scheinen das kleinste UI-Problem zu sein, das Sie haben können. Sie sind winzig und normalerweise versteckt. Wenn jemand fragt, wie man ein solches System erstellt, antwortet die herkömmliche Antwort fast immer mit einer JavaScript-Bibliothek. Und das war lange Zeit der vernünftige Rat. Ich habe es auch befolgt. Oberflächlich betrachtet ist ein Tooltip einfach. Bewegen Sie den Mauszeiger über ein Element oder fokussieren Sie es, zeigen Sie ein kleines Kästchen mit etwas Text an und blenden Sie es dann aus, wenn der Benutzer sich wegbewegt. Aber sobald man es an echte Benutzer verschickt, zeigen sich die Grenzen. Tastaturbenutzer tippen auf den Auslöser, sehen jedoch nie den Tooltip. Screenreader kündigen es zweimal oder gar nicht an. Der Tooltip flackert, wenn Sie die Maus zu schnell bewegen. Es überlappt Inhalte auf kleineren Bildschirmen. Durch Drücken von Esc wird es nicht geschlossen. Der Fokus geht verloren. Mit der Zeit entwickelte sich mein Tooltip-Code zu etwas, das ich eigentlich nicht mehr besitzen wollte. Die Zuhörer des Ereignisses häuften sich. Hover und Fokus mussten separat gehandhabt werden. Für externe Klicks waren Sonderfälle erforderlich. ARIA-Attribute mussten manuell synchronisiert werden. Jeder kleine Fix fügte eine weitere Ebene der Logik hinzu. Bibliotheken haben geholfen, aber sie waren auch eher wie Blackboxen, an denen ich herumarbeitete, anstatt vollständig zu verstehen, was sich hinter den Kulissen abspielte. Das hat mich dazu bewogen, mir die neuere Popover-API anzuschauen. Ich wollte sehen, was passieren würde, wenn ich einen einzelnen Tooltip mit dem nativen Modell des Browsers ohne die Hilfe einer Bibliothek neu erstellen würde. Zu Beginn ist es erwähnenswert, dass es, wie bei jeder neuen Funktion, einige Dinge gibt, die noch ausgebessert werden müssen. Dennoch verfügt es derzeit über eine hervorragende Browserunterstützung, obwohl sich mehrere Teile der gesamten API im Wandel befinden. Es lohnt sich, Caniuse in der Zwischenzeit im Auge zu behalten. Der „alte“ Tooltip Vor der Popover-API war die Verwendung einer Tooltip-Bibliothek keine Abkürzung. Es war die Standardeinstellung. Browser verfügten nicht über ein natives Tooltip-Konzept, das mit Maus, Tastatur und unterstützenden Technologien funktionierte. Wenn Ihnen die Korrektheit wichtig war, blieb Ihnen nur die Verwendung einer Bibliothek, und genau das habe ich getan. Auf einer hohen Ebene war das Muster immer dasselbe: ein Triggerelement, ein verstecktes Tooltip-Element und JavaScript, um die beiden zu koordinieren.
Die Bibliothek kümmerte sich um die Verkabelung, die es dem Element ermöglichte, beim Schweben oder Fokussieren angezeigt, bei Unschärfe oder beim Verlassen der Maus ausgeblendet und beim Scrollen neu positioniert/in der Größe geändert zu werden.
Mit der Zeit könnte der Tooltip brüchig werden. Kleine Änderungen bergen Risiken. Kleinere Korrekturen verursachten Regressionen. Schlimmer noch: Das Hinzufügen neuer Tooltips führte zu derselben Komplexität. Technisch funktionierte alles, aber es fühlte sich nie erledigt oder abgeschlossen an. Das war der Stand der Dinge, als ich beschloss, den Tooltip mithilfe der nativen Popover-API des Browsers neu zu erstellen. Der Moment, als ich die Popover-API ausprobierte Ich bin nicht auf die Verwendung der Popover-API umgestiegen, weil ich mit etwas Neuem experimentieren wollte. Ich habe gewechselt, weil ich es satt hatte, das Tooltip-Verhalten beizubehalten, von dem ich glaubte, dass der Browser es bereits hätte verstehen sollen. Ich war zunächst skeptisch. Die meisten neuen Web-APIs versprechen Einfachheit, erfordern aber dennoch Glue, Edge-Case-Handling oder Fallback-Logik, die stillschweigend dieselbe Komplexität wiederherstellt, der Sie entkommen wollten. Also habe ich die Popover-API so klein wie möglich ausprobiert. So sah das aus:
her
1. Die Tastatur „funktioniert einfach“ Die Tastaturunterstützung hing von der korrekten Ausrichtung mehrerer Ebenen ab: Der Fokus musste den Tooltip auslösen, Unschärfe musste ihn ausblenden, Esc musste manuell verdrahtet werden und das Timing war wichtig. Wenn Sie einen Randfall übersehen haben, bleibt der Tooltip entweder zu lange geöffnet oder verschwindet, bevor er gelesen werden kann. Wenn das Popover-Attribut auf „Auto“ oder „Manuell“ eingestellt ist, übernimmt der Browser die Grundlagen: Tab und Umschalt+Tab verhalten sich normal, Esc schließt den Tooltip jedes Mal und es sind keine zusätzlichen Listener erforderlich.
Was aus meiner Codebasis verschwand, waren globale Keydown-Handler, Esc-spezifische Bereinigungslogik und Statusprüfungen während der Tastaturnavigation. Das Tastaturerlebnis war nicht mehr etwas, das ich beibehalten musste, sondern wurde zu einer Browsergarantie. 2. Vorhersehbarkeit des Screenreaders Das war dasgrößte Verbesserung. Selbst bei sorgfältiger ARIA-Arbeit variierte das Verhalten, wie ich bereits dargelegt habe. Jede kleine Veränderung fühlte sich riskant an. Die Verwendung eines Popovers mit einer geeigneten Rolle sieht viel stabiler und vorhersehbarer aus und fühlt sich auch so an, was das betrifft, was passieren wird:
Und hier ist ein weiterer Vorteil: Nach der Umstellung hat Lighthouse aufgehört, falsche ARIA-Statuswarnungen für die Interaktion zu kennzeichnen, vor allem weil es keine benutzerdefinierten ARIA-Status mehr gibt, bei denen ich versehentlich einen Fehler machen könnte.
3. Fokusmanagement Früher war der Fokus fragil. Früher hatte ich Regeln wie: Fokusauslöser Tooltip anzeigen lassen, Fokus in Tooltip verschieben und nicht schließen, Unschärfe auslösen, wenn er zu nah ist, und Tooltip schließen und Fokus manuell wiederherstellen. Das hat funktioniert, bis es nicht mehr funktionierte. Mit der Popover-API erzwingt der Browser ein einfacheres Modell, bei dem der Fokus natürlicher in das Popover verschoben werden kann. Durch das Schließen des Popovers wird der Fokus wieder auf den Auslöser gerichtet, und es gibt keine unsichtbaren Fokusfallen oder Fokusverlustmomente. Und ich habe keinen Code zur Fokuswiederherstellung hinzugefügt; Ich habe es entfernt.
Fazit Dank der Popover-API können Sie Tooltips nicht mehr simulieren. Sie sind etwas, das der Browser versteht. Öffnen, Schließen, Tastaturverhalten, Escape-Handhabung und ein großer Teil der Barrierefreiheit kommen jetzt von der Plattform selbst und nicht von Ad-hoc-JavaScript. Das bedeutet nicht, dass Tooltip-Bibliotheken veraltet sind, weil sie für komplexe Designsysteme, umfangreiche Anpassungen oder ältere Einschränkungen immer noch sinnvoll sind, aber die Standardeinstellung hat sich verschoben. Zum ersten Mal kann der einfachste Tooltip auch der korrekteste sein. Wenn Sie neugierig sind, probieren Sie dieses Experiment aus: Ersetzen Sie einfach nur einen Tooltip in Ihrem Produkt durch die Popover-API, schreiben Sie nicht alles neu, migrieren Sie nicht ein ganzes System, sondern wählen Sie einfach einen aus und sehen Sie, was aus Ihrem Code verschwindet. Wenn die Plattform Ihnen ein besseres Grundelement bietet, bedeutet der Gewinn nicht nur weniger Zeilen JavaScript, sondern Sie müssen sich auch um weniger Dinge kümmern. Schauen Sie sich den vollständigen Quellcode in meinem GitHub-Repo an. Weiterführende Literatur Für tiefere Einblicke in Popovers und verwandte APIs:
„Poppin‘ In“, Geoff Graham „Klärung der Beziehung zwischen Popovers und Dialogen“, Zell Liew „Was ist Popover=Hint?“, Una Kravets „Invoker Commands“, Daniel Schwarz „Erstellen einer Benachrichtigung zum automatischen Schließen mit einem HTML-Popover“, Preethi Öffnen Sie den UI-Popover-API-Explainer „Pop(over) the Balloons“, John Rhea „CSS-Ankerpositionierung“, Juan Diego Rodríguez
MDN bietet auch umfassende technische Dokumentation für die Popover-API.
