Tabellen oder Divsuppe. Was ist besser?

[Markus]

Hallo,

immer wieder gerate ich an sogenannte Designs (Graphikblöcke etc.), die auch mit Stylesheets relativ schwer umzusetzten sind.

Beim erstellen eines HTML Gerüsts ist mir aufgefallen, dass ich trotz mancher Kniffe eine Menge div-Elemente brauche, allein um beispielsweise Bildabschnitte um bestimmten Text 'herumzuwickeln'. Zusammen mit dem CSS ergibt sich dadurch eine weit größere Dateigröße als wenn ich das Gerüst mit Tabellen erstellen würde.

Dadurch bin ich auf die Titelfrage gekommen. Tabellen sind natürlich nur für tabellarische Daten gedacht, das ist mir klar. Aber wenn ich mit einer großen Tabelle, in der effektiv nur 3 übereinandergelegene Zellen genutzt werden, arbeite, ist dies dann nicht einer Divsuppe vorzuziehen?

Verwirrt, Markus

[Timo "God's Boss" Reitz]

immer wieder gerate ich an sogenannte Designs (Graphikblöcke etc.), die auch mit Stylesheets relativ schwer umzusetzten sind.

Das kann gut sein, Stylesheets (durch Fehler und Unzulänglichkeiten diverser Implementationen zusätzlich eingeschränkt) sind nicht perfekt und auch keine Alleskönner.

Beim erstellen eines HTML Gerüsts ist mir aufgefallen, dass ich trotz mancher Kniffe eine Menge div-Elemente brauche, allein um beispielsweise Bildabschnitte um bestimmten Text 'herumzuwickeln'.

Das ist in der Tat derzeit nicht mit CSS nicht möglich. Sicher, dass du einen derartigen Effekt nicht anders lösen kannst?

Zusammen mit dem CSS ergibt sich dadurch eine weit größere Dateigröße als wenn ich das Gerüst mit Tabellen erstellen würde.

Hast du auch daran gedacht, das CSS auszulagern, so dass es im Cache gehalten wird? Wenn ein Stylesheet beispielsweise zwanzig Seiten formatieren soll, dann kannst du die Größe des Stylesheets getrost durch zwanzig teilen.
Außerdem ist die Größe des HTML- und CSS-Codes meist irrelevant, zumal du nach eigener Aussage anscheinend recht grafiklastige Layouts hast.

Dadurch bin ich auf die Titelfrage gekommen. Tabellen sind natürlich nur für tabellarische Daten gedacht, das ist mir klar. Aber wenn ich mit einer großen Tabelle, in der effektiv nur 3 übereinandergelegene Zellen genutzt werden, arbeite, ist dies dann nicht einer Divsuppe vorzuziehen?

Idealerweise verwendet man weder das eine noch das andere. Das Markup zu ändern, um ein bestimmtes Layout verwirklichen zu können, ist schlecht und sollte nur als allerletzte Möglichkeit gesehen werden.

[molily]

Hallo,

Dadurch bin ich auf die Titelfrage gekommen. Tabellen sind natürlich nur für tabellarische Daten gedacht, das ist mir klar. Aber wenn ich mit einer großen Tabelle, in der effektiv nur 3 übereinandergelegene Zellen genutzt werden, arbeite, ist dies dann nicht einer Divsuppe vorzuziehen?
Idealerweise verwendet man weder das eine noch das andere. Das Markup zu ändern, um ein bestimmtes Layout verwirklichen zu können, ist schlecht und sollte nur als allerletzte Möglichkeit gesehen werden.

Mal allgemein: Das ist glaube ich die Lebenslüge der CSS-Layout-Freunde. »Idealerweise« trifft es genau.

Wenn man ein komplexes Layout nach den Regeln der Kunst baut, braucht man oft sehr viele Angriffspunkte für Styles im Markup. Das führt dazu, dass man divs und spans einfügt, die größtenteils strukturell keinen Sinn ergeben. Mit semantischem Code haben sie daher nichts zu tun, ich bezeichne sie gerne als Präsentationsgliederungen. Sie strukturieren den Inhalt nur in der Hinsicht, später im CSS adressierbar zu sein. Vor allem werden sie für ein bestimmtes Layout eingefügt, damit werden Markup und Stylesheet verschränkt, anstatt dass sie unabhängig voneinander bleiben und das Stylesheet ohne Änderung am Markup auswechselbar ist. Die vielgelobte Trennung von Textauszeichnung und Präsentationslogik ist damit Makulatur.

