(TABELLEN) Für Formulare sinnvoll?

[Christian Seiler]

Hallo Forum,

Eine eher HTML-philosophische Frage:

Wenn ich ein Formular erstelle, könnte ich dazu ja eine Tabelle verwenden:

+-----------------------+-------------------------+
|                       | +---------------------+ |
| Name:                 | | ...                 | |
|                       | +---------------------+ |
+-----------------------+-------------------------+
|                       | +---------------------+ |
| Email:                | | ...                 | |
|                       | +---------------------+ |
+-----------------------+-------------------------+

So, jetzt bleibt halt die Frage: Ist das semantisch/logisch wertvoll? Ist das ein Fall von tabellarischen Daten oder nicht? Ich kann ja so argumentieren, das die Beschriftungen zu sich selbst in Form des Zwecks in Relation stehen, und dass diese wieder in Form des Inhalts in Relation zu den Eingabefeldern stehen. Somit wäre eine Tabelle also Teil der logischen Struktur der Seite, oder? Oder spricht etwas dagegen, weil ich keine *Daten* verwende? Kann ich noch andere Ansätze als die Tabelle verwenden, um die Elemente so anzuordnen? Oder noch anders gefragt: Ist das so überhaupt sinnvoll oder sollten die Eingabefelder vielleicht doch nicht alle gleich ausgerichtet sein?

Grüße,

Christian

[uepselon]

Hi Christian,

So, jetzt bleibt halt die Frage: Ist das semantisch/logisch wertvoll? Ist das ein Fall von tabellarischen Daten oder nicht?

Oder noch anders gefragt: Ist das so überhaupt sinnvoll oder sollten die Eingabefelder vielleicht doch nicht alle gleich ausgerichtet sein?

Wo liegt das Problem, außer der Frage ob es tabellarische Daten sind oder nicht? Welchen Sinn macht eine Enteilung in tabellarische Daten und nicht tabellarischen Daten?

Ein HTML Konstrukt wie eine Tabelle sollte da verwendet werden wo es Sinn macht und nicht nach Datengesichtspunkten in Kategorien denken.

Ich habe auch schon öfters versucht auf Tabellen als Hilfsmittel der Layoutgestaltung zu verzichten. Der Erfolg zeigt sich in vielen Browsern unterschiedlich. Deshalb kommt es darauf an welches Ziel du erreichen willst?

Trennung von Daten und Layout? Oder eine Mischung die den Ansprüchen genügt?

Da ein gut ausgerichtetes Formular optisch viel ansprechendenr ist als ein evtl. zerhacktes, bin ich der Ansicht das man hier getrost auf Tabellen zurückgreifen kann.

Gruß

ueps

[Christian Seiler]

Hallo uepselon,

Wo liegt das Problem, außer der Frage ob es tabellarische Daten sind oder nicht?

Das ist ein Glaubensproblem. ;-)

Ein HTML Konstrukt wie eine Tabelle sollte da verwendet werden wo es Sinn macht und nicht nach Datengesichtspunkten in Kategorien denken.

IMHO nicht.

Trennung von Daten und Layout? Oder eine Mischung die den Ansprüchen genügt?

Möglichst Trennung von Daten und Layout, aber trotzdem noch meinen Ansprüchen gerecht werdend. (ich weiß, ich verlange warscheinlich das unmögliche)

Da ein gut ausgerichtetes Formular optisch viel ansprechendenr ist als ein evtl. zerhacktes, bin ich der Ansicht das man hier getrost auf Tabellen zurückgreifen kann.

Ich werde darüber nachdenken...

Grüße,

Christian

[uepselon]

Hi,

Möglichst Trennung von Daten und Layout, aber trotzdem noch meinen Ansprüchen gerecht werdend. (ich weiß, ich verlange warscheinlich das unmögliche)

In der Tat, es ergibt sich quasi ein unlösbares Problem.

Trennt man Daten und Layout strikt, werden Browser die den CSS Standard nicht oder nicht richtig verstehen, nur bescheidene Seiten anzeigen die quasi unlesbar oder zumindest layouttechnischer Unfug  sind.

Mischt man Layout und Daten, bekommt man wahrscheinlich das maximale Ergebnis aus Darstellung und Kompatibilität, mal von Textbrowsern abgesehen. Wichtig ist einfach das man den Tabellen ansich keine Attribute mitgeben sollte, sondern dies wieder über CSS macht und somit zumindest die Grundstruktur auch ohne CSS am leben hält.

Gruß

ueps

[Christian Seiler]

Hallo uepselon,

Trennt man Daten und Layout strikt, werden Browser die den CSS Standard nicht oder nicht richtig verstehen, nur bescheidene Seiten anzeigen die quasi unlesbar oder zumindest layouttechnischer Unfug  sind.

