<ul> versa <dl> - weder noch

[Gunther]

Hallo,

Mal davon abgesehen, dass es imho eine bis heute andauernde Unzulänglichkeit von HTML ist, dass es kein "vernünftiges/ brauchbares" Element dafür gibt (Stichwort <menu>),

Inwiefern wäre ein menu-Element besser?

Es wäre insofern besser, als dass es von der Semantik her eine "präzisere" Auszeichnung erlauben würde (zusammen mit <menuitem>, wobei dann immer noch entsprechende Attribute fehlen, die die "Beziehung" der Links untereinander repräsentieren würden).

Denn auch das in HTML5 neu eingeführte Nav Element sorgt nicht für die notwendige Klarheit/ Eindeutigkeit.

ist die Verwendung einer ungeordneten Liste für diesen Zweck also eher eine "historisch gewachsene Behelfslösung", als eine semantisch korrekte Auszeichnung.

Aha. Was ist daran nicht korekt?

Es verleiht den Elementen nicht die semantische Bedeutung, die sie eigentlich haben sollten/ müssten.

Das kannst du ja auch gerne machen. Deshalb muss es aber semantisch gesehen noch lange nicht "die (einzig) richtige" Variante sein.

Ja. Man darf gerne Gegenargumente formulieren.

Ich bemühe mich ja gerade ...! ;-)

Denn nach dieser Argumentation könntest/ müsstest die ja bspw. auch die Artikelübersicht auf der Blog Startseite (http://blog.selfhtml.org/) in eine Liste packen!

Ich habe damit gerechnet, dass dieser Einwand kommt. ;) Und habe deshalb geschrieben.

Um das zusammenzufassen: Ja, man könnte es in eine Liste packen – man muss und sollte es aber nicht, da ein Dokument auf der obersten Ebene aus Sections besteht, welche per definitionem gleichförmig sind und in einer Abfolge stehen. Die korrekte Auszeichnung auf dieser Ebene sind also Sectioning-Elemente. Im Falle von blog.selfhtml.org: aufeinander folgende article-Elemente.

Sehr schön ..., dann sind wir ja im Prinzip einer Meinung. Den Beitrag hatte ich noch nicht gelesen, bevor ich meinen verfasst hatte.

Da jeder dieser Links zu einem "eigenständigen" Teil von SELFHTML verlinkt, sie also keine hierarchische Reihe bilden,

Was ist eine »hierarchische Reihe«?

Zugegeben, schlecht formuliert. Gemeint war so etwas wie ein "Breadcrumb Trail", wo also quasi jeder nachfolgende Punkt/ Link den vorhergehenden beinhaltet und sozusagen jeweils eine Ebene tiefer reicht.

Eine ungeordnete Liste erfordert keine Hierarchie.

Eine alleine kann keine Hierarchie "abbilden", verschachtelte schon.

wäre die Anordnung der Links ohne Listenelement innerhalb des Nav Elements aus meiner Sicht genauso möglich.

So etwa?

<nav>

> <a>…</a>
> <a>…</a>
> <a>…</a>
> </nav>

Ja, warum denn deiner Meinung nach nicht? Die Semantik kommt, genau wie die "Gruppierung" von dem Nav Element, welches man ggf. noch mit einem role Attribut (role="navigation") ergänzen kann.

Das geht natürlich so lange, wie die Links alle auf "einer Ebene" liegen, also es keine Links gibt, die hierachisch unter einem anderen Link liegen.

Aus diesem Grund, und weil vor HTML5 A Elemente keine Blocklevel Elemente beinhalten durften, ist imho mangels passenderer Alternativen die Auszeichnung mittels UL entstanden. Davon mal abgesehen, wäre wohl in den allermeisten Fällen eine OL "richtiger", da es sehr wohl auf die Reihenfolge ankommt.

Wo sind dann deiner Meinung nach Listen überhaupt noch angebracht? ;)

Überall da, wo es sich um "Aufzählungen/ Auflistungen" handelt. Also z.B. bei einer Pro und Kontra Liste, Eigenschaften einer Sache/ eines Produkts etc.

Natürlich kann man auch, so wie du, argumentieren, dass ein Menü auch eine "Auflistung" von Links ist und sieht sich aufgrund der millionenfachen Umsetzung als solche auch leicht darin bestätigt. Aber nochmal, ich halte das für "falsch" und sehe eine derartige Umsetzung nur aufgrund mangelnder (passenderer/ richtigerer) Alternativen gegeben.

