Verktøytips føles som det minste UI-problemet du kan ha. De er små og vanligvis skjulte. Når noen spør hvordan man bygger en, kommer det tradisjonelle svaret nesten alltid tilbake ved å bruke et eller annet JavaScript-bibliotek. Og lenge var det det fornuftige rådet. Jeg fulgte den også. På overflaten er et verktøytips enkelt. Hold musepekeren eller fokuser på et element, vis en liten boks med litt tekst, og skjul den så når brukeren beveger seg bort. Men når du sender en til ekte brukere, begynner kantene å vise seg. Tastaturbrukere Tapper inn i utløseren, men ser aldri verktøytipset. Skjermlesere kunngjør det to ganger, eller ikke i det hele tatt. Verktøytipset flimrer når du beveger musen for raskt. Det overlapper innhold på mindre skjermer. Hvis du trykker på Esc, lukkes den ikke. Fokus forsvinner. Over tid vokste verktøytipskoden min til noe jeg egentlig ikke ønsket å eie lenger. Arrangementslyttere hopet seg opp. Hover og fokus måtte håndteres separat. Utenfor klikk trengte spesielle tilfeller. ARIA-attributter måtte holdes synkronisert for hånd. Hver liten reparasjon la til et nytt lag med logikk. Biblioteker hjalp, men de var også mer som svarte bokser jeg jobbet rundt i stedet for å forstå fullt ut hva som skjedde bak kulissene. Det var det som fikk meg til å se på det nyere Popover API. Jeg ønsket å se hva som ville skje hvis jeg gjenoppbygget et enkelt verktøytips ved hjelp av nettleserens opprinnelige modell uten hjelp av et bibliotek. Når vi starter, er det verdt å merke seg at, som med alle nye funksjoner, er det noen ting med den som fortsatt blir ryddet ut. Når det er sagt, nyter den for tiden god nettleserstøtte, selv om det er flere deler av den generelle API-en som er i endring. Det er verdt å holde øye med Caniuse i mellomtiden. Det "gamle" verktøytipset Før Popover API var bruk av et verktøytipsbibliotek ikke en snarvei. Det var standard. Nettlesere hadde ikke et innfødt konsept av et verktøytips som fungerte på tvers av mus, tastatur og hjelpeteknologi. Hvis du brydde deg om korrekthet, var din eneste mulighet å bruke et bibliotek, og det var akkurat det jeg gjorde. På et høyt nivå var mønsteret alltid det samme: et triggerelement, et skjult verktøytipselement og JavaScript for å koordinere de to.
Biblioteket håndterte ledningene som gjorde at elementet kunne vises ved sveving eller fokus, gjemme seg ved uskarphet eller museavbrudd, og endre plassering/endre størrelse ved rulling.
Over tid kan verktøytipset bli skjørt. Små endringer ga risiko. Mindre rettinger forårsaket regresjoner. Enda verre, å legge til nye verktøytips arvet den samme kompleksiteten. Ting fungerte teknisk, men føltes aldri avgjort eller komplett. Det var tingenes tilstand da jeg bestemte meg for å gjenoppbygge verktøytipset ved å bruke nettleserens opprinnelige Popover API. Øyeblikket jeg prøvde Popover API Jeg byttet ikke til å bruke Popover API fordi jeg ønsket å eksperimentere med noe nytt. Jeg byttet fordi jeg var lei av å opprettholde verktøytipsadferd som jeg trodde nettleseren allerede burde ha forstått. Jeg var skeptisk i begynnelsen. De fleste nye web-API-er lover enkelhet, men krever fortsatt lim, kant-case-håndtering eller reservelogikk som stille gjenskaper den samme kompleksiteten som du prøvde å unnslippe. Så jeg prøvde Popover API på den minste mulige måten. Slik så det ut:
1. Tastaturet "fungerer bare" Tastaturstøtten var avhengig av at flere lag stilte opp på riktig måte: fokus måtte utløse verktøytipset, uskarphet måtte skjule det, Esc måtte kobles manuelt, og timing var viktig. Hvis du gikk glipp av ett kanthus, ville verktøytipset enten være åpent for lenge eller forsvinne før det kunne leses. Med popover-attributtet satt til auto eller manuell, tar nettleseren over det grunnleggende: Tab og Shift+Tab oppfører seg normalt, Esc lukker verktøytipset hver gang, og ingen ekstra lyttere er nødvendig.
Det som forsvant fra kodebasen min var globale tastenedbehandlere, Esc-spesifikk oppryddingslogikk og tilstandskontroller under tastaturnavigering. Tastaturopplevelsen sluttet å være noe jeg måtte vedlikeholde, og det ble en nettlesergaranti. 2. Forutsigbarhet for skjermleser Dette varstørste forbedring. Selv med nøye ARIA-arbeid varierte oppførselen, som jeg skisserte tidligere. Hver liten endring føltes risikabel. Å bruke en popover med en skikkelig rolle ser ut og føles mye mer stabil og forutsigbar når det gjelder hva som skal skje:
Og her er en annen seier: Etter byttet sluttet Lighthouse å flagge ukorrekte ARIA-tilstandsadvarsler for interaksjonen, hovedsakelig fordi det ikke lenger er tilpassede ARIA-tilstander for meg å ta feil.
3. Fokusstyring Fokus pleide å være skjørt. Før hadde jeg regler som: la fokusutløse vise verktøytips, flytte fokus til verktøytips og ikke lukke, uskarp utløser når det er for nært, og lukk verktøytips og gjenopprett fokus manuelt. Dette fungerte til det ikke gjorde det. Med Popover API håndhever nettleseren en enklere modell der fokus kan flyttes mer naturlig inn i popover. Når du lukker popoveren, returnerer fokus til utløseren, og det er ingen usynlige fokusfeller eller tapte fokusøyeblikk. Og jeg la ikke til fokusgjenopprettingskode; Jeg fjernet den.
Konklusjon Popover API betyr at verktøytips ikke lenger er noe du simulerer. De er noe nettleseren forstår. Åpning, lukking, tastaturatferd, rømningshåndtering og en stor del av tilgjengeligheten kommer nå fra selve plattformen, ikke fra ad-hoc JavaScript. Det betyr ikke at verktøytipsbiblioteker er foreldet fordi de fortsatt gir mening for komplekse designsystemer, tung tilpasning eller eldre begrensninger, men standarden har endret seg. For første gang kan det enkleste verktøytipset også være det mest korrekte. Hvis du er nysgjerrig, prøv dette eksperimentet: Bare bytt ut ett verktøytips i produktet ditt med Popover API, ikke skriv om alt, ikke migrér et helt system, og velg bare ett og se hva som forsvinner fra koden din. Når plattformen gir deg en bedre primitiv, er gevinsten ikke bare færre linjer med JavaScript, men det er færre ting du trenger å bekymre deg for i det hele tatt. Sjekk ut hele kildekoden i GitHub-repoen min. Videre lesing For dypere dykk i popovers og relaterte APIer:
"Poppin' In", Geoff Graham "Avklare forholdet mellom popovers og dialoger", Zell Liew "Hva er popover=hint?", Una Kravets "Invoker Commands", Daniel Schwarz "Opprette en automatisk stengingsvarsling med en HTML Popover", Preethi Åpne UI Popover API Explainer "Popp(over) ballongene", John Rhea "CSS Anchor Positioning", Juan Diego Rodríguez
MDN tilbyr også omfattende teknisk dokumentasjon for Popover API.
