HTML Navigation: lieber als Liste oder als <div>?

Mondgesang

Lieutenant
Registriert
Dez. 2023
Beiträge
675
Vor einigen Jahren habe ich mal eine Methode zur Erstellung von Navigationen aufgeschnappt, die basierte auf Listen.

HTML:
<ul>

<li>Link 1</li>
<li>Link 2</li>
   <ul>
     <li>Unterlink 1</li>
     <li>Unterlink 2</li>
   </ul>
<li>Link 3</li>
</ul>

Und mit CSS hat man das ganze eben schön kachelig gemacht, mit entsprechenden Dropdowns usw.

Jetzt stolpere ich gerade über eine Methode in W3 Schools die arbeitet nur mit </div>s.

HTML:
<div class="navbar">
  <a href="#home">Home</a>
  <a href="#news">News</a>
  <div class="dropdown">
    <button class="dropbtn">Dropdown
      <i class="fa fa-caret-down"></i>
    </button>
    <div class="dropdown-content">
      <a href="#">Link 1</a>
      <a href="#">Link 2</a>
      <a href="#">Link 3</a>
    </div>
  </div>
</div>

Und das CSS dazu:

CSS:
.navbar {
  overflow: hidden;
  background-color: #444;
}

.navbar a {
  float: left;
  font-size: 16px;
  color: white;
  text-align: center;
  padding: 14px 16px;
  text-decoration: none;
}

.dropdown {
  float: left;
  overflow: hidden;
}

.dropdown .dropbtn {
  font-size: 16px; 
  border: none;
  outline: none;
  color: white;
  padding: 14px 16px;
  background-color: inherit;
  font-family: inherit;
  margin: 0;
}

.navbar a:hover, .dropdown:hover .dropbtn {
  background-color: red;
}

.dropdown-content {
  display: none;
  position: absolute;
  background-color: #f9f9f9;
  min-width: 160px;
  box-shadow: 0px 8px 16px 0px rgba(0,0,0,0.2);
  z-index: 1;
}

.dropdown-content a {
  float: none;
  color: black;
  padding: 12px 16px;
  text-decoration: none;
  display: block;
  text-align: left;
}

.dropdown-content a:hover {
  background-color: #ddd;
}

.dropdown:hover .dropdown-content {
  display: block;
}

Optisch läuft das ganze bei beiden Methoden auf dasselbe hinaus.

Dropdown Navbar.jpg


Nur ist dieser Code hier deutlich schlanker und braucht irgendwie deutlich weniger Zeilen, als eine Liste in eine Navbar umzuhübschen.

Frage: ist das ein klassischer Fall von viele Wege führen nach Rom und nimm einfach was dir besser liegt? Oder hat das auch Performance-Auswirkungen? Ich weiß ja nicht, ob es vielleicht Dinge gibt (Listen oder vielleicht zu viele <div>s) die einem Browser unnötig zu schaffen machen und die Performance der Seite beeinträchtigen könnten.

Eigentlich setze ich immer große Stücke auf W3 Schools, da ich vieles dort gelernt habe und vertraue, dass die nicht mit langsamem, ressourcenfressendem Code um die Ecke kommen würden.
 
Von der Performance macht das keinen Unterschied, nimm das, was dir besser gefällt. Glaub, Listen waren früher für Leute mit Screenreadern angenehmer. Kann auch nicht schaden Semantic html zu verwenden, also z. B. <nav></nav>
 
  • Gefällt mir
Reaktionen: netzgestaltung und DHundt
nav ist eigentilch das richtige und wenn du unbedingt div nehmen musst (für welche Zwecke auch immer) ggf. die ARIA attribute betrachten. https://www.w3.org/TR/html-aria/
Damit können die Screenreader oder ähnliches die Ausgabe "korrekt" interpretieren obwohl es eigentlich nicht das passende Element ist.
 
Okay, das Über-Paket kann ich gerne in Semantics machen. Hatte ich vorher auch. Bloß beinhaltete mein <nav> dann eben eine Liste.

Mir geht es ehr um dieses Dropdown-Menü. Bei meiner Listenfunktion war das eine ul innerhalb eines li. In CSS wirds dann irgendwann echt unübersichtlich wenn man li ul li a bearbeitet. Da musste ich mir immer mit Kommentaren aushelfen was davon jetzt was ist.

