nicht angemeldet
Welchen Sinn hat es hier, bei jedem Eintrag <dt>Adresse</dt> zu schreiben?
Den, ein übergeordnete Zusammenfassung der folgenden Datensätz zu bilden.
Häh? Da folgt im Beispiel nur ein Datensatz; außerdem, wie kann das Wort »Adresse« die folgenden Datensätze zusammenfassen, wenn alle Datensätze bzw. Datensatzgruppen denselben Titel haben?
Wenn ich nicht gerade "Rechnungsadresse", "Lieferadresse", "Besucheradresse" etc. unterscheide,
Jaja, nehmen wir einmal an, diese Unterscheidung wird nicht gemacht und es gibt nur Adressen gleichen Typs, sodass über jedem Datensatz <dt>Adresse</dt> stünde. Das fände ich vollkommen überflüssig.
blende ich diese Angabe aber meist aus.
Dieser Vorgehensweise kann ich nachwievor keinerlei Nutzen abringen - Informationen im Text unterzubringen, sie dann aber in nahezu allen Zusammenhängen als unwesentlich zu betrachten und zu verstecken.
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.
Das ändert nichts daran, dass die Wichtigkeit und das Herausragen nicht aus dem Markup erkennbar ist, sondern erst durch die Formatierung. Damit gibt das Markup nicht die Bedeutung wieder. Das führt zu den geschilderten Nachteilen.
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.
Das ist dann tatsächlich eher eine Frage von flexiblen Kopfzellen, also der Kategorisierungsleistung der Datenstruktur. Mit Listen entzieht man sich natürlich jedem Zwang zur Vereinheitlichung und Kategorisierung, wie gesagt. Die Merkmale/Eigenschaften der Datensätze folgen dabei keinem gemeinsamen Schema, da sie sich nicht (bzw. nicht explizit, nicht maschinenlesbar, nicht redundant usw.) auf ein gemeinsames Schema beziehen, wie es bei Tabellen im thead definiert wird. Denke auch an maschinelle Verarbeitung und Speicherung, also wie gesagt über SQL bzw. XML - da ist Kategorisierung wieder Zwang.
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.
Rede doch bitte nicht um den heißen Brei herum und bleibe konkret beim Beispiel. Wo sollen bei der in eine Tabelle umgewandelten DCMI-Core-Elementliste Differenzen aufgezeigt werden, was liegt denn hier vor? Die Differenz besteht nur darin, dass sie unterschiedliche Aspekte von Metadaten behandeln, aber was soll daran speziell herausgearbeitet und visualisiert werden? Ich nehme mal an, dass du meinst, dass hier der Fall der großen Differenz zutrifft. Wie gesagt erscheint mir der Sprung innerhalb einer Spalte abgesehen von der <th scope="row">-Kopfspalte für wenig sinnvoll, in welcher Hinsicht sollte da denn was genau verglichen werden?
Und war jetzt der Punkt, in dem sich diese Daten von der Auflistung der Metadaten des Dokuments am Dokumentanfang fundamental unterscheiden, sodass für die Elementliste eine Tabelle gebraucht werden sollte und für die Metadatenliste eine Listenstruktur? (Bitte nicht zum x-ten Mal die Theorie wiederholen...)
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.
Ähm... Es ging um die Struktur, von der du sagtest, sie solle als Tabelle ausgezeichnet werden, oder wie habe ich deinen Allgemeinplatz »Sobald die Vergleichbarkeit der Datensätze im Vordergrund steht, verwende ich Tabellen.« auf meine konkrete Frage zu verstehen, warum du gerade hier eine Tabelle für angemessen hältst?
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.
Ich wollte doch gerade sagen, dass dieser Sachverhalt nichts daran ändert, dass die (möglichst) eindeutigen Indizes, also die Namen, für den Vorgang der geschilderten »Abfrage« der Datenbank von oberster Bedeutung sind. Dass die Namen direkt untereinander in einer Spalte aufgelistet sind, ermöglicht erst diese Nutzung, das Scannen, das schnelle Erfassen. Darauf bist du gar nicht eingegangen, ich sehe hier aber einen Knackpunkt in der Bedienung.
Die gedanklichen Operationen des Lesers/Benutzers sind die des durchlaufens der Indexspalte und das Abgleichen mit dem gesuchten Namen. Man könnte sich die Liste also auch verkürzt als Namensliste vorstellen, die die Namen mit Dokumenten verlinkt, die den gesamten Datensatz enthalten (das nur zur Verdeutlichung der logischen Beziehungen).
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.
Eben diese Auffassung kritisiere ich, da CSS nicht das Mittel ist, um Bedeutung hervorzuheben. Wenn der Name von einer solchen Wichtigkeit für den Datensatz und die Datenbank insgesamt ist, dann sollte diese auch aus dem Markup hervorgehen und der Titel des Datensatzes sein. Das es das erstgenannte Eigenschaft-Wert-Paar des Datensatzes ist, reicht keinesfalls aus und bietet nicht die Vorteile bei der Rezeption, die hx/th haben.
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?
Das sollte etwas anderes bedeuten, sonst würde ich mir selbst widersprechen: Ich wollte sagen, dass ich nicht erkenne, dass eine solche Umsetzung mit der Absicht und dem Willen entstanden ist, den erwarteten Benutzungsprozessen gerecht zu werden. Natürlich will ich die Umstände der Informatiosnaufnahme weitesgehend in die gewünschte Richtung beeinflussen, daher denke ich, dass bei der Adressenliste die Tabellenstruktur den üblichen Aufgaben gerecht wird.
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.
Zum Glück leben wir im Hypertext, da sind prinzipiell verschiedene Perspektiven möglich, sich einen Inhalt zu erschließen. Serverseitige Techniken erlauben verschiedene pointierte »Darstellungen« ein und derselben Datenstruktur, die verschiedenen Zwecken und Ansprüchen gerecht werden.