Rezepte gegen die DIVterie

Rezepte gegen die DIVterie

Diphterie

Corynnbacterium Diphtheria (Foto: CDC).

Wir wissen ja schon lange, dass valides HTML noch kein gutes HTML ist. Kalter Kaffee. Sehen wir dabei einmal vom durchaus validem Tabellenlayout ab, sind die größten Feinde mangelnde semantische Auszeichnung und in deren Schlepptau immer wieder DIVterie, soll heissen: übermäßige Benutzung von DIV-Containern, wo andere Elemente angebrachter wären. Bekannte Nebenwirkung dieser Krankheit sind übrigens Klassizismus, IDologie und natürlich VerSPANnung.

Zugegeben: DIVterie ist durchaus verbreitet (ich selbst zeichne für eine Seite verantwortlich, die deutlich darunter leidet) und auch irgendwie ansteckend. Infiziert von einem CSS-Framework kann man sich schon mal anstecken. Dem begegnet HTML5 übrigens (demnächst), in dem ein ganzes Rudel semantisch bedeutungsvoller Block-Level-Elemente eingeführt werden, die demnächst so manches DIV ersetzen könnten. Das würde auch ein wenig gegen die Nebenwirkungen helfen, aber soweit sind wir wohl noch nicht.

Wo ist eigentlich das Problem

DIVterie kann man von zwei Seiten betrachten: zunächst einmal ist ein DIV im Zusammenhang ziemlich bedeutungslos, ein Container, in den man Sachen packt, von denen dann niemand weiss, zu was sie gehören und warum sie dort herumlungern. Das kann man manchmal sogar brauchen, meist wäre es aber sinnvoll, wenn man ein Element einsetzt, ihm auch eine Bedeutung zu verleihen. Ja, wenn man ein Element einsetzt. Denn man kann und muss DIVterie natürlich auch noch von einer anderen Warte aus beleuchten: zuviele DIVs, Klassen, IDs machen den Code fett, das HTML wächst krankhaft an, das zugehörige CSS gleich mit. Schwerer Code ist langsamer Code. Man mag das in Zeiten von Highspeed-DSL-Anschlüssen vernachlässigen wollen, aber im professionellen Umfeld kann man das nicht: die Menge an Code ist letztendlich so hoch, dass es auf jedes gesparte Zeichen ankommt.

Was tun?

Beiden Betrachtungsweisen begegnen wir mit einer einfachen Regel:

Prüfe zunächst, ob Du wirklich ein Element brauchst. Wenn Du Dir sicher bist, dass Du eines brauchst, prüfe alle Möglichkeiten kein DIV zu verwenden. Wenn all das nichts geholfen hat…

Das ist jetzt schwieriger, als es klingt. Hilfreich ist es übrigens, wenn man ein Bild von der Seite oder besser noch den Seiten, die man bauen will, hat. Nein, keinen Photoshop-Ausdruck, sondern eine Skizze, auf der man die benötigten Elemente (bspw. als Kästen) anordnet. Schon in dieser Phase lassen sich DIVs vermeiden. Wenn man einfach drauf loscodet ist man immer in Gefahr noch hier und da schnell noch einen Container drum zu ziehen, eine Klassen oder gar ID dranzuschreiben.

Ein Beispiel

Hier mal ein Codeschnipsel als schlechtes Beispiel, bitte nicht nachmachen:

[html light=“true“]
<div class="container clearfix">
<div class="teaser">
<img alt="Lorem ipsum dolor sit amet" title="Lorem ipsum dolor sit amet: velit esse cillum dolore" src="loremipsum.jpg" class="img_left" />
<h3 class="text"><a href="loremipsum.html" title="Lorem ipsum dolor sit amet"><span class="bold">Lorem ipsum:</span> Dolor sit amet</a></h3>
<div class="teasertext">Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.</div>
</div>
<div class="teaser">
<img alt="Lorem ipsum dolor sit amet" title="Lorem ipsum dolor sit amet: velit esse cillum dolore" src="loremipsum.jpg" class="img_left" />
<h3 class="text"><a href="loremipsum.html" title="Lorem ipsum dolor sit amet"><span class="bold">Lorem ipsum:</span> Dolor sit amet</a></h3>
<div class="teasertext">Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.</div>
</div>
</div>
[/html]