Es ist also nicht die »allerletzte Möglichkeit«, sondern leider Gang und Gäbe bei anspruchsvolleren Layouts. Die Frage ist also nicht, wie man komplett auf Präsentationsgliederungen im Markup verzichten kann, sondern wie man sie möglichst reduziert und abstrakt hält.

Die Entwicklung hin zur div-Suppe sah man schon, als die ersten großen Sites auf CSS-Layout umstiegen. Heutige große Sites arbeiten meist mit CSS-Layout, aber von aufgeräumtem, semantischen Markup sind sie weit entfernt. Selbst der CSS Zen Garden hatte damals gezeigt: Jedes beliebige anspruchsvolle CSS-Layout mit demselben Code umsetzen geht nur, wenn dieser voll von Präsentationsgliederungen ist, die Bereiche bloß markieren, damit Style-Regeln greifen können. Sicherlich ist das nicht einem prinzipiellen Problem zuzuschreiben, in der Regel lassen sich Optimierungen vornehmen, man denke an den Focus-Redesign.

Es macht jedenfalls Mühe, divs, spans, Klassen usw. zu reduzieren und CSS möglichst effizient anzuwenden. Es erfordert einigen Sachverstand und Erfahrung, die Auszeichnungen trotz hochkomplexer CSS-Anwendung sauber und allgemein zu halten. Das kommt mit der Zeit, wenngleich das Grundproblem bleibt. Es lässt sich wohl feststellen, dass niemand in der Frage den Stein der Weisen gefunden hat.

Mathias

[Gunther]

Hallo Mathias,

auch wenn ich häufig mit deiner Meinung & deinen Ansichten übereinstimme, so muss ich dir hier doch ein wenig widersprechen.

Idealerweise verwendet man weder das eine noch das andere. Das Markup zu ändern, um ein bestimmtes Layout verwirklichen zu können, ist schlecht und sollte nur als allerletzte Möglichkeit gesehen werden.

Mal allgemein: Das ist glaube ich die Lebenslüge der CSS-Layout-Freunde. »Idealerweise« trifft es genau.

Das sind nicht die "CSS-Layout-Freunde", sondern wenn überhaupt die "Puristen", bzw. die "Minimalisten".

Wenn man ein komplexes Layout nach den Regeln der Kunst baut, braucht man oft sehr viele Angriffspunkte für Styles im Markup. Das führt dazu, dass man divs und spans einfügt, die größtenteils strukturell keinen Sinn ergeben.

Hier ist schon der erste entscheidende Punkt: Man muss differenzieren zwischen Elementen, die für die Umsetzung eines Layouts zwingend erforderlich/ notwendig sind, und solchen, die der Autor aus Unkenntnis überflüssigerweise einfügt.

Mit semantischem Code haben sie daher nichts zu tun, ich bezeichne sie gerne als Präsentationsgliederungen. Sie strukturieren den Inhalt nur in der Hinsicht, später im CSS adressierbar zu sein. Vor allem werden sie für ein bestimmtes Layout eingefügt, damit werden Markup und Stylesheet verschränkt, anstatt dass sie unabhängig voneinander bleiben und das Stylesheet ohne Änderung am Markup auswechselbar ist.

Was kann an einem DIV-Element nicht semantisch sein? Auszug aus SELFHTML Allgemeines Block-Element:"Dieses allgemeine Element bewirkt nichts weiter als dass es in einer neuen Zeile des Fließtextes beginnt. Ansonsten hat es keine Eigenschaften. Es ist dazu gedacht, um mit Hilfe von nach unten CSS formatiert zu werden."
Wo, wenn nicht im Markup sollen denn sonst die per CSS zu strukturierenden Elemente stehen?