Tja, ich hoffe halt immer noch, dass man die Formulartabelle semantisch trotzdem noch als Tabelle ansehen kann, aber ausdiskutiert ist das noch nicht...

Grüße,

Christian

[jens]

Hi Christian,

meiner Meinung nach grenzt es an eine Glaubensfrage, ob die Benutzung von Tabellen hier semantisch sinnvoll ist.

So antworte ich mit einem klaren jein :-)

Ich halte es aber in Hinblick auf die Benutzbarkeit eines Formulares für sehr sinnvoll, die Eingabefelder entsprechend auszurichten.

Mein Lösungsvorschlag ohne Einsatz von Tabellen wäre (auf die Schnelle):

<div style="float:left;width:25%">
<div style="height:25px">Name:</div>
<div style="height:25px">Adresse:</div>
<div style="height:25px">e-mail:</div>
</div>
<div style="float:left;width:25%">
<div style="height:25px"><input type="text" name="Name"></div>
<div style="height:25px"><input type="text" name="adresse"></div>
<div style="height:25px"><input type="text" name="email"></div>
</div>

jens

[Christian Seiler]

Hallo jens,

meiner Meinung nach grenzt es an eine Glaubensfrage, ob die Benutzung von Tabellen hier semantisch sinnvoll ist.

Genau das wollte ich ja diskutieren... ;-)

Mein Lösungsvorschlag ohne Einsatz von Tabellen wäre (auf die Schnelle):

Gut gemeint, aber wenn man das linearisiert (oder einen Netscape 4 nimmt), dann ist der Spaß vorbei... Nix für ungut.

Grüße,

Christian

[jens]

Genau das wollte ich ja diskutieren... ;-)

Gut. Es handelt sich um keine Tabelle, da nur die erste Spalte Daten enthält, in der zweiten jedoch nur die Möglichkeit vorhandener Daten.

Das Einfügen einer summary würde aus diesem Grunde auch keinen Sinn ergeben.

Die Tabelle wird auch nicht um der Tabelle, sondern der Gestaltung
Willen eingesetzt.

Aus tabellarisch-semantisch-puritanischer Sicht verurteile ich somit die Benutzung der Tabelle in einem Formular in Grund und Boden!

jens ;-)

[Christian Seiler]

Hallo Jens,

Gut. Es handelt sich um keine Tabelle, da nur die erste Spalte Daten enthält, in der zweiten jedoch nur die Möglichkeit vorhandener Daten.

Und warum sollte die Möglichkeit vorhandener Daten nicht auch als Daten zählen? Warum dürfen "Platzhalter" nicht als Daten zählen?

Das Einfügen einer summary würde aus diesem Grunde auch keinen Sinn ergeben.

Warum nicht? So etwas wie:

"Die Tabelle enthält jeweils eine Spalte für die Bezeichnungen und eine Spalte für die Eingabefelder."

Außerdem ließe sich so eine Tabelle wunderschön linear ablesen...

Aus tabellarisch-semantisch-puritanischer Sicht verurteile ich somit die Benutzung der Tabelle in einem Formular in Grund und Boden!

*GRMBL* Hast Du dann nicht wenigstens eine linearisierbare Alternative...

Grüße,

Christian

[Sönke Tesch]

Mein Lösungsvorschlag ohne Einsatz von Tabellen wäre (auf die Schnelle):

<div style="float:left;width:25%">
<div style="height:25px">Name:</div>
<div style="height:25px">Adresse:</div>
<div style="height:25px">e-mail:</div>
</div>
<div style="float:left;width:25%">
<div style="height:25px"><input type="text" name="Name"></div>
<div style="height:25px"><input type="text" name="adresse"></div>
<div style="height:25px"><input type="text" name="email"></div>
</div>

Das ist IMHO genau der Weg, wie man es _nicht_ machen sollte. Mal abgesehen von der unschönen Pixelhöhe reißt Du hier Bezeichner und Formularfelder so auseinander, daß das berühmte Schwein nicht mehr weiß, wo was hingehört - Du könntest die Bezeichner beinahe auch komplett weglassen.
Sicherlich sieht es gut in einem Browser aus, der mit den <div>s umgehen kann, aber der Punkt bei "HTML pur" ist ja gerade, daß man die Dokumente auch ohne supertolle Grafik-Browser lesen können soll. Für diesen Bereich ist die Aufzählung "Name, Adresse, eMail, Eingabe, Eingabe, Eingabe" nicht gerade hilfreich. So gesehen ist Dein Vorschlag schon ein Argument _für_ Formulartabellen.

Ein Formular in eine (einfache) Tabelle zu packen ist deshalb durchaus korrekt; die Erklärung hat Robert bereits gebracht (man könnte die Bezeichner auch in <th>-Blöcke packen und nur die <input>-Elemente in <td> einfassen).