Dazu würde folgendes CSS passen (es passt auch in der Fehlerhaftigkeit, also bitte nicht als Vorlage verwenden):

[css light=“true“]
div.container {
border: 1px solid #000;
color: #000;
font-size: 12px;
margin: 0;
padding: 0;
}

.container .teaser {
margin: 10px;
}

img.img_left {
float: left;
margin: 0 10px 7px 0;
}

h3.text {
font-size: 14px;
font-weight: 400;
}

span.bold {
font-weight: 700 !important;
}

.container .teaser .teasertext {
font-size: 10px;
line-height: 14px;
}
[/css]

Geht so gar nicht! Geradezu klassisch übrigens, die Klasse „container“. Aber mal im Ernst: hier haben wir einen Container, der mehrere Text-Bild-Blöcke enthält, die den gleichen Aufbau haben. Und einen typischen Fall von DIVterie. Zunächst wäre zu überlegen, ob man nicht ein paar DIVs und ein paar Klassen loswerden kann. Möglicherweise so:

[html light=“true“]
<div class="container clearfix">
<div>
<img alt="Lorem ipsum dolor sit amet" title="Lorem ipsum dolor sit amet: velit esse cillum dolore" src="loremipsum.jpg" />
<h3><a href="loremipsum.html" title="Lorem ipsum dolor sit amet"><strong>Lorem ipsum:</strong> Dolor sit amet</a></h3>
<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.</p>
</div>
<div>
<img alt="Lorem ipsum dolor sit amet" title="Lorem ipsum dolor sit amet: velit esse cillum dolore" src="loremipsum.jpg" />
<h3><a href="loremipsum.html" title="Lorem ipsum dolor sit amet"><strong>Lorem ipsum:</strong> Dolor sit amet</a></h3>
<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.</p>
</div>
</div>
[/html]

Von oben nach unten: wenn wir davon ausgehen, dass der „Container“ gebraucht wird, bspw. weil die Teaser eine inhaltliche Einheit dartellen und ggf. mit einer border umschlossen werden sollen, dann fällt zunächst das <div class="teaser"> auf. Gäbe es keine anderen DIVs in dem Block, wäre die Klasse überflüssig. Ebenso scheinen alle Bilder die gleiche Klasse zu haben. Dann weg damit. Das <h3 class="text"> war ja schon ein netter Versuch, die Klasse allerdings ist überflüssig und ausserdem ist „text“ ein denkbar schlechter Klassenname. Weg bitte auch mit dem (zugegeben etwas konstruierten) <span class="bold">, dafür bitte <strong> verwenden. Ebenso falsch ist <div class="teasertext">, denn dort passt viel besser ein <p>. Das ist ja nun schon ein wenig kompakter, aber auch sinniger, wie ich finden muss. Alle Elemente sind immer noch voll per CSS ansprechbar und können genauso gestyled werden wie oben.

Passendes CSS sähe dann so aus:

[css light=“true“]
.container {
border: 1px solid #000;
color: #000;
font-size: 10px;
line-height: 14px;
}

.container div {
margin: 10px;
}

.container img {
float: left;
margin: 0 10px 7px 0;
}

.container h3 {
font-size: 14px;
font-weight: 400;
}
[/css]

Zur Erläuterung: Durch die bessere semantische Auszeichnung haben wir auch im CSS schon viel gewonnen. Ich mühe mich immer redlich eine Balance zwischen generellem und spezialisierten CSS-Anweisungen zu finden, es stellen sich also häufig Fragen wie: »sind vielleicht alle H3 auf der Seite gleich, oder nur das in dem Container?«. Das ist im zweiten CSS-Schnipsel besser umgesetzt. Eine Formatierung des <p> ist z.B. – vorrausgesetzt es wird an anderer Stelle nicht umformatiert – gar nicht nötig, da es schon die geschickt gewählten Eigenschaften des Containers erbt (zugegeben: man müsste sich ggf. noch um margin und padding kümmern). Ebenso sind die übertriebenen Klassenverkettungen (wie .container .teaser .teasertext) entfernt.

Das ist nun schon ganz guter Code, geht aber vielleicht auch noch besser. Eben schrieb ich, wir hätten es mit Container, der mehrere Text-Bild-Blöcke enthält, die den gleichen Aufbau haben zu tun. Klingt fast nach einer Liste von Text-Bild-Blöcken. Wenn man will, kann man sich also komplett aller DIVs entledigen:

