DECAF° blog für digitale kommunikation
21Man spricht von »Divitis«, wenn eine Webseite aus übermäßig vielen <div></div>-Elementen besteht (und/oder: divs statt sinnvoller HTML-Elemente verwendet). Divitis ist unter webstandardisierten Autoren verhasst, man meidet sie wie die Pest.
Neulich im XING-Forum »Webdesign und Usability« hatten wir eine lange Diskussion zum Thema, und weil ich gerade bei xwolf einen weiteren Beitrag über »Extrem-Divitis« gelesen habe (vermutlich berechtigt, aber siehe nachfolgenden Punkt 4), nehme ich das mal zum Anlass, ein paar von den divs zu zerpflücken. Hier die Thesen:
Sowas wie Thesen
- Divitis ist niemals richtig böse, sondern allenfalls störend.
- Divitis ist browserbedingt (Box-Model) sehr weit verbreitet und in vielen Fällen sinnvoll/nachvollziehbar (Stichwort auch: YAML).
- Divitis kann bei großen Projekten sehr heilsam sein (Erweiterbarkeit).
- Divitis kann nur dann richtig prognostiziert werden, wenn die Frontendstruktur vollständig bekannt ist. Ein erster und zweiter Blick reichen dafür selten aus.
Ich brauche Code.
Divitis oder nicht?
<div id="a" class="..">
<div id="b1">
<div class="c">
<div class="d1">
<div class="e">
<p>Hallo Welt!</p>
</div><!-- e -->
</div><!-- d1 -->
<div class="d2">
..
</div><!-- d2 -->
</div><!-- c -->
</div><!-- b1 -->
<div id="b2">
..
</div><!-- b2 -->
</div><!-- a -->
Auf den ersten Blick: verdammt, ja!
Auf den zweiten Blick: vermutlich, ja.
Wenn man aber die (beispielhaft ausgedachte) Frontend-Struktur kennt und von innen nach außen geht:
- .e hält den eigentlichen Content auf Abstand, wenn es kein pixelbasiertes Layout ist und dementsprechend die Ausmaße von Inhaltsbereichen nicht bekannt sind
- .d1 und .d2 bilden zwei Spalten
- .c ist umschließender Wrapper und nötig, um floats aufzuheben und den Abstand nach unten zu schaffen
- #b1 und #b2 gruppieren den ganzen Kram und agieren als Elternelement für Styleangaben, die von oben »durchgegeben« werden, nämlich von..
- #a, das dynamisch seine Klasse verändern kann, um z.B. wahlweise #b1 oder #b2 auszublenden oder zu verändern
Auf den dritten Blick ist also jedes einzelne dieser divs notwendig, um Layout und Funktionalität abzubilden. Und das Beispiel war noch harmlos, denn obiges Gebilde könnte allein der kleine Inhalt von nur einer Spalte oder eines Inhaltsbereichs sein. Und er hat nichtmal abgerundete Ecken. Denken wir uns einen flotten Dreispalter drumrum, und wir könnten locker 238-503 divs draus machen, die allsamt irgendwie notwendig sind.
Klar,
natürlich sollte man jedes überflüssige <div></div> vermeiden. Aber es ist oft nicht einfach, zu erkennen, wann ein <div></div> wirklich überflüssig ist. Für Außenstehende mag deshalb die Regel gelten:
Man spricht nicht über Krankheiten.
Und um mal wieder positiv aus dieser Nummer rauszukommen, gibt’s auch eine Empfehlung für Webautoren:
Benutze kein div, wenn ein anderes Element sinnvoller wäre und vermeide jedes div, das nicht notwendig ist.
Irgendwie geht’s doch wieder nur ums Bauchgefühl.
Kommentar hinterlassen // RSS-Feed mit Kommentaren zu diesem Beitrag
21 Kommentare
1
Björn Seibert
Hallo Dirk, mich stört oft, dass manche vorschnell von Divitis sprechen, nur weil auf den ersten Blick sehr viele DIVs verwendet werden. Um das zu beurteilen, muss man sich das Ganze genau ansehen.
Es kommt oft auf das umzusetzende Screendesign an. Wenn z.B. Projektmanagement & Co. Designs mit vielen “runden Ecken” abnicken, bereitet das uns Webdesignern viel Kopfzerbrechen und macht mehr Arbeit.
Da es sich bei vorgegebenen Screendesigns aber schlicht um konkrete Anforderungen an das Webdesign handelt, muss man sich damit arrangieren. Die Anforderung ist dann erfüllt, wenn das Screendesign auf HTML/CSS übertragen ist. Die technische Qualität ist (u.v.a.) dann gut, wenn man es geschafft hat, unter den gegebenen Voraussetzungen, mit möglichst wenigen DIVs auszukommen.
Grundregel: Wenn zur Verfügung, dann immer passende bzw. sinnvolle Elemente nutzen und entsprechend stylen. Schon die Beachtung dieser einen Grundregel, sollte den Ausbruch einer Divitis verhindern. Der Rest ist anforderungs- oder browserbedingt.
2
Heiko Eckert
Danke Björn, denn ich hab mich gerade schon panisch gefragt wie man dann runde Ecken und ähnliches realisieren könnten soll… :)
3
Micha
allerdings könnte man im Zeitalter des rehabilitierten Javascript die Divitis auch verschweigen und einfach dem Client ein wenig Arbeit aufhalsen
Mir stellt sich bei der aktuellen W3C Entwicklung die Frage warum man nicht einfach via CSS z.B. dem <h1> Element alle gewünschten Attribute unterjubelt. Die diversen nicht semantischen Spielereien (Divitis ist ja nur eine davon) sind wie Quacksalber die das Problem nicht wirklich heilen.
4
Tom
Zu welchem ursprünglichen Zweck wurde das DIV eigentlich erschaffen?
Wird es nicht zu 90% zweckentfremdet?
5
Tom K.
Leider wird allzu oft vergessen, daß man auch semantischeren HTML-Tags als <div> und <span> per CSS ein Styling verpassen kann. Und genau an den Stellen tritt in meinen Augen, eine „echte Divitis” auf.
Folgendes klitzekleine Beispiel, wie man es häufiger finden dürfte:
<div id="menue">
<ul>
<li>Menuepunkt 1</li>
<li>Menuepinkt 2</li>
</ul>
</div>
Warum nicht einfach <ul id=”menue”> schreiben? Das <div> ist hier überflüssig.
Nun kommt bestimmt wieder der Hinweis auf die „runden Ecken”, aber dafür kann man ebenfalls erst mal den vorhandenen Tags einzelne Klassen zuweisen um den gewünschten Effekt zu erhalten. Allein die kleine Beispielliste enthält 3 stylebare Elemente…
6
Christian Pfeil
Hallo,
sorry aber sei mir bitte nicht böse wenn ich das jetzt sage, aber ich werde manchmal das Gefühl nicht los das eine Wissenschaft aus Themen gemacht werden die völlig banal und uninteressant sind.
Was ist an verschachtelten DIV Elementen so interessant das man dafür gleich ein Wort kreieren muss? Ich finde es spricht in der Informationsarchitektur nichts gegen eine endlose Verschachtelung von DIV Elementen (genau wie bei XML Knoten) wenn man sie logisch begründen kann und die Verschachtelung ihren Zweck erfüllt.
Solche Diskussionen (und man nehme es mir bitte nicht übel) tagge ich unter “der übliche web 2.0 quatsch”.
Aber gut das wir drüber geredet haben ;-)
Grüße Christian
7
Dirk Schürjohann (Autor)
(Entschuldigt, dass ich nicht auf alle Kommentare eingehe, bin etwas im Zeitdruck.)
Tom K.: Meiner Meinung nach macht es einen Unterschied, ob du die ul-Liste direkt ansprichst, oder ob du mit einem umschließenden Container arbeitest. Das ist nämlich immer genau dann relevant, wenn die Liste in einem Kontext, und nicht alleine, steht. Das sollte man im Vorfeld bedenken, und ich empfehle immer, solche Strukturen (sprich: ein zusätzliches div) schon frühzeitig anzulegen, wenn absehbar ist, dass sich der Kontext mal verändern könnte -> Punkt 3, Erweiterbarkeit.
Zur Erklärung vielleicht mal folgende Situation: dein ul-Liste soll als Hauptnavigation fungieren und erhält die ID #navigation. Es gibt Ankerlinks, die auf diese Navigation springen. Jetzt ändern sich die Anforderungen: »Wir möchten eine Überschrift über der Navigation haben, und unter der Navigation soll noch ein Teaserblock für unser neues Produkt eingesetzt werden.« -> Plötzlich hat die ehemals alleine stehende Liste einen Kontext, und es ist sinnvoll, diesen auch zwecks Positionierung und Außenabständen gemeinsam zu erfassen. Spätestens jetzt wird das umschließende div notwendig, das zudem die ID #navigation erhält, um die neue Überschrift über die Sprungmarken mit einzubeziehen.
Der neue Code wäre also: <div id=”navigation”><h3>..</h3><ul class=”navigation”>..
Immer dann also, wenn ein unmittelbarer Kontext wichtig sein/werden könnte, sollte man nicht mehr alleine nur mit inneren Elementen (in diesem Fall die Liste) arbeiten, sondern möglichst direkt auch äußere Elemente (in diesem Fall das div) mit einbeziehen.
Christian: Ich hatte nicht die Absicht, eine Wissenschaft aus dem Thema zu machen. Ganz im Gegenteil: ich wollte eigentlich genau darauf hinaus, das Thema »Divits« (das Wort wurde seinerzeit übrigens von Zeldman angestoßen) nicht so verklemmt zu sehen, sondern viel mehr aus dem Bauch heraus zu entscheiden und gerne mal gegen (Pseudo-)Regeln zu arbeiten, wenn es sinnvoll erscheint. Ich sehe es genau wie du, dass nichts gegen eine tiefe Verschachtelung von divs spricht, wenn sie ihren Zweck erfüllen.
8
Jens Grochtdreis
Danke für diesen Beitrag. Ich gebe Dir zu hundert Prozent Recht!
9
Björn
@Dirk: Gut, dass Du nochmal auf die Erweiterbarkeit eingehst und ein Beispiel bringst. Genau so einen Fall hatten wir zuletzt beim Branding einer Webanwendung, als konkrete Kundenanfiorderungen sogar einen kleinen Umbau erforderten. Der Code erschien uns bis dahin optimal, nur hatten wir eben diesen Punkt an der speziellen Stelle nicht berücksichtigt.
Zukünftig wird dieses Thema im Styleguide im Hiblick auf Brandings entsprechend berücksichtigt und der Code für bestimmte Componenten entsprechend angepasst bzw. “divitisiert” :-)
10
Gerhard
Ihr diskutiert ernsthaft über mehrere Seiten darüber ob man eine Tabelle als Tabelle auszeichnen oder doch lieber mit zahlreichen ineinander verschachtelten und inhaltlich völlig bedeutungslosen Divisionen umsetzen sollte? Da scheinen sich ja mal wieder mächtig kompetente Menschen mit deutlich zu viel Zeit bei XING versammelt zu haben.
11
Christian Pfeil
Meine Rede Gerhard ;-)
Jetzt noch schnell die Fakten in einer PowerPoint Präsentation zusammenfassen und ab zum nächsten Webmontag. Natürlich spielt die Semantik von Elementen eine immer wichtigere Rolle, aber das man dazu solch eine Diskussion anstößt verstehe ich nicht.
Grüße Christian
12
Dirk Schürjohann (Autor)
Björn, danke für den Einwurf! Du beschreibst genau das, worum es geht.
Gerhard, du hast aber schon bis zum Ende gelesen, oder? Die Anfangsdiskussion um die Tabellen-Geschichte ist an dieser Stelle nicht wichtig, sondern war nur der Auslöser für die tpyische Divitis-Kritik, die widerum für mich der Auslöser war, diesen Artikel hier zu schreiben.
Christian: Webmontag? Gibt’s da denn leckeren Kaffee? ;) – Vielleicht nochmal kurz als Beweggrund, ohne dich nerven zu wollen: ich halte das Thema für beinahe abartig wichtig, denn es betrifft in den meisten Fällen die Grundstruktur der Website. Und wenn man mal davon ausgeht, dass ein Großteil aller Redesigns – vor allem großer Websites – allein deshalb stattfindet, weil die Basisstruktur neue Prozesse nicht abdecken und/oder die aufkommenden Anforderungen nicht bestehen kann, dann kann man erahnen, dass eine saubere und durchdachte Basis der Grundstein einer guten Website ist. Frameworks wie YAML zielen z.B. genau darauf ab: flexibel und »sicher« genug zu sein, um mit allen Inhalten bestehen zu können. Und Kritik in Form von »Divitis« macht nunmal in vielen Fällen das Gegenteil: nicht zu erkennen, wie wichtig eine Struktur ist.
13
mike
Das ist jetzt mal eine interessante Wendung der Diskussion. Wie weit soll man denn gehen, wenn man “neue Prozesse abdecken” möchte? Mal blöd+rhetorisch gefragt: Um jedes Element 4 Divs rumpfriemeln, weil man ja eventuell irgendwann “abgerundete Ecken” reinhaben wollen könnte? Und noch eins drum, um ‘nen Float zu setzen? Oder ist das schon übertrieben und wir einigen uns drauf, dass nur Menüs in Divitis eingepackt werden sollen?
Ich weiss nicht Recht, bei gängigen absehbaren Kleinigkeiten mag das (Thema) ja angehen, für andere Sachen kann man das notwendige Element auch fürchterlich oldstyle nachträglich einbauen.
14
Dirk Schürjohann (Autor)
Mike, ich würde dir gerne noch antworten, bin aber jetzt für ein kleines Weilchen offline. Wird also nachgeholt!
15
Ulf
Bei großen Projekten die im CMS umgesetzt werden, kommt man oft über die oben genannte Struktur nicht hinweg. Anfangs hatte ich da auch oft Bauchscmerzen bie vielen DIV-Containern, mittlerweile sehe ich das aber auch gelassener. Guter Artikel!
16
Jutta
Hallo,
neulich begegnete ich einer anderen Diskussion, in der es darum ging, was besser sei: xhtml und css mit (einfachem Design aber dafür) viel Content oder Webseiten mit viel Schnickschnack für’s Auge. Ich muss gestehen, dass ich verwundert darüber war, dass einige wohl meinen, dass es hier wohl nur schwarz oder weiß gibt, da man doch wohl auch mit dem Boxmodel grafisch anprechende Seiten erstellen kann und dass das eine das andere nicht ausschließt. Allerdings kommt man dann eben nicht umhin manchmal ein div zu verwenden nur um z.B. ein zweites Hintergrundbild einzufügen. Die Divities-Krankheit hat auch mich schon so weit im Griff, dass ich das nicht ohne “schlechtes Gewissen” tue – aber ist es denn wirklich so schlechter Stil des Webdesigners, wenn einem die CSS-Möglichkeiten einfach keine andere Wahl lassen und wie schlimm ist das denn wirklich, wenn man mal den Nutzen vergleicht. Kunden möchten eine erfolgreiche Webseite und die wird nunmal nicht nur für Suchmaschinen geschrieben, sondern auch für die menschlichen Besucher. “Das Auge liest mit” – ein Satz, den ich auch in einem Forum aufgeschnappt habe und der es auf den Punkt bringt. Webseiten sollten zwar kein Werbeprospekt sein, aber sie beeinflussen dennoch nicht unwesentlich das Image desjenigen, der dahinter steht. Natürlich sollte man immer nach dem Motto “so viel wie nötig und so wenig wie möglich”arbeiten, aber ich gebe zu, dass mir im Zweifelsfall die Gestaltung wichtiger ist, zumal man das, denke ich auch mal relativ im Vergleich zu allen Methoden der Weberstellung sehen muss. Dadurch, dass man auf xhtml und Webstandards aufbaut, tut man ja schon einiges in Richtung “erfolgreiche Webseite” … was machen da ein paar divs zu viel wenn man sieht wie viele Seiten noch mit Frames arbeiten, Navigationen mit JS realsieren und den content in Flash stecken?
just my two cents ;-)
Jutt
17
Siegfried
Die Definition ist falsch. Nicht die Menge an divs macht die Divitis aus, sondern deren Verwendung. Im Extremfall könnte ein einziges div bereits Divitis sein, oder im anderen Extrem eine Seite mit hunderten divs völlig Divitis-frei sein.
Deine Argumentation, wozu die diversen divs in Deinem Beispiel da sein sollen, beziehen sich alle auf Präsentation: Die divs sind dazu da, um die Seite so und so aussehen zu lassen. Das ist Divitis. In semantisch korrektem html hat Markup, das nur der Präsentation dient, Nichts zu suchen. Präsentation gehört ins css. Und entgegen der Behauptung bei Wikipedia sind die beiden container div und spann erstens nicht völlig semantisch bedeutungslos und zweitens dazu da, per Attribute ihrem Inhalt eine in sehr weiten Grenzen anpassbare Bedeutung zu geben. _Alle_ html Elemente sind dazu da, ihrem Inhalt Bedeutung zu geben (na gut, bis auf die, die inzwischen als “deprecated” gelten). Also sind logischerweise auch div und span dazu da, ihrem Inhalt eine Bedeutung zu geben. Sie sind also nicht semantisch bedeutungslos. Die mindeste Bedeutung, die sie ganz ohne Attribute ihrem Inhalt geben, ist, sie gruppieren ihren Inhalt. Sie heben ihren Inhalt als Gruppe aus dem Rest heraus.
Also: Nicht die Menge an divs macht die Divitis, sondern deren unsemantische Verwendung zu reinen Präsentationszwecken.
Siehe auch: http://www.rorkvell.de/news/2007/ar0925T071541
18
Dirk Schürjohann (Autor)
Mike, zu deiner Frage, wie weit man gehen sollte, um flexibel genug für neue Prozesse zu sein: das hängt meiner Meinung nach vor allem vom unmittelbaren Kontext der Inhalte ab, die man bearbeitet. Eine absolut positionierte vertikale Navigation als ul-Liste, die definitiv keinen begleitenden Content erhält, benötigt sehr wahrscheinlich auch keinen umschließenden Container, sondern kann für sich alleine stehen. Steht diese Liste jedoch horizontal und floatend innerhalb eines Spaltensatzes, würde ich von Anfang an nicht mehr nur das Listenkonstrukt verwenden – auch wenn es für die Darstellung ausreichen sollte –, sondern würde je nach Kontext mindestens ein weiteres Element hinzunehmen, das als umschließender Container agiert, Abstände generieren und per Klasse oder ID angesprochen werden kann.
Viele Dinge lassen sich – wie du richtig sagst – natürlich nachrüsten, aber es macht einen großen Unterschied, ob man auf einer sicheren Basiskonstruktion nachrüsten muss, die YAML-like alle Arten von Inhalten verkraftet, und bei der sich bereits die äußeren Elemente direkt ansprechen lassen, oder ob man an ein Gebilde anstückeln muss, das zu wenig sichernde (äußere) Elemente enthält und schon beim Hinzufügen von Paddings auseinander fetzt, das nicht über sinnvolle Hierachien und Positionierungsmöglichkeiten für Inhaltsbereiche verfügt, und/oder dessen ungeschickte Vererbung von relativen Schriftgrößen dazu führt, dass beim Hinzufügen zusätzlicher Strukturen ungewollte Fitzelschriften entstehen.
Ulf und Jutta, danke für euer Feedback!
Siegfried, in der Theorie hört sich das alles Klasse an, aber du weißt selbst, dass wir in der Praxis weit davon entfernt sind, rein semantisches HTML schreiben zu können – wenn Präsentation in irgendeiner Form relevant ist. Und das ist sie. Nach deiner Definition – ich kann sie gut nachvollziehen – wäre Divitis eine echte Volkskrankheit, denn ein Großteil aller Websites wäre davon befallen; Es sei denn, du lässt ein mehrfaches Gruppieren von Inhaltsbereichen zum Zweck einer sauberen Positionierung als »Bedeutung geben« durchgehen – aber da du es nicht bei den abgerundeten Ecken tust, bin ich jetzt davon ausgegangen, dass du es auch nicht bei komplizierten Spalten- und Blocksätzen tust.
Die aktuellen Entwicklung von CSS arbeiten ja darauf hin, dass sich ein großer Haufen der heutigen divs vermeiden lassen wird, denn Spaltensatz, Floating und sogar abgerundete Ecken werden dann nicht mehr (so sehr) die HTML-Struktur betreffen — aber bis es soweit ist, halte ich eine gesunde Divitis für genauso wichtig wie die Maßnahme, dass man Kinder auch im Dreck spielen lassen soll ;)
19
Siegfried
Sagen wir’s mal so: Natürlich ist mir der Unterschied zwischen Theorie und Praxis bekannt. Natürlich ist mir bekannt, dass man, um bestimmte Kundenanforderungen zu befriedigen, oft auf unsemantische Krücken zurückgreifen muss. Das ändert aber Nichts daran, dass es unsemantische Krücken sind. Einerseits ist es bedauerlicherweise so, dass man Seiten nach der “reinen Lehre” kaum erstellen kann, andererseits wird diese “reine Lehre” dadurch nicht falsch, und es lohnt sich, so gut es geht, nach ihrer Verwirklichung zu streben. Man wird es nie 100% hinbekommen, aber wenn man aufhört, es zu versuchen, hat man verloren.
Und stimmt, css3 dürfte etliche dieser Krücken überflüssig machen. Hoffen wir, dass es bald umgesetzt wird.
20
Marius
Je weniger HTML Elemente im Quelltext vorkommen, desto einfacher ist es, das Layout so zu stylen, dass es auf den gängigen Browsern richtig angezeigt wird. Es gibt natürlich Ausnahmen, aber ich habe diese Erfahrung gemacht. Dazu gehört natürlich, divs zu vermeiden, so gut es geht. Außerdem ist der Quellcode wesentlich übersichtlicher, und man kann später, falls notwendig, Änderungen schnell und einfach vornehmen.
Meiner Meinung nach sollte man auch das Design abändern, falls die Umsetzung zu unsauber wird. Der Aufwand, um z.B. runde Ecken für eine variable Box zu erstellen, ist für mich zu groß. Es gibt genügend wunderschöne Designs, die auch ohne runde Ecken oder derartigen Schnickschnack auskommen. Sobald CSS3 verbreitet eingesetzt werden kann, sieht das wieder anders aus. Aber momentan ist eine Designanpassung in meinen Augen eine passable Lösung, um Frustration und aufgeblähtem Quellcode aus dem Weg zu gehen. Die Problematik besteht nur darin, welcher Designer kennt sich schon mit guten XHTML aus!
21
Dirk Schürjohann (Autor)
Marius, ich habe schon oft gegenteilige Erfahrungen gemacht und bin der Meinung, dass sich Inhalte in der Regel einfacher stylen lassen, wenn sie über ausreichend viele Auszeichnungselemente verfügen – oft mit der alleinigen Aufgabe, die Inhalte »abzusichern« –, und dass ein aufs nötigste ausgezeichneter Inhalt oftmals schwer erweiterbar sein kann (Beispiele wurden oben schon genannt).
Ich verstehe den Wunsch nach Semantik, sinnvollen und reduzierten Strukturen, und ich arbeite ebenso darauf hin, aber es geht in diesem Artikel genau darum, dass es nicht sinnvoll ist, allzu unbedacht zu reduzieren, und dass die Prognose der »Divitis« häufig falsch gestellt wird.
Möchte man eine Kosten-Nutzen-Rechnung aufstellen, halte ich sichere Strukturen innerhalb einer Website für brachial wertvoller als ein HTML, das möglichst wenige Auszeichnungselemente enthält. Denn das Ziel »Trennung von Inhalt und Form« kann nur dann ernsthaft aufgehen, wenn der Inhalt ausreichend viele Ansatzpunkte mitbringt, um Formen aufnehmen zu können.
Kommentar hinterlassen