Gruß,
  soenk.e

[Robert Bamler]

Hallo Christian,

So, jetzt bleibt halt die Frage: Ist das semantisch/logisch wertvoll?

Dein Beispiel finde ich genau passend für eine Tabelle. Auch wenn du es irgendwie hinbekommen solltest, die Daten ohne table-Tags so auszurichen, *ist* das ganze eine Tabelle. Du kannst dir das so veranschaulichen:

|      BEZEICHNER       |          WERT           |
+=======================+=========================+
|                       | +---------------------+ |
| Name:                 | | ...                 | |
|                       | +---------------------+ |
+-----------------------+-------------------------+
|                       | +---------------------+ |
| Email:                | | ...                 | |
|                       | +---------------------+ |
+-----------------------+-------------------------+

Egal, mit welchen Mitteln du das so ausrichtest, semantisch gesehen ist es IMHO eine Tabelle, nur dass die Spaltenüberschriften fehlen (die bringen's auch nicht wirklich).

Ist das so überhaupt sinnvoll oder sollten die Eingabefelder vielleicht doch nicht alle gleich ausgerichtet sein?

Ich finde es um einiges übersichtlicher, wenn die Eingabefelder alle untereinander stehen, als wenn sich ihre Position an die jeweilige Länge des Textes davor anpasst und sie eher "durcheinander" auf der Seite erscheinen. Eben daran sieht man, dass es sich hier wirklich um eine Tabelle handelt.

Robert (der im Übrigen sowieso kein <table>-Semantik-Purist ist.)

[Christian Seiler]

Hallo Robert,

*ist* das ganze eine Tabelle. Du kannst dir das so veranschaulichen: [...]
Egal, mit welchen Mitteln du das so ausrichtest, semantisch gesehen ist es IMHO eine Tabelle, nur dass die Spaltenüberschriften fehlen (die bringen's auch nicht wirklich).

Von dieser Meinung bin ich auch ausgegangen, aber ich hatte so meine Zweifel... Aber bis jetzt bin ich in dieser Meinung bestärkt worden. Also werde ich die Tabelle vermutlich als HTML-Purist guten Gewissens hier einsetzen können, aber ich warte noch mal ab, was andere dazu sagen.

Grüße,

Christian

[molily]

Hallo, Christian und Robert,

*ist* das ganze eine Tabelle. Du kannst dir das so veranschaulichen: [...]
Egal, mit welchen Mitteln du das so ausrichtest, semantisch gesehen ist es IMHO eine Tabelle, nur dass die Spaltenüberschriften fehlen (die bringen's auch nicht wirklich).

Full ACK.

Von dieser Meinung bin ich auch ausgegangen, aber ich hatte so meine Zweifel... Aber bis jetzt bin ich in dieser Meinung bestärkt worden. Also werde ich die Tabelle vermutlich als HTML-Purist guten Gewissens hier einsetzen können, aber ich warte noch mal ab, was andere dazu sagen.

Ich stimme Robert vollkommen zu, es geht hier um eine Zuordnung zwischen dem Label und dem Eingabefeld, das wird alleine schon an dem Doppelpunkt veranschaulicht. Insofern stimmt es IMHO, dass das Label als Kopfzeile für das dem Label zugeordneten Eingabefeld dient. Bei Radiogroups ist es natürlich anders, da im th dann kein label steht, aber dies ändert nichts daran, dass sich die Beschreibung auf die gesamte Radiogroup als Eingabefeldeinheit bezieht, das heißt Label -> Formularfeld.

Wenn du die Zugangsrichtlinien 5.*, 12.4 und vor allem 10.2 beachtest und hinterher den tablin die Seite inspizieren lässt, kann gar nichts schief gehen.

In den Specs zu label wird auch eine Tabelle benutzt, http://www.w3.org/TR/html401/interact/forms.html#edef-LABEL, zwar ohne th, aber dort wird sonst nur table für Datentabellen gepredigt. Für mich ist hier eine Relation offensichtlich und damit table zweifelsohne gerechtfertigt.

Im Übrigen würden CSS-Lösungen mit float oder position momentan keine hohe Kompatibilität erreichen - ich habe damit schon einmal experimentiert. Die im Nebenthread vorgestellte CSS-Lösung ist natürlich völlig unpassend.

Grüße,
Mathias

[Christian Seiler]

Hallo Mathias,

Erst einmal danke, dass Du mich in meiner Auffassung bestärkst, aber ich habe immer so Reflexe, wenn ich auch nur an Tabllen denke, da frage ich sicherheitshalber noch mal nach. ;-)

Wenn du die Zugangsrichtlinien 5.*,

Bei 5.1 habe ich so meine Probleme, müssen die Spaltenüberschriften in dem Fall sein? Oder reicht es nicht, wenn ich <th> für die Zeilen mit dem Label verwende?

Grüße,

Christian

[molily]

Hallo, Christian,

Erst einmal danke, dass Du mich in meiner Auffassung bestärkst, aber ich habe immer so Reflexe, wenn ich auch nur an Tabllen denke, da frage ich sicherheitshalber noch mal nach. ;-)

Hm, »undogmatisch« argumentiert wäre selbst das Gegenüberstellen von Überschrift und deren »Kindabsätze« in einer Tabelle legitim, oder bei der anderen »Strukturmetainformation«. Zwei Beispiele:

----------------------------------------------------------------
Überschrift |  Kindabsatz     Text Text Text Text Text Text Text
            |  Text Text Text Text Text Text Text Text Text Text
            |  Text Text Text Text Text Text Text Text Text Text
            |  Text Text Text Text Text Text Text Kindabsatzende
----------------------------------------------------------------
... weitere Zeilen/Paare ...
----------------------------------------------------------------

Weiterhin:

----------------------------------------------------------------------------
Absatz    Text Text Text Text Text Text  |   Zusammenfassung des Absatzes
Text Text Text Text Text Text Text Text  |   Zusammenfassung Zusammenfassung
Text Text Text Text Text Text Text Text  |   Zusammenfassung Zusammenfassung
Text Text Text Text Text Text Abstzende  |   Ende der Absatzzusammenfassung
----------------------------------------------------------------------------
... weitere Zeilen/Paare ...
----------------------------------------------------------------------------

Natürlich müsste eine sequenzartige Textstruktur bestehen, das heißt das Dokument besteht zumindest teilweise aus gleichförmigen in ihrer Struktur gleichen Elementen (aufzählungs- bzw. listenartig), sodass eine gewöhnliche Tabelle mit mehreren Zeilen möglich ist.
Womöglich wäre eine Definitionsliste (dl-Element) beim ersten Beispiel optimal, aber eine Tabelle wäre nicht strenggenommen nicht ein Verstoß gegen die Vorgabe, Tabellen nur für tabellarische Daten zu benutzen.

Von der Dokumentstruktur her gesehen ist das p in folgendem Beispiel ein Kind von h2:
  <h2>murks</h2>
  <p>murks</p>
(»Gott wirf XHTML 2 vom Himmel!«)

Deshalb wird auch mit einer scheinbar linearen Struktur eine Zu- und Unterordnung vorgenommen, eine Tabelle, welche explizit mit ihrem tr-Element einen Datensatz kennzeichnet und in Datensatztitel und Datensatzinhalt aufteilt, ist nicht unbedingt nötig, hätte aber mehr semantisschen Wert. Ein paar Beispiele:

Die Struktur einer Tabelle wäre:

<datensatzliste>
 [Definition der Semantik der datensatz-Kindelemente]
  (<datensatz>
    <datensatzname>...</datensatzname>
    (<[beliebiges Element]>...</[beliebiges Element]>){1,}
  </datensatz>){1,}
</datensatzliste>

Die Struktur einer Definitionsliste:

<datensatzliste>
  (<datensatzname>...</datensatzname>
  <datensatzinhalt>...</datensatzinhalt>){1,}
</datensatzliste>

Eine hX-Struktur:

(<datensatzname>...</datensatzname>
(<datensatzinhalt>...</datensatzinhalt>){1,}){1,}

Erneut: »Gott wirf XHTML 2 (mit den besseren Möglichkeiten zur Dokumentstrukturierung) vom Himmel!« Die schon jetzt mögliche ideelle Verschachtelung habe ich weggekürzt, zugegeben. Darum geht es hier aber nicht, ich gehe von einer

Der Vorteil der Tabelle liegt auf der Hand - denn über die th-Elemente lassen sich sogar quasi neue Elementnamen einführen (um in der Veranschaulichung zu bleiben) beziehungsweise die Bedeutung der Elemente determinieren.

Wenn ich folglich eine Datenstruktur in XML abbilden würde, würde ich ohne Zweifel die erste, semantisch vollwertigere Struktur benutzen. Warum die Semantik verschenken, wenn diese Daten in (X)HTML transformiert werden?

Wenn du die Zugangsrichtlinien 5.*,

Bei 5.1 habe ich so meine Probleme, müssen die Spaltenüberschriften in dem Fall sein?

IMHO: nein. Und zwar aus dem Grund, weil es für das Verständnis nicht nötig ist und die doppelte Verknüpfung zwischen th und td aufgrund desselben tr-Vaters und zwischen label/for und input/id eindeutig genug ist. Das label-Element gibt genug Metainformation über den Spaltenkopfinhalt, sodass ein zusätzliches th als Spaltenüberschrift (scope="col") darüber nicht nötig ist.

Für den Tabellenlinearisierer eines Screenreaders halte ich die zusätzliche Ausgabe der kompletten Headers für unnötig... Man denke an:
  Eingabefeldbeschreibung Doppelpunkt  {label-Inhalt}
  Formulareingabefeld Doppelpunkt Texteingabefeld [Möglichkeit, in den Formularmodus zu wechseln]
Das ist auch nicht Sinn der Sache. Inwieweit label von den Browsern und Zusatzprogrammen momentan überhaupt unterstützt wird, sodass ein Browser aus den labels unabhängig vom umgebenden Markup das Formular in einer bestimmten Weise ausgeben kann, ist mir unbekannt.

Im Grunde genommen sind momentan Tabellen unnötig, da die Zuordnung dank label schon explizit besteht und somit die tabellarische Darstellung nicht mit Markup gelöst werden muss (aber kann).
Ich tippe darauf, dass XForms die Zugänglichkeit sowieso grundlegend vereinfachen wird...

Oder reicht es nicht, wenn ich <th> für die Zeilen mit dem Label verwende?

IMHO ja.

Grüße,
Mathias

[Christian Seiler]

Hallo Mathias,

Hm, »undogmatisch« argumentiert wäre selbst das Gegenüberstellen von Überschrift und deren »Kindabsätze« in einer Tabelle legitim, oder bei der anderen »Strukturmetainformation«.

Hm. Da hast Du recht. Ich werde in Zukunft weniger sparsam mit Tabellen umgehen.

Womöglich wäre eine Definitionsliste (dl-Element) beim ersten Beispiel optimal,

Warum? Ich definiere doch im Normalfall nicht die Überschrift, oder?

Zur Darstellung: Ähm, wie wäre es mit einem float: left;? *duck*

aber eine Tabelle wäre nicht strenggenommen nicht ein Verstoß gegen die Vorgabe, Tabellen nur für tabellarische Daten zu benutzen.

Im Fall eins würde ich doch dazu tendieren, dass das ein Verstoß wäre, im Fall zwei ist das nicht ganz so einfach zu entscheiden.

(»Gott wirf XHTML 2 vom Himmel!«)

Hehe. ;-)

