at: Geeigneter Listentyp für Pargraphen?

Beitrag lesen

Hallo.

Welchen Sinn hat es hier, bei jedem Eintrag <dt>Adresse</dt> zu schreiben?

Den, ein übergeordnete Zusammenfassung der folgenden Datensätz zu bilden. Wenn ich nicht gerade "Rechnungsadresse", "Lieferadresse", "Besucheradresse" etc. unterscheide, blende ich diese Angabe aber meist aus.

Darüber hinaus habe ich absichtlich herausgestellt, dass der eindeutige Datensatztitel (»Primärschlüssel«) hier meinem Verständnis nach der Name ist, es ist also kein Merkmal wie alle anderen Merkmale.

Was "kein Merkmal wie alle anderen Merkmale" sein soll, hebe ich durch logische Formatierung hervor.

Die Eigenschaft eines Datensatzes ruft immer eine Spalte hervor, die Gleichförmigkeit aller anderen Datensätze verlangt.

Gut, diesen Nachteil einer Tabelle hatte ich bisher nicht beachtet. Ein Vorteil erwächst ja nur dann daraus, wenn die Datensätze einem Vergleich unterzogen werden sollen -- und genau dann sind Tabellen ja sinnvoll.

Ich sehe den Vorteil nicht nur bei Vergleichen.

Ich sehe vor allem den Nachteil, für jeden abweichenden oder zusätzlichen Eintrag eine weitere Spalte oder flexiblere Überschrift finden zu müssen, etwa bei zusätzlichen Postfachadressen etc.

Worin besteht diese Vergleichbarkeit? Die Aufzählung ist weitesgehend ungeordnet und Querbezüge sind, soweit ich es sehe, nicht vorhanden.

Wäre sie geordnet -- im Sinne einer Rang- oder festen Reihenfolge --, würde ich <ol> einsetzen, Querbezüge zeichne ich mittels <a> aus. Eine Vergleichbarkeit besteht meines Erachtens dann, wenn Datensätze so weit aufgelöst werden, dass sie sich entweder nur noch in so geringem Maß voneinander unterscheiden, wenn man sie direkt nebeneinander hält, oder aber wenn die herausgearbeitete Differenz so groß ist, dass genau diese Eigenschaft visualisiert werden soll.

Insofern halte ich die jetzige Aufteilung noch für angemessener, weil der Sprung in einer Spalte von Zeile zu Zeile nicht sehr notwendig ist, da das Springen von Eintrag zu Eintrag bereits über die Überschriften ermöglicht wird.

Das Springen des Auges von einem hervorgehobenen Eintrag zum nächsten ist sicher ebenso leicht.

Sicherlich könnte man behaupten, das Durchsuchen über diese Kopfzellen wäre bereits ein Vergleichen/Abgleichen, aber wieso dann eine Adressenliste nicht als Tabelle auszeichnen? Die häufigste Nutzung einer solchen Adressenliste/-datenbank ist, die Liste nach einem bestimmten Namen zu durchforsten, der den gesuchten Eintrag bezeichnet, und dann in den Datensatz einzusteigen.

Eben, ein Vergleich der Daten untereinander ist da wohl eher selten.

Da bei der Adressliste die Namen wie gesagt als »Index« verwendet werden, sollten sie auch entsprechend formatiert sein; in deinem Vorschlag sehen sie wie alle Eigenschaften des Eintrags aus. Der Sprung mit dem Auge zum nächsten hervorgehobenen Text wäre also ebenfalls erschwert.

Selbst ohne weiteres HTML wäre dem mittels ":first-child" beizukommen.

Die Strukturierung kann also die Lesebedingungen und die Bedienungssituation entscheidend ändern und diese »Präsentation« der Daten hängt m.E. sehr stark mit der Verständlichkeit der Aussage zusammen, selbst wenn man annimmt, dass die verschiedenen Markupstrukturen denselben Sachverhalt wiedergeben, nur andere Schwerpunkte setzen und Herangehensweisen verwenden.

Dass sie die Bedingungen und die Handhabung beeinflussen ist mir natürlich klar. -- Das ist ja auch kein Zufall, sondern gewollt.

Das kann ich mir irgendwie nicht vorstellen, wenn ich mir die gängigen Lese- und Vorarbeitungsprozesse vorstelle, die ein Leser an solchen strukturieren Informationen vollzieht.

Warum zeichnest du überhaupt aus, wenn du nicht vorstellen kannst, die Voraussetzungen der Informationsaufnahme beeinflussen zu wollen?

Aber als Autor kann ich ja nur einen Schwerpunkt und nur eine Herangehensweise mittels der Struktur präferieren.

Ja, vielleicht wäre es wirklich angemessen, danach zu fragen, welchen Zweck der Text erfüllen will, wie mit ihm umgegangen wird, und vor allem danach eine angemessene Struktur zu wählen.

Ja, aber gleichzeitig suggeriere ich als Autor einen bestimmten Zweck -- und damit die Form. In diesem Zwiespalt lebt die Semantik.

Und natürlich wähle ich da die mir semantisch korrekt erscheinende, aber den Inhalt beeinflusst die Struktur dennoch nicht.

Wie gesagt, ich halte die Auszeichnungsweise durchaus für eine »Botschaft« und die besagten Schwerpunkte und Herangehensweisen bzw. Perspektiven vermitteln m.E. auch verschiedene Auffassungen des Inhalts, sie beeinflussen »das, was ankommt« folglich durchaus (ob das jetzt der Inhalt »an sich« ist oder nicht, finde ich irgendwie unwichtig).

Das liegt vielleicht daran, dass insgesamt sehr wenig oder gedankenlos ausgezeichnet wird, so dass jeder ausgearbeiteten Struktur eine sehr große Bedeutung beigemessen wird. -- Ich finde das schade, trage dem aber Rechnung, indem ich die Struktur teilweise wieder kaschiere.

Bei Überschriften muss man sich genauso Gedanken darüber machen, in wie weit sie den betitelten Inhalt kennzeichnen und »repräsentieren«, da stehen aber m.M.n. andere Kriterien im Vordergrund als bei der Definitionsliste im strengen Sinne, die Überschrift umfasst den Inhalt nicht. Aber die Unterscheidung verschwimmt mir, wenn ich von der Definition absehe und jeweils nur die Zuordnung vergleiche (gemäß dem Zitat aus der ersten HTML-Spec).

Zunächst würde ich niemals eine <dl> ohne <hx> verwenden, um immer einen klaren Bezugspunkt zu haben. Wenn ich eines dieser Elemente oder gar beide mit unpassenden Inhalten versehe, funktioniert das Konstrukt natürlich nicht, aber das ist ja bei einer Tabelle oder einzelnen Absätzen auch nicht anders.

Es ging mir auch eher um den Fall, in denen die Überschriften anstelle der dt-Elemente genutzt werden, also die dl-Hierarchie als Hierarchie des Inhalts des gesamten Dokuments begriffen wird (was m.E. meist der Fall ist, wenn dein einleitendes hx ein h1-Element ist).

Das ist schwer an einem Code-Fragment festzumachen, aber du hast natürlich Recht, wenn du meinst, dass man sich bei meinem Ansatz sehr weitreichend mit der Struktur befassen muss, ehe man ein zufriedenstellendes Ergebnis erhält. Zufrieden bin ich mit meiner Lösung ja auch nicht, so dass ich ständig an ihr feile, aber bis zu einem zufriedenstellenden Standard seitens des W3C habe ich ja wohl noch etwas Zeit ;-)
MfG, at