Die Argumente mit dem "CSS-Angriffspunkt" und dem "DOM Scripting" greifen ja nicht wirklich. Beides ist in jedem anderen Fall genauso möglich (und selbst wenn nicht, gäbe es dafür die "inhaltslosen" Elemente <div> und <span>).

Ja, ich kann auch andere, schlechter passende, nahezu aussagelose Elemente zur Auszeichnung verwenden. Aber wieso sollte ich das tun? ;)

Nicht nur "nahezu", sondern per Definition "inhaltslos"! Tun sollte man das immer dann, wenn aus Gründen der Präsentation (CSS) oder des Scriptings "angebracht" ist. Denn aus diesen Gründen eine Liste im HTML zu verwenden, verändert ja die Semantik. Und genau das ist in diesen Fällen ja nicht angebracht.

Auch der Punkt mit der "komfortablen Navigation" ist weder ein Grund, noch ein Argument für die Verwendung einer Liste! Denn über Links ließ sich schon immer sehr komfortabel bspw. per Tastatur navigieren.

Erst einmal ging es um komplexe Listeneinträge bestehend aus Bild, Bildunterschrift, Beschreibung und Link.

Ferner meinte ich mit Navigation nicht nur die Navigation zwischen den Einträgen. Es geht darum, den ganzen Block zu kennzeichnen, damit zwischen Blöcken navigiert werden kann. Wenn ein Screenreader-Nutzer »Liste mit 10 Einträgen« liest, so kann er in diese Liste hineinspringen (weiterlesen) oder sie überspringen.

Dann muss man sich aber zu allererst einmal die Frage stellen, ob die Semantik gegenüber einer "komfortablen Navigation" für Screenreader (oder andere Ausgabemedien) nachrangig ist, oder nicht?

Der einzige wirkliche Vorteil scheint mir hier zu sein, dass der Screenreader (wenn ich deine Aussage richtig interpretiere) hier gleich die Anzahl der Listeneinträge ansagt. Das ließe sich ja auch leicht anders bewerkstelligen. Und Skip Links kann man auch sehr leicht integrieren. Und per "tabindex" kann man ein "komfortables" Navigieren innerhalb des Blocks ermöglichen.

Das hat aber alles nichts mit der Semantik zu tun. Denn die ergibt sich rein aus dem Inhalt und nicht daraus, wie ggf. durch selbigen navigiert werden kann.

Klar, das erübrigt sich, wenn die Liste der gesamte <main>-Inhalt ist. Dann wären Sections angebracht.

Gut, dann sind wir uns ja einig (wie auch in deinem anderen Beitrag geschrieben).

Und auch der letzte Punkt, assoziative Techniken betreffend, ist kein Argument. Hier gibt es durchaus andere Möglichkeiten (Stichwort: "visually hidden").

Ich verstehe nicht, was du damit meinst. Wahrscheinlich meinst du assistive Techniken.

Haha ..., war wohl schon (zu) spät. Aber schön, dass du mich trotzdem verstanden hast. ;-)

Aber was soll ich nun für Screenreader verstecken? Die Information »Liste mit 10 Einträgen« bekomme ich nicht durch Verstecken.

Siehe oben!

Wenn ich Tom richtig verstanden habe in seinem Ausgangsposting, dann ist diese Galerie-Übersicht quasi der Hauptinhalt (der einzige Inhalt?) dieser Seite.