Deshalb wird auch mit einer scheinbar linearen Struktur eine Zu- und Unterordnung vorgenommen, eine Tabelle, welche explizit mit ihrem tr-Element einen Datensatz kennzeichnet und in Datensatztitel und Datensatzinhalt aufteilt, ist nicht unbedingt nötig, hätte aber mehr semantisschen Wert.

Unter Umständen: ja. Wenn man alle 'Kapitel' in eine Tabelle packt, könnte das legitim sein.

Darum geht es hier aber nicht, ich gehe von einer

Hier fehlt doch was, hier wird doch wohl nicht zens

;-)

Der Vorteil der Tabelle liegt auf der Hand - denn über die th-Elemente lassen sich sogar quasi neue Elementnamen einführen (um in der Veranschaulichung zu bleiben) beziehungsweise die Bedeutung der Elemente determinieren.

Hmmm, ja, aber wir entfernen uns hier wieder vom tabellarischen.

Wenn ich folglich eine Datenstruktur in XML abbilden würde, würde ich ohne Zweifel die erste, semantisch vollwertigere Struktur benutzen. Warum die Semantik verschenken, wenn diese Daten in (X)HTML transformiert werden?

Ja klar, aber Du darfst XML nicht mit XHTML mischen, denn <table>&co sind in XHTML nicht anderes als Tabellen, bei XML können die Tags eine von Dir festgelegte, andere semantische Bedeutung haben.

