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:

<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>

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

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;
}

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:

<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>

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:

.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;
}

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:

<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>

Das CSS dazu:

.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;
}

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.

www.youtube.com/watch?v=AmUPhEVWu_E

Via Roger Johansson:
Headings, heading hierarchy, and document outlines, ein absolutes must-read.

Simon Pieters schlägt einen Dreischritt vor:

1. Know what the DOM looks like and target other elements than the new elements for styling.
2. Use the universal selector (*) to target the right element.
3. Use noscript.

Dabei ist das Kernstück folgender CSS-Regeltrick: statt dieses schönen Konstruktes für Browser, die die Elemente stylen können…

article + header + h1 + p { font-weight:bold }

… schreibt man, speziell auf IE zugeschnitten…

body > * + * + h1 + p { font-weight:bold }

… ersetzt also die unbekannten Elemente durch den universellen Selektor. Naja…

Ggf. auftretende Nebenwirkungen lassen sich vermeiden, in dem man sowas in ein Stylesheet nur für IEs ohne Javascript packt (das ist allerdings lustig):

<head>
    <!--[if IE]>
        <noscript><link rel="stylesheet" href="ie-noscript.css"></noscript>
    <![endif]-->

Darauf muss man nun wieder erstmal kommen. Im ganzen ziemlich großer Aufwand noch, aber immerhin, eine Möglichkeit.

The above techniques might not be very scalable or might well impact maintanence, but the point of this article is to show that it is possible to use the new elements while still supporting IE with scripting disabled.

blog.whatwg.org

Mir reicht’s aber auch irgendwie: über drei Einträge hab ich nun Gründe gefunden, warum man HTML5 nicht einsetzen sollte – das wurmt mich ein wenig. Denn möglicherweise gibt es Gründe, warum man es einsetzen will. Zum Beispiel aus politische; oder, weil man vorrausschauend arbeiten will; oder es gibt doch Features, die man jetzt schon nutzen will.

It’s our future?
Foto: Mike Licht @ flickr/CC Lizenz

Machen wir es also mal umgekehrt und sagen JA! zu HTML5, auch im produktiven Einsatz! Was geht dann?

Doctype

Das haben wir schon gelernt, den sexy Doctype von HTML5 kann man schon jetzt nutzen. Zur Zeit kann man damit nicht beim W3C validieren, dafür zunächst mal bei validator.nu.

Strukturierende Elemente mit Alternativen

Wenn man Firefox 2 und IE-Nutzer, die ihr Javascript abschalten an Bord behalten will, kann man die neuen strukturellen Elemente von HTML5 nicht nutzen. Andersherum gesagt: bei meinen Projekten würde ich damit ca. 10% der User ausschliessen (über den Daumen gepeilt: 6% FF2-Nutzer, plus js-lose IE’ler geschätzt). Das wird man kaum durchsetzen können oder wollen.

Stehen fürdahin zwei Wege zur Verfügung. Entweder kann man die neuen strukturierenden Tags (bspw. <head>, <article>, <figure>) einsetzen ohne sie zu stylen. Dazu schreibt man sie zusätzlich ins Dokument, beachtet sie aber weiter gar nicht. Bspw. So:

<!doctype html>
<head>
    <title>Nicht so gutes Beispiel?</title>
</head>
<body>
    <header>
        <div class="logo">
        <h1>Ich bin ganz oben</h1>
        </div>
    </header>
    <p>[…]</p>
</body>

Nachteil: Man füllt den Code mit zusätzlich, zunächst überflüssigen, Elementen (hier auch noch dumm benannt). Will man ja eigentlich nicht. Bringt im Grunde auch nur etwas, wenn Suchmaschinen morgen damit beginnen würden, nach den neuen Tags zu suchen und abzuwiegen. Wenn HTML5 dann einmal weitläufig unterstützt wird (oder die Anforderungen sich ändern), muss man aufwendig HTML und CSS auswechseln.

Wenn man das sowieso nochmal machen muss, kann man aber auf zusätzlich Tags auch verzichten. Jon Tan hat schon im März letzten Jahres vorgeschlagen, stattdessen eine angepasste semantische Auszeichnung mit Klassennamen vorzunehmen (wie in Microformaten), die an die HTML5-Elemente angelehnt ist. Ungefähr so:

<!doctype html>
<head>
    <title>Nicht so gutes Beispiel?</title>
</head>
<body>
    <div class="header">
        <h1>Ich bin ganz oben</h1>
    </div>
    <p>[…]</p>
</body>