Die vielgelobte Trennung von Textauszeichnung und Präsentationslogik ist damit Makulatur.

Wer lobt die? Geht es nicht vielmehr um die Trennung von Elementen und deren Auszeichnung? Die Präsentationslogik (wobei Logik hier imho schon der falsche Ausdruck ist) muss mangels fehlender Alternativen ja zwangsläufig im  Markup stehen. Ich glaube, dass man diesen Aspekt bei der Erfindung von CSS außer Acht gelassen hat. Ein weiterer kurzer Auszug aus SELFHTML Stylesheets (CSS):"Dieses Kapitel beschreibt die HTML-Ergänzungssprache der Cascading Stylesheets, mit der Sie HTML-Elemente exakt formatieren und positionieren können.". Die Betonung liegt klar auf "HTML-Elemente" - ergo: wo keine solchen sind, kann man mit CSS auch nichts machen. Hier fehlt also eher eine dritte Sprache, nämlich eine Layoutsprache. In Ermangelung einer solchen, wird also aktuell CSS (mit dazugehörigen HTML-Elementen) als "Ersatz-Krücke" benutzt. Scheinbar hat man ja auch beim W3C erkannt, dass sich nicht alle (An)Forderungen, die man so gerne an CSS stellt, mit den bisherigen Mitteln umsetzen lassen. Man denke nur etwa an das Multi-column layout Modul in CSS 3.

Es ist also nicht die »allerletzte Möglichkeit«, sondern leider Gang und Gäbe bei anspruchsvolleren Layouts. Die Frage ist also nicht, wie man komplett auf Präsentationsgliederungen im Markup verzichten kann, sondern wie man sie möglichst reduziert und abstrakt hält.

Wie bereits gesagt, glaube ich nicht, dass du eine "Präsentationsgliederung" aus dem Markup heraushalten kannst - aktuell jedenfalls nicht (und meiner Meinung nach auch in absehbarer Zukunft nicht).

Die Entwicklung hin zur div-Suppe sah man schon, als die ersten großen Sites auf CSS-Layout umstiegen. Heutige große Sites arbeiten meist mit CSS-Layout, aber von aufgeräumtem, semantischen Markup sind sie weit entfernt. Selbst der CSS Zen Garden hatte damals gezeigt: Jedes beliebige anspruchsvolle CSS-Layout mit demselben Code umsetzen geht nur, wenn dieser voll von Präsentationsgliederungen ist, die Bereiche bloß markieren, damit Style-Regeln greifen können. Sicherlich ist das nicht einem prinzipiellen Problem zuzuschreiben, in der Regel lassen sich Optimierungen vornehmen, man denke an den Focus-Redesign.

Wo ist eigentlich das Problem? DIV sind sinnentleerte Elemente, die der Präsentationsgliederung dienen. Zehn DIVs mehr oder weniger in einem HTML-Dokument tuen doch keinem weh (solange die Standardkonformität gewahrt bleibt). Der normale User interessiert sich doch wohl auch eher für die ihm präsentierten Inhalte, als für das Markup einer Seite. Wenn aber dadurch erreicht werden kann, dass die Inhalte auf den verschiedensten Ausgabemedien jeweils möglichst optimal dargestellt/ rübergebracht werden können, ist imho das eigentliche Ziel erreicht.

Es lässt sich wohl feststellen, dass niemand in der Frage den Stein der Weisen gefunden hat.

Stein der ... wer oder was? Ja gibt's denn sowas? ;-)

Gruß Gunther

[Timo "God's Boss" Reitz]

Mal allgemein: Das ist glaube ich die Lebenslüge der CSS-Layout-Freunde. »Idealerweise« trifft es genau.
Das sind nicht die "CSS-Layout-Freunde", sondern wenn überhaupt die "Puristen", bzw. die "Minimalisten".

Nein. Die "Puristen" oder "Minimalisten" würden auf Layout-Möglichkeiten verzichten, um dafür ihr semantisches Markup exakt so zu erhalten, wie es geschrieben war (also ohne an das Layout zu denken).
Erst "eine Stufe Purismus weniger" würde das Ändern des Markups überhaupt erlauben.

