Appell für sauberes HTML

Ein neuer Tag, ein neues CSS-Framework und immer wieder das alte Problem:

<div id="page_wrap" class="container row">
 <header class="row span_12">
  <hgroup class="row span_12">
   <h1 class="col span_4">Site Title</h1>
   <h2 class="col span_8">Site Description</h2>

Fünf Elemente, zehn Klassen, eine ID? Diese netten Zusatzinformationen führen zu 193 statt 68 Zeichen. Ich weiß nicht, wer einmal beschlossen hat, Stylesheets vom Markup zu trennen. Und ich weiß auch nicht wie lange das her ist. Aber ich bin mir sicher: Das hat er oder sie sicher nicht gewollt.

Auch Style-Klassen sind Designinformationen…

… und haben im Markup nichts zu suchen. HTML hat im wesentlichen genau eine Aufgabe: Den Inhalt der Seite zu transportieren. Zudem können noch zusätzliche Informationen angegeben werden, etwa wo sich Dateien befinden, welche Scripts oder eben auch Stylesheets enthalten. Diese Dateien sind optional, es steht jedem zu sie wegzulassen.

Ein großer Teil von Website-Besuchern sind Bots, die solche Sachen in der Regel nicht interessiert. Trotzdem verdoppeln die meisten ihre HTML-Größe auf oben beschriebene Weise.

Fehlende Wiederverwendbarkeit von CSS

Auf den meisten Websites bestimmt also das HTML durch seine Klassen selbst, wie es dargestellt werden soll. Der Grund hierfür ist aus meiner Sicht der stark begrenzte Funktionsumfang von CSS: Es gibt keine Variablen, keine Vererbung und keine anderen Wiederverwendungstechniken. Sollen Header und Footer die selbe Hintergrundfarbe haben, muss diese für beide definiert werden. Das führt zu einer problematischen Code-Dopplung: Will man die Farbe ändern, muss man dies an zwei Stellen tun.

Viele Webdesigner und Framework-Schreiber versuchen daher, diese Eigenschaften, die für beide Elemente gleich sind, in eine neue Klasse auszulagern. Da CSS diese Klassenstyles aber nicht mit bestimmten Elementen verknüpfen kann, wird diese Information ins HTML ausgelagert. Auch wenn man es nicht immer direkt wahrnimmt: Solche Klassen sind ein direkter Teil von CSS.

Um dieses Problem abzuschwächen, gibt es viele interessante erweiterte Sprachen, die CSS erzeugen. Less ist sicher einer der prominentesten Vertreter, den ich aber meist in seiner PHP-Variante Less-PHP benutze.

Schlimmer geht immer: Wrapper-Elemente

Das obige Beispiel enthält mit <div id="page_wrap" class="container row"> ein noch viel schlimmeres Problem: Wrapper-Elemente. Typo 3 geht hier mit schlechtem Beispiel voran. Überschrift gefällig?

<div id="c304" class="csc-default">
 <div class="csc-header csc-header-n1">
  <h1 class="user class">Impressum</h1>
 </div>
</div>

Das sind 130 Zeichen Markup für neun Buchstaben. Und das ist durchaus üblich.

Meine Vorsätze für künftige Websites

  • Akzeptieren, dass eine Gruppe von Elementen nicht umrandet werden kann, wenn es an der Stelle kein Elternelement gibt. Meist ist dort kein Extra-Div, weil es dort nicht hingehört. Wenn es semantisch nicht zusammengehört, warum sollte man es optisch gruppieren?
  • Warum nicht mal Javascript? Wenn man es trotzdem nicht lassen kann, kann man die Wrapper doch einfach mit Javascript ergänzen. Auch das hält das ausgelieferte HTML rein.
  • Es geht auch semantisch: Klassen und IDs sind nichts schlechtes. Sie können Informationen über ein HTML-Element enthalten. Klassen wie article, comment oder author sind Metainformationen des Inhalts und somit legitimer Teil des Markups. Stylesheets sollten solche Informationen adressieren.
  • HTML-5-Elemente: Besser sind die vielen neuen HTML-5-Elemente, die solche semantischen Informationen bereits in sich tragen.
  • Alte Browser fallenlassen. Schluss mit Browserweichen und Zusatz-Wrappern.
  • Eine Weiche vielleicht doch: Für IE < 8 CSS und Javascript gleich ganz abschalten.

Ich träume von einer Welt, in der man Websites auch im Quelltext lesen kann…

