Czy powinienem używać <ul> i <li> w moich <nav>?


114

Tytuł właściwie to wyjaśnia.

Teraz, gdy mamy dedykowany <nav>tag,

Czy to jest:

<nav>
  <ul>
    <li><a href="#foo">foo</a></li>
    <li><a href="#bar">bar</a></li>
    <li><a href="#baz">baz</a></li>
  </ul>
</nav>

lepiej niż poniższe?

<nav>
  <a href="#foo">foo</a>
  <a href="#bar">bar</a>
  <a href="#baz">baz</a>
</nav>

To znaczy, zakładając, że nie potrzebuję dodatkowego poziomu DOM dla niektórych pozycji / dopełnień CSS, jaki jest preferowany sposób i dlaczego?


To dobre pytanie ... Czy w przypadku tagów, które nie mają sensu w HTML 4, mają zastosowanie którekolwiek z poprzednich sprawdzonych metod?
Guffa

Odpowiedzi:


63

element nav i lista zawierają różne informacje semantyczne:

  • Element nav informuje, że mamy do czynienia z głównym blokiem nawigacji

  • Lista informuje, że łącza wewnątrz tego bloku nawigacji tworzą listę elementów

Na http://w3c.github.io/html/sections.html#the-nav-element widać, że element nav może również zawierać prozę.

Więc tak, posiadanie listy wewnątrz elementu nav dodaje znaczenia.


Wielkie dzięki, tego potrzebowałem! Bardzo przydatny był również komentarz robertca dotyczący czytników ekranu ogłaszających poniżej „listę 3 elementów”.
kikito,

7
Wygląda na to, że tag UL w niczym nie pomaga: css-tricks.com/navigation-in-lists-to-be-or-not-to-be
psycho brm

2
Wydaje się, że łącze działa dla mnie. Upewnij się, że przeczytałeś dalszy ciąg, który deklaruje listy, a nie losowanie. css-tricks.com/wrapup-of-navigation-in-lists
RobW

Moim zdaniem <nav>bez <ul><li>wydaje się, że będzie miał bardziej dynamiczne menu dla dzieci. Co się stanie, jeśli masz wiele list menu, które są różnego typu i znajdują się w różnych miejscach <nav>? Pogrupowałbym te listy menu tak, jak <ul><li>w <nav>. Więc jeśli twoje menu jest regularne, pójdę z <ul><li>.
wonsuc

3

W tym momencie zachowałbym <ul><li>elementy, ponieważ nie wszystkie przeglądarki obsługują jeszcze tagi HTML5.

Na przykład napotkałem problem przy użyciu <header>tagu - Chrome i FF działały jak urok, ale Opera się zepsuła.

Dopóki wszystkie przeglądarki w pełni nie obsługują HTML, będę je umieszczać, ale polegam na starych, aby zapewnić kompatybilność wsteczną.


3
Użyj pliku javascript HTML 5 Shim ( remysharp.com/2009/01/07/html5-enugging-script ), aby złagodzić wszelkie możliwe błędy kompatybilności wstecznej z przeglądarkami takimi jak Opera i IE.
acconrad

Ale twoja strona nie jest przyjazna dla nieuciążliwych skryptów :)
Demian Brecht

1
Masz na myśli dopóki IE8 nie wyjdzie z rynku ... tak jak do 2016 ...:)
Šime Vidas

@ Šime - dokładnie :) A wyłączanie Javascript nie jest już opcją w przeglądarkach;)
Demian Brecht

@ Agent_9191 tak będzie - jestem dziś kompletnie zaskoczony, gdy chciałem po prostu sprawdzić, ile osób nadal korzysta z IE7 i zgadnij co - w większości krajów na przeglądarkach typu Opera czy iPad safari jest więcej ludzi niż w IE7. Tak się cieszę, że mogę teraz zrezygnować z obsługi IE7! IE8 zniknie prędzej czy później. To ostatnia uparta przeglądarka, z którą będziemy musieli się zmierzyć (IE9 nie jest tak zły do ​​kodowania).
Camilo Martin

2

To naprawdę zależy od ciebie. Jeśli zwykle używasz nieuporządkowanej listy do oznaczania menu nawigacyjnego, powiedziałbym, że kontynuuj to w elemencie <nav>. Celem elementu <nav> jest identyfikacja nawigacji strony na przykład do czytnika komputera, więc to, czy korzystasz z listy, czy po prostu linków, nie ma znaczenia.


+1, ponieważ wspomniałem, że dla czytników ekranu navs i as są teraz równie dobre jak listy.
Camilo Martin

2

Dla mnie nieuporządkowane listy to dodatkowe znaczniki, które tak naprawdę nie są wymagane. Kiedy patrzę na dokument HTML, chcę, aby był tak czysty i łatwy do odczytania, jak to tylko możliwe. Dla widza już jest jasne, że lista jest prezentowana, jeśli zastosowano odpowiednie wcięcie. Zatem dodanie UL do tych znaczników jest niepotrzebne i utrudnia odczytanie dokumentu.

Chociaż możesz zyskać pewną elastyczność, uważam, że lepszym pomysłem jest nie nadużywanie znaczników niesemantycznymi klasami ul i stylizowanie elementów a za jednym zamachem. I nie masz wymówki: użyj pseudo-selektorów: before i: after.

Edycja : Zostałem poinformowany, że niektóre czytniki ekranu ARIA traktują listy inaczej niż zwykłe znaczniki kotwicy. Jeśli Twoja witryna jest przeznaczona dla osób niepełnosprawnych, mógłbym rozważyć zastosowanie podejścia opartego na liście.


1

Nie, są równoważne. Pamiętaj, że HTML 5 jest wstecznie kompatybilny z listami HTML 4, więc możesz swobodnie używać ich w tym samym zakresie. Kompromisem jest mniej kodu dla drugiej wersji.

Jeśli obawiasz się wstecznej kompatybilności z przeglądarkami, pamiętaj o dołączeniu tej podkładki, aby zapewnić funkcjonalność tagów, takich jak <nav>i <article>.


8
Lista linków zapewnia dodatkową semantykę i dostępność (np. Czytniki ekranu ogłaszają „Listę trzech elementów” po wejściu do nawigacji).
robertc

@robertc Punkt dotyczący czytników ekranu jest bardzo dobry. Powinieneś był umieścić to na odpowiedzi! Oznaczałbym to jako poprawne. +1 w każdym przypadku.
kikito,

1

Jeśli mówimy „na podstawie książki”, to nie; nie musisz używać list do oznaczania nawigacji. Jedyną prawdziwą zaletą, jaką oferują, jest zapewnienie większego stopnia elastyczności podczas stylizacji.


1

Chciałbym zachować <ul><li>tagi, ponieważ nowe znaczniki ( <nav>, <section>, <article>i tak dalej) to tylko bardziej semantyczne wersje <div>s.

Z tego samego powodu nie miałbyś po prostu załadowania linków w tagu <div>, powinny one również mieć strukturę wewnątrz <nav>tagu.


Powodem, dla którego użyłem <ul> s zamiast wielu linków w <div> w przeszłości, było właśnie to, że <ul> były bardziej semantyczne. Ale teraz <nav> są bardziej semantyczne. Jestem zmieszany.
kikito,

2
<ul> są nadal bardziej semantyczne niż zwykłe linki <a>, ale <nav> jest bardziej semantyczne niż <div>. <ul> vs <a> jest oddzielne od <nav> vs <div>
whostolemyhat Kwietnia

Brak dbałości o semantykę nie jest właściwą drogą podczas pisania HTML.
Andrew Marshall

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.