Ang mga tooltip ay parang ang pinakamaliit na problema sa UI na maaari mong magkaroon. Maliit ang mga ito at kadalasang nakatago. Kapag may nagtanong kung paano bumuo ng isa, ang tradisyonal na sagot ay halos palaging bumabalik gamit ang ilang JavaScript library. At sa mahabang panahon, iyon ang matinong payo. Sinundan ko rin ito. Sa ibabaw, ang isang tooltip ay simple. Mag-hover o tumuon sa isang elemento, magpakita ng maliit na kahon na may ilang text, pagkatapos ay itago ito kapag lumayo ang user. Ngunit kapag naipadala mo na ang isa sa mga totoong user, magsisimulang lumabas ang mga gilid. Mga user ng keyboard Mag-tab sa trigger, ngunit hindi kailanman makikita ang tooltip. Dalawang beses itong inanunsyo ng mga screen reader, o hindi man lang. Kukutitap ang tooltip kapag masyadong mabilis mong ginalaw ang mouse. Nag-o-overlap ito ng content sa mas maliliit na screen. Ang pagpindot sa Esc ay hindi ito isasara. Nawawala ang focus. Sa paglipas ng panahon, ang aking tooltip code ay naging isang bagay na hindi ko na gustong pag-aari. Nakatambak ang mga nakikinig sa kaganapan. Ang pag-hover at focus ay kailangang hawakan nang hiwalay. Ang mga pag-click sa labas ay nangangailangan ng mga espesyal na kaso. Ang mga katangian ng ARIA ay kailangang panatilihing naka-sync sa pamamagitan ng kamay. Ang bawat maliit na pag-aayos ay nagdagdag ng isa pang layer ng lohika. Nakatulong ang mga aklatan, ngunit mas katulad din sila ng mga itim na kahon na ginawa ko sa halip na lubos na maunawaan kung ano ang nangyayari sa likod ng mga eksena. Iyon ang nagtulak sa akin na tingnan ang mas bagong Popover API. Gusto kong makita kung ano ang mangyayari kung bubuo akong muli ng isang tooltip gamit ang katutubong modelo ng browser nang walang tulong ng isang library. Sa pagsisimula namin, nararapat na tandaan na, tulad ng anumang bagong tampok, may ilang mga bagay na kasama nito na pinaplantsa pa rin. Iyon ay sinabi, kasalukuyang tinatangkilik nito ang mahusay na suporta sa browser, kahit na mayroong ilang mga piraso sa pangkalahatang API na nasa pagbabago. Ito ay nagkakahalaga ng pagsubaybay sa Caniuse pansamantala. Ang "Lumang" Tooltip Bago ang Popover API, ang paggamit ng tooltip library ay hindi isang shortcut. Ito ang default. Ang mga browser ay walang katutubong konsepto ng isang tooltip na gumagana sa mouse, keyboard, at pantulong na teknolohiya. Kung nagmamalasakit ka sa kawastuhan, ang tanging pagpipilian mo ay gumamit ng library, at iyon mismo ang ginawa ko. Sa isang mataas na antas, ang pattern ay palaging pareho: isang elemento ng pag-trigger, isang nakatagong elemento ng tooltip, at JavaScript upang pag-ugnayin ang dalawa.
Pinangangasiwaan ng library ang mga wiring na nagpapahintulot sa elemento na lumabas sa hover o focus, itago sa blur o pag-alis ng mouse, at muling iposisyon/baguhin ang laki sa scroll.
Sa paglipas ng panahon, ang tooltip ay maaaring maging marupok. Ang maliliit na pagbabago ay nagdadala ng panganib. Ang mga maliliit na pag-aayos ay nagdulot ng mga regression. Mas masahol pa, ang pagdaragdag ng mga bagong tooltip ay nagmana ng parehong kumplikado. Ang mga bagay ay teknikal na nagtrabaho, ngunit hindi kailanman nadama na ayos o kumpleto. Iyon ang kalagayan ng mga bagay noong nagpasya akong buuin muli ang tooltip gamit ang native Popover API ng browser. Ang Saglit na Sinubukan Ko Ang Popover API Hindi ako lumipat sa paggamit ng Popover API dahil gusto kong mag-eksperimento ng bago. Lumipat ako dahil pagod na akong panatilihin ang pag-uugali ng tooltip na sa tingin ko ay dapat naiintindihan na ng browser. Nagdududa ako noong una. Karamihan sa mga bagong web API ay nangangako ng pagiging simple, ngunit nangangailangan pa rin ng pandikit, paghawak ng edge-case, o fallback na logic na tahimik na nililikha ang parehong kumplikado na sinusubukan mong takasan. Kaya, sinubukan ko ang Popover API sa pinakamaliit na paraan na posible. Narito kung ano ang hitsura nito:
1. Ang Keyboard na "Gumagana Lang" Ang suporta sa keyboard ay nakadepende sa maraming layer na nakalinya nang tama: kinailangan ng focus ang tooltip, kinailangang itago ito ng blur, kinailangang i-wire ang Esc, at mahalaga ang timing. Kung napalampas mo ang isang gilid na case, ang tooltip ay mananatiling bukas nang masyadong mahaba o mawawala bago ito mabasa. Gamit ang katangian ng popover na nakatakda sa auto o manual, ang browser ay tumatagal sa mga pangunahing kaalaman: Tab at Shift+Tab na kumikilos nang normal, sinasara ng Esc ang tooltip sa bawat oras, at walang karagdagang tagapakinig ang kinakailangan.
Ang nawala sa aking codebase ay ang mga pandaigdigang tagapangasiwa ng keydown, lohika ng paglilinis na partikular sa Esc, at mga pagsusuri ng estado sa panahon ng pag-navigate sa keyboard. Ang karanasan sa keyboard ay tumigil sa pagiging isang bagay na kailangan kong panatilihin, at ito ay naging isang garantiya ng browser. 2. Predictability ng Screenreader Ito ay angpinakamalaking pagpapabuti. Kahit na may maingat na gawain ng ARIA, iba-iba ang pag-uugali, gaya ng binalangkas ko kanina. Ang bawat maliit na pagbabago ay nadama na mapanganib. Ang paggamit ng popover na may tamang papel ay mukhang mas matatag at mahuhulaan kung ano ang mangyayari:
At narito ang isa pang panalo: Pagkatapos ng paglipat, huminto ang Lighthouse sa pag-flag ng mga maling babala ng estado ng ARIA para sa pakikipag-ugnayan, higit sa lahat dahil wala nang mga custom na estado ng ARIA para hindi ko sinasadyang magkamali.
3. Focus Management Dati marupok ang focus. Dati, mayroon akong mga panuntunan tulad ng: hayaan ang focus trigger na magpakita ng tooltip, ilipat ang focus sa tooltip at huwag isara, blur trigger kapag ito ay masyadong malapit, at isara ang tooltip at i-restore nang manu-mano ang focus. Ito ay gumana hanggang sa hindi ito nangyari. Gamit ang Popover API, ang browser ay nagpapatupad ng isang mas simpleng modelo kung saan ang focus ay maaaring mas natural na lumipat sa popover. Ang pagsasara ng popover ay nagbabalik ng focus sa trigger, at walang mga invisible focus traps o mga nawawalang focus moments. At hindi ako nagdagdag ng focus restoration code; Tinanggal ko.
Konklusyon Ang Popover API ay nangangahulugan na ang mga tooltip ay hindi na isang bagay na ginagaya mo. Ang mga ito ay isang bagay na naiintindihan ng browser. Ang pagbubukas, pagsasara, pag-uugali ng keyboard, paghawak sa Escape, at isang malaking bahagi ng pagiging naa-access ay nagmumula na ngayon sa platform mismo, hindi mula sa ad-hoc JavaScript. Hindi iyon nangangahulugan na ang mga library ng tooltip ay hindi na ginagamit dahil may katuturan pa rin ang mga ito para sa mga kumplikadong sistema ng disenyo, mabigat na pag-customize, o mga legacy na hadlang, ngunit ang default ay inilipat. Sa unang pagkakataon, ang pinakasimpleng tooltip ay maaari ding maging ang pinakatama. Kung mausisa ka, subukan ang eksperimentong ito: Palitan lang ang isang tooltip sa iyong produkto ng Popover API, huwag muling isulat ang lahat, huwag mag-migrate ng buong system, at pumili lang ng isa at tingnan kung ano ang nawawala sa iyong code. Kapag ang platform ay nagbibigay sa iyo ng isang mas mahusay na primitive, ang panalo ay hindi lamang mas kaunting mga linya ng JavaScript, ngunit ito ay mas kaunting mga bagay na dapat mong alalahanin. Tingnan ang buong source code sa aking GitHub repo. Karagdagang Pagbasa Para sa mas malalim na pagsisid sa mga popover at mga nauugnay na API:
"Poppin' In", Geoff Graham "Paglilinaw sa Relasyon sa Pagitan ng Popovers at Dialogs", Zell Liew "Ano ang popover=hint?", Una Kravets "Mga Utos ng Invoker", Daniel Schwarz "Paggawa ng Auto-Closing Notification na may HTML Popover", Preethi Buksan ang UI Popover API Explainer "Pop(over) the Balloons", John Rhea “CSS Anchor Positioning”, Juan Diego Rodríguez
Nag-aalok din ang MDN ng komprehensibong teknikal na dokumentasyon para sa Popover API.