IMHO: nein. Und zwar aus dem Grund, weil es für das Verständnis nicht nötig ist und die doppelte Verknüpfung zwischen th und td aufgrund desselben tr-Vaters und zwischen label/for und input/id eindeutig genug ist. Das label-Element gibt genug Metainformation über den Spaltenkopfinhalt, sodass ein zusätzliches th als Spaltenüberschrift (scope="col") darüber nicht nötig ist.

So etwas dachte ich mir auch, ich wollte nur mal auf 'Nummer sicher' gehen.

Für den Tabellenlinearisierer eines Screenreaders halte ich die zusätzliche Ausgabe der kompletten Headers für unnötig... Man denke an:
  Eingabefeldbeschreibung Doppelpunkt  {label-Inhalt}
  Formulareingabefeld Doppelpunkt Texteingabefeld [Möglichkeit, in den Formularmodus zu wechseln]

Waaaaaaah!!!!1111 Hiiiilfeeeee!!11111 ;-)

Inwieweit label von den Browsern und Zusatzprogrammen momentan überhaupt unterstützt wird, sodass ein Browser aus den labels unabhängig vom umgebenden Markup das Formular in einer bestimmten Weise ausgeben kann, ist mir unbekannt.

Ich kann Dir nur so viel sagen: Wenn beim Mozilla ein Label für eine Checkbox oder einen Radiobutton definiert ist, dann aktiviert er diese beim Click auf den Inhalt des Labels. Leider wird das noch nicht häufig genug verwendet.

