html - Frage - ul - li was ist verpflichtend?

Hall,

ein <ul> ohne <li> ergibt keinen Sinn. Ein <br> ist ein Zeilenumbruch, kann dementsprechend überhaupt keine Listenpunkte voneinander trennen. Verwendest du nur <br>, dann ist semantisch gesehen alles ein einziger Punkt. Und dazu ist es von der "Grammatik" her falsch. Ein Text-Knoten darf nie direkt auf <ul> folgen, ohne <li> geht es nicht. Falls es um die Darstellung geht, dafür ist CSS. Bei HTML dreht sich alles um die Semantik. Das heißt: verwende HTML, ganz egal, wie es dargestellt wird, so, dass die Bedeutung stimmt. Das Aussehen passt du danach über CSS an. Heißt übrigens auch, dass du <ul> nur verwendest, wenn die Reihenfolge der Elemente egal ist, ansonsten <ol>.

Es gibt verschiedene Spezifikationen. Die Bekanntesten sind die vom W3C und von der WHATWG.

Ein Text-Knoten ist ein Element, welches Text beinhaltet. In folgendem Beispiel:

<ul>Listenpunkt</ul>

ist "Listenpunkt" ein reiner Text-Knoten und eben kein HTML-Element - alles muss irgendwie bezeichnet werden können. Ein <ul> darf komplett leer sein. Ansonsten ist aber nur <li> und sonst gar nichts erlaubt.

"ohne <li> geht es nicht" meint in meinem Fall, dass das kein valides HTML und dementsprechend nicht erlaubt ist. Dass die Browser das trotzdem darstellen, ist richtig. Aber das HTML ist falsch. Das Beispiel von a-coding-project.de ist daher Humbug. Ich würde auch nicht davon sprechen, dass der Browser etwas korrigiert. Er interpretiert.

Das Problem mit falschem HTML ist, dass die Browser praktisch machen können, was sie wollen. Dieser Fall mag harmlos sein, was die Darstellung betrifft, aber andere Fehler können zu vollkommen unterschiedlichen Darstellungen in verschiedenen Browsern führen. Schlimmer noch: es gibt ganz viele Menschen, die sind auf semantisch korrektes HTML angewiesen. Man denke nur an all die blinden Menschen, welche Screenreader nutzen. Die können nicht mit den Augen sehen. Die müssen sich darauf verlassen, dass die Auszeichnung des Dokuments (das HTML) nicht "lügt". Eine schlechte Auszeichnung, nur um ein bestimmtes optisches Ergebnis zu erzielen, ist da ein großes Problem.

Zitat von kernig

https://www.a-coding-project.de/ratgeber/html/listen
Listen ohne Listenpunkte ist das Beispiel mit <br> angeführt.

Schon lange nicht mehr so einen Quatsch gelesen. :roll:
Als "Profis" sollten die das eigentlich besser wissen.
Ansonsten hat Sören das ja schon sehr ausführlich erläutert. :klasse:

Zitat von Sören Hentzschel

Dass die Browser das trotzdem darstellen, ist richtig. Aber das HTML ist falsch. Das Beispiel von a-coding-project.de ist daher Humbug. Ich würde auch nicht davon sprechen, dass der Browser etwas korrigiert. Er interpretiert.

Bestes Beispiel hier der thread von heute : https://www.camp-firefox.de/forum/viewtopi…066834#p1066834
Ein unvollständiger und überflüssiger Tag und schon wird die gesamte Seite nicht mehr im FF angezeigt. Völlig korrekt.
Edge und Opera zeigen sich toleranter, ignorieren den Fehler allerdings und zeigen die Seite an. Was meiner Meinung nach aber nicht sein sollte.

Zitat von kernig

ist beim ul-Tag verpflichtend einen li zu verwenden?

In der Praxis: Ja.

Zitat von kernig

Habe eine Quelle gefunden, die das ohne macht und die Listenpunkte nur mit <br> trennt, das ergibt dann eine Liste ohne Punkte.
Ist das "erlaubt"?

Nein.

Zitat von kernig

Wer bestimmt, was erlaubt ist? w3c?

Ja, bzw. auch "living standards" der Browserhersteller.

Zitat von kernig

Wo finde ich das beim w3-Konsortium?

Hier in der Spezifikation: https://www.w3.org/TR/html51/grou…l#elementdef-ul
Bei "Content Model" stehen die erlaubten Inhalte.

Zitat von kernig

https://www.a-coding-project.de/ratgeber/html/listen
Listen ohne Listenpunkte ist das Beispiel mit <br> angeführt.

Schlichtweg falsch.

Zitat von kernig

Kann - muss aber nicht?

Genau, muss nicht. Kann auch leer da stehen als <ul></ul>. Sowas bleibt manchmal bei dynamisch generierten Seiten noch stehen, wenn keine Inhalte gefunden wurden.
Außerdem können da auch Dinge rein, die nicht gerendert werden, auch wenn das semantisch nicht viel Sinn ergibt (in den Specs sind <script> oder <template> als Beispiele angeführt).

Nur um das klarustellen, weil das auch in meinem Beitrag nicht klar hervorging: das W3C liefert nicht die Spezifikation, an der sich die Browserhersteller orientieren, sondern die WHATWG, die ich auch schon weiter oben kurz andeutete. Das ist eine andere Spezifikation. Auf T3N gibt es einen aktuellen Artikel, der die Situation vereinfacht darstellt. Ich zitiere daraus mal den wichtigen Teil:

Zitat

Diese paradoxe Situation hängt damit zusammen, dass das W3C nun mal nicht die Autorität in Sachen Web-Standards ist, die sie gerne wäre. Um das zu erklären, müssen wir ein paar Jahre zurückgehen. Genauer gesagt ins Jahr 2004: Damals entschloss sich das W3C dazu, HTML zugunsten einer XML-basierten Sprache aufzugeben. Daran störten sich vor allem die Browser-Entwickler Mozila und Opera, die daraufhin die Web Hypertext Application Technology Working Group (WHATWG) gründeten, um HTML weiterzuentwickeln.

2007 näherten sich die beiden Organisationen wieder an, und das W3C entwickelte HTML5 auf Basis der Arbeit der WHATWG. Damit hätte der Streit eigentlich beigelegt sein können, aber 2012 kam es erneut zu Auseinandersetzungen. Die WHATWG war und ist der Überzeugung, dass versionierte und in festgelegten zeitlichen Intervallen veröffentlichte HTML-Spezifikationen der Schnelllebigkeit des Web entgegenlaufen. Das W3C wiederum sah das anders, und deswegen existieren heute zwei HTML-Spezifikationen.

Die HTML-Spezifikationen der WHATWG, zu der mittlerweile alle großen Browser-Hersteller gehören, werden regelmäßig aktualisiert. Feste Versionsnummern gibt es genauso wenig wie Veröffentlichungsintervalle. Sobald eine Technologie von mindestens zwei der großen Browser unterstützt wird, findet sich üblicherweise ein Eintrag dazu in den Spezifikationen.

Die Spezifikationen der W3C, also auch die gerade vorgestellte HTML-5.2-Empfehlung, erscheinen hingegen einmal jährlich. Damit hinken sie dem Stand der aktuellen Entwicklung immer ein wenig hinterher.

https://t3n.de/news/w3c-html-…ationen-887407/