Az eszköztippek a lehető legkisebb felhasználói felületi problémának tűnnek. Aprók és általában rejtve vannak. Amikor valaki megkérdezi, hogyan kell létrehozni egyet, a hagyományos válasz szinte mindig valamilyen JavaScript-könyvtár használatával jön vissza. És sokáig ez volt az értelmes tanács. Én is követtem. A felszínen az eszköztipp egyszerű. Vigye az egérmutatót egy elemre vagy fókuszáljon rá, mutasson meg egy kis szöveget tartalmazó dobozt, majd rejtse el, amikor a felhasználó eltávolodik. De amint elküld egyet valódi felhasználóknak, az élek megjelennek. Billentyűzet-felhasználók Lapozzon a triggerbe, de soha ne látja az elemleírást. A képernyőolvasók kétszer jelentik be, vagy egyáltalán nem. Az eszköztipp villog, ha túl gyorsan mozgatja az egeret. Kisebb képernyőkön átfedi a tartalmat. Az Esc megnyomása nem zárja be. A fókusz elvész. Idővel az eszköztipp-kódom olyanná nőtte ki magát, amit már nem igazán akartam birtokolni. Felhalmozódtak az eseményhallgatók. A lebegtetést és a fókuszt külön kellett kezelni. A külső kattintásokhoz speciális esetekre volt szükség. Az ARIA attribútumokat kézzel kellett szinkronban tartani. Minden apró javítás újabb logikai réteget adott. A könyvtárak segítettek, de inkább fekete dobozok voltak, amelyek körül dolgoztam, ahelyett, hogy teljesen megértettem volna, mi történik a színfalak mögött. Ez késztetett arra, hogy megnézzem az újabb Popover API-t. Meg akartam nézni, mi történik, ha egyetlen elemleírást újraépítek a böngésző natív modelljével, könyvtár segítsége nélkül. Amint elkezdjük, érdemes megjegyezni, hogy mint minden új funkciónál, ebben is vannak olyan dolgok, amelyeket még mindig elsimítanak. Ennek ellenére jelenleg nagyszerű böngészőtámogatást élvez, bár az API-nak számos olyan része van, amely folyamatosan változik. Érdemes addig is figyelni a Caniuse-t. A „régi” eszköztipp A Popover API előtt az eszköztipp-könyvtár használata nem volt parancsikon. Ez volt az alapértelmezett. A böngészőknek nem volt natív koncepciója az egér, a billentyűzet és a kisegítő technológiák között működő eszköztippről. Ha törődött a helyességgel, az egyetlen lehetőség a könyvtár használata volt, és én pontosan ezt tettem. Magas szinten a minta mindig ugyanaz volt: trigger elem, rejtett eszköztipp elem és JavaScript a kettő összehangolására.
A könyvtár kezelte azokat a vezetékeket, amelyek lehetővé tették az elem megjelenítését lebegtetéskor vagy fókuszáláskor, elrejtést az elmosódáskor vagy az egér elhagyásakor, valamint az áthelyezést/méretezést görgetéskor.
Idővel az eszköztipp törékennyé válhat. A kis változtatások kockázatot hordoztak magukban. A kisebb javítások regressziót okoztak. Ami még rosszabb, az új eszköztippek hozzáadása ugyanazt a bonyolultságot örökölte. A dolgok technikailag működtek, de soha nem érezték rendezettnek vagy befejezettnek. Ez volt a dolgok állása, amikor úgy döntöttem, hogy újraépítem az eszköztippet a böngésző natív Popover API-jával. A pillanat, amikor kipróbáltam a Popover API-t Nem azért váltottam a Popover API használatára, mert valami újjal akartam kísérletezni. Azért váltottam, mert belefáradtam abba, hogy fenntartsam az eszköztipp-viselkedést, amelyet szerintem a böngészőnek már meg kellett értenie. Először szkeptikus voltam. A legtöbb új webes API egyszerűséget ígér, de továbbra is ragasztót, éles esetkezelést vagy tartalék logikát igényel, amely csendben újrateremti ugyanazt a komplexitást, amelyet megpróbált elkerülni. Tehát a Popover API-t a lehető legkisebb módon próbáltam ki. Íme, hogy nézett ki:
A kapcsolatot
1. A billentyűzet „csak működik” A billentyűzet támogatása attól függött, hogy több réteg megfelelően illeszkedett: a fókusznak ki kellett váltania az eszköztippet, az elmosódásnak el kellett rejtenie, az Esc-t manuálisan kellett bekötni, és az időzítés számított. Ha kihagyott egy éles esetet, az eszköztipp vagy túl sokáig nyitva marad, vagy eltűnik, mielőtt elolvashatná. Ha a popover attribútumot automatikusra vagy manuálisra állítja, a böngésző átveszi az alapokat: a Tab és a Shift+Tab normálisan viselkedik, az Esc minden alkalommal bezárja az eszköztippet, és nincs szükség további figyelőkre.
A kódbázisomból a globális billentyűzetkezelők, az Esc-specifikus tisztítási logika és a billentyűzet-navigáció során végzett állapotellenőrzések tűntek el. A billentyűzet-élmény megszűnt olyasvalaminek lenni, amit karban kellett tartanom, és ez böngészőgarancia lett. 2. Képernyőolvasó kiszámíthatósága Ez volt alegnagyobb javulás. Még a gondos ARIA-munka mellett is változott a viselkedés, amint azt korábban vázoltam. Minden apró változtatás kockázatosnak tűnt. A megfelelő szerepkörrel rendelkező popover használata sokkal stabilabbnak és kiszámíthatóbbnak tűnik, ami a történéseket illeti:
És itt van egy másik győzelem: a váltás után a Lighthouse nem jelezte a helytelen ARIA-állapotra vonatkozó figyelmeztetéseket az interakcióhoz, főként azért, mert már nincsenek egyéni ARIA-állapotok, amelyek miatt véletlenül tévednék.
3. Fókuszkezelés A fókusz korábban törékeny volt. Korábban olyan szabályaim voltak, mint: engedje, hogy a fókusz kioldója mutassa az elemleírást, helyezze át a fókuszt az elemleírásba, és ne zárja be, az elmosódás triggerje, ha túl közel van, és zárja be az elemleírást, és állítsa vissza manuálisan a fókuszt. Ez addig működött, amíg meg nem. A Popover API-val a böngésző egy egyszerűbb modellt kényszerít ki, ahol a fókusz természetesebben mozoghat a popoverben. A felugró ablak bezárásával a fókusz visszakerül a triggerre, és nincsenek láthatatlan fókuszcsapdák vagy elveszett fókuszpillanatok. És nem adtam hozzá fókuszhelyreállító kódot; eltávolítottam.
Következtetés A Popover API azt jelenti, hogy az eszköztippeket többé nem szimulálja. Ezeket a böngésző megérti. A nyitás, bezárás, a billentyűzet viselkedése, az Escape-kezelés és a kisegítő lehetőségek nagy része immár magától a platformtól származik, nem pedig az ad-hoc JavaScripttől. Ez nem jelenti azt, hogy az eszköztipp-könyvtárak elavultak, mert még mindig értelmet adnak az összetett tervezési rendszerekhez, a súlyos testreszabáshoz vagy az örökölt megszorításokhoz, de az alapértelmezés megváltozott. Most először a legegyszerűbb eszköztipp lehet a leghelyesebb is. Ha kíváncsi, próbálja ki ezt a kísérletet: Egyszerűen cserélje ki a termékben lévő egyetlen eszközleírást a Popover API-val, ne írjon át mindent, ne migráljon át egy egész rendszert, csak válasszon egyet, és nézze meg, mi tűnik el a kódból. Amikor a platform jobb primitívet ad, akkor nem csupán kevesebb sornyi JavaScript nyer, hanem kevesebb dolog miatt kell aggódnia. Tekintse meg a teljes forráskódot a GitHub-tárhelyemben. További olvasás A popoverek és a kapcsolódó API-k mélyebb megismeréséhez:
„Poppin’ In”, Geoff Graham „A felbukkanó üzenetek és a párbeszédek közötti kapcsolat tisztázása”, Zell Liew „Mi az a popover=hint?”, Una Kravets „Invoker Commands”, Daniel Schwarz „Automatikus bezáródási értesítés létrehozása HTML-előugró üzenettel”, Preethi Nyissa meg a UI Popover API Explainert „Pop(over) the Balloons”, John Rhea „CSS horgony pozicionálás”, Juan Diego Rodríguez
Az MDN átfogó műszaki dokumentációt is kínál a Popover API-hoz.