Das wird auch schon in produktiven Umgebungen so gemacht, beispielsweise auf der Seite der UX London. Es gibt dazu auch ein hervorragendes Cheat-Sheet, dass alle nötigen Elemente und Klassennamen aufführt. Wieder steht der Nachteil da, den Code nochmal anfassen zu müssen. Dies dürfte bei dieser Konstruktion aber wesentlich leicher fallen…

[Bytheway, die letzten drei Links stammen alle aus der hervorragenden der Sammlung, die Cameron Moll zum Thema HTML5 angelegt hat (welche ich widerum hier gefunden hab).]

Warum?

Superdasallesist, aber zwangsläufig stellt sich doch die Frage nach dem warum?.

Zwei Antworten gibt uns Jeremy Keith, der die UX London Site gebaut hat:

Now our document structure has pre-built documentation. Want to know what class=”article” denotes? RTFM.

Apart from providing easier documentation, there’s another good reason to take this approach: interoperability. Think about how much easier user styling would be if sites shared many of the same class names. Even if you don’t think that they are the best class names—I know, for instance, that Malarkey doesn’t like the presentational smell of footer—the benefits of an aggregate shared vocabulary could be very empowering. So if you do insist on creating a CSS framework that mandates using certain specific names (a concept I despise) please, please, please use those class names.

adactio.com

So far, so good. Das ist ein Ja! So richtig überzeugt bin ich aber noch nicht. So wird’s wohl auch Eric Meyer gegangen sein, der seinen Artikel dazu erst ganz euphorisch pro HTML5 beginnt, dann aber letztendlich doch zum bekannten HTML4-Markup zurückkehrt…

Wie schon in der letzten Antwort demonstriert, kann man den IEs mit ein wenig Javascript jedes Element beibiegen, es landet korrekt im DOM, es lässt sich mit CSS stylen. Auch schon angemerkt: Firefox 2 bereitet da mehr Probleme.

Und zwar liegen die bei den neuen Block-Level-Elementen, die ihrerseits Block-Level-Elemente enthalten, also beispielsweise ein <h1> in einem <article>. Ein wenig ausführlicher bei den Kollegen von webmasterpro.de nachzulesen. FF2 schliesst das <article> vor dem <h1> einfach <article></article><h1> und macht so jeden Versuch, styling anzuwenden zu Nichte. Und richtig ärgerlich: es gibt keinen praktikablen Workaround.

Es sei denn, man nutzt XHTML5, schreibt also XML-valide und vor allem zwingend erforderlich, liefert die Datei mit dem Mimetype application/xhtml+xml aus. Da beisst sich die Katze jedoch in den Schwanz, denn das geht nun wieder gar nicht mit dem IE, der will solche Dateien bekanntlich zum Download anbieten, er braucht text/html.

Bis hier haben wir nur neins gegen den Einsatz von HTML5 schon heute auf der Liste. Allerdings nur gegen den Einsatz der neuen Elemente. Nein, das ist auch nicht ganz richtig: es sind Argumente gegen das stylen neuer Elemente. Soll heissen: natürlich kann man den HTML5 Doctype bereits einsetzen. Natürlich kann man neue Elemente wie <nav> schon benutzen. Nur wenn man per CSS diese Elemente styled, dann fallen FF2 und IEs ohne Javascript aus der Unterstützungsliste. Wie John Resig schreibt:

You don’t have to use any new aspect of HTML 5 in order to get the standards-mode benefits of using the HTML5 DOCTYPE. This DOCTYPE is able to push Firefox, Safari, Opera, IE6, IE7, and IE8 into standards mode and allow us to (as best as we can) develop web applications in a standards-based way (CSS, HTML, JavaScript, DOM). You don’t have to use a single one of the new features in order to make this happen and can begin doing so today.

snook.ca

Schliesst sich die Frage an: Warum sollte man das tun? Gibt es denn schon Sachen, die funktionieren, die man nutzen kann?

Einerseits bildet HTML5 den Ist-Zustand dessen, was man mit Webbrowsern heute machen kann ab, ist also ziemlich kompatibel. Allerdings bringt HTML5 auch jede Menge neue Elemente mit (abbr, article, aside, audio, bb, canvas, datagrid, datalist, details, dialog, eventsource, figure, footer, header, mark, menu, meter, nav, output, progress, section, time, video), die zunächst mal nur mangelhaft in Browsern implementiert sind.

Etwas mehr Tagsoup gefällig?
Foto: daisybush@flickr/CC Lizenz

