Tooltips voelen aan als het kleinste UI-probleem dat je kunt hebben. Ze zijn klein en meestal verborgen. Wanneer iemand vraagt hoe je er een moet bouwen, komt het traditionele antwoord bijna altijd terug met behulp van een JavaScript-bibliotheek. En dat was lange tijd het verstandige advies. Ik heb het ook gevolgd. Op het eerste gezicht is een tooltip eenvoudig. Beweeg of focus op een element, toon een klein vakje met wat tekst en verberg het vervolgens wanneer de gebruiker weggaat. Maar zodra u er een naar echte gebruikers verzendt, beginnen de randen zichtbaar te worden. Toetsenbordgebruikers Druk op de trigger, maar zie nooit de tooltip. Schermlezers kondigen dit twee keer aan, of helemaal niet. De tooltip flikkert als u de muis te snel beweegt. Het overlapt inhoud op kleinere schermen. Als u op Esc drukt, wordt het niet gesloten. De focus gaat verloren. Na verloop van tijd groeide mijn tooltipcode uit tot iets dat ik niet echt meer wilde bezitten. Luisteraars van evenementen stapelden zich op. Hover en focus moesten afzonderlijk worden afgehandeld. Voor klikken van buitenaf waren speciale gevallen nodig. ARIA-attributen moesten met de hand gesynchroniseerd worden. Elke kleine oplossing voegde een extra laag logica toe. Bibliotheken hielpen, maar het waren ook meer zwarte dozen waar ik omheen werkte, in plaats van dat ik volledig begreep wat er achter de schermen gebeurde. Dat was wat mij ertoe aanzette om naar de nieuwere Popover API te kijken. Ik wilde zien wat er zou gebeuren als ik een enkele tooltip opnieuw zou opbouwen met behulp van het oorspronkelijke model van de browser, zonder de hulp van een bibliotheek. Als we beginnen, is het de moeite waard om op te merken dat, net als bij elke nieuwe functie, er een aantal dingen zijn die nog steeds worden gladgestreken. Dat gezegd hebbende, geniet het momenteel van geweldige browserondersteuning, hoewel er verschillende onderdelen van de algehele API in beweging zijn. Het is de moeite waard om Caniuse in de tussentijd in de gaten te houden. De ‘oude’ tooltip Vóór de Popover API was het gebruik van een tooltipbibliotheek geen snelkoppeling. Het was de standaard. Browsers hadden geen eigen concept van tooltip dat werkte met muis, toetsenbord en ondersteunende technologie. Als je om correctheid gaf, was je enige optie het gebruik van een bibliotheek, en dat is precies wat ik deed. Op een hoog niveau was het patroon altijd hetzelfde: een triggerelement, een verborgen tooltip-element en JavaScript om de twee te coördineren.
De bibliotheek zorgde voor de bedrading waardoor het element kon worden weergegeven bij zweven of scherpstellen, verbergen bij vervagen of muis verlaten, en verplaatsen/vergroten bij scrollen.
Na verloop van tijd kan de tooltip kwetsbaar worden. Kleine veranderingen brachten risico's met zich mee. Kleine reparaties veroorzaakten regressies. Erger nog, het toevoegen van nieuwe tooltips erfde dezelfde complexiteit. Technisch werkte het allemaal, maar het voelde nooit vertrouwd of compleet. Dat was de stand van zaken toen ik besloot de tooltip opnieuw op te bouwen met behulp van de eigen Popover API van de browser. Het moment dat ik de Popover API probeerde Ik ben niet overgestapt op het gebruik van de Popover API omdat ik met iets nieuws wilde experimenteren. Ik ben overgestapt omdat ik het zat was om tooltip-gedrag te handhaven waarvan ik dacht dat de browser het al had moeten begrijpen. Ik was eerst sceptisch. De meeste nieuwe web-API's beloven eenvoud, maar vereisen nog steeds lijm, edge-case-afhandeling of fallback-logica die stilletjes dezelfde complexiteit herschept waaraan u probeerde te ontsnappen. Dus ik heb de Popover API op de kleinst mogelijke manier geprobeerd. Hier is hoe dat eruit zag:
1. Het toetsenbord “werkt gewoon” Toetsenbordondersteuning was afhankelijk van meerdere lagen die correct uitgelijnd waren: focus moest de tooltip activeren, onscherpte moest deze verbergen, Esc moest handmatig worden aangesloten en de timing was van belang. Als u één randgeval miste, bleef de tooltip te lang open of verdween voordat deze kon worden gelezen. Als het popover-attribuut is ingesteld op automatisch of handmatig, neemt de browser de basisfuncties over: Tab en Shift+Tab gedragen zich normaal, Esc sluit elke keer de tooltip en er zijn geen extra luisteraars vereist.
Wat uit mijn codebase verdween waren globale keydown-handlers, Esc-specifieke opruimlogica en statuscontroles tijdens toetsenbordnavigatie. De toetsenbordervaring was niet langer iets dat ik moest onderhouden, en het werd een browsergarantie. 2. Voorspelbaarheid van schermlezers Dit was degrootste verbetering. Zelfs met zorgvuldig ARIA-werk varieerde het gedrag, zoals ik eerder heb geschetst. Elke kleine verandering voelde riskant. Het gebruik van een popover met de juiste rol oogt en voelt een stuk stabieler en voorspelbaarder wat betreft wat er gaat gebeuren:
En hier is nog een overwinning: na de overstap stopte Lighthouse met het markeren van onjuiste ARIA-statuswaarschuwingen voor de interactie, grotendeels omdat er niet langer aangepaste ARIA-statussen zijn die ik per ongeluk fout kan krijgen.
3. Focusmanagement Focus was vroeger kwetsbaar. Vroeger had ik regels als: laat de focustrigger knopinfo weergeven, verplaats de focus naar knopinfo en sluit niet, vervaag de trigger wanneer deze te dichtbij is, en sluit knopinfo en herstel de focus handmatig. Dit werkte totdat het niet meer gebeurde. Met de Popover API dwingt de browser een eenvoudiger model af waarbij de focus natuurlijker naar de popover kan worden verplaatst. Als u de popover sluit, keert de focus terug naar de trigger en zijn er geen onzichtbare focusvallen of verloren focusmomenten. En ik heb geen focusherstelcode toegevoegd; Ik heb het verwijderd.
Conclusie Dankzij de Popover API zijn tooltips niet langer iets dat u simuleert. Ze zijn iets dat de browser begrijpt. Openen, sluiten, toetsenbordgedrag, Escape-afhandeling en een groot deel van de toegankelijkheid komen nu van het platform zelf, niet van ad-hoc JavaScript. Dat betekent niet dat tooltipbibliotheken verouderd zijn omdat ze nog steeds zinvol zijn voor complexe ontwerpsystemen, zware aanpassingen of verouderde beperkingen, maar de standaard is verschoven. Voor het eerst kan de eenvoudigste tooltip ook de meest correcte zijn. Als je nieuwsgierig bent, probeer dan dit experiment: vervang eenvoudigweg één tooltip in je product door de Popover API, herschrijf niet alles, migreer niet een heel systeem, maar kies er gewoon één en kijk wat er uit je code verdwijnt. Als het platform je een betere primitief geeft, is de winst niet alleen minder regels JavaScript, maar ook minder dingen waar je je zorgen over hoeft te maken. Bekijk de volledige broncode in mijn GitHub-repository. Verder lezen Voor een diepere duik in popovers en gerelateerde API's:
“Poppin’ In”, Geoff Graham “De relatie tussen popovers en dialogen verduidelijken”, Zell Liew “Wat is popover=hint?”, Una Kravets "Invoker-opdrachten", Daniel Schwarz "Een melding voor automatisch sluiten maken met een HTML-popover", Preethi Open UI Popover API-uitleg "Knal (over) de ballonnen", John Rhea “CSS-ankerpositionering”, Juan Diego Rodríguez
MDN biedt ook uitgebreide technische documentatie voor de Popover API.