Ich tippe darauf, dass XForms die Zugänglichkeit sowieso grundlegend vereinfachen wird...

Damit (XForms) habe ich mich noch gar nicht beschäftigt...

Oder reicht es nicht, wenn ich <th> für die Zeilen mit dem Label verwende?

IMHO ja.

Ok.

Grüße,

Christian

[molily]

Hallo,

Womöglich wäre eine Definitionsliste (dl-Element) beim ersten Beispiel optimal,

Warum? Ich definiere doch im Normalfall nicht die Überschrift, oder?

Doch, abstrahiert gesehen schon. Das dt-Element definiert einen Titel für die Daten im dd-Element und somit ist es einer Überschrift ähnlich (term -> description). Wenn wie beschrieben eine listenartige Sequenz vorliegt, welche jeder Überschrift diese erläuternde Daten unterordnet (»der Bereich, welcher mit $Überschrift betitelt ist, besteht aus bzw. enthält $Daten«), ist eine Definitionsliste strukturell passend.

Genau genommen hast du Recht, eine Definitionsliste ist für die Definition von Begriffen gedacht... Aber eine Tabelle ist nur eine weitere Abstraktionsebene mit mehr Metadaten, eine Definitionsliste lässt sich eins zu eins auf eine Tabelle übertragen:

<table>
<tr>
<th scope="col">Begriff</th>
<th scope="col">Beschreibung</th>
</tr>
<tr>
<th scope="row">foo</th>
<td>bar</td>
</tr>
...
</table>

In XHTML 2-Dimensionen gedacht ist der Unterschied zwischen h, section und p auf der einen und dl, dt und dd auf der anderen von der Struktur her (sic) gering. Das heißt, man würde, wie du sagst, nicht dl verwenden, aber das Modell bliebe nahezu dasselbe, weshalb sich IMHO auch beides tabellarisch in einer sequenziellen Liste darstellen lässt.

Ich persönlich verwende Definitionslisten wahrlich nicht nur um Begriffe zu erläutern, sondern generell um fast schon tabellarische Datenzuordnungen vorzunehmen, siehe http://home.t-online.de/home/dj5nu/molily.html. Ich hätte dort genauso gut Tabellen benutzen können, IMHO wäre es legitim, aufgrund der Darstellung habe ich aber Definitionslisten benutzt, weil diese die Datenzuordnung IMHO genauso passend verdeutlichen - die von mir angesprochene höhere semantische Wertigkeit von Tabellen aufgrund der zusätzlichen Metainformationen über die erste th-Zeile ist hier ebenfalls nicht nötig (habe ich als Autor willkürlich entschieden).

Zur Darstellung: Ähm, wie wäre es mit einem float: left;? *duck*

Ja - darum geht es hier aber nicht, sondern darum, dass generell Metadaten mit einem anderen Datenpaket verknüpft werden, beispielsweise in Form einer Überschrift (header), eines Titels oder einer Zusammenfassung.

Die Darstellung ist im Endeffekt gleichgültig, denn sofern das Markup genug Struktur hergibt, lässt sich (im Idealfall) mit CSS jede mögliche Darstellung erreichen. Die einzige Frage ist deshalb, welches Markup am passendsten ist. float:left anzuwenden, ohne dass im Markup eine tatsächliche logische Verbindung besteht, wäre IMHO sogar gewissermaßen Missbrauch von CSS, da diese zuerst im Markup etabliert werden sollte.
Momentan besteht zwischen einem hX-Element und einem p-Element, welches logisch dem untergeordnet ist, keine Verbindung - das section-Element von XHTML 2 gruppiert immerhin diese zusammengehörigen Daten.

aber eine Tabelle wäre nicht strenggenommen nicht ein Verstoß gegen die Vorgabe, Tabellen nur für tabellarische Daten zu benutzen.

Im Fall eins würde ich doch dazu tendieren, dass das ein Verstoß wäre, im Fall zwei ist das nicht ganz so einfach zu entscheiden.

Warum? Ich sehe vom Datenmodell her keinen großen Unterschied - der Punkt ist einfach, dass hX existiert, welches explizit diesen Fall abdeckt. Ich wollte nur theoretisch beweisen, dass sich beides ineinander überführen lässt, ohne dass die Abhängigkeiten und Neben- und Unterordnungen verloren gehen. Somit läge nehazu dieselbe Struktur vor, semantisch exakter (weil weniger universell) wäre dennoch hX.
Im Zweifelsfall würde ich sicher auch etwas, was eindeutig als Kapitel (chapter/section)-Überschrift aussieht, mit einem hX-Element auszeichnen, wenn nicht alles in einer Tabelle äquivalent organisiert werden kann.