Was kann an einem DIV-Element nicht semantisch sein? Auszug aus SELFHTML Allgemeines Block-Element:"Dieses allgemeine Element bewirkt nichts weiter als dass es in einer neuen Zeile des Fließtextes beginnt. Ansonsten hat es keine Eigenschaften. Es ist dazu gedacht, um mit Hilfe von nach unten CSS formatiert zu werden."

Hier irrt SelfHTML bzw. ist ungenau. Es ist richtig, dass div-Elemente (auch span) in großer Zahl eingesetzt werden, um später von CSS und JavaScript genutzt zu werden. Das ist aber nicht der eigentliche Zweck, denn div und span haben in HTML eine genau definierte Aufgabe: Sie bieten eine generische Möglichkeit, Struktur in HTML-Dokumente zu bringen. Das hat mit CSS und JavaScript noch nichts zu tun.
Einfach gesagt: Wenn man ein Element benötigt, aber kein anderes passendes Element findet, dann nimmt man div (im Block-Kontext) bzw. span (im Inline-Kontext).

…
Hier fehlt also eher eine dritte Sprache, nämlich eine Layoutsprache. In Ermangelung einer solchen, wird also aktuell CSS (mit dazugehörigen HTML-Elementen) als "Ersatz-Krücke" benutzt.
…

Ich denke nicht, dass eine solche fehlt, sondern dass sie lediglich mangelhaft unterstützt wird. Stellt nicht XSL-FO eine solche Layoutsprache dar? Man könnte es vielleicht auch ganz anders herum sehen: (X)HTML zeichnet ja lediglich die *Struktur* von Inhalt aus, nicht die tatsächliche *Bedeutung*. Man könnte sich also Sprachen vorstellen (beispielsweise XML-Sprachen), die etwas solches leisten und per XSL-Transformation in XHTML umgewandelt werden. Damit wäre XHTML genau die Sprache, die du meinst.
Und ich habe gleich noch einen: Was ist Mozilla-Software und ihrer XML Binding Language? Diese bietet die Möglichkeit, per CSS ein bestimmtes, mittels JavaScript und einigen XML-Sprachen (XUL, XHTML beispielsweise) definiertes Verhalten an Elemente zu binden.
Vielleicht sind die Möglichkeiten schon längst da, nur noch nicht ausreichend standardisiert und implementiert?

Wie bereits gesagt, glaube ich nicht, dass du eine "Präsentationsgliederung" aus dem Markup heraushalten kannst - aktuell jedenfalls nicht (und meiner Meinung nach auch in absehbarer Zukunft nicht).

Das ist wohl leider wahr.

[molily]

Hallo,

Was kann an einem DIV-Element nicht semantisch sein?

Geschickte Argumentation: Es hat keine Bedeutung, damit steht es neutral abseits der Semantik-Diskussion und man kann es einsetzen, wie man will, aus der Warte lässt es sich einfach nicht bewerten.

Klingt logisch, glaube ich aber nicht. Wie alle Elemente sind div und span zur Strukturierung geeignet. Wenn ich z.B. um Navigation ein div lege und um den Hauptinhalt auch, dann habe ich einen Elementbaum, der die innere Struktur des Dokuments wiedergibt. Diese divs haben eine Bedeutung. Dasselbe gilt für viele divs mit Klassen, die wirklich die Struktur des Textes sichtbar machen und deren Verfasstheit herausarbeiten. Für <span class="..."> gilt ähnliches. Dahinter steckt ein Dokumentmodell: Elemente organisieren Informationen in einem hierarchischen Baum.

Das Eigentümliche an den Präsentationsgliederungen ist nun, dass sie nun Strukturierungen vornehmen, wo das Dokument selbst keine solche Struktur hergibt und es auch keinen Sinn macht, eine solche Strukturierung vorzunehmen (außer eben für Zwecke der einen bestimmten Präsentation). Dadurch wird der Elementenbaum nur komplexer, aber nicht strukturierter/bedeutungsvoller.

<div class="a"><ul class="b"><li><div class="c"><h2 class="d"><span class="e"><a href=""><span class="f">...

Die vielgelobte Trennung von Textauszeichnung und Präsentationslogik ist damit Makulatur.