[html light=“true“]
<ul class="teaserlist">
<li>
<img alt="Lorem ipsum dolor sit amet" title="Lorem ipsum dolor sit amet: velit esse cillum dolore" src="loremipsum.jpg" />
<h3><a href="loremipsum.html" title="Lorem ipsum dolor sit amet"><strong>Lorem ipsum:</strong> Dolor sit amet</a></h3>
<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.</p>
</li>
<li>
<img alt="Lorem ipsum dolor sit amet" title="Lorem ipsum dolor sit amet: velit esse cillum dolore" src="loremipsum.jpg" />
<h3><a href="loremipsum.html" title="Lorem ipsum dolor sit amet"><strong>Lorem ipsum:</strong> Dolor sit amet</a></h3>
<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.</p>
</li>
</ul>
[/html]

Das CSS dazu:

[css light=“true“]
.teaserlist {
border: 1px solid #000;
color: #000;
font-size: 10px;
line-height: 14px;
list-style: none;
margin: 0;
padding: 0;
}

.teaserlist li {
margin: 10px;
}

.teaserlist img {
float: left;
margin: 0 10px 7px 0;
}

.teaserlist h3 {
font-size: 14px;
font-weight: 400;
}
[/css]

Beim CSS ist der Gewinn nicht mehr so groß, aber dafür ist der HTML-Code semantisch ausgezeichnet und schlanker als der Ausgangscode. In meinen Augen besserer Code.