Und hier die Sub-Einträge als <div>-Dropdown zu realisieren sieht mir ziemlich schlank und übersichtlich aus.



=========

Frage an dieser Stelle: haben Semantics irgendwelche SEO-Vorteile bzw das Nicht benutzen irgendwelche Nachteile? Dass der Browser oder Suchmaschinen-Crawler dann denken, dass die Seite nicht mal eine Navigation hat oder so? Oder ist das einfach wie Schönschrift, dass der Code einfach schöner, leserlicher, benutzerfreundlicher aussieht? Z.B. wenn man dann damit auf der Suche nach Hilfe in Foren hausieren geht, dass einem die Nutzer effektiver helfen können, weil die sofort sehen was was ist?
 
Semantic HTML sollte sich theoretisch auch besser auf SEO auswirken, weil der Crawler dann weis, um welche Art von Element es sich handelt z. B. <article> bei Newsseiten. Es ist sicherlich auch für die Nutzung mit einem Screenreader hilfreich, wenn man z. B. direkt zu Navigation springen kann. Bei einem einfachen div weis man ja nicht, welche Art von Inhalt es beinhaltet.
 
Da ich meine Seiten immer in Grids baue, habe ich mir irgenwann mal angewöhnt, meine Grid-Elemente als Div Class="grid-..." zu benennen. Vielleicht auch nur zu Lernzwecken weil ich in meiner CSS-file diese grundlegende Struktur immer als erstes stehen hatte.

Code:
.grid-header {
...
}

.grid-nav {
...
}

.grid-article {
...
}

.grid-sidebox {
...
}

.grid-adbox {
...
}

.grid-footer {
...
}

Andererseits bin ich auch irgendwann dahin übergegangen, mehr Kommentarfunktionen zu nutzen und so habe ich mir meine Struktursektion entsprechend markiert z.B. /* ===== Grid Layout ===== */ und da kann man eigentlich auch die Semantics gut reinpacken und trotzdem vernünftig unterscheiden können, was davon was ist.
Ergänzung ()

Bamu schrieb:
Semantic HTML sollte sich theoretisch auch besser auf SEO auswirken, weil der Crawler dann weis, um welche Art von Element es sich handelt z. B. <article> bei Newsseiten
Das ist tatsächlich ein valides Argument für mich, Semantics zu benutzen.
Ergänzung ()

EDIT: habe mal eben in der W3 School Testumgebung deren <div class="navbar"> zu <nav> umgeschrieben und in CSS entsprechend .navbar zu nav gemacht und das Ergebnis sieht gleich aus.

Ergo:

Ich werde weiterhin so weit es geht auf die zugelassenen bzw standardisierten Semantics zurückgreifen, aber meine Navigationsinhalte von Listen zu Divs umstellen.
 
Wenn dir die Kommentare helfen, spricht ja nichts dagegen. Bei uns im Team arbeiten wir inzwischen nur noch mit Tailwind und schreiben kaum normales CSS mehr, aber da du ja Anfänger bist, ist es natürlich der richtige Weg erstmal HTML und CSS zu lernen. Schau dir in Hinblick auf die Nutzung von CSS auch mal BEM (Block, Element, Modifier) an.
 
Zuletzt bearbeitet:
Ich schreibe tatsächlich sehr gerne von Hand und auf diesem "Zu-Fuß" Weg. Zum Einen lernt man das Handwerk auf diese Weise und zum Anderen habe ich dieses peace of mind, dass jede Zeile von mir handgeschrieben ist und ich die volle Kontrolle habe :D
 
  • Gefällt mir
Reaktionen: Questionmark
ich würde klassen weniger nach dem layout sondern eher nach dem inhalt benennen - also auch semantische klassen. Im grunde nehmen die semantischen elemente diese entwicklung teilweise ab. Deswegen möchte ich auch so asematische Libs wie Bootstrap vermeiden. 90er Tabellenlayout ole´ (ja, das lässt sich auch anders nutzen, aber so gehts doch am schnellsten, nicht?)

