Työkaluvinkit tuntuvat pienimmältä käyttöliittymäongelmalta. Ne ovat pieniä ja yleensä piilossa. Kun joku kysyy, miten sellainen rakennetaan, perinteinen vastaus tulee melkein aina takaisin käyttämällä jotakin JavaScript-kirjastoa. Ja se oli pitkään järkevä neuvo. Minäkin seurasin sitä. Pinnalta katsottuna työkaluvihje on yksinkertainen. Vie hiiri elementtiin tai keskitä siihen, näytä pieni laatikko, jossa on tekstiä, ja piilota se, kun käyttäjä siirtyy pois. Mutta kun lähetät sellaisen todellisille käyttäjille, reunat alkavat näkyä. Näppäimistön käyttäjät Napauta laukaisinta, mutta älä koskaan näe työkaluvihjettä. Näytönlukijat ilmoittavat sen kahdesti tai eivät ollenkaan. Työkaluvihje välkkyy, kun liikutat hiirtä liian nopeasti. Se peittää sisällön pienemmillä näytöillä. Esc-näppäin ei sulje sitä. Tarkennus katoaa. Ajan myötä työkaluvinkkikoodini kasvoi sellaiseksi, jota en todellakaan enää halunnut omistaa. Tapahtuman kuuntelijat kasaantuvat. Hover ja tarkennus piti käsitellä erikseen. Ulkopuoliset napsautukset vaativat erikoistapauksia. ARIA-attribuutit piti pitää synkronoituna käsin. Jokainen pieni korjaus lisäsi uuden kerroksen logiikkaa. Kirjastot auttoivat, mutta ne olivat myös enemmän mustia laatikoita, joiden ympärillä työskentelin sen sijaan, että olisin ymmärtänyt täysin, mitä kulissien takana tapahtui. Tämä sai minut katsomaan uudempaa Popover-sovellusliittymää. Halusin nähdä, mitä tapahtuisi, jos rakentaisin uudelleen yhden työkaluvihjeen käyttämällä selaimen alkuperäistä mallia ilman kirjaston apua. Aloittaessamme on syytä huomata, että kuten kaikissa uusissa ominaisuuksissa, siinä on joitain asioita, jotka ovat edelleen selvittämättä. Se kuitenkin nauttii tällä hetkellä erinomaisesta selaintuesta, vaikka yleisessä API:ssa on useita osia, jotka muuttuvat. Caniusea kannattaa pitää silmällä sillä välin. "Vanha" työkaluvinkki Ennen Popover-sovellusliittymää työkaluvihjekirjaston käyttö ei ollut pikakuvake. Se oli oletusarvo. Selaimilla ei ollut omaa käsitettä työkaluvihjeestä, joka toimisi hiiren, näppäimistön ja aputekniikan välillä. Jos välitit oikeellisuudesta, ainoa vaihtoehtosi oli käyttää kirjastoa, ja juuri niin tein. Korkealla tasolla malli oli aina sama: laukaisuelementti, piilotettu työkaluvihje-elementti ja JavaScript koordinoivat näitä kahta.
Kirjasto käsitteli johdotuksen, joka mahdollisti elementin näkymisen hiiri- tai tarkennettaessa, piilottamisen sumennuksen tai hiiren poiston aikana ja paikan muuttamisen tai koon muuttamisen vierittäessä.
Ajan myötä työkaluvihjeestä voi tulla hauras. Pienillä muutoksilla oli riski. Pienet korjaukset aiheuttivat taantumista. Mikä pahempaa, uusien työkaluvihjeiden lisääminen peri saman monimutkaisuuden. Asiat toimivat teknisesti, mutta eivät koskaan tuntuneet ratkaistuilta tai valmiilta. Tämä oli asioiden tila, kun päätin rakentaa työkaluvihjeen uudelleen käyttämällä selaimen alkuperäistä Popover-sovellusliittymää. Hetki, kun kokeilin Popover-sovellusliittymää En siirtynyt käyttämään Popover APIa, koska halusin kokeilla jotain uutta. Vaihdoin, koska olin kyllästynyt ylläpitämään työkaluvihjeiden toimintaa, jonka uskoin selaimen jo ymmärtäneen. Olin aluksi skeptinen. Useimmat uudet verkkosovellusliittymät lupaavat yksinkertaisuutta, mutta vaativat silti liimaa, reunakotelon käsittelyä tai varalogiikkaa, joka luo hiljaa uudelleen saman monimutkaisuuden, jota yritit paeta. Joten kokeilin Popover API:ta pienimmällä mahdollisella tavalla. Tältä se näytti:
1. Näppäimistö "vain toimii" Näppäimistön tuki riippui useiden kerrosten kohdistamisesta oikein: tarkennuksen piti laukaista työkaluvihje, sumennuksen piti piilottaa se, Esc oli kytkettävä manuaalisesti ja ajoituksella oli väliä. Jos unohdat yhden reunan tapauksen, työkaluvihje joko pysyy auki liian kauan tai katoaa ennen kuin sitä voitiin lukea. Kun popover-attribuutti on asetettu automaattiseen tai manuaaliseen, selain ottaa perusasiat: Tab ja Shift+Tab toimivat normaalisti, Esc sulkee työkaluvihjeen joka kerta, eikä ylimääräisiä kuuntelijoita tarvita.
Koodikannastani katosivat globaalit näppäinkäsittelijät, Esc-kohtainen puhdistuslogiikka ja tilantarkistukset näppäimistön navigoinnin aikana. Näppäimistökokemus lakkasi olemasta jotain, jota minun piti ylläpitää, ja siitä tuli selaimen takuu. 2. Näytönlukijan ennustettavuus Tämä olisuurin parannus. Jopa huolellisella ARIA-työllä käyttäytyminen vaihteli, kuten aiemmin hahmottelin. Jokainen pieni muutos tuntui vaaralliselta. Popoverin käyttäminen oikean roolin kanssa näyttää ja tuntuu paljon vakaammalta ja ennakoitavammalta mitä tulee tapahtumaan:
Ja tässä on toinen voitto: Vaihdon jälkeen Lighthouse lakkasi ilmoittamasta virheellisiä ARIA-tilavaroituksia vuorovaikutuksesta, suurelta osin siksi, että minulla ei ole enää mukautettuja ARIA-tiloja, jotka voisivat erehtyä vahingossa.
3. Focus Management Keskittyminen oli ennen hauras. Aiemmin minulla oli sääntöjä, kuten: anna tarkennuksen liipaisimen näyttää työkaluvihjeen, siirrä tarkennus työkaluvihjeeseen ja älä sulje, sumenna liipaisinta, kun se on liian lähellä, ja sulje työkaluvihje ja palauta tarkennus manuaalisesti. Tämä toimi, kunnes ei toiminut. Popover API:n avulla selain toteuttaa yksinkertaisempaa mallia, jossa fokus voi siirtyä luonnollisemmin popoveriin. Ponnahdusikkunan sulkeminen palauttaa tarkennuksen liipaisimeen, eikä näkyviä tarkennusloukkuja tai kadonneita tarkennushetkiä ole. En lisännyt tarkennuksen palautuskoodia; Poistin sen.
Johtopäätös Popover API tarkoittaa, että työkaluvihjeitä ei enää simuloida. Ne ovat jotain, jonka selain ymmärtää. Avaaminen, sulkeminen, näppäimistön toiminta, Escape-käsittely ja suuri osa saavutettavuudesta tulevat nyt itse alustasta, ei ad-hoc JavaScriptistä. Tämä ei tarkoita, että työkaluvihjekirjastot olisivat vanhentuneita, koska ne ovat edelleen järkeviä monimutkaisille suunnittelujärjestelmille, raskaalle mukauttamiselle tai vanhoille rajoituksille, mutta oletusarvo on muuttunut. Ensimmäistä kertaa yksinkertaisin työkaluvihje voi olla myös oikein. Jos olet utelias, kokeile tätä kokeilua: Korvaa vain yksi työkaluvihje tuotteessasi Popover API:lla, älä kirjoita kaikkea uudelleen, älä siirrä koko järjestelmää ja valitse vain yksi ja katso, mitä koodistasi katoaa. Kun alusta tarjoaa sinulle paremman primitiivisen, voitto ei ole vain vähemmän JavaScript-rivejä, vaan se on vähemmän asioita, joista sinun on huolehdittava. Katso koko lähdekoodi GitHub-varastostani. Lue lisää Syvemmälle ponnahdusikkunoihin ja niihin liittyviin sovellusliittymiin:
"Poppin' In", Geoff Graham "Ponnahdusikkunoiden ja dialogien välisen suhteen selvittäminen", Zell Liew "Mikä on popover = vihje?", Una Kravets "Invoker Commands", Daniel Schwarz "Automaattisen sulkeutuvan ilmoituksen luominen HTML-ponnahdusikkunalla", Preethi Avaa UI Popover API Explainer "Pop(over) the Balloons", John Rhea "CSS-ankkuripaikannus", Juan Diego Rodríguez
MDN tarjoaa myös kattavan teknisen dokumentaation Popover API:lle.