8 Gedanken zu „Rezepte gegen die DIVterie

  1. Vielen Dank für den schönen und informativen Artikel!
    Zwei Anmerkungen habe ich noch:

    1) Sobald nicht nur für eine Seite gecoded wird, sondern sich Muster einstellen, sei es CSS-Framework oder das Zen Template von Drupal, entsteht schon fast automatisch DIVterie. Hier ist sorgfältig abzuwägen zwischen schlanker Radneuerfindung und DIVidiertem, leicht übergewichtigem, aber wiederverwendbaren und gut stylebarem Code .

    2) Den letzten Schritt mit der Liste finde ich nicht wirklich „semantisch“. Vielleicht liegt es an meiner Ausbildung als Technischer Redakteur, dass ich mir unter „Liste“ klassischerweise eine Liste im Text vorstelle (im Printbereich idealerweise mit bullet points) und nicht als „Abfolge beliebiger Elemente“. Das Argument „2 Bytes pro Eintrag gespart“ lasse ich im Zeitalter des mobilen Browsens wieder gelten 😉

  2. Hi Gabriel, danke für die Anmerkungen. Mal sehen:

    1) Nein, nein und nochmals nein. 😉 Alles Ausrede! Hüstel.

    OK, ich geb’s zu, Templates machen die Sache nicht einfacher. Ich arbeite in der Regel mit XML-Daten, die mit XSL transformiert werden, das hat ungefähr den gleichen Effekt: entweder man behandelt jeden Fall gleich (und hat dann schnell einen Codeoverhead), oder man arbeitet mit vielen, schwierig zu wartenden Ausnahmen. Der Mittelweg ist entscheidend. Auch hier zählt aber einmal mehr: gute Planung führt zu besseren Lösungen, zu weniger Code. Das funktioniert btw auch besser als nachträgliches Aufräumen und Refactoring.

    2) bei uns heisst ein solcher Block „Teaser“ und ist tatsächlich der Liste näher als man denkt. Im CMS wird er bspw. (zumindest zur Zeit noch) als numerierte Liste repräsentiert. Solange es sich um eine Abfolge immer gleich gestrickter Blöcke handelt, sehe ich da schon eine Liste, auch ohne Bullets (die ja weniger mit der Semantik als mehr mit dem Layout zu tun haben).

  3. Hi,

    ich gebe Dir mit der DIVterie vollkommen recht. Viel zu oft werden einfach DIV-Tags anstelle von TD-Tags benutzt und so ein Tabellenloses Layout vorgegaukelt. Schaut man aber mal genauer hin, so ist das Code-Layout immer noch das gleiche Tabellenkonstrukt nur mit anderen Tags, ohne jegliche Semantik.

    Bei dem zweiten Punkt muss ich Gabriel beipflichten. Auch für mich als Webentwickler ist eine Liste eigentlich her eine Aufzählung (Navigationspunkte, etc.). Der Punkt, dass hier eine Liste besser ist, als das Konstrukt mit den (bereinigten) DIV-Layern, sehe ich nicht so. Zumal eine Liste standardmäßig mit Listenpunkten ausgestattet ist, die man dann per CSS deaktivieren müsste.

    Sieht man sich dann die Seite „nackt“ ohne CSS an, würde diese Listenpunkte wieder erscheinen. Bei einer Navigation macht das evtl. noch Sinn, aber hier sehe ich das nicht so.

    Da die Elemente in den einzelnen Blöcken identisch aussehen sollen, würde ich in diesem Beispiel die DIVs innerhalb des umgebenden Layers auch noch weglassen und stattdessen ein HR zum trennen einsetzen.

    http://pastie.org/476630

    Wie man es letztendlich macht ist auch ein gewisser Stil des Entwicklers. Viele Wege führen zu validem und auch semantisch korrektem Quellcode. Was dann semantisch korrekt ist, ist dann in vielen Fällen mehrdeutig.

    Toller Blog, mach weiter so,

    viele Grüße,
    Eddie

    Dann würde das Ganze auch wieder ohne CSS gut aussehen.

  4. Solange man von Null anfangen kann, ist es kein Problem, schlankes HTML/CSS zu bauen. Aber CMS müssen vielen möglichen Fällen gerecht werden und schleppen daher oft eine ganze Menge Ballast herum. Wobei nicht benötigte Container meist noch am einfachsten zu entfernen sind, wohingegen überzählige Klassen tendenziell in tieferen Schichten des Codes erzeugt werden und daher oft viel schwerer greifbar sind.

    Meine Erfahrung ist: Je eher ein System dem Themer erlaubt, modular und nah am Code zu arbeiten – ohne dabei zu tief in die Objektstruktur eintauchen zu müssen – desto leichter fällt es, schlanken, semantischen Code zu produzieren. WordPress z.B. bietet das, was sicher einen Teil seiner Beliebtheit ausmacht. Auf der anderen Seite des Spektrums: Je stärker ein System die Elemente über ein intuitives Interface zum Zusammenbau anbietet, desto mehr entsteht fast zwangsläufig wieder Ballast. Typolight ist ein gutes Beispiel für diesen Trade-Off. Allerdings kann der erfahrene Themer hier viele Voreinstellungen umgehen, jedoch geht damit auch wieder ein Stück intuitiver Bedienbarkeit für den Endkunden verloren. Drupal scheint sich zunehmend zu einer Mischung aus den Vorteilen beider Konzepte zu entwickeln, mit viel Interface zum intuitiven Bedienens einerseits und den Möglichkeiten des Template-Override andererseits. Noch ist es allerdings nur zu erahnen – derzeit ist es noch sehr mühsam, sich die notwendigen Bausteine jenseits des Standard zusammenzusuchen …

    Was die Listen angeht: Wenn ich die Semantikexperten richtig verstehe, ist jede Aufzählung gleichförmiger Bestandteile als Liste zu verstehen und sollte auch so verpackt werden, ob es nun ein Menu, eine Aufzählung im Text oder die Reihe der Linklisten in der Sidebar ist, und natürlich, wenn es sich nicht gleichzeitig um anderweitig semantisch belegte Elemente wie z.B. Textabsätze handelt. Allerdings baue ich die Voreinstellung eines CMS bspw. bei Teasern oder Kommentaren auch nicht unbedingt um – aber vielleicht sollte man ja?

    Interessant, @Eddie, dass Du das -Tag erwähnst. Das scheint mit CSS2 irgendwie in Misskredit geraten zu sein. Dabei ist es sehr nützlich, gerade im Hinblick auf den ungestylten Output, der durch -Tags an Übersichtlichkeit gewinnt. Und semantisch kann es doch gar nicht so falsch sein, zum Trennen von Bereichen ist es ja in den ganz alten HTML-Zeiten erfunden worden? Schade, dass man dazu fast nichts liest.

Die Kommentare sind geschloßen.

Die Kommentare sind geschloßen.