HTML 5 ist ein Buzzword, unter dem dutzende neue und zukünftige Webtechniken subsummiert werden. Das ist zum einen gerechtfertigt, zum anderen irreführend, da es verschiedene Entwicklungen in einen Topf wirft. HTML 5 ist vieles zugleich. Tim Tepaße versuchte einmal, in einem Forumsposting zumindest einiges davon zusammenzufassen. Neben den mannigfachen technischen und geschichtlichen Aspekten ist HTML 5 nämlich auch eine Seifenoper, der sich sogar satirisch-kritische Comic-Strips widmen.
Dieser Text soll ein weiterer Beitrag zur Frage darstellen, was hinter HTML 5 steht – und bleibt bewusst einseitig und unvollständig.
HTML als Textauszeichnungssprache
Dem Namen nach ist HTML 5 die kommende Version der Sprache, in der Webseiten geschrieben sind. Die letzte Version ist HTML 4, welches vor mehr als zehn Jahren das letzte Mal geändert wurde.
HTML ist eine Auszeichnungssprache für Dokumente im World Wide Web – daher »Hypertext Markup Language«. Ausgangspunkt ist das Anreichern von Texten mit sogenannten Tags (Markierungen):
<h1>Dies ist eine Überschrift!</h1>
Drumherum notiert man ein Gerüst, sodass HTML zu einem vollständigen Dokumentformat wird.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<title>Beispieldokument</title>
</head>
<body>
<h1>Dies ist eine Überschrift!</h1>
</body>
</html>
HTML-Dokumente werden üblicherweise mit Stylesheets verknüpft, die die Präsentation des Dokuments bestimmen, und mit JavaScripten verbunden, die Interaktivität innerhalb des Dokuments ermöglichen.
Der erweiterte Blick von HTML 5
Die HTML-5-Spezifikation ist nun weit mehr als ein Regelwerk, das das Dokumentformat für Webseiten beschreibt. HTML 5 hat einen erweiterten Blick und definiert nicht mehr nur das Markup, sondern auch verwandte Techniken und technische Verfahren, die früher von getrennten Regelwerken abgedeckt wurden. Die Idee dahinter ist, das Web als »Plattform« insgesamt zu verbessern, indem das Fundament rundherum gefestigt wird.
In HTML 5 gehört vieles zusammen und baut aufeinander auf, aber zum Verständnis möchte ich die Kernideen von HTML 5 »aufdröseln«.
1. Das Dokument-Objektmodell als Ausgangsbasis
HTML 5 startet bei etwas abstraktem, wenig anschaulichem: dem Dokument-Objektmodell (DOM). Das DOM ist eine Baumstruktur von sogenannten Knoten – das sind grob gesagt Elemente, deren Attribute sowie Textinhalte. Das DOM kann man nicht direkt sehen oder festhalten, es ist nur ein Modell, in dem Daten zueinander in einer Unter- und Nebenordnung stehen. In dem Artikel HTML-Dokumentmodelle habe ich versucht, das DOM anschaulich zu machen.
Das DOM ist die Repräsentation des Dokuments, wenn es im Arbeitsspeicher eines verarbeitenden Programms, z.B. eines Browsers liegt. Das war bei HTML 4 immer nachrangig und in eigene Spezifikationen ausgelagert. Das DOM kam erst ins Spiel, wenn vom Zugriff auf HTML-Dokumente die Rede war. HTML 5 zäumt das Pferd von hinten auf, indem das abstrakte Datenmodell am Anfang steht. Wir kommen später dazu, warum das sinnvoll ist.
Diese Umkehrung mag für die meisten HTML-Autoren verwirrend sein, denn sie sind gewohnt, dass am Anfang der konkrete, sichtbare Code steht. Vom DOM auszugehen entspricht allerdings der Logik von Auszeichnungssprachen, von CSS, JavaScript und anderen Webtechniken. Die beschreiben bzw. behandeln HTML-Dokumente allesamt als Objektmodell.
2. Grammatik und Semantik
Mit der »objektorientierten« Sichtweise definiert HTML 5 die Grammatik und die Semantik: welche Elemente und Attribute gibt es, was bedeuten sie, wie dürfen sie verschachtelt werden und wie ist das Gerüst eines Dokuments aufgebaut. HTML 5 ist daher ein Vokabular zur Dokument-Strukturierung bzw. Textauszeichnung.
3. Das DOM als Programmierschnittstelle (API) zum Zugriff auf Dokumente
Mit der Definition der Struktur eines Dokuments wird direkt die Schnittstelle zum Zugriff durch Computerprogramme definiert. Ein verarbeitendes Programm sieht das Dokument als Objekte. HTML 5 definiert, wie die DOM-Knoten als Objekte zugänglich sind und welche Eigenschaften und Methoden sie besitzen. Grundlage ist der Standard W3C DOM 2 Core (das Kern-DOM), das eigentlich den Zugriff auf sämtliche XML-Dokumente regelt. Gleichzeitig stellt HTML 5 den Nachfolger von W3C DOM 2 HTML dar, dem spezifischen DOM für HTML 4 bzw. XHTML 1.
Diese Programmierschnittstelle kann in vielen Fällen Anwendung finden. Der wichtigste und häufigste Fall ist unbestreitbar, dass JavaScript im Browser mit dem Dokuments arbeitet.
4. Zwei Serialisierungen mit zwei Syntaxen
Üblicherweise schreiben wir HTML-Code, wenn wir ein HTML-Dokument in unseren Texteditor laden. Wir tippen also im Grunde Zeichen ein, die HTML-Tags oder natürlichsprachigen Text bilden. Wir erinnern uns an das Beispiel:
<h1>Dies ist eine Überschrift!</h1>
Aus Sicht von HTML 5 ist dieser Code eine sogenannte Serialisierung. Das ist ein textbasiertes Format, das die DOM-Struktur speicherbar macht. Erst damit kann sie z.B. von Menschen direkt bearbeitet und über das Netz übertragen werden kann.
Die HTML-5-Spezifikation definiert gleich zwei mögliche Serialisierungen, d.h. zwei mögliche Textdateiformate, in denen HTML-5-Dokumente geschrieben und gespeichert werden können:
- Die HTML-Syntax ähnelt HTML 4, welches auf SGML basierte. Es handelt sich jedoch nicht mehr um eine SGML-Sprache.
- Die XHTML-Syntax basiert auf XML und gleicht somit in großen Teilen XHTML 1.0.
Diese Serialisierungen schließen sich nicht gegenseitig aus: Polyglotte (vielsprachige) Dokumente können sowohl eine gemäß HTML-Syntax als auch gemäß XHTML-Syntax gültig sein. Das führt uns zu der Verarbeitung der Serialisierungen.
4. Die Verarbeitung der HTML-Syntax: fehlertolerant, aber streng reguliert
Bekommt der Browser ein HTML-Dokument geliefert, so parst er es. Parsen bedeutet, den HTML-Code einzulesen und zu einem DOM-Baum im Arbeitsspeicher zu verarbeiten. Anhand dieses DOM-Baums erzeugt der Browser die Darstellung des Dokuments, die wir schließlich im Browser sehen und bedienen.
Serialisierung
DOM ---------------> Code
<---------------
Parsing
Aus dem Code <h1>Dies ist eine Überschrift!</h1> wird letztlich ein h1-Elementknoten, der einen Textknoten mit dem Inhalt »Dies ist eine Überschrift!« enthält.
Zusammen mit der verbindlichen HTML-Syntax definiert HTML 5 die einzig richtige Verarbeitung von HTML-Dokumenten, also die Regeln für einen jeden HTML-Parser. Diese Verarbeitung ist zwar sehr fehlertolerant, aber es ist genau definiert, was im Fehlerfalle passiert. Ein gewisser Code erzeugt ein bestimmtes DOM, den Browsern wird möglichst wenig Interpretationsspielraum gelassen. Die Darstellung einer Webseite mit fehlerhaftem HTML-Code ist somit genauso determiniert wie die einer fehlerfreien.
Die Verarbeitung der XHTML-Syntax ist ebenfalls genau geregelt. Dies muss die HTML-5-Spezifikation allerdings nicht selbst vornehmen, sondern hier gilt einfach der XML-Standard.
Der besagte HTML-Parser soll künftig die bestehenden Parser in den Browsern ersetzen. Allerdings werden manche Browser den HTML-5-konformen Parser voraussichtlich nur für Dokumente verwenden, die einen HTML-5-DOCTYPE verwenden (<!DOCTYPE html>). Es gibt noch keine Browserversionen für den Produktiveinsatz, die einen solchen Parser beinhalten. Lediglich Testversionen von Mozilla Firefox (Nightly Builds) besitzen einen experimentellen HTML-5-Parser. Diesen muss man absichtlich anschalten, damit alle Webseiten (zumindest die vom Typ text/html) damit verarbeitet werden.
Des weiteren definiert HTML 5 genau, wie Browser mit den Elementen umgehen sollen. Das ist bei Elementen wie h1 oder p recht trivial. Der Umgang mit aktiven und dynamischen Inhalten, die mit embed, object, video und audio eingebunden werden, bedarf jedoch einer detaillierten Beschreibung, da nichts mehr dem Zufall überlassen werden soll.
Hier zeigt sich, warum HTML 5 im Gegensatz zu HTML 4 nicht Sprachvokabular, Serialisierung und Verarbeitung/Parsing vermischt und miteinander verschränkt. Die Syntax von HTML 4 ergab sich noch von selbst, denn HTML 4 war eine SGML-Anwendung. HTML 5 räumt sich eine gewisse Flexibilität ein, indem es sich von SGML emanzipiert: Es definiert ein eigenes Textformat (Serialisierung des DOM) und gleichzeitig die korrekte Verarbeitung (Parsen zurück zum DOM). Das Ziel ist, dass der HTML-5-Parser den bestehenden, mitunter fehlerhaften HTML-Dokumenten im Web gewachsen ist. Gleichzeitig bleibt die Option einer XML-Serialisierung offen, um von den Vorteilen der XML-Plattform Gebrauch zu machen.
Ein Schaubild von Karl Dubost zeigt den Zusammenhang von DOM, der Serialisierung hin zu HTML- oder XHTML-Syntax und dem umgekehrten Prozess des Parsens vom Markup zum DOM:
Quelle: HTML 5 and XHTML 5 – one vocabulary, two serializations
5. Weitergehende Scripting-Schnittstellen (APIs)
HTML 5 startete unter dem Namen »Web Applications 1.0« und trägt jetzt noch den Untertitel »A vocabulary and associated APIs for HTML and XHTML« (ein Vokabular und zugehörige Programmierschnittstellen für HTML und XHTML). HTML 5 befasst sich mit einem bunten Strauß an Techniken für Webanwendungen. Damit sind interaktive Websites gemeint, die zum Teil stark auf JavaScript und setzen, um sich in puncto Bedienkomfort klassischen Desktop-Programmen anzugleichen.
Wenn derzeit von HTML 5 die Rede ist, dann sind oftmals die neuen JavaScript-Fähigkeiten gemeint, die einige Browser bereits unterstützen. Branchengrößen wie Google propagieren »HTML 5« als ein Schlagwort für dynamische, JavaScript-angetriebene Webanwendungen wie Google Wave. Seitdem Google einen eigenen Browser namens Chrome veröffentlicht hat und an einem Web-gestützten Betriebssystem namens Chrome OS arbeitet, nimmt die Idee von »HTML 5« als Plattform für Anwendungen Substanz an. Daher ist es kein Wunder, dass der Hauptautor der HTML-5-Spezifikation, Ian Hickson, bei Google angestellt ist.
Ungefähr ein dutzend neue JavaScript-Schnittstellen, die dem HTML-5-Kontext entstammen, sind derzeit in Arbeit. Viele davon wurden von einzelnen Browserherstellern erfunden und werden nun standardisiert und weiterentwickelt, um eine browserübergreifende Umsetzung zu ermöglichen. Hinzu kommen alte Schnittstellen, die längst breit unterstützt werden, aber im Zuge von HTML 5 erstmals herstellerunabhängig und normativ spezifiziert werden. Das beste Beispiel ist das oberste JavaScript-Objekt window, das seit dem ersten JavaScript-fähigen Webbrowser existiert, das aber nie durch ein unabhängiges Gremium standardisiert wurde. Insofern ist HTML 5 ein größeres Unternehmen, um durch Webstandards Einheitlichkeit und Verlässlichkeit in die Webentwicklung zu bringen.
Einige der APIs sind Teil der Hauptspezifikation, was Kritiker bemängeln. Nach und nach werden Teilmodule in eigenständige Spezifikationen ausgelagert, um die Entwicklungsrhythmen voneinander abzukoppeln.
Zu den wichtigsten neuen JavaScript-APIs gehören:
- Audio- und Video-Einbettung und -Ansteuerung
- Mit Canvas kann eine »Leinwand« mit JavaScript bezeichnet werden
- Textverarbeitung im Browser, Rich Text Editing
- Drag und Drop von Elementen innerhalb eines Dokuments und von Dateien vom Desktop auf die Webseite
- Offline-Speicherung von Daten (Session Storage), einfache clientseitige SQL-Datenbank
- JavaScript-Kommunikation zwischen Dokumenten, auch von unterschiedlichen Domains
- Web Workers ermöglichen das parallele Ausführen mehrerer abgekoppelter JavaScripte
- Ansprechen von Elementen über CSS-artige Selektoren, wie es bereits zahlreiche JavaScript-Bibliotheken erlauben
- Echtzeit-Kommunikation mit dem Server über Socket-Verbindungen anstatt nur über aufgeblähte HTTP-Anfragen
Kann ich HTML 5 bereits einsetzen?
Während es in diesem Artikel um die Grundprinzipien von HTML 5 ging, haben sich andere Autoren eingehend solchen praktischen Fragen gewidmet. Eine allgemeine Antwort lautet: Es kommt darauf an. HTML 5 besteht aus dutzenden Teiltechniken unterschiedlicher Herkunft, deren Browserunterstützung stark variiert.
DOCTYPE
Sie können bereits HTML-5-konforme Dokumente schreiben, indem Sie Ihre Dokumente mit <!DOCTYPE html> beginnen. Zur Validierung können sie einen speziellen HTML-5-Validator nutzen. Aber auch der gewöhnliche W3C-Validator kann HTML-5-Dokumente validieren.
Seien Sie sich darüber bewusst, dass in diesem experimentellen HTML-5-Validator bisher der einzige wirkliche HTML-5-Parser steckt. Von der robusten und definierten Verarbeitung als HTML 5 können Sie derzeit noch nicht profitieren – es sei denn, Sie nutzen diese Parser-Bibliothek oder die html5lib in Ihren eigenen serverseitigen Programmen.
Neue Elemente und Attribute
Die neuen Elemente zur Grobstrukturierung des Dokuments wie section, nav, article, aside, hgroup, header und footer kennt bisher kein Browser. Damit ist gemeint: Die Bedeutung erkennt kein Browser.
Allerdings gehen die meisten Browser mit unbekannten Elementen um wie mit bekannten: Aus den Tags erzeugen sie entsprechende DOM-Knoten und erlauben eine CSS-Formatierung. Der Internet Explorer tut dies nicht. Es zwar gibt einen JavaScript-Trick, mit dem man die neuen Elemente im Internet Explorer »anmelden« kann. Ohne JavaScript-Unterstützung ist dieser allerdings hinfällig und damit nicht robust. Auf Produktiv-Websites lohnt sich der Einsatz der besagten Elemente daher nicht, denn sie sind nicht browserübergreifend per CSS formatierbar. Wenn Sie sie einsetzen, sind daher immer noch zusätzliche div-Container nötig.
Auch wenn es pessimistisch und niederschmetternd klingt, hat Eric Eggert die aktuelle Lage auf die treffende Formel gebracht: »Wer heute schon HTML5 einsetzen sollte: Fast niemand. HTML5 [gemeint sind die neuen Elemente] wird von keinem Browser aktiv unterstützt, es geht im Moment nur nichts kaputt«.
Weitere Hinweise zur Anwendung des neuen Markups finden sich auf beim HTML5 Doctor, helping you implement HTML5 today.
Welche Serialisierung – HTML 5 oder XHTML 5? Beides!
In den letzten Monaten haben viele Fachleute eine Lanze für »polyglotte« (X)HTML-5-Dokumente gebrochen. Das sind Dokumente nach XHTML-Syntax, die dank der neuen Verarbeitungsregeln auch als HTML geparst werden können. Dies ermöglicht es, auf die bewährte strenge und »pädagogische« XHTML-Syntax zu setzen und gleichzeitig maximale Kompatibilität mit bestehenden XML-Werkzeugen und künftigen HTML-5-Parsern zu erreichen. Der besagte HTML-5-Validator macht Fortschritte, um die Erstellung von polyglotten Dokumenten zu unterstützen.
Die Idee von HTML-Dokumenten, die Teil beider Welten sind, ist nun nichts Neues: Sogenanntes abwärtskompatibles XHTML 1.0 wird seit Jahren als text/html ausgeliefert. Bereits dafür gab es in der Vergangenheit vehemente Fürsprecher und erbitterte Gegner. Der Grabenkampf darum, ob XML für Websites sinnvoll ist, ist also nicht beigelegt: Die alten Kontrahenten streiten unaufhörlich weiter. Was die einen für Zeitverschwendung halten, sehen die anderen als stilles Revival von XML. Wie auch immer: Mit HTML 5 hat sich ein pragmatischer Kompromiss durchgesetzt, der den Webautoren die Wahl lässt und sie dabei so gut es geht unterstützt.
JavaScript-Schnittstellen aus dem HTML-5-Umfeld
Die Nutzung der neuen JavaScript-Schnittstellen gestaltet sich insofern einfach, dass sich Fähigkeitenerkennung durch gezielte Objektabfragen vornehmen lassen. Es gibt sogar eine JavaScript-Bibliothek namens Modernizr, die die Abfrage der Unterstützung von gewissen HTML-5-Features sowie zahlreiche CSS-Erweiterungen vereinfacht. Mark Pilgrim erklärt in Detecting HTML5 Features verschiedene Feature-Abfragen im Detail.
Nur wenige der neuen JavaScript-APIs sind bisher browserübergreifend nutzbar. Das muss nicht heißen, dass Sie sie noch nicht im Sinne des »Progressive Enhancement« einsetzen können. Sie können die APIs als obligatorisch voraussetzen, was i.d.R. nur in homogenen Intranets tragbar ist. Oder sie verwenden die APIs für optionale Zusatzfeatures. Oder sie nutzen Fallback-Lösungen für ältere Browser, sofern solche existieren.
Eine gute Vergleichstabelle zur Browserunterstützung unter anderem der neuen APIs bietet When can I use ...?. Folgende Site demonstriert die JavaScript-Fähigkeiten: HTML 5 Demos and Examples (Remy Sharp)
Zum Schluss eine Warnung
HTML 5 ist work in progress. HTML 5 hat schon einen langen Weg hinter sich, ist aber erst vor Kurzem richtig durchgestartet. Es ist weder ausgereift noch für den robusten Praxieinsatz geeignet. Vor allem ist die Spezifikation noch längst nicht fertig, auch wenn sie bereits in den Browsern implementiert und massig Sekundärliteratur produziert wird.
Mit der zunehmenden Popularität haben sich mehr Experten mit HTML 5 beschäftigt und haben grundlegende und fundierte Kritiken gewisser HTML-5-Techniken formuliert. Im Zuge der Einarbeitung dieses Feedbacks ändern z.B. gewisse HTML-Elemente ihre Bedeutung oder fallen ganz aus dem Regelwerk heraus. Der kommende Standard wird also ständig revidiert. Das ist eine gute Sache, heißt aber für Webautoren, dass sie lediglich mit einer Momentaufnahme arbeiten, deren Halbwertszeit gering ausfallen kann.
Ausblick
In einem Folgebeitrag möchte ich ein Überblick über die verschiedenen Spezifikationen und die zahlreiche Hintergrundliteratur geben.