Wer lobt die?

Die gesamte Webstandards-Maschinerie, wie sie sich gegen Tabellen und für CSS-Layout eingesetzt hat, beruht auf diesem Modell.

Geht es nicht vielmehr um die Trennung von Elementen und deren Auszeichnung?

Äh... häh?

Die Präsentationslogik (wobei Logik hier imho schon der falsche Ausdruck ist) muss mangels fehlender Alternativen ja zwangsläufig im  Markup stehen.

Der Theorie nach zeichnet HTML Texte gemäß deren Struktur aus, Überschriften als solche, Absätze, Listen, Tabellen, Hyperlinks, Abschnitte usw. Dabei ist das Schaffen von Angriffspunkten für ein Stylesheet erst einmal ausgeklammert.

Die Betonung liegt klar auf "HTML-Elemente" - ergo: wo keine solchen sind, kann man mit CSS auch nichts machen. Hier fehlt also eher eine dritte Sprache, nämlich eine Layoutsprache. In Ermangelung einer solchen, wird also aktuell CSS (mit dazugehörigen HTML-Elementen) als "Ersatz-Krücke" benutzt. Scheinbar hat man ja auch beim W3C erkannt, dass sich nicht alle (An)Forderungen, die man so gerne an CSS stellt, mit den bisherigen Mitteln umsetzen lassen. Man denke nur etwa an das Multi-column layout Modul in CSS 3.

Die Überlegungen kann ich nicht nachvollziehen, inwiefern ist dieses Modul etwas neues? Es bezieht sich auch immer nur auf die Darstellung von bereits bestehenden HTML-Strukturen.

Wo ist eigentlich das Problem? DIV sind sinnentleerte Elemente, die der Präsentationsgliederung dienen.

Sie durchkreuzen die Idee von HTML als ausgabeunabhängiger Auszeichnungssprache, bei der man die bestehende Dokumentstruktur möglichst adäquat auszeichnet. Informationen werden mehrfach in Container verschachtelt, ohne dass das irgendetwas über die Informationen aussagt. Die folgenden Praxisprobleme sind weitesgehend eine Folge der Nicht-Verwirklichung dieses Anspruchs.

Der normale User interessiert sich doch wohl auch eher für die ihm präsentierten Inhalte, als für das Markup einer Seite.

Das versteht sich von selbst, es ging in der Ausgangsfrage auch wohl eher um die Konsequenzen für das Webauthoring.

Mathias

[Timo "God's Boss" Reitz]

Mal allgemein: Das ist glaube ich die Lebenslüge der CSS-Layout-Freunde. »Idealerweise« trifft es genau.

Naja, "Lebenslüge" ist wohl zuviel gesagt. Diese Vorgehensweise dürfte ziemlich sauberen Code hervorrufen, wenn nicht sogar den saubersten Code.

Wenn man ein komplexes Layout nach den Regeln der Kunst baut, braucht man oft sehr viele Angriffspunkte für Styles im Markup.

An dieser Stelle möchte ich bereits einhaken, denn was ist ein "komplexes Layout nach den Regeln der Kunst"? Klar ist, dass CSS einige Mängel hat, noch schlimmer wiegen die Mängel der allgemein verfügbaren Implementationen, die dazu führen, dass man nur einen Teil (sinnvoll) benutzen kann.

Das führt dazu, dass man divs und spans einfügt, die größtenteils strukturell keinen Sinn ergeben. Mit semantischem Code haben sie daher nichts zu tun, ich bezeichne sie gerne als Präsentationsgliederungen. Sie strukturieren den Inhalt nur in der Hinsicht, später im CSS adressierbar zu sein. Vor allem werden sie für ein bestimmtes Layout eingefügt, damit werden Markup und Stylesheet verschränkt, anstatt dass sie unabhängig voneinander bleiben und das Stylesheet ohne Änderung am Markup auswechselbar ist. Die vielgelobte Trennung von Textauszeichnung und Präsentationslogik ist damit Makulatur.

Alternativ könnte man sich bei dem Layout einschränken und stattdessen versuchen, jedem Client ein bestmögliches Layout zukommen zu lassen.