Wie Peter im Kommentar hier schon angedeutet hat, kann man die verschiedenen Internet Explorer durch einen Javascript-Trick dazu bewegen, für sie unbekannte HTML-Tags richtig zu erkennen und ins DOM zu rendern. Der Trick ist altbekannt, wird aber auch nochmal im WhatWG-Blog ausführlich beschrieben. Um den <section> im IE bekannt zu machen, reicht folgende Zeile Javascript: document.createElement("section");. Hier gibt’s ein Script, das alle neuen Elemente aktiviert, einzubinden über conditional comments.

Die anderen gängigen Browser parsen auch unbekannte Tags, fressen HTML5 also eher… dummerweise hat nun gerade Firefox 2 dabei ein paar Probleme, die aber seit Version 3 behoben sind. Firefoxnutzer sind sicherlich updatefreudiger als IE-Anhänger, wenn aber in der Liste der zu unterstützenden Browser Firefox 2+ steht, dann muss man die Einsatzfähigkeit von HTML5 zunächst verneinen. In diesem Fall lautet die Antwort diesmal: nein.

<!DOCTYPE html>

Dieser Doctype ist bei vielen Browsern natürlich unbekannt. Aber das macht nichts, die Browser schalten in diesem Fall in den Standard- oder Strictmode. Gewünschtes Verhalten. Natürlich funktionieren noch nicht alle neuen HTML5 Features, im Gegenteil.

Im Grunde kann es losgehen.

So as Bruce discovered, pretty much all browsers will already let you wrap a elements around other stuff, so it got added to HTML 5. And when I tried it, it worked, clickably speaking. That is, all the elements I wrapped became part of one big hyperlink, which is what I wanted.

[...]

I was happy to get the layout problems sorted out, obviously. Only, at that point, I wasn’t doing anything that required HTML 5.

meyerweb.com

Dabei nennt er einige Gründe schon jetzt HTML5 zu nutzen, die ich für ziemlich sexy halte, widerlegt sich aber leider ein wenig selbst. Preisfrage: ist HTML5 schon reif für den Produktiveinsatz?

Was sind die Vorteile? Wo sind die Stolpersrähte? Welche Browsersupportliste bekommt man damit hin?

Updates

• 1. Antwort: Neue HTML5-Elemente: nein.
• 2. Antwort: Wie war das mit Firefox 2: nein.
• 3. Antwort: Jetzt schon HTML5 nutzen!: ja.

In der grandiosen Artikelserie Benimmregeln für Datentabellen [via] findet man nun all diese Dinge erklärt, ausführlich, mit erklärenden Abbildungen, Codelistings und Hörproben (von Screenreadern). Lesebefehl!

Im Moment wird zwar nur das offene Ogg-Format unterstützt, weitere Formate kann man sich allerdingsleicht vorstellen. Und je nach Willen der Zusammenarbeit der Lizenzinhaber sicherlich auch umsetzbar. Jedenfalls mit…

<video src="http://v2v.cc/~j/theora_testsuite/320x240.ogg" autoplay>
    Your browser does not support the <code>video</code> element.
</video>

… ist in windeseile ein Videoplay umsetzt, der Ogg-Videos abspielt und sich mit Javascript auch steuern lässt.

Seit Ian Hickson im Interview einen Zeitplan für HTML5 aufmachte, der bis 2022 reicht, wird es nicht mehr ruhig in Standardspiesserhausen. Nicht nur Unbedarfte und Ahnungslose, auch hochdekorierte und anerkannte Szenegrößen liefen zum Sturm, gegen ein Mißverständnis. Man hat fast ein wenig den Eindruck, als ginge es allein um Animositäten und verletzten Stolz. Wie peinlich ist das denn wieder?

Nochmal zum Mitschreiben, Ende 2009 wird die Entwicklungsphase von HTML5 als Standard weitegehend abgeschlossen sein, bereits jetzt werden HTML5-Elemente in Browser eingebaut, man rechnet damit, dass sich HTML5 im Jahre 2022 flächendeckend urchgesetzt hat. Oder wie Anne van Kersteren es schreibt:

What used to be known as W3C Recommendation (in the HTML 4 era) is something we now know as Last Call Working Draft or maybe Candidate Recommendation. Using the new terminology, Ian expects HTML5 to become a Last Call Working Draft in 2009 and W3C Recommendation in 2022. So it’s actually quite close given that the latter date is not that meaningful. On top of that, HTML5 features are already shipping in various browsers today.

annevankesteren.nl

Wie man nun Tabellen nutzt, die dabei auch noch gut aussehen, zeigen uns die Kollegen vom Smashing Magazine. Sehr schön.