Listele HTML sunt plictisitoare. Ei nu do mult, așa că nu ne gândim cu adevărat la ele, în ciuda cât de larg utilizate sunt. Și suntem în continuare capabili să facem aceleași lucruri pe care le-am făcut întotdeauna pentru a le personaliza, cum ar fi eliminarea marcatorilor, inversarea ordinii și realizarea de contoare personalizate.
Există, totuși, câteva lucruri „mai noi” – inclusiv pericole – de știut atunci când folosiți liste. Pericolele sunt în mare parte minore, dar mult mai frecvente decât ați putea crede. Vom ajunge la acestea, plus câteva lucruri noi pe care le putem face cu liste și chiar noi moduri de a aborda soluțiile vechi.
Pentru a clarifica, acestea sunt elementele HTML despre care vorbim:
- Liste ordonate
- Liste neordonate
- Liste de descriere
- Liste interactive
Listele ordonate, listele neordonate și listele interactive conțin elemente de listă (
) care sunt afișate în funcție de tipul de listă cu care avem de-a face. O listă ordonată (
) afișează numere lângă elementele din listă. Liste neordonate (
) și elemente de meniu (
) afișează marcatori lângă elementele din listă. Acestea le numim „marcatori de listă” și pot fi chiar stilizate folosind ::marker pseudo-element. Listele de descriere folosesc termeni de descriere (
) și detalii de descriere (
) in loc de
și nu au marcatori de listă. Ele ar trebui să fie folosite pentru a afișa metadate și glosare, dar nu pot spune că le-am văzut vreodată în sălbăticie.
Să începem cu lucrurile simple - cum să resetați corect (cel puțin după părerea mea) stilurile listelor. După aceea, vom arunca o privire la câteva probleme de accesibilitate înainte de a arunca o lumină asupra evazivei
element, pe care s-ar putea să fii surprins să înveți... este de fapt un tip de listă, de asemenea!
Resetarea stilurilor listelor
Browserele își aplică în mod automat propriile stiluri de agent de utilizator pentru a ajuta la structura vizuală a listelor imediat din cutie. Asta poate fi grozav! Dar dacă vrem să începem cu o tablă goală fără opinii de stil, atunci trebuie să resetam mai întâi acele stiluri.
De exemplu, putem elimina marcatorii de lângă elementele listei destul de ușor. Nimic nou aici:
/* Zap all list markers! */
ol, ul, menu {
list-style: none;
}Dar CSS modern are noi modalități de a ne ajuta să țintăm anumite instanțe de listă. Să presupunem că vrem să ștergem marcatorii din toate listele, cu excepția cazului în care acele liste apar în conținut de formă lungă, cum ar fi un articol. Dacă combinăm puterile funcțiilor de pseudo-clasă CSS mai noi :where() și :not(), putem izola acele instanțe și permite marcatorii în acele cazuri:
/* Where there are lists that are not articles where there are lists... */
:where(ol, ul, menu):not(article :where(ol, ul, menu)) {
list-style: none;
}De ce sa folosim :where() în loc de :is()? Specificul lui :where() este întotdeauna zero, în timp ce :is() ia specificul celui mai specific element din lista sa de selectori. Deci, folosind :where() este un mod mai puțin puternic de a depăși lucrurile și poate fi ușor depășit în sine.
Stilurile UA aplică, de asemenea, umplutură pentru a distanța conținutul unui element din listă de la marcatorul acestuia. Din nou, în unele cazuri este un avantaj destul de bun, dar dacă eliminăm deja marcatorii de listă, așa cum am făcut mai sus, atunci putem la fel de bine să ștergem și acea umplutură. Acesta este un alt caz pentru :where():
:where(ol, ul, menu) {
padding-left: 0; /* or padding-inline-start */
}OK, asta va împiedica elementele din listă fără markeri să pară să plutească în spațiu. Dar am aruncat copilul cu apa de baie și am îndepărtat căptușeala în toate cazurile, inclusiv în cele pe care le-am izolat anterior într-un
. Deci, acum acele liste cu marcatori atârnă de pe marginea casetei de conținut.
Observați că stilurile UA aplică un plus 40px la
element.
Deci ceea ce vrem să facem este să împiedicăm marcatorii de listă să „atârne” în afara containerului. Putem rezolva asta cu list-style-position proprietate:
Sau nu... poate că se reduce la preferințele stilistice?
Probleme mai noi de accesibilitate cu liste
Din păcate, există câteva probleme de accesibilitate când vine vorba de liste - chiar și în aceste vremuri mai moderne. O preocupare este rezultatul aplicării list-style: none; așa cum am făcut când am resetat stilurile UA.
Pe scurt, Safari nu citește liste ordonate și neordonate stilate cu list-style: none ca liste reale, cum ar fi atunci când navigați prin conținut cu un cititor de ecran. Cu alte cuvinte, eliminarea markerilor elimină și semnificația semantică a listei. The remediere pentru această remediere it a aplica o ARIA list rol pe listă și a listitem rol la elementele din listă astfel încât cititorii de ecran le vor ridica:
- ...
- ...
- ...
- ...
- ...
- ...
In mod ciudat, Safari consideră că aceasta este o caracteristică mai degrabă decât un bug. Practic, utilizatorii ar raporta că cititorii de ecran anunță prea multe liste (deoarece dezvoltatorii tind să le folosească excesiv), așa că acum, doar cei cu role="list" sunt anunțate de cititoarele de ecran, ceea ce nu este chiar atât de ciudat până la urmă. Scott O'Hara are o rezumat detaliat despre cum a mers totul.
O a doua problemă de accesibilitate nu este una creată de noi (ura!). Deci, știi cum ar trebui să faci adăuga o aria-label la
elemente fără titluri? Ei bine, uneori are sens să faci același lucru cu o listă care nu conține un element de titlu care ajută la descrierea listei.
Grocery list
Tu absolut nu trebuie să folosească oricare dintre metode. Folosirea unui titlu sau a unei etichete ARIA este doar un context adăugat, nu o cerință - asigurați-vă că vă testați site-urile web cu cititoare de ecran și faceți ceea ce oferă cea mai bună experiență de utilizator pentru situație.
Într-o știri oarecum asemănătoare, Eric Bailey a scris un articol excelent despre de ce și cum consideră aria-label a fi un miros de cod.
Aștepta,
este și o listă?
OK, deci, probabil că vă întrebați despre toate
elemente pe care le-am introdus în exemplele de cod. Este de fapt super simplu; meniurile sunt liste neordonate, cu excepția faptului că sunt destinate elementelor interactive. Sunt chiar expuși arborelui de accesibilitate ca liste neordonate.
În primele zile ale rețelei semantice, am crezut în mod eronat că meniurile erau ca
s înainte de a crede că erau pentru meniuri contextuale (sau „barele de instrumente” ca spune specificația) pentru că asta spuneau versiunile timpurii ale specificației HTML. (MDN are un articol interesant pe toate lucrurile depreciate legate de
dacă ești deloc interesat.)
Astăzi, însă, acesta este modul semantic de a folosi meniurile:
Personal, cred că există câteva cazuri de utilizare bune pentru
. Ultimul exemplu arată o listă de butoane de partajare socială împachetate într-o etichetă
element, aspectul notabil fiind că eticheta „Distribuie articol” contribuie cu o cantitate semnificativă de context care ajută la descrierea a ceea ce fac butoanele.
Meniurile sunt absolut necesare? Nu. Sunt ei Repere HTML? Cu siguranta nu. Dar sunt acolo dacă vă bucurați de mai puține
s și simțiți că componenta ar putea folosi an aria-label pentru context suplimentar.
Altceva?
Da, există și cele menționate mai sus
element (listă de descriere), totuși, MDN nu pare să le ia în considerare liste în același mod — este o listă de grupuri care conțin termeni — și nu pot spune că le-am văzut cu adevărat în uz. Potrivit MDN, acestea ar trebui să fie utilizate pentru metadate, glosare și alte tipuri de perechi cheie-valoare. Le-aș evita doar pe motiv că toți cititorii de ecran le anunță diferit.
Dar să nu încheiem lucrurile pe o notă negativă. Iată o listă de lucruri super cool pe care le poți face cu liste:
