Täydellinen nappi? Se saattaa olla suurin ongelmasi
#-div-elementistä ei koskaan tule oikeaa nappia
Jokainen kehittäjä tuntee tilanteen. rakennat komponenttikirjastoa, ja suunnitelma vaatii napin. Ei mitä tahansa nappia – erikoisnapin. Se tarvitsee räätälöityjä tyylejä, uniikin hover-efektin, mahdollisesti liukuvärin, joka muuttuu painalluksessa. Keinot on nopeasti keksitty: otat <div>-elementin, lisäät vähän CSS:ää, ja homma on selvä.
Figmassa se näyttää täydelliseltä. Demo toimii moitteettomasti. Sitten oikea käyttäjä yrittää tabata käyttöliittymän läpi, lähettää lomakkeen näppäimistöllä tai navigoida sivustoa ruudunlukijan avulla – ja kaikki menee pieleen.
Ongelma ei ole CSS:ssä. Ongelma on, että pyysit <div>-elementtiä tekemään työtä, jota varten sitä ei ole suunniteltu.
Nappi, joka ei ollut nappi
Tässä on tyypillinen tilanne: tarvitset napin, joka näyttää tietynlaiselta. Luot <div>-elementin, lisäät class="btn", ja tyylittelet sitä kunnes se vastaa suunnitelmaa. Lopputulos näyttää hyvältä. Mutta sitten tarvitset, että se tekee nappimaisia asioita.
Lisäät siis click-käsittelijän. Sitten hover-tilan. Sitten focus-renkaan näppäimistökäyttäjille. Sitten tajuat, ettei Space eikä Enter toimi, joten lisäät keydown-kuuntelijat. Nappia pitää sometimes saada disabloitua, joten lisäät .disabled-luokan, jonka toivottavasti estää kaikki oikeat interaktiot. Jossain vaiheessa lisäät role="button" ja tabindex="0", jotta saavutettavuustyökalut eivät täysin игнорируа ваш шедевр.
Onneksi olkoon. Olet rakentanut napin muotoisen objektin, joka vaatii noin 200 riviä JavaScriptiä tehdäkseen sen, minkä selain olisi antanut sinulle ilmaiseksi.
Tämä on sitä, mitä tarkoitamme puhuessamme "huonon arkkitehtuurin vuokranosta". Jokainen työaroundin koodirivi on korkoa alkuperäisestä valinnasta käyttää väärää elementtiä.
Näkymätön sopimus
Native-HTML-elementit tulevat mukanaan kokonainen interaktiosopimus, jota useimmat kehittäjät eivät ajattele ennen kuin se puuttuu.
Kun käytät oikeaa <button>-elementtiä, saat:
- Automaattisen näppäimistökäsittelyn – Enter ja Space toimivat täsmälleen niin kuin käyttäjät odottavat
- Oikean fokuksen hallinnan – Se menee tabijärjestykseen luonnollisesti, voi vastaanottaa ohjelmallisen fokuksen
- Disabloidun tilan toiminnan – Estää kaiken interaktion, ei voi vastaanottaa focusia, ilmoitetaan disabloiduksi
- Lomakeosallistumisen – Lähettää lomakkeita, kunnioittaa validointia, osallistuu form.reset()-kutsuun
- Saavutettavuussemantiikan – Ruudunlukijat ilmoittavat sen napiksi ilman ylimääräistä ARIAa
- Alustakonventiot – Käyttäjät already tietävät, miten napit toimivat, koska napit behave samalla tavalla kaikkialla
<div>-napilla saat... CSS:n. Kaikki muu on sinun vastuullasi toteuttaa. Ja tässä on likaisen salaisuus: riippumatta siitä, kuinka perusteellisesti toteutat, oma toteutuksesi on huonompi kuin mitä selaimet tarjoavat. Selaimilla on insinööritiimejä optimoimassa näitä käyttäytymisä kaikilla alustoilla, reunatapauksissa ja avustavissa teknologioissa. Sinulla on vain sinä.
Oikea kysymys ei ole "voinko tyylitellä sen?"
Tämä on kohta, jossa design- ja kehitystiimien yhteistyö joko loistaa tai luo teknistä velkaa. Kehittäjät usein tulkitsevat "semanttisen HTML:n" tarkoittavan "hyväksymällä selaimen rumat oletukset". Se ei ole mistään tässä on kyse.
Kysymys ei ole "voinko tehdä tästä räätälöidyn näköisen?" – kyllä se voi olla. Kysymys on: "mitkä natiivit käyttäytymiset tulisi säilyttää tyylittelyn läpi?"
<button> voi saada minkä tahansa visuaalisen käsittelyn. Voit poistaa kaikki oletustyylit appearance: none-komennolla. Voit lisätä liukuvärejä, varjoja, animaatioita, omia fontteja – mitä suunnitelma vain vaatiin. Selaimen interaktiosopimus ei välitä siitä, miltä nappi näyttää.
Mitä et voi helposti tehdä <div>-elementillä, on toistaa se, minkä selain antaa sinulle automaattisesti. Valitse siis taistelusi viisaasti: käytä insinööriponnistelusi siihen, mikä tekee tuotteestasi uniikin, äläkä nappien uudelleenkeksimiseen.
Rakentaminen oikeaa webiä varten
Käyttäjäsi eivät käytä tuotetta tyhjiössä. He tabbaavat kenttien välillä kädet näppäimistöllä. He käyttävät ääniohjausta navigointiin. He suurentavat näyttöä 300 prosenttiin, koska se toimii heille. Heillä on eri selaimet, eri käyttöjärjestelmät, erilaiset avustavat teknologiat.
Web-alusta antaa sinulle valtavan etumatkan semantisella HTML:llä. Natiivit elementit ovat saavutettavia oletuksena, näppäimistönavigoitavissa oletuksena, alustojen välisesti yhteensopivia oletuksena. Kun taistelet tätä infrastruktuuria vastaan, et vain tee itsellesi enemmän töitä – luot komponentteja, jotka epäonnistuvat hienovaraisilla tavoilla oikeille käyttäjille.
Seuraavan kerran kun olet lisäämässä <div>-elementtiä, jolle lisäät role="button", kysy itseltäsi: rakennanko jotain, joka genuiinesti tarvitsee räätälöidyn toteutuksen, vai pelkäänkö vain <button>-tagia? Koska tylsä ratkaisu on usually oikea. Ja "selain käsittelee sen oikein" on ominaisuus, ei rajoite.
Semanttinen web ei ole sääntöjen seuraamista. Se on oikeiden työkalujen käyttämistä oikeaan työhön – ja energiasi käyttämistä siihen, missä siitä on oikeasti hyötyä.