Deshalb wird auch mit einer scheinbar linearen Struktur eine Zu- und Unterordnung vorgenommen, eine Tabelle, welche explizit mit ihrem tr-Element einen Datensatz kennzeichnet und in Datensatztitel und Datensatzinhalt aufteilt, ist nicht unbedingt nötig, hätte aber mehr semantisschen Wert.

Unter Umständen: ja. Wenn man alle 'Kapitel' in eine Tabelle packt, könnte das legitim sein.

Genau, darauf wollte ich hinaus.
Wenn man die erste Ebene eines Dokuments anschaut, kann man sicherlich eine sequentielle Struktur erkennen...

Darum geht es hier aber nicht, ich gehe von einer

...nicht verschachtelten Struktur aus. Die Datenmodelle setzen sich ja gleichförmig bei der Verschachtelung fort, insofern reicht es, das Grundmodell zu betrachten.

(Die minutenlange Verzögerung beim Absenden und bei der Vorschau bringt mich komplett durcheinander...)

Der Vorteil der Tabelle liegt auf der Hand - denn über die th-Elemente lassen sich sogar quasi neue Elementnamen einführen (um in der Veranschaulichung zu bleiben) beziehungsweise die Bedeutung der Elemente determinieren.

Hmmm, ja, aber wir entfernen uns hier wieder vom tabellarischen.

Über die Definition einer Tabelle und damit was »tabellarisch« ist, lässt sich streiten. :) Alles, was einander zu- bzw. untergeordnet wird, lässt sich für mich mittels einer Tabelle darstellen, da ich versucht habe, die Tabelle als XML-Datenmodell aufzufassen, haben alle HTML-Strukturen mit der Tabelle sehr viel gemein... (Die Tabelle ist der Archetyp jedes Datenmodells, oder die Brutstätte... Asche zu Asche, Staub zu Staub, beziehungsweise Metalement zu Metaelement und Datenelement zu Datenelement. ;))

Wenn ich folglich eine Datenstruktur in XML abbilden würde, würde ich ohne Zweifel die erste, semantisch vollwertigere Struktur benutzen. Warum die Semantik verschenken, wenn diese Daten in (X)HTML transformiert werden?

Ja klar, aber Du darfst XML nicht mit XHTML mischen, denn <table>&co sind in XHTML nicht anderes als Tabellen, bei XML können die Tags eine von Dir festgelegte, andere semantische Bedeutung haben.

Die festgelegte Semantik der HTML-Elemente reicht aber (IMHO) nicht aus, um bestimmte Datenstrukturen adäquat abzubilden. Wenn man ul, ol, dl, hX und table nur in einer Weise benutzt, wie sie explizit vorgesehen ist, wird man nicht weit kommen, deshalb möchte ich gerne die Tabelle als Muster für die anderen Elementstrukturen sehen... (Siehe mein Beispiel, indem ich strenggenommen dl missbrauche, weil es sich nicht um einen Glossar handelt.)

Oder reicht es nicht, wenn ich <th> für die Zeilen mit dem Label verwende?

IMHO ja.

Sollte übrigens »doch, es reicht aus« heißen, denn eine positive Antwort auf eine negative These wird in der Regel als Bestätigung der Annahme aufgefasst. Deine Annahme lautete »Es reicht nicht aus, (...)«, ich antwortete inkorrekt: »Diese Annahme halte ich für wahr (true, ACK).« *smirk*

(Ich glaube, ich habe mich insgesamt einige Male wiederholt. Hmmm.)

Grüße,
Mathias

[Christian Seiler]

Hallo Mathias,

Warum? Ich definiere doch im Normalfall nicht die Überschrift, oder?

Das dt-Element definiert einen Titel für die Daten im dd-Element und somit ist es einer Überschrift ähnlich (term -> description).

<verblendeter-w3c-jünger>
NACK. Das dt-Element enthält einen Begriff, der im dd-Element definiert wird. Punkt.
</verblendeter-w3c-jünger>

*smirk*

Wenn wie beschrieben eine listenartige Sequenz vorliegt, welche jeder Überschrift diese erläuternde Daten unterordnet (»der Bereich, welcher mit $Überschrift betitelt ist, besteht aus bzw. enthält $Daten«), ist eine Definitionsliste strukturell passend.

Strukturell ja, semantisch nein.

Genau genommen hast du Recht,

:-)