Dann wäre bspw. auch die Verwendung von <section> für jede Fotogalerie denkbar (ggf. jeweils mit <header> und <footer>.

Das kann ich nachvollziehen, ja. Unter diesen Umständen würde ich auch keine Liste, sondern Sections verwenden, und halte das für die bessere Lösung. (Wie gesagt, um den Teil abzudecken, hatte ich noch das geschrieben.)

Wie bereits gesagt, sind wir uns darin einig. Umgekehrt würde ich eine (ungeordnete) Liste verwenden, wenn bspw. auf einer Seite als "ein Punkt unter vielen" aufgeführt wird: Unser Fotoarchiv umfasst (u.a.) die folgenden Galerien:

• Galerie X
• Galerie Y
• Galerie Z

Und dennoch halte ich oftmals die Verwendung einer solchen Liste zumindest für "überflüssig" und semantisch eher für falsch, da dadurch eine "Verbindung" zwischen "Objekten/Elementen" hergestellt wird, die tatsächlich gar nicht gegeben ist.

Im konkreten Fall kommt es also maßgeblich darauf an, als für wie "einzelständig" man die Galerien ansieht?

Die Verbindung – oder Gemeinsamkeit, wie ich es lieber bezeichne – ist entweder lose oder sehr stark. Wenn man sich z.B. Flickr anschaut, so gibt es tausende Möglichkeiten, warum Bilder in einer Liste erscheinen. Was haben die schon miteinander zu tun? Sie könnten teilweise nicht verschiedener sein. Doch meistens ist es eine Auswahl unter einem bestimmten Aspekt, und dieser Aspekt steht meistens in der Überschrift direkt über der Liste. Mein Beispiel mit lässt sich einfach umkehren. Wenn die Überschrift wäre »Potpourri an Bildern, die ich sehenswert finde«, so gibt es durchaus einen inhaltlichen Grund, warum die Bilder in einer Liste stehen.

Das ist ja das "Problem" ...! :-P Es lassen sich immer sehr leicht Gründe/ Argumente dafür finden, warum man "Dinge" in eine Liste packt. Und sehr oft ist das ja auch durchaus "korrekt".

Nur leiden manche Autoren imho schon fast an einem "Listenwahn", und erkennen eben nicht mehr, wann eine Liste ggf. _nicht_angebracht ist.

Und in dem vorliegenden Fall (davon ausgehend, dass die Fotogalerie Übersicht der Hauptinhalt der Seite ist), ist sie eben imho nicht angebracht (und bei Navigationen eigentlich auch nicht - s.o.)!

Insofern finde ich die strukturellen Gründe gewichtiger: Es gibt eine Aneinanderreihung von gleichartigen Elementen (Fotos, Fotoalben…), und sie gehören zusammen in einen Block, um sie von den Elementen vorher und nachher abzugrenzen. Eine entsprechende Auszeichnung bringt die besagten Vorteile.

Ich bin mir nicht ganz sicher, ob diese Aussage richtig verstehe. Aber prinzipiell besteht ja ein Unterschied zwischen "Elemente gruppieren" (durch das Umschließen, um sie so als "Block" zu kennzeichnen) und "Listenelementen" (die dadurch bereits "gruppiert" sind, weil sie eben Teil einer Liste sind). Daraus aber abzuleiten, dass pauschal alle Elemente, die "zusammengefasst/ gruppiert" werden können, deshalb auch immer Listenelemente sind (und deshalb die Gruppierung in Form einer Liste erfolgt), halte ich für falsch.

Klassiker: "Alle Chinesen sind Menschen, aber nicht alle Menschen sind Chinesen (jedenfalls noch nicht)!"

Es kommt bei Fragen der Semantik ja immer auf die Intention an, und da gibt es meist sehr feine Unterschiede.

Ist die Übersicht über die existierenden Fotogalerien der Hauptinhalt der entsprechenden Seite, oder möchte ich nur einen "Überblick/ Ausblick" auf vorhandene Galerien geben, oder gebe ich die Galerien als "Treffer" einer Suchanfrage wieder, oder gruppiere ich sie anhand anderer Kriterien, oder oder oder ...?

Und zumindest viele dieser Fälle rechtfertigen jeweils eine andere Auszeichnung im HTML. Denn eine Liste eignet sich erstmal nicht dafür, Inhalte thematisch zu gruppieren, da bspw. eine ul/ ol nur li Elemente als Kindelemente haben darf und auch keinen "sectioning content" darstellt. Das heißt die "Gruppierung" müsste eh schon auf einer darüberliegenden Ebene stattfinden. Und dann stellt sich doch oftmals die Frage, ob eine weitere Zusammenfassung in Form einer Liste überhaupt noch erforderlich, bzw. semantisch korrekt ist?

In Gunnars Beispielcode sorgen ja z.B. die A Elemente für eine entsprechende Gruppierung zu einzelnen Blöcken. Und es würde imho semantisch nicht "besser", wenn man diese zusätzlich noch in li Elemente stecken würde. Wozu? Und angenommen diese Blöcke stecken in einem section Element mit entsprechender "section heading", was würde das rein semantisch gesehen bringen/ bedeuten?

Imho ist das genau wie bei dem Beispiel mit der Navigation nur "doppelt gemoppelt".

Gruß Gunther