(der Rest)

Die Frage ist doch wohl, was einem wichtiger ist: Ein "komplexes, anspruchsvolles" Layout oder ein etwas weniger gewaltiges Layout und dafür komplett sauberes Markup.

[molily]

Hallo,

Die Frage ist doch wohl, was einem wichtiger ist: Ein "komplexes, anspruchsvolles" Layout oder ein etwas weniger gewaltiges Layout und dafür komplett sauberes Markup.

Eben. Die Frage beantwortet sich für 99% der Webautoren von selbst. Wieso aus technischen Gründen, die in der Praxis nun einmal weniger wichtig sind, Zugeständnisse machen? Es ist doch illusorisch und abgehoben, die Technik die Ansprüche bestimmen zu lassen. Unverhältnismäßig viele divs und spans schränken den Autor ein, aber sie schränken weniger den Seitenbesucher ein, als der Verzicht auf sie mittels einer einfacheren Gestaltung.

Mathias

[Detlef G.]

Hallo Markus

Beim erstellen eines HTML Gerüsts ist mir aufgefallen, dass ich trotz mancher Kniffe eine Menge div-Elemente brauche, allein um beispielsweise Bildabschnitte um bestimmten Text 'herumzuwickeln'. Zusammen mit dem CSS ergibt sich dadurch eine weit größere Dateigröße als wenn ich das Gerüst mit Tabellen erstellen würde.

Ist das Layout vielleicht als Tabellenlayout konzipiert, und du versuchst den grundsätzlichen Tabellenaufbau mit Div und CSS nachzubilden?

"Bildabschnitte um bestimmten Text 'herumzuwickeln'" klingt für mich nach der typischen Herangehensweise bei Tabellenlayout, viele Teilgrafiken in vielen einzelnen Tabellenzellen um den Text herum anzuordnen.
Bei einem CSS-Layout werden eher größere Grafiken als Hintergrund der bestehenden Elemente verwendet, bei flexiblen Elementgrößen kombiniert mit wenigen Teilgrafiken die sich durch Überlagerung (nicht durch Anneinanderreihung) ergänzen. Weil CSS leider weder die Möglichkeit bietet, einem Element mehrere Hintergrundgrafiken noch ihm Bordergrafiken zuzuweisen, kommt es vor, dass sich nicht ausreichend Elemente dazu finden und _wenige_ zusätzliche Elemente notwendig sind.

Dabei ist es wichtig, nicht vom Layout zum Inhalt zu denken und zu arbeiten, sondern genau andersherum. Erst, wenn der entsprechend logisch strukturierte (X)HTML-Inhalt vorliegt, können die dann vorhandenen Elemente mittels CSS formatiert werden und erst dann lässt sich zuverlässig erkennen, wo wirklich noch zusätzliche Elemente erforderlich sind.
Ein schönes Beispiel dazu ist z.B. eine Seitennavigation. Diese als Anneinanderreihung von Links erfordert meist zusätzliche sinnleere Elemente, um sie ansprechend zu formatieren. Wird diese aber als Liste von Links (was sie ja auch ist) im (X)HTML notiert, stehen bereits mehrere beliebig formatierbarer Elemente zur Verfügung, ein Container für die Navigation (ul) und jeweils zwei Container für jeden Link (li und a).

Dadurch bin ich auf die Titelfrage gekommen. Tabellen sind natürlich nur für tabellarische Daten gedacht, das ist mir klar. Aber wenn ich mit einer großen Tabelle, in der effektiv nur 3 übereinandergelegene Zellen genutzt werden, arbeite, ist dies dann nicht einer Divsuppe vorzuziehen?

Ist wirklich eine Divsuppe erforderlich oder bei einer optimalen Auszeichnung und Formatierung vorhandener Elemente nur wenige zusätzliche Elemente?
Lässt sich ein entsprechendes Layout mit vertretbarem Aufwand wirklich nur als Tabelle umsetzen oder eventuell nur deshalb, weil du noch in Tabellen denkst, und diese versuchst durch Divs nachzubilden?

Auf Wiederlesen
Detlef