Auch das W3C begann, einen HTML 5-Standard zu entwickeln (zur Abgrenzung zur WHATWG mit einem Leerzeichen vor der 5), da die Entwicklung von XHTML 2.0 ins Stocken geraten war. Da es unklar war, welcher Standard langfristig gültig sein würde, arbeiteten Webentwickler erst mal mit XHTML 1.0 weiter, um nicht auf einen falschen Zug aufzuspringen. Ein neuer verbindlicher Standard schien in weiter Ferne zu sein.
Irgendwann haben die Standardentwickler jedoch realisiert, dass es keine zwei konkurrierenden Standards geben kann. Zudem zeichnete sich 2007 bereits ab, dass es nie zu einem fertigen XHTML 2.0-Standard kommen wird, dessen Entwicklung 2009 dann auch endgültig eingestellt wurde. Schließlich hat das W3C den Entwurf der WHATWG als Grundlage für einen neuen HTML5-Standard akzeptiert.
Seitdem arbeiten beide Gruppen gemeinsam am neuen Standard (beide Organisationen
fungieren aber nach wie vor als Herausgeber von HTML5). Für den Webentwickler
bei der täglichen Arbeit ist es letztendlich gleichgültig, wer den Standard
entwickelt. Wichtig hingegen: Es gibt irgendwann einen verbindlichen Standard!
HTML5 vereint im Grunde HTML 4.01 oder XHTML 1.0 und lässt beide Schreibweisen zu. Im Gegensatz zu XHTML 1.0 straft HTML5 keine HTML-Elemente als böse ab, sondern benennt veraltete HTML-Elemente und rät, diese nicht mehr zu verwenden und empfiehlt stattdessen, geeignete CSS-Techniken einzusetzen.
Gerade die »unsaubere« HTML 4.01-Syntax mag den einen oder anderen Quelltextliebhaber
auf die Palme bringen. Hier muss man vor allem aber den praxisnahen Ansatz sehen:
Auch wenn in HTML5 kein acronym mehr auftaucht und die semantische
Aufgabe über das abbr erfüllt wird, ist es letztlich egal, wenn
jemand ein acronym einsetzt, da alle Browser dieses Element kennen
und auch korrekt anzeigen. Und kein Browserhersteller »explementiert« ein
Feature, nur weil ein Standard es nicht mehr enthält.
Darüber hinaus definiert sich HTML5 als letzter Standard. Eine Version 6 soll es nicht geben, da alle Elemente, die es in der Vergangenheit gab und auch jene, die in Zukunft hinzukommen, automatisch Teil von HTML5 sind. HTML5 wird damit in Zukunft wachsen. Aktuell besteht keine Absicht, den Standard durch einen Folgestandard zu ersetzen.
Dies entspricht ohnehin dem, wie sich das Web und die Browser weiter entwickeln. Es ist nicht so, dass das W3C oder die WHATWG einen Standard entwickeln, diesen verabschieden und danach die Browserhersteller beginnen, die neuen Features zu implementieren. Im Gegenteil, Browserhersteller entwickeln neue Funktionalitäten, integrieren diese in den Browser und wenn sie gut sind, gehen sie in die Standardentwicklung ein und werden dann auch von den anderen Browserherstellern übernommen.
In der Praxis ist die Arbeitsweise auch anders, wie man jetzt vermuten könnte. Kein Entwickler schaut in den Standard und nimmt sich die Dinge, die er zum Aufbau seiner Seite benötigt.
Vielmehr nimmt er sich ein neues Feature, beispielsweise ein video-Tag, oder
die CSS-Eigenschaft transform und prüft dann, welche Browser diese neuen
Elemente kennen. Unterstützt nur ein kleiner Teil der Browser ein neues
Attribut, kommt es in der Regel erst mal nicht zum Praxis-Einsatz. Unterstützt
ein großer Teil der Browser ein neues Feature, muss geschaut werden, ob ein
vertretbares Fallback für die anderen Browser angeboten werden kann oder ob
die fehlende Unterstützung keinen Funktionsverlust für die übrigen Browser bedeutet.
Sprich: ein fehlender Schlagschatten oder keine runden Ecken führt selten dazu, dass eine Seite nicht mehr bedient werden kann. So meine zynische Haltung, die nicht von jedem Webentwickler geteilt wird: Auch wenn es anders ausschaut, aber immer noch funktioniert, warum nicht…
Eine großer Gewinn von HTML5 sind die audio und
video-Elemente, mit dem Audios beziehungsweise Videos ohne
Flash-Player ins HTML eingebunden werden können. Ob diese neuen Tags
unterstützt werden, hängt neben der eigentlichen Browserunterstützung von
HTML5 vom Audio- beziehungsweise Video-Format ab. Eine zuverlässige Einbindung
erreicht man nur, wenn die Dateien in den richtigen Formaten hinterlegt sind
(da unterschiedliche Browser unterschiedliche Formate unterstützen, müssen in
der Regel auch mehrere Media-Dateien hinterlegt werden) und zusätzlich für
ältere Browser ein Flash-Player als Fallback eingebunden werden.
Dies bedeutet für die Praxis: Zieht der Einsatz eines neuen HTML-Elements nach sich, dass jede Menge Fallbacks eingebaut werden müssen und dadurch eher neue Schwierigkeiten entstehen, ist es ratsam, einen funktionieren Flash-Player noch eine Weile auf der Webseite zu belassen.
Innovativ ist HTML5 in Bezug auf Formulare, speziell was Eingabefelder betrifft.
Ein <input type="date"> beispielsweise erzeugt ein Eingabefeld,
welches nativ vom Browser mit einem Auswahlkalender angezeigt wird und das
aufwendige Einbinden eines »Date-Pickers« über JavaScript erübrigt. Da weder
Internet Explorer 8 noch 9 dieses neue date-Attribut unterstützen
und keinen Kalender anzeigen, ist wiederum ein Fallback notwendig einschließlich
einer durchdachten Validierung, wenn Nutzer ein Datum auch per Hand eingeben
können (davon abgesehen: Ein date-Attribut ist kein Freibrief
dafür, ein Datum serverseitig nicht mehr zu prüfen).
Der Gewinn von HTML5 liegt manchmal aber auch im Kleinen, wie die Attribute
autofocus und placeholder für input-Felder.
Sie ersparen die Arbeit mit JavaScript, um Platzhalter in das Feld zu schreiben,
den Wechsel von Platzhalter und Benutzereingabe zu kontrollieren oder den Fokus
auf ein Feld zu legen.
Da es hier lediglich um die Verbesserung der Bedienung geht und die Funktionalität
einer Seite trotzdem gegeben ist, wenn ein Browser die Attribute nicht kennt,
können autofocus und placeholder getrost einsetzen.
Allerdings kann man auch hier den Standpunkt einnehmen, dass man solche
Usability-Features solange und vollständig durch vorhandene JavaScripte
sicherstellt, bis alle wichtigen Browser diese HTML5-Attribute beherrschen
und solange auf die neuen Attribute verzichtet.
Lesen Sie weiter: Teil 4: Sinnvoller Einsatz von neuen HTML5-Elementen