6 Kommentare

  1. Pingback: Optimiert für Internet Explorer und Facebook – Sebastians Blog

  2. Moin,

    also ich bin auch dafür, dass Entwickler penibel sauberes HTML beziehungsweise XHTML schreiben sollten. Das Beispiel von TYPO3 ist schon ziemlich heftig für eine einfache Überschrift. Schlimm finde ich außerdem die Klassen-Namen. Aus denen lässt sich nur schwer erkennen, was sie bedeuten. Was sich hinter csc verbirgt, weiß ich als Nicht-TYPO3-Entwickler nicht.

    IDs und Klassen können semantisch sein. Mikroformate benutzen ja die Klassen, um den Inhalt des Elements semantisch zu kennzeichnen. Allerdings dienen Klassen in erster Linie dazu, Schnittstellen für CSS und JavaScript zu bieten. Klassen-Namen sollten Entwickler sinnvoll über die Aufgabe eines Elements informieren. Beispiel:
    <article class="post"></article>
    Entwickler, die sich noch nicht so sehr damit befasst haben, erkennen sofort, worum es sich handelt. Und wenn man diese Klassen-Namen kontinuierlich anwendet, dann ist der Code automatisch semantisch. Es ist auch nicht schlimm, wenn man mal ein Element mit der Klasse .clearfix verzieht. Also die Klassen-Namen können ruhig vom Inhalt unabhängig sein. Dadurch wird es nicht „unsemantisch“.

    Und wenn man einen Container um mehrere Elemente schließt, halte ich das auch nicht für schlimm, wenn es notwendig ist, wenn man beispielsweise einen grauen Hintergrund haben will und der zentrierte Inhalt einen weißen über die komplette Monitorbreite bekommen soll. Von dem Vorschlag, dieses Problem mit JavaScript zu lösen, halte ich nichts, denn das ist nicht die Aufgabe von JavaScript. Das erhöht die Ladezeit eventuell.

  3. Ich verstehe deine Argumentation nicht ganz. Sicher ist es nicht „schlimm“ wenn in einem Element eine Klasse clearfix steht, aber es ist eben schlechter Stil. Im Markup kein Design – ganz einfach. HTML und CSS können von zwei völlig verschiedenen Personen entwickelt werden und dein Designer wird dir schon was anderes erzählen, wenn du ihm da irgendwelche Sachen aufzwingst.

    Und was meinen JS-Ansatz betrifft: Doch, DOM-Manipulation ist genau die Aufgabe von Javascript. Und Ladezeiten kann man für sowas vernachlässigen. Aber wie gesagt: Das ist ohnehin eine Notlösung, am besten sollte man ohne auskommen.

  4. Ja, JavaScript hat die Aufgabe der DOM-Manipulation, allerdings nicht zu dem Zweck, ein bestimmtes Verhalten des Design herbeizuführen. Außerdem kann man die Ladezeit aus meiner Sicht nicht einfach vernachlässigen.

    Den Satz mit dem Designer verstehe ich nicht ganz – kannst Du ihn nochmal anders formulieren?

  5. Ich verstehe nicht, was du meinst. Wie gesagt, das ist eine Form der DOM-Manipulation: Ein Dokument nehmen und es anpassen. Das ist Javascripts Job, dafür ist es da. Wofür man solche Änderungen macht ist doch unerheblich. Es ist gängige Praxis JS zu nutzen, um z.B. das Design bestimmter Standard-HTML-Elemente umzubauen. Einfaches Beispiel: http://jqueryui.com/demos/button/ Du kannst es gern als falsch oder unsauber ansehen, aber es widerspricht doch nicht dem Zweck von JS.

    Ein Element mit JS in ein Dokument einzufügen ist eine zentrale Operation, die i.d.R. direkt in C implementiert ist und nicht viel mehr Aufwand kostet als wäre das Element direkt im HTML. Der Code dafür passt in eine Zeile. Wo siehst du hier also Probleme bei der Ladezeit? Wir leben in Zeiten von jQuery Mobile und vergleichbaren Vertretern, in so einer Umgebung kann man das wirklich vernachlässigen.

    Mit der Arbeitsteilung: Typischerweise ist es ja der Anwendungsentwickler, der das HTML schreibt (ggf. auch ein Redakteur, je nach Sichtweise). Das CSS kommt üblicherweise von einem Designer. HTML-Schreiber und Designer (im Sinne von grafischer Gestalter) können gerne zwei verschiedene Personen sein (darum geht es ja bei der Trennung von Inhalt und Design). Ich als Entwickler muss aber das Gebiet des Designers respektieren und eben nicht sagen, dass dieser Button groß zu sein hat. Ich kann sagen, dass ein Button ein Formular bestätigt, der andere abbricht. Ob jetzt aber einer davon größer oder andersfarbig oder was weiß ich zu sein hat, liegt ganz beim Designer.

    Du schreibst deinem Blog, Klassen können Hinweise für Entwickler enthalten. Tatsächlich bescheibst du aber auch Hinweise für Designer (button-BIG). Und hier liegt das Problem: Du mischt Inhalt und Design und ich denke dass es allgemein anerkannt ist, dass das als schlechte Praxis gilt.

    Wie gesagt, du hast ja recht, man kann reinschreiben was man will und das wird heute ja auch gern so gemacht. Ich finde das nur sehr unsauber.

  6. Auf meinem Blog habe ich nochmal einen Kommentar zu dem geschrieben, was nicht mit JavaScript zu tun hat.

    Hier möchte ich nochmal sagen, wieso ich nicht der Meinung bin, dass man JavaScript dazu verwenden sollte, nur um Elemente zu erzeugen, die ausschließlich fürs Design zuständig sind.

    JavaScript dient dazu, das DOM so zu manipulieren, dass die Website interaktiv genutzt werden kann. Das heißt Inhalte zu generieren oder nachzuladen.

    Wenn man mit Hilfe von JavaScript einen „künstlichen Mantel“ erzeugt, der dafür sorgt, dass die Seite anders aussieht, entspricht das nach meiner Meinung nicht den Zweck.

    Sowas halte ich unter anderem für einen schlechten Stil, weil ob man das Element nachträglich hinzufügt oder direkt im Markup einbindet, macht keinen Unterschied im endgültigen Quellcode.

Kommentare sind geschlossen.