Menüs müssen keine Liste sein, ich würde es aber dann machen, wenn es "wie eine Liste" angeordnet wäre (vgl zu einer Tabelle...). ein <nav> Element sollte die Navigation aber immer umschließen. Alternativ wäre auch eine <ul aria-role="navigation"> möglich (das geht mit jedem Element) aber wozu? Welche Vorteile hat ein Div eigentlich?

Ich finde das ul li a{} css konzept nicht unübersichtlich, aber mit einer sematischen inneren <ul class="submenu"> klasse lässt sich vieles vereinfachen.

Daher mein üblicher (Basis-Stripped-Down)Aufbau:

HTML:
<nav class="{menuname}-menu">
  <ul class="menu">
    <li><a href="...">Text</a></li>
    <li><a href="...">Text</a>
      <ul class="submenu">
        <li><a href="...">Text</a></li>
      </ul>
    </li>
  </ul>
</nav>

Dazu kommen oft noch Breadcrumb-Klassen also active, parent, inpath etc..., diese kommen meistens auf die <li> Elemente

MMN sollte das HTML komplett ohne CSS-Layout gedacht werden.
Es sollte ein gut lesbares Dokument entstehen und erst dann sollten in einer idealen Welt Layouts darauf apliziert werden.
 
  • Gefällt mir
Reaktionen: Lawnmower
Mondgesang schrieb:
Frage an dieser Stelle: haben Semantics irgendwelche SEO-Vorteile bzw das Nicht benutzen irgendwelche Nachteile?
Du musst dir das mal von der Crawler Seite vorstellen, die haben pro Seite ein gewisses Zeit-/Prozessorbudget und wenn sie dann erst auf den Aufbau der Seite durch Javascript/CSS und Konsorten warten müssen um den Inhalt zu "analysieren", werden sie weniger Zeit auf der Seite verbringen können, das ist auch u.A. einer der Gründe wieso man von dem ganzen Dynamic Schund weggeht und Themen wie Server Side Rendering wieder stark in Mode sind, einfach damit die erste Seite so "schnell wie möglich" im Browser darstellbar ist und ggf. anfallende Korrekturen des DOM etc. erst danach anfallen.

Das heißt im Allgemeinen (gilt nicht nur für SEO) dass man sich soweit wie möglich an die vorhandenen Standards halten sollte (Semantic HTML, ARIA etc.)
Je nach Crawler werden dann "lesbare" Seiten "besser" bewertet.
 
  • Gefällt mir
Reaktionen: Mondgesang
Bamu schrieb:
Schau dir in Hinblick auf die Nutzung von CSS auch mal BEM (Block, Element, Modifier) an.
Das würde ich unbedingt vermeiden xD. MMN sind mit Bindestrichen kombinierte Klassen hinderlich in der CSS-Entfaltung. Die wurde früher eigentlich deswegen eingeführt, weil der IE6 keine 2. Klasse nach einem Abstand identifizieren und nutzen konnte. Außerdem ist Block und Element semantisch unnötig und das Element mit dem Element identifizierbar.
 
Ich hab jetzt BEM schon länger nicht mehr genutzt, weil wir inzwischen mit vue 3 und nuxt arbeiten und ich dort modulares css schreiben kann, das nur innerhalb des scopes gültig ist. Ich meine mich zu erinnern, dass wir BEM davor hauptsächlich genutzt haben, um die Probleme von globalen CSS und dem zugrundeliegenden Cascading zu umgehen, vor allem bei komplexen Seiten mit mehreren Entwicklern. Aber da wir ja wissen, dass das Benennen von Dingen schwierig sein kann, war dann Tailwind die optimale Lösung für uns.
 
Zuletzt bearbeitet:
Ich hab das damals auf der jquery Dokumtationsseite kennengelernt, dass es auch ganz einfach funktionieren kann.

Globales CSS und die Cascade ist ja genau das, was man nutzen will - dazu wärs da, ich hab bei der Architektur auch ein paar Runden gedreht aber am Schluß hat sich bewährt, spezifisches CSS nach Inhaltsreihenfolge zu schreiben.

Da muß zwar oft eingefügt statt angefügt werden, aber mit Git und dgl ist das eigentlich kein Thema mehr. Zusätzlich hilft mobile-first, dh zunächst allgemeine definitionen, die mobil gleich funktionieren zu definieren und am Ende die größeren Viewports hinzuzufügen.

