Værktøjstip føles som det mindste brugergrænsefladeproblem, du kan have. De er små og normalt skjulte. Når nogen spørger, hvordan man bygger en, kommer det traditionelle svar næsten altid tilbage ved hjælp af et eller andet JavaScript-bibliotek. Og det var længe det fornuftige råd. Jeg fulgte den også. På overfladen er et værktøjstip enkelt. Hold musemarkøren eller fokuser på et element, vis en lille boks med noget tekst, og skjul den, når brugeren bevæger sig væk. Men når du sender en til rigtige brugere, begynder kanterne at vise sig. Tastaturbrugere Tab ind i udløseren, men se aldrig værktøjstippet. Skærmlæsere annoncerer det to gange, eller slet ikke. Værktøjstippet flimrer, når du bevæger musen for hurtigt. Det overlapper indhold på mindre skærme. Et tryk på Esc lukker det ikke. Fokus forsvinder. Med tiden voksede min værktøjstip-kode til noget, jeg egentlig ikke havde lyst til at eje længere. Begivenhedslyttere hobede sig op. Hover og fokus skulle håndteres separat. Udefrakommende klik krævede særlige tilfælde. ARIA-attributter skulle holdes synkroniseret i hånden. Hver lille rettelse tilføjede endnu et lag af logik. Biblioteker hjalp, men de var også mere som sorte kasser, jeg arbejdede omkring i stedet for fuldt ud at forstå, hvad der skete bag kulisserne. Det var det, der fik mig til at se på den nyere Popover API. Jeg ville se, hvad der ville ske, hvis jeg genopbyggede et enkelt værktøjstip ved hjælp af browserens oprindelige model uden hjælp fra et bibliotek. Når vi starter, er det værd at bemærke, at der, som med enhver ny funktion, er nogle ting med den, der stadig er ved at blive slettet. Når det er sagt, nyder det i øjeblikket stor browserunderstøttelse, selvom der er flere dele af den overordnede API, der er i forandring. Det er værd at holde øje med Caniuse imens. Det "gamle" værktøjstip Før Popover API var det ikke en genvej at bruge et værktøjstip-bibliotek. Det var standard. Browsere havde ikke et indbygget koncept af et værktøjstip, der fungerede på tværs af mus, tastatur og hjælpeteknologi. Hvis du bekymrede dig om korrekthed, var din eneste mulighed at bruge et bibliotek, og det er præcis, hvad jeg gjorde. På et højt niveau var mønsteret altid det samme: et trigger-element, et skjult værktøjstip-element og JavaScript for at koordinere de to.
Biblioteket håndterede ledningerne, der gjorde det muligt for elementet at blive vist ved svæv eller fokus, gemme sig ved sløring eller museforladelse og omplacere/ændre størrelse på scroll.
Med tiden kan værktøjstippet blive skrøbeligt. Små ændringer indebar risiko. Mindre rettelser forårsagede regression. Værre er det, at tilføjelse af nye værktøjstip arvede den samme kompleksitet. Tingene fungerede teknisk, men føltes aldrig afklarede eller fuldstændige. Det var tingenes tilstand, da jeg besluttede at genopbygge værktøjstippet ved hjælp af browserens oprindelige Popover API. Det øjeblik, jeg prøvede Popover API Jeg skiftede ikke til at bruge Popover API, fordi jeg ville eksperimentere med noget nyt. Jeg skiftede, fordi jeg var træt af at opretholde værktøjstip-adfærd, som jeg troede, at browseren allerede burde have forstået. Jeg var skeptisk i starten. De fleste nye web-API'er lover enkelhed, men kræver stadig lim, kant-case-håndtering eller fallback-logik, der stille og roligt genskaber den samme kompleksitet, som du forsøgte at undslippe. Så jeg prøvede Popover API på den mindst mulige måde. Sådan så det ud:
1. Tastaturet "fungerer bare" Tastaturunderstøttelse afhang af, at flere lag lå korrekt på linie: fokus skulle udløse værktøjstip, sløring skulle skjule det, Esc skulle forbindes manuelt, og timing havde betydning. Hvis du gik glip af en kantkasse, ville værktøjstippen enten forblive åben for længe eller forsvinde, før den kunne læses. Med popover-attributten indstillet til auto eller manuel, overtager browseren det grundlæggende: Tab og Shift+Tab opfører sig normalt, Esc lukker værktøjstippet hver gang, og der kræves ingen ekstra lyttere.
Det, der forsvandt fra min kodebase, var globale nedtastningshandlere, Esc-specifik oprydningslogik og tilstandstjek under tastaturnavigation. Tastaturoplevelsen holdt op med at være noget, jeg skulle vedligeholde, og det blev en browsergaranti. 2. Skærmlæser forudsigelighed Dette varstørste forbedring. Selv med omhyggeligt ARIA-arbejde varierede adfærden, som jeg skitserede tidligere. Hver lille ændring føltes risikabel. At bruge en popover med en ordentlig rolle ser ud og føles meget mere stabil og forudsigelig med hensyn til, hvad der kommer til at ske:
Og her er endnu en sejr: Efter skiftet stoppede Lighthouse med at markere ukorrekte ARIA-tilstandsadvarsler for interaktionen, hovedsagelig fordi der ikke længere er tilpassede ARIA-tilstande, som jeg ved et uheld kan tage fejl af.
3. Fokusstyring Fokus plejede at være skrøbeligt. Før havde jeg regler som: lad fokus trigger vise værktøjstip, flyt fokus til værktøjstip og luk ikke, slør trigger, når det er for tæt, og luk værktøjstip og gendan fokus manuelt. Dette virkede, indtil det ikke gjorde det. Med Popover API'en gennemtvinger browseren en enklere model, hvor fokus kan flyttes mere naturligt ind i popoveren. Lukning af popover vender fokus tilbage til udløseren, og der er ingen usynlige fokusfælder eller mistede fokusøjeblikke. Og jeg tilføjede ikke fokusgendannelseskode; Jeg fjernede den.
Konklusion Popover API betyder, at værktøjstip ikke længere er noget, du simulerer. De er noget, browseren forstår. Åbning, lukning, tastaturadfærd, Escape-håndtering og en stor del af tilgængeligheden kommer nu fra selve platformen, ikke fra ad-hoc JavaScript. Det betyder ikke, at biblioteker med værktøjstip er forældede, fordi de stadig giver mening for komplekse designsystemer, tung tilpasning eller ældre begrænsninger, men standarden har ændret sig. For første gang kan det enkleste værktøjstip også være det mest korrekte. Hvis du er nysgerrig, så prøv dette eksperiment: Du skal blot udskifte ét værktøjstip i dit produkt med Popover API, ikke omskrive alt, ikke migrere et helt system, og bare vælge et og se, hvad der forsvinder fra din kode. Når platformen giver dig en bedre primitiv, er gevinsten ikke bare færre linjer JavaScript, men det er færre ting, du overhovedet skal bekymre dig om. Tjek den fulde kildekode i min GitHub-repo. Yderligere læsning For dybere dyk ned i popovers og relaterede API'er:
"Poppin' In", Geoff Graham "Afklaring af forholdet mellem popovers og dialoger", Zell Liew "Hvad er popover=hint?", Una Kravets "Invoker Commands", Daniel Schwarz "Oprettelse af en auto-lukkende notifikation med en HTML popover", Preethi Åbn UI Popover API Explainer "Pop(over) ballonerne", John Rhea "CSS Anchor Positioning", Juan Diego Rodríguez
MDN tilbyder også omfattende teknisk dokumentation til Popover API.
