Via @datenkind.

→

Da ist ein Eisbär im Raum?

Im Moment gibt es wieder viel zu lernen, in Sachen CSS. Da sind zunächst die vielen neuen Dinge, die CSS3 bringt. Durch die derzeit rasante Browserentwicklung, Polyfills oder einfache Fallbacklösungen kann man vieles davon schon heute oder wenigstens morgen gebrauchen. Dazu kommen die Learnings aus einigen Jahren intensiven Einsatzes von CSS, seit der internationalen Ächtung des Tabellenlayout ist viel passiert.

Seit CSS dem style-Attribut entwachsen ist, unterlag es lange Zeit einer eher langsamen Entwicklung. Gehemmt durch den Internet Explorer hat es ewig gedauert, bis sich CSS 2(.1) überhaupt durchgesetzt hat. Man hat lange Zeit eher mit den gegebenen Umständen hantiert, anstatt CSS weiter zu entwickeln. Die floats lösten die Tabellen ab, die CSS Hacks beherrschten die Szene lange, machten zweigleisige Entwicklung für potente und für beschränkte Browser möglich. Das Set an Techniken hat sich aber in der Menge kaum verändert, vielmehr lernten wir immer besser damit umzugehen. Dabei sind aber auch viele Standardlösungen entstanden, die heute einer genaueren Prüfung unterzogen werden müssen.

Our best practices are killing us!

Nicole Sullivan (die, nicht die) tritt derzeit mit einem Vortrag unter diesem Titel auf, den ich sehr beeindruckend finde, weil er so sehr das trifft, was ich derzeit selbst in der Praxis feststelle. Viele der best practices, die in den letzten Jahren ersonnen, gepaukt und umgesetzt wurden, klingen gut, haben sich aber in den Jahren ihres Einsatzes vielleicht gar nicht bewährt. Andere wurden von der Entwicklung überholt, wurden zur Angewohnheit. Um mal ein klassisches Beispiel aus einem anderen Bereich zu bringen: wenn Sie <script>-Blöcke in einem HTML-Document nutzen, umgeben sie den Code dann auch noch mit HTML-Kommentarzeichen? Eine Technik, die heute lange nicht mehr nötig ist. Trotzdem sieht man sie immer wieder. So geht es auch mit vielen Angewohnheiten in CSS.

Nicole Sullivan nennt viele Beispiele. Unter anderem findet sie:

• die Angabe von Schriftgrößen nicht in Pixel sei kontraproduktiv,

• etwas mehr Klassizitis wäre gar nicht so schlecht, da so lange Selektorketten vermieden würden,

• durch semantische Klassennamen würde der Codewiederholung der Weg bereitet,

• der Mythos, kein zusätzliches Markup für das Layout einführen zu dürfen, sei mehr als schädlich, da durch Container Layoutprobleme auf festgelegte Bereiche beschränkt werden könnten.

In der Praxis nicht bewährt

Da geht es ihr genau wie mir. Wenn man betrachtet, wie wirklich große Website-Projekte entstehen, stellt man fest, dass durch die genannten best practices Nötiges nur von einer Ecke des Projekts in die andere verschoben wurde. So kann man wunderbares, absolut semantisch reines HTML schreiben, ohne jegliche Layout-Divs, so klein wie nur irgend möglich, ob die Seite dadurch wirklich schneller wird? Oder übersichtlicher? Nun, das HTML natürlich schon, aber wenn wir uns anschauen, wieviel sich gegenseitig überschreibendes CSS benötigt wird, merkt schnell, das man die Komplexität nur verlagert hat. Miss Sullivans Beispiel: bei Facebook hatte man vor einem umfassenden CSS-Relaunch 706 CSS Dateien, in denen 261 Mal die gleiche Farbe blau definiert war. Do not repeat yourself?

Und dabei geht’s nicht mal darum, sich gegenseitig den schwarzen Peter zuzuschieben: Komplexität im CSS schadet allen Beteiligten, denn sie drückt auf die Performance. Mein Beispiel ist die tägliche Praxis. Bei einem großen Projekt wurden nahezu nach Lehrbuch beim Schreiben von HTML-Code (und Javascript^[1]) auf auf eine ganze Reihe best practices geachtet. Das hat zunächst mal dazu geführt, dass wir zwar schlankes HTML, aber ziemlich viel CSS (und Javascript) über die Leitungen schicken. Dabei ist die Menge an CSS und seine Komplexität eine direkte Folge der semantischen Strukturen im HTML. Aber wo im HTML bspw. nur wenige Klassen stehen, muss im CSS mit unendlich langen Selektorketten auf Elemente zugegriffen werden, was die Menge an CSS erhöht, die Geschwindigkeit des Renderings aber herabsetzt. Nach einigen Jahren ist diese Situation immer schlimmer geworden. Sie ist dabei kaum noch überschaubar, weil man praktisch nur noch mit dem Firebug entscheiden kann, welche CSS-Regel auf ein Element greift. Und die schiere Menge an Code macht es nicht besser. Abhilfe schafft da oft, einfach mal eine Klasse ins HTML zu schreiben, die direkt angesteuert wird. Und die darf dann vielleicht auch mal “blue” heissen, naja, vielleicht besser “main-color”.

CSS Refactoring?

Will man sich aber, mindestens in Teilen nun aber von dieser Praxis abwenden, dann hat man jetzt den GAU, den man eigentlich vermeiden wollte: Änderungen an der Codebasis und am CSS. Zumindest kann man das Nutzen, um die IE6-Unterstützung endgültig zu droppen und so das ganze CSS etwas zu modernisieren. So stehen nun vieler Orten viele Änderungen in Sachen CSS an. Neues hinzufügen, alte Zöpfe abschneiden. Alte Projekte auf den aktuellen Stand heben.

^[1] Noch ein Nebensatz zur Rolle von Javascript: dies wurde erstaunlicherweise viel zu oft genutzt, um die selbst gesetzten Grenzen bei HTML und CSS zu überwinden oder umgehen. Hüstel…

→

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.

http://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