Wenn man das im Team besser abspricht oder auch CSS Experimente, zb im Intranet wagt lässt sich einiges dazu lernen, damit das kaskadieren nicht mehr so verwirrend ist.
 
Jetzt verstehe ich, warum so viele Navigationen DOCH als Liste gebaut sind. Das Nicht-Listen-Beispiel von W3 Schools funktioniert so lange gut, bis man anfängt Dinge verschieben zu wollen. Dann sah das bei mir schnell wüst aus.

Dann stieß ich gestern Abend auf einen ziemlich hübschen Denkanstoß und habe der Liste nochmal eine Chance gegeben.

HTML:
<nav role="navigation" class="primary-navigation">
  <ul>
    <li><a href="#">Home</a></li>
    <li><a href="#">Work &dtrif;</a>
      <ul class="dropdown">
        <li><a href="#">Web Development</a></li>
        <li><a href="#">Web Design</a></li>
        <li><a href="#">Illustration</a></li>
        <li><a href="#">Iconography</a></li>
      </ul>
    </li>
    <li><a href="#">About</a></li>
    <li><a href="#">Contact</a></li>
  </ul>
</nav>

CSS:
nav {
    margin: 0 auto;
    display: block;
 
    padding: 120px 0 0 0; 
    text-align: center;
    font-size: 16px;
}

    ul li {
      list-style: none;
      margin: 0 auto;
      border-left: 2px solid #3ca0e7;
      display: inline-block;
      padding: 0 30px;
      position: relative;
      text-decoration: none;
      text-align: center;
      font-family: arvo;
    }

    li a {
      color: black;
    }

    li a:hover {
      color: #3ca0e7;
    }

    li:hover {
      cursor: pointer;
    }

    ul li ul {
      visibility: hidden;
      opacity: 0;
      position: absolute;
padding-left: 0;
      left: 0;
      display: none;
      background: white;
    }

    ul li:hover > ul,
    ul li ul:hover {
      visibility: visible;
      opacity: 1;
      display: block;
      min-width: 250px;
      text-align: left;
      padding-top: 20px;
      box-shadow: 0px 3px 5px -1px #ccc;
    }

    ul li ul li {
      clear: both;
      width: 100%;
      text-align: left;
      margin-bottom: 20px;
      border-style: none;
    }

    ul li ul li a:hover {
      padding-left: 10px;
      border-left: 2px solid #3ca0e7;
      transition: all 0.3s ease;
    }
  }
}

a {

    text-decoration: none;

    &:hover {
        color: #3CA0E7;
    }
 
}

 ul li ul li a { transition: all 0.5s ease; }

Und so ist doch eine ziemlich ansehliche bedienerfreundliche navbar entstanden. Hmmmm. Dann habe ich wohl einfach bei meiner früheren Listen-Navi wilde Sau gespielt und kreuz und quer gecodet :D
 
  • Gefällt mir
Reaktionen: netzgestaltung
Schaut gut aus! Achtung: bei einer <nav> brauchst du die aria-role nicht mehr anzugeben, da das Element diese bereits innehat, außer du mußt noch IE6-8 supporten, die kannten die neuen Elemente ja nicht.
 
  • Gefällt mir
Reaktionen: Mondgesang
Vielleicht wäre es auch eine definition-list(leider ist nur flow content in <dd> erlaubt), wenn es level1 submenus ohne rekursion gäbe - manche Menüs wirken auch tabellarisch manchmal. Ich liebe dieses Thema!
 
Möchte an dieser Stelle nur den Tipp geben wirklich das HTML auszureizen, und Elemente so zu nutzen wie sie gedacht sind. Für die Navigation etwa Nav Elemente zu nutzen ist wirklich wertvoll.
Suchmaschinen wie Google würdigen das wirklich, ins besonders wenn man Ads schaltet kann man so echt den Unterschied machen.

Klar, mit CSS kann man wohl auf vielen Wegen den vermeintlich gleichen Output schaffen, aber das HTML ist wirklich die Basis.
Sections nutzen, die richtigen Elemente nutzen, Captions etc nutzen und und und.
 
  • Gefällt mir
Reaktionen: Guru-Meditation
Zurück
Oben