eine Definitionsliste ist für die Definition von Begriffen gedacht... Aber eine Tabelle ist nur eine weitere Abstraktionsebene mit mehr Metadaten, eine Definitionsliste lässt sich eins zu eins auf eine Tabelle übertragen:

[...]

Und hier erkennt man schon, dass man nicht zwischen struktureller und semantischer Beschreibung unterscheiden kann, zumindest nicht, wenn man nicht 100000 verschiedene Tags definiert. ;-) Dennoch bin ich der Meinung, dass dort, wo es Elemente gibt, die für die gewünschen semantische Bedeutung zutreffend sind, diese verwendet werden sollten, und nur dort, wo es keine Elemente gibt, die eine passende semantische Bedeutung haben, wohl aber unterschiedliche mit einer passenden strukturellen Bedeutung, sich die Elemente 'aussuchen' kann.

In XHTML 2-Dimensionen gedacht ist der Unterschied zwischen h, section und p auf der einen und dl, dt und dd auf der anderen von der Struktur her (sic) gering. Das heißt, man würde, wie du sagst, nicht dl verwenden, aber das Modell bliebe nahezu dasselbe, weshalb sich IMHO auch beides tabellarisch in einer sequenziellen Liste darstellen lässt.

Ja. Strukturell gesehen. Aber wie gesagt nicht semantisch.

Ich persönlich verwende Definitionslisten wahrlich nicht nur um Begriffe zu erläutern, sondern generell um fast schon tabellarische Datenzuordnungen vorzunehmen, siehe http://home.t-online.de/home/dj5nu/molily.html. Ich hätte dort genauso gut Tabellen benutzen können, IMHO wäre es legitim, aufgrund der Darstellung habe ich aber Definitionslisten benutzt, weil diese die Datenzuordnung IMHO genauso passend verdeutlichen - die von mir angesprochene höhere semantische Wertigkeit von Tabellen aufgrund der zusätzlichen Metainformationen über die erste th-Zeile ist hier ebenfalls nicht nötig (habe ich als Autor willkürlich entschieden).

Hmmm. In dem Fall, den Du da beschreibst, ist eine Definitionsliste durchaus angebracht, da die semantische Bedeutung, die Du erzielen willst, ihr näher liegt, als einer Tabelle.

Die einzige Frage ist deshalb, welches Markup am passendsten ist.

Ja, das sehe ich ein.

float:left anzuwenden, ohne dass im Markup eine tatsächliche logische Verbindung besteht, wäre IMHO sogar gewissermaßen Missbrauch von CSS, da diese zuerst im Markup etabliert werden sollte.

ACK.

Momentan besteht zwischen einem hX-Element und einem p-Element, welches logisch dem untergeordnet ist, keine Verbindung - das section-Element von XHTML 2 gruppiert immerhin diese zusammengehörigen Daten.

Ja, nur das Problem wird folgendes sein: Es gibt im Moment keinen Browser, der XHTML 2 unterstützt. Es gibt im Moment keinen Browser, der CSS2 vollständig unterstützt, obwohl dieser Standard über 4 Jahre alt ist. Es gab bis vor kurzem keinen Browser, der benutzbar war *und* HTML 2 unterstützt hat, welches schon 7 Jahre alt ist. *grmf*

Ich wollte nur theoretisch beweisen, dass sich beides ineinander überführen lässt, ohne dass die Abhängigkeiten und Neben- und Unterordnungen verloren gehen. Somit läge nehazu dieselbe Struktur vor, semantisch exakter (weil weniger universell) wäre dennoch hX.

Eben. Das sind zwei Ebenen, die strukturelle und die semantische.

(Die Tabelle ist der Archetyp jedes Datenmodells, oder die Brutstätte... Asche zu Asche, Staub zu Staub, beziehungsweise Metalement zu Metaelement und Datenelement zu Datenelement. ;))

Damit hättest Du nun dargelegt, dass rein strukturell gesehen Tabellenlayouts zulässig sind. Semantisch gesehen natürlich nicht.

Sollte übrigens »doch, es reicht aus« heißen, denn eine positive Antwort auf eine negative These wird in der Regel als Bestätigung der Annahme aufgefasst. Deine Annahme lautete »Es reicht nicht aus, (...)«, ich antwortete inkorrekt: »Diese Annahme halte ich für wahr (true, ACK).« *smirk*

Schon klar, wir sind hier nicht im Deutschunterricht. ;-)

(Ich glaube, ich habe mich insgesamt einige Male wiederholt. Hmmm.)

Ich warscheinlich öfter als Du, so what?

Grüße,

Christian

P.S.: Mit diesem Thread hätten wir bewiesen, dass wir keine Ahnung vom richtigen[tm] Internet haben. ;-) Ich habe vorhin erst wieder emus </archiv/2002/3/7072/#m39152> durchgelesen.

P.P.S.: You got my mail?