Listy HTML są nudne. oni nie do wiele, więc tak naprawdę nie myślimy o nich, pomimo tego, jak szeroko są używane. I nadal możemy robić te same rzeczy, które zawsze robiliśmy, aby je dostosować, takie jak usuwanie znaczników, odwracanie kolejności i tworzenie niestandardowych liczników.
Istnieje jednak kilka „nowszych” rzeczy — w tym niebezpieczeństw — o których warto wiedzieć podczas korzystania z list. Zagrożenia są w większości niewielkie, ale o wiele bardziej powszechne, niż mogłoby się wydawać. Przejdziemy do nich, a także do kilku nowych rzeczy, które możemy zrobić z listami, a nawet nowych sposobów podejścia do starych rozwiązań.
Gwoli wyjaśnienia, mówimy o tych elementach HTML:
- Listy uporządkowane
- Listy nieuporządkowane
- Opis listy
- Listy interaktywne
Listy uporządkowane, listy nieuporządkowane i listy interaktywne zawierają elementy listy (
), które są wyświetlane w zależności od tego, z jaką listą mamy do czynienia. Uporządkowana lista (
) wyświetla liczby obok elementów listy. Listy nieuporządkowane (
) i elementów menu (
) wyświetla punktory obok elementów listy. Nazywamy je „znacznikami list” i można je nawet stylizować używając ::znacznik pseudoelement. Listy opisów używają terminów opisowych (
) i szczegóły opisu (
) zamiast
i nie mają znaczników listy. Mają służyć do wyświetlania metadanych i glosariuszy, ale nie mogę powiedzieć, żebym kiedykolwiek widział je na wolności.
Zacznijmy od łatwych rzeczy — jak poprawnie (przynajmniej moim zdaniem) zresetować style list. Następnie przyjrzymy się kilku problemom z ułatwieniami dostępu, zanim rzucimy światło na to, co nieuchwytne
element, który może cię zaskoczyć… to tak naprawdę także rodzaj listy!
Resetowanie stylów list
Przeglądarki automatycznie stosują własne style agenta użytkownika, aby pomóc w wizualnej strukturze list od razu po wyjęciu z pudełka. To może być świetne! Ale jeśli chcemy zacząć od czystej karty wolnej od opinii o stylizacji, musimy najpierw zresetować te style.
Na przykład możemy dość łatwo usunąć znaczniki obok elementów listy. Tu nic nowego:
/* Zap all list markers! */
ol, ul, menu {
list-style: none;
}Ale współczesny CSS ma nowe sposoby, aby pomóc nam kierować reklamy na określone wystąpienia list. Powiedzmy, że chcemy usunąć znaczniki ze wszystkich list, z wyjątkiem sytuacji, gdy te listy pojawiają się w długa forma, taka jak artykuł. Jeśli połączymy moce nowszych funkcji pseudoklasy CSS :where() i :not(), możemy wyizolować te instancje i zezwolić na znaczniki w tych przypadkach:
/* 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;
}Dlaczego warto korzystać :where() zamiast :is()? Specyfika :where() jest zawsze zerem, podczas gdy :is() bierze specyfikę najbardziej konkretnego elementu na swojej liście selektorów. Więc używając :where() jest mniej stanowczym sposobem zastępowania rzeczy i może być łatwo zastąpiony.
Style UA stosują również dopełnienie w celu oddzielenia zawartości elementu listy od jego znacznika. Ponownie, w niektórych przypadkach jest to całkiem niezła afordancja od razu po wyjęciu z pudełka, ale jeśli już usuwamy znaczniki listy, tak jak to zrobiliśmy powyżej, równie dobrze możemy również usunąć to wypełnienie. To kolejna sprawa dot :where():
:where(ol, ul, menu) {
padding-left: 0; /* or padding-inline-start */
}OK, to zapobiegnie pojawianiu się elementów listy bez znaczników unoszących się w przestrzeni. Ale w pewnym sensie wylaliśmy dziecko z kąpielą i usunęliśmy wyściółkę we wszystkich przypadkach, w tym w tych, które wcześniej izolowaliśmy w
. Teraz te listy ze znacznikami jakby zwisają z krawędzi pola zawartości.
Zwróć uwagę, że style UA mają zastosowanie dodatkowe 40px do
elementem.
Więc to, co chcemy zrobić, to zapobiec „wisieniu” znaczników listy poza kontenerem. Możemy to naprawić za pomocą list-style-position własność:
A może nie… może to kwestia preferencji stylistycznych?
Nowsze problemy z dostępnością list
Niestety, jeśli chodzi o listy, istnieje kilka problemów z dostępnością — nawet w tych bardziej współczesnych czasach. Jedna obawa jest wynikiem zastosowania list-style: none; tak jak zrobiliśmy to podczas resetowania stylów UA.
W skrócie Safari nie czytaj uporządkowane i nieuporządkowane listy stylizowane za pomocą list-style: none jako rzeczywiste listy, na przykład podczas przeglądania zawartości za pomocą czytnika ekranu. Innymi słowy, usunięcie znaczników usuwa również znaczenie semantyczne listy. The poprawka dla tej poprawki to zastosować ARIA list miejsce na liście i a listitem rolę do elementów listy więc czytniki ekranu je wybiorą:
- ...
- ...
- ...
- ...
- ...
- ...
Dziwnie, Safari uważa to za funkcję a nie błąd. Zasadniczo użytkownicy zgłaszaliby, że czytniki ekranu wyświetlają zbyt wiele list (ponieważ programiści mają tendencję do ich nadużywania), więc teraz tylko te z role="list" są ogłaszane przez czytniki ekranu, co wcale nie jest takie dziwne. Scott O'Hara ma szczegółowe podsumowanie o tym, jak to wszystko się potoczyło.
Drugi problem dotyczący dostępności nie jest naszym własnym dziełem (hura!). Więc wiesz jak powinieneś dodaj aria-label do
elementy bez nagłówków? Cóż, czasami warto zrobić to samo z listą, która nie zawiera elementu nagłówka, który pomaga opisać listę.
Grocery list
Absolutnie nie trzeba użyć dowolnej metody. Używanie nagłówka lub etykiety ARIA to tylko dodatkowy kontekst, a nie wymóg — pamiętaj, aby przetestować swoje witryny za pomocą czytników ekranu i zrobić to, co zapewnia najlepsze wrażenia użytkownika w danej sytuacji.
W nieco powiązanych wiadomościach Eric Bailey napisał doskonały artykuł na temat dlaczego i jak uważa aria-label być zapachem kodu.
Czekać,
to też lista?
OK, więc prawdopodobnie zastanawiasz się nad wszystkimi
elementy, które wsuwałem do przykładów kodu. W rzeczywistości jest to bardzo proste; menu to nieuporządkowane listy, z wyjątkiem tego, że są przeznaczone dla elementów interaktywnych. Są nawet widoczne w drzewie ułatwień dostępu jako listy nieuporządkowane.
We wczesnych latach sieci semantycznej błędnie wierzyłem, że menu są podobne
s, zanim uwierzyłem, że są one przeznaczone dla menu kontekstowych (lub „pasków narzędzi” jako specyfikacja mówi), ponieważ tak mówiły wczesne wersje specyfikacji HTML. (MDN ma ciekawy opis na wszystkie przestarzałe rzeczy związane z
jeśli w ogóle jesteś zainteresowany).
Dziś jednak jest to semantyczny sposób korzystania z menu:
Osobiście uważam, że istnieje kilka dobrych przypadków użycia
. Ten ostatni przykład pokazuje listę przycisków udostępniania społecznościowego opakowaną w etykietę
elementem, godnym uwagi aspektem jest to, że etykieta „Udostępnij artykuł” wnosi znaczną ilość kontekstu, który pomaga opisać działanie przycisków.
Czy menu jest absolutnie konieczne? Nie. Czy są Znaki HTML? Absolutnie nie. Ale są tam, jeśli lubisz mniej
s i czujesz, że komponent mógłby użyć pliku an aria-label dla dodatkowego kontekstu.
Coś jeszcze?
Tak, jest też wspomniany
(lista opisów) elementu, jednak Wydaje się, że MDN nie uważa ich za listy w ten sam sposób — jest to lista grup zawierających terminy — i nie mogę powiedzieć, że naprawdę widziałem ich użycie. Według MDN mają one służyć do metadanych, glosariuszy i innych typów par klucz-wartość. Po prostu unikałbym ich na tej podstawie, że wszystkie czytniki ekranu ogłaszają je inaczej.
Ale nie kończmy rzeczy negatywnym akcentem. Oto lista super fajnych rzeczy, które możesz zrobić z listami:
