Verktygstips känns som det minsta UI-problem du kan ha. De är små och vanligtvis dolda. När någon frågar hur man bygger en, kommer det traditionella svaret nästan alltid tillbaka med hjälp av något JavaScript-bibliotek. Och det var länge det vettiga rådet. Jag följde den också. På ytan är ett verktygstips enkelt. Håll muspekaren eller fokusera på ett element, visa en liten ruta med lite text och dölj den sedan när användaren flyttar sig bort. Men när du väl skickar en till riktiga användare börjar kanterna synas. Tangentbordsanvändare Tryck in avtryckaren, men se aldrig verktygstipset. Skärmläsare meddelar det två gånger, eller inte alls. Verktygstipset flimrar när du flyttar musen för snabbt. Det överlappar innehåll på mindre skärmar. Att trycka på Esc stängs inte. Fokus försvinner. Med tiden växte min verktygstipskod till något jag egentligen inte ville äga längre. Eventlyssnare hopade sig. Hover och fokus måste hanteras separat. Utomstående klick behövde specialfall. ARIA-attribut måste hållas synkroniserade för hand. Varje liten fix lade till ytterligare ett lager av logik. Biblioteken hjälpte till, men de var också mer som svarta lådor jag arbetade runt istället för att helt förstå vad som hände bakom kulisserna. Det var det som fick mig att titta på det nyare Popover API. Jag ville se vad som skulle hända om jag byggde om ett enda verktygstips med hjälp av webbläsarens ursprungliga modell utan hjälp av ett bibliotek. När vi börjar är det värt att notera att, precis som med alla nya funktioner, finns det några saker med den som fortfarande håller på att strykas ut. Som sagt, det åtnjuter för närvarande bra webbläsarstöd, även om det finns flera delar av det övergripande API:et som är i förändring. Det är värt att hålla ett öga på Caniuse under tiden. Det "gamla" verktygstipset Innan Popover API var användningen av ett verktygstipsbibliotek inte en genväg. Det var standard. Webbläsare hade inte ett inbyggt koncept av ett verktygstips som fungerade med mus, tangentbord och hjälpmedel. Om du brydde dig om korrekthet var ditt enda alternativ att använda ett bibliotek, och det var precis vad jag gjorde. På en hög nivå var mönstret alltid detsamma: ett triggerelement, ett dolt verktygstipselement och JavaScript för att koordinera de två.
Biblioteket hanterade ledningarna som gjorde det möjligt för elementet att visas vid svävning eller fokus, dölja sig vid oskärpa eller musen lämnar, och flytta/ändra storlek på scroll.
Med tiden kan verktygstipset bli ömtåligt. Små förändringar innebar risk. Mindre korrigeringar orsakade regressioner. Ännu värre, att lägga till nya verktygstips ärvde samma komplexitet. Saker och ting fungerade tekniskt, men kändes aldrig avgjorda eller kompletta. Det var läget när jag bestämde mig för att bygga om verktygstipset med webbläsarens inbyggda Popover API. I samma ögonblick som jag provade Popover API Jag bytte inte till att använda Popover API eftersom jag ville experimentera med något nytt. Jag bytte eftersom jag var trött på att upprätthålla verktygstipsbeteende som jag trodde att webbläsaren redan borde ha förstått. Jag var skeptisk först. De flesta nya webb-API:er lovar enkelhet, men kräver fortfarande lim, kant-case-hantering eller reservlogik som tyst återskapar samma komplexitet som du försökte undkomma. Så jag provade Popover API på minsta möjliga sätt. Så här såg det ut:
1. Tangentbordet "fungerar bara" Tangentbordsstödet berodde på att flera lager ställdes upp på rätt sätt: fokus måste utlösa verktygstipset, oskärpa måste dölja det, Esc måste kopplas manuellt och timingen spelade roll. Om du missade ett kantfodral skulle verktygstipset antingen vara öppet för länge eller försvinna innan det kunde läsas. Med popover-attributet inställt på auto eller manuell tar webbläsaren över grunderna: Tab och Shift+Tab beter sig normalt, Esc stänger verktygstipset varje gång och inga extra lyssnare krävs.
Det som försvann från min kodbas var globala keydown-hanterare, Esc-specifik rensningslogik och tillståndskontroller under tangentbordsnavigering. Tangentbordsupplevelsen slutade vara något jag var tvungen att underhålla, och det blev en webbläsargaranti. 2. Skärmläsare Förutsägbarhet Detta varstörsta förbättringen. Även med noggrant ARIA-arbete varierade beteendet, som jag beskrev tidigare. Varje liten förändring kändes riskabel. Att använda en popover med en riktig roll ser ut och känns mycket mer stabil och förutsägbar när det gäller vad som kommer att hända:
Och här är en annan vinst: Efter bytet slutade Lighthouse att flagga felaktiga ARIA-tillståndsvarningar för interaktionen, till stor del för att det inte längre finns anpassade ARIA-tillstånd som jag av misstag får fel.
3. Fokushantering Fokus brukade vara bräckligt. Förut hade jag regler som: låt fokusutlösaren visa verktygstips, flytta fokus till verktygstipset och stäng inte, oskärpa utlösaren när det är för nära och stäng verktygstipset och återställ fokus manuellt. Detta fungerade tills det inte gjorde det. Med Popover API tvingar webbläsaren fram en enklare modell där fokus kan flyttas mer naturligt in i popover. När du stänger popover-fönstret återgår fokus till avtryckaren, och det finns inga osynliga fokusfällor eller förlorade fokusögonblick. Och jag lade inte till fokusåterställningskod; Jag tog bort den.
Slutsats Popover API innebär att verktygstips inte längre är något du simulerar. De är något webbläsaren förstår. Öppning, stängning, tangentbordsbeteende, Escape-hantering och en stor del av tillgängligheten kommer nu från själva plattformen, inte från ad-hoc JavaScript. Det betyder inte att verktygstipsbibliotek är föråldrade eftersom de fortfarande är meningsfulla för komplexa designsystem, tung anpassning eller äldre begränsningar, men standarden har ändrats. För första gången kan det enklaste verktygstipset också vara det mest korrekta. Om du är nyfiken, prova det här experimentet: Byt bara ut ett verktygstips i din produkt med Popover API, skriv inte om allt, migrera inte ett helt system, och välj bara ett och se vad som försvinner från din kod. När plattformen ger dig en bättre primitiv är vinsten inte bara färre rader JavaScript, utan det är färre saker du behöver oroa dig för överhuvudtaget. Kolla in hela källkoden i min GitHub-repo. Ytterligare läsning För djupare dykning i popovers och relaterade API:er:
"Poppin' In", Geoff Graham "Att klargöra förhållandet mellan popovers och dialoger", Zell Liew "Vad är popover=hint?", Una Kravets "Invoker Commands", Daniel Schwarz "Skapa ett meddelande om automatisk stängning med en HTML-popover", Preethi Öppna UI Popover API Explainer "Pop (över) ballongerna", John Rhea "CSS Anchor Positioning", Juan Diego Rodríguez
MDN erbjuder också omfattande teknisk dokumentation för Popover API.
