molily Navigation

Ein Podcast über die Geschichte von HTML

Eine parteiische Erzählung der HTML-Geschichte von SGML über HTML, XML und XHTML bis HTML5.

Die Audio-Datei ist nicht mehr verfügbar, aber das Transkript unten.

Inhaltsverzeichnis

  1. SGML-Ära und Anfänge von HTML
  2. XML-Ära

    1. Entstehen von XHTML 1
    2. Vorteile von XHTML
    3. Erfolge von XHTML
  3. XHTML 2
  4. HTML5 und WHATWG

    1. Ursprüngliche Ziele der WHATWG
    2. Umfassende Reform unter dem Begriff HTML5
    3. Grundideen von HTML5
    4. HTML5 hat keine Version
    5. HTML5 als Projekt der Browserhersteller
    6. Das Web als Anwendungsplattform
    7. Neues HTML5-Markup
  5. Gesamtfazit und Ausblick

    1. Shipping code wins?
    2. Konkurrenz der beiden HTML5-Arbeitsgruppen
    3. Wird HTML5 ein Erfolg werden?
    4. HTML5 ist nicht das Ende der Geschichte

Einleitung

Hallo, mein Name ist molily und ich möchte über die Geschichte von HTML erzählen.

Warum überhaupt über HTML erzählen? Zuerst einmal bekommt das Thema derzeit wenig Aufmerksamkeit trotz des anstehenden HTML5-Umbruchs. Wenn ich über HTML rede, dann will ich über die technischen Grundlagen reden. Die interessieren relativ wenige, zumindest mit den theoretischen Hintergründen beschäftigen sich nicht viele. Warum will ich die Geschichte von HTML erzählen? Ich möchte die Geschichtsschreibung infrage stellen, denn im Zuge des HTML5-Umbruchs wird die HTML-Geschichte neu geschrieben – von denen neu geschrieben, die historisch gewonnen haben. Nachträglich kämpfen verschiedene Parteien um die Bewertung der geschichtlichen Entwicklungen und deswegen möchte ich meine Sicht einbringen. Ich beziehe mich vor allem auf einen Artikel von Mark Pilgrim. Der schreibt gerade ein Buch über HTML5 namens Dive into HTML5. Das Buch fängt mit dem Text A quite biased history of HTML5 an. Dieser basiert auf einem seiner Blogartikel, wo er hauptsächlich die Geschichte des img-Elements in HTML erzählt. Wie kam es überhaupt zu der Standardisierung? Wie der Titel schon sagt, ist dieser Text quite biased, das ist er tatsächlich. Es ist zwar der beste Text, den es zur HTML-Geschichte bis HTML5 gibt. Aber man muss sich die Frage stellen, was für Schlüsse er daraus zieht. Ist seine Lesart der Geschichte die einzig mögliche und sind seine Lehren daraus die einzig möglichen?

Ich habe meinen Vortrag in fünf historische Abschnitte geteilt:

  1. Die SGML-Ära.
  2. Die XML-Ära
  3. Zwischenabschnitt über XHTML2
  4. HTML5 - wo die Entwicklung hingeführt hat
  5. Gesamtfazit

1. SGML-Ära

SGML ist eine Metasprache zur Definition von Textauszeichnungssprachen. Das mag erst einmal verwirrend klingen: Eine Sprache zur Definition von Sprachen. Der Hauptstandard für SGML wurde 1986 festgelegt. Das ist eine richtiger Industriestandard, von der ISO spezifiziert. SGML steht für Standard Generalized Markup Language, standardisierte allgemeine Auszeichnungssprache. Das ist ein riesiger Standard, den man auch gar nicht frei im Web einsehen kann. Es gibt ihn meines Wissens nur gedruckt oder als PDF mit hunderten Seiten. Er stammt aus einer Zeit vor dem Web, vor dem kommerziell interessanten Internet. Er knüpft an vorige Ideen von Auszeichnungssprachen an. Im Grunde geht es darum, dass man Texte auszeichnen kann und sie mit Bedeutung füllen kann. Man kann Dokumenttypen erstellen, mit denen man Daten speichern kann.

Als Tim Berners-Lee das Hypertextsystem World Wide Web erfand, bezog er sich einfach auf SGML, weil das der herrschende Standard war, mit dem man eine Textauszeichnungssprache erfinden kann. Er erfand damit HTML. HTML 2, die erste große, feste Version von HTML, war eine SGML-Anwendung. Das heißt, er benutzte SGML, um Vokabular und Syntax dieser Sprache zu definieren. Dazu nutzte er die seit Jahren existierenden technischen Möglichkeiten.

SGML brachte eine entsprechende Komplexität mit sich. Mit SGML kann man sehr verschiedene Syntaxen definieren. HTML nutzte eine SGML-Deklaration, das ist die Hauptdefinition, welche SGML-Features in der Sprache erlaubt sind. Beim Vokabular von HTML ging es darum, wissenschaftliche Dokumente auszuzeichnen, denn anfangs war das Web so gedacht, dass Wissenschaftler über die ganze Welt hinweg ihre wissenschaftlichen Texte austauschen. Tim Berners-Lee war am Kernforschungszentrum in Genf angestellt und forschte dazu, ein weltweites Hypertextsystem aufzubauen, in dem vor allem Naturwissenschaftler ihre Dokumente publizieren können. Schon früher in den 70ern und 80ern hatte man die Einsicht gehabt, dass Textauszeichnung rein logisch und strukturell sein soll. Das heißt, Information zur Darstellung gehören auf keinen Fall in die Textauszeichnung hinein. Die Idee der Trennung zwischen Inhalt und Präsentation bzw. Form ist schon sehr alt und lag auch HTML 2 von Anfang an zugrunde.

Hinzu kam Hypertextmöglichkeiten. Von Anfang an enthielt HTML Ideen von früheren Hypertextsystemen, nicht nur einfach Links, sondern auch verschiedene logische Beziehungen. Später kamen Bilder, beliebige Objekte und Plugins hinzu.

Wie gesagt, HTML ist eine SGML-Sprache. Das bedeutet, dass HTML einerseits über eine SGML-Deklaration definiert wird, in der die Features angeschaltet werden und die Syntax genau festgelegt wird. Adererseits wird das Sprachvokabular in der sogenannten Dokumenttyp-Definition (DTD) festgelegt. Die Crux bei HTML war, dass es als sehr komplexe SGML-Anwendung definiert wurde. Syntaktisch gibt es sehr verschiedene Möglichkeiten, es lassen sich sehr obskure Features von SGML anwenden und das ist immer noch korrektes HTML. In der Praxis würde man diese ganzen Verkürzungsmöglichkeiten nur teilweise anwenden. Es stellte sich heraus, dass in der Praxisanwendung diese HTML-Features nicht nötig sind. HTML schleppte über Jahre diese Features mit sich und sie brachten eigentlich nur Nachteile.

Als kleines Zwischenfazit: HTML auf SGML aufzubauen war eine großartige akademische Idee. Das ist, wie ich finde, immer noch eine der genialsten Ideen, die das Web erfolgreich gemacht haben. Man nimmt eine sehr konventionelle Textauszeichnung und kombiniert sie mit Hypertext. Das ganze baut auf einer etablierten und ausgereiften Plattform auf. Das war damals der höchste Forschungsstand.

Nun komme ich zu dem Umschlag: HTML ist eine SGML-Anwendung, aber wurde nie wirklich als SGML verarbeitet. Es kamen die ersten Browser auf, die wirklich HTML-Seiten angezeigt haben, und diese haben HTML nicht als SGML angesehen. Sie besaßen überhaupt keine SGML-Parser. Um HTML zu verarbeiten, beachteten sie die SGML-Regeln nicht. Stattdessen redet man von sogenannten Tag-Soup-Parsern (Tag-Suppen-Parsern). Diese sehen den HTML-Quelltext nicht als korrektes SGML-Dokument und parsen die Eingabe nicht nach SGML-Regeln, sondern notwendigerweise – weil es viele fehlerhafte Seiten im Netz gibt – sehr fehlertolerant und nach eigenen Regeln. Das war die Grundlage dafür, dass sich HTML als SGML nie wirklich etabliert hat.

Trotzdem gab es Programme, die HTML als SGML-Anwendung verarbeitet haben. Das waren aber nur ganz wenige, nämlich die Validatoren und HTML-Lints. Diese sprachen mehr oder weniger SGML, hatten also echte SGML-Parser. Vor allen Dingen der W3C-Validator. Sie waren die einzigen Clients, die einzigen User-Agents, die HTML so verarbeitet haben, wie es ursprünglich gedacht war. Sie maßen HTML an den Standards , gemäß denen HTML korrekt definiert worden war. Sie nahmen die Dokumenttyp-Definition (DTD) und konnten so die Validatität eines HTML-Dokuments prüfen. Der Punkt ist, dass die Browser diese Regeln nie angewendet haben. Deswegen ist Validitätsprüfung bei HTML 4 ein bisschen abseitig: Der Validator kreidet eine Syntax als falsch an, die praktisch völlig problemlos möglich ist. Umgekehrt lässt er Syntax durchgehen, weil manche SGML-Features in HTML angeschaltet sind, die die Autoren nur verwirren. Wenn man im HTML gewisse Fehler macht, sieht sie der Validator nicht als Fehler an, weil er denkt, es sei ein spezielles SGML-Feature. Das hat sehr lange zu Problemen geführt. Die tatsächliche HTML-Verarbeitung biss sich immer mit der theoretischen Definition von HTML. Deswegen hatte der HTML-Standard als Theorie wenig mit der Realität zu tun.

Jetzt wechsle ich die Perspektive. Nachdem HTML standardisiert worden war, entstanden nach und nach die kommerziellen Webbrowser. Zuerst Mosaic, später Netscape und der Internet Explorer. Diese führten auf Basis von HTML 2, was noch sehr minimal war, ihre eigenen Elemente ein. Sie führten vor allem Elemente ein, die der bisherigen Philosophie von HTML völlig widersprachen wie beispielsweise font. Schon 1970 wusste man, dass man in Textauszeichnungssprachen nicht so etwas wie font machen sollte, aber es wurde trotzdem im Web eingeführt. In dem Zuge wurde das W3C, das World Wide Web Konsortium als übergreifende Standardisierungsorganisation gegründet. Die kommenden HTML-Standards, HTML 3 und 4, holten die Eigenentwicklung, die auf dem Browsermarkt passierte, nur ein. Größtenteils kodifizierten diese Standards die erfundenen Elemente einfach, nahmen sie also in den Standard auf. HTML 4 war jedoch im Gegensatz zu HTML 3 wieder der Versuch, HTML zurück auf den ursprünglichen Weg zu bringen, nämlich den Weg des Generic Coding. Die strikte Variante von HTML 4 forciert gutes HTML forciert, sie besitzt keine Elemente wie font. Man beschränkt sich auf eine sinnvolle Struktur des Dokuments lagert Informationen, die direkt die Darstellung betreffen, aus. Ein Beispiel ist Frames, ein HTML-Zusatz, der mit dem Auszeichnen von Dokumenten wenig zu tun hat.

Das Fazit ist: HTML auf Basis von SGML war im Web eher ein Fehlschlag. Was man sich dabei dachte, kam nie richtig zum tragen. HTML wurde nie als SGML verarbeitet und faktisch regierte die sogenannte Tag Soup. Die wenigsten Websites waren valide und die wenigsten konnten überhaupt als SGML verarbeitet werden. Die Browser waren schlicht dazu gezwungen, Tag-Soup-Parser einzubauen, die sehr fehlertolerant sind, im Grunde alles schlucken und versuchen, aus jeder Eingabe ein sinnvolles Dokument zu machen.

Dieser Widerspruch während der SGML-Ära wurde natürlich gesehen. Deswegen dreht sich der nächste Zeitabschnitt darum, mit diesen Fehlern aufzuräumen.

2. XML-Ära

Dieser historische Abschnitt wirkt bis heute fort. Zunächst, was ist XML? XML wurde vom W3C erfunden als abgespecktes SGML. XML ist genauso ein Baukasten für beliebige Auszeichnungssprachen. Es ist in erster Linie ein beschränktes SGML: Es gibt eine ganz bestimmte Syntax und wenig Freiräume. Es ist ein kleineres, kompatibleres, einfacher zu implementierendes Set von SGML.

Bei aller Kritik an XML ist XML sehr weit verbreitet. Auf fast allen Plattformen kann man mit XML arbeiten und es gibt viele Programmiersprachen und Bibliotheken, die XML verarbeiten können. XML ist nicht nur dieser Baukasten für Auszeichnungssprachen, es ist ein ganzes Ökosystem. Es gibt viele Techniken und Sprachen, die man miteinander kombinieren kann. Das wurde zum Credo und zur großen Idee vom W3C: Eine Architektur aus verschiedenen Techniken rund um XML zu schaffen, mit der man alle Anwendungen im Web abdecken kann. Zu XML selbst kam XSL(T) hinzu, also XSL-Transformation. Mit dieser weiteren XML-Sprache lassen sich XML-Sprachen in andere XML-Sprachen überführen. XSLT ist eine Art deklarative Programmiersprache. Hinzu kommt XPath, welches man mit CSS-Selektoren vergleichen kann, es ist nur komplexer. Damit lassen sich Elemente, Attribute und jegliche Knoten in einem XML-Dokument ansprechen und auswählen. Schließlich kamen weitere Sprachen wie XLink, SVG und so weiter hinzu.

Die gute Idee an diesem XML-Ökosystem ist, dass alle Sprachen strengen Grundlagen folgen. Beispielsweise ist Zugänglichkeit sehr wichtig (Barrierefreiheit/Accessibility), ferner Interoperabilität. Das heißt, es läuft auf allen möglichen System, darunter Mobilsystemen. Diese Sprachen sind sehr stark modularisiert, das heißt es gibt nicht eine monolithische Sprache, sondern viele kleine Sprachen, die sich miteinander kombinieren lassen. Letztlich sollte das ganze bis in die Zukunft hinein ausbaubar sein.

Langfristig ergab sich ein Abschied von der DTD, dieser standardisierten Möglichkeit von SGML und XML, die Grammatik einer Auszeichnungssprache festzulegen. Es entstanden bessere Möglichkeiten, Grammatiken maschinenlesbar festzulegen, nämlich zum Beispiel XML Schema. In der Perspektive verabschiedete man sich von der alten DTD als normative Festlegung einer Sprache. Das war ein großer Fortschritt gegenüber dem SGML-Universum.

Bei XML ist ganz klar festgelegt, wie ein Dokument verarbeitet wird. Die große Voraussetzung ist die sogenannte Wohlgeformtheit. Das heißt, es gibt bestimmte Regeln der Korrektheit, denen ein Dokument genügen muss. Wenn ein XML-Dokument nicht wohlgeformt ist, dann kann es auch nicht verarbeitet werden. Der XML-Parser bricht bei einem Syntaxfehler einfach ab. Das ist die sogenannte drakonische Fehlerbehandlung, auf die ich später noch einmal zurückkommen werde.

Entstehen von XHTML 1

Warum erzähle ich von der XML-Ära, wo es doch um die HTML-Geschichte geht? Das W3C entschied sich, HTML auf Basis der XML-Plattform weiterzuentwickeln. In den Jahren 1999 bzw. 2000 entstand XHTML 1.0. Das ist erst einmal nicht anderes als das Sprachvokabular HTML 4.01, welches in XML-Syntax geschrieben wird. Es war vorgesehen, diese XHTML-Dokumente auch als XML an den Browser zu senden. Die Idee war, dass die Browser ihren XML-Parser verwenden und nach und nach alle anderen Techniken der XML-Plattform implementieren, sodass man irgendwann das schöne XML-Ökosystem im Browser nutzen kann.

Diese Idee ging nicht auf. Die Idee fand bei den Browserherstellern und sowohl den HTML-Autoren keine Unterstützung. XHTML ist jetzt mehr als 10 Jahre in der Welt und immer noch gibt es keine browserübergreifende Unterstützung. Und wie es sich abzeichnet wird es auch nie so sein, dass man echtes XHTML mit allen Zusätzen, die die XML-Welt bietet, im Browser nutzen kann.

Vorteile von XHTML

XHTML hat sehr viele großartige Ideen und hat auch viele Vorteile. Ein Vorteil gegenüber HTML 4 ist die einheitliche Syntax. Es gibt ein paar Regeln, nach denen XHTML funktioniert und wenn man diese verstanden hat, dann muss man sie nur noch konsequent anwenden. Die Syntax ist also sehr pädagogisch, weswegen viele Handbücher XHTML benutzen, um klare und eindeutige Regeln zu vermitteln. Wie gesagt, XHTML will sich von den Problem abkehren, die SGML als Grundlage für HTML ausgelöst hat. Es gibt nicht mehr wie bei HTML 4 eine Mehrdeutigkeit und komische obskure Features. Weil sich XML reduktionistisch auf eine eindeutige Syntax beschränkt, kann man nichts falsch machen. Das ist für Webautoren eine Vereinfachung. Wenn man XHTML und XML-Tools sowie XML-Validatoren mit vernünftigen XML-Schemas verwendet, dann ist eine richtige gute Qualitätssicherung des Quellcodes möglich.

Das ist mit HTML 4 nur sehr schwer erreichbar. Viele Leute haben sich zur Zeiten von HTML 4 den Kopf über eine maschinelle Überprüfung zerbrochen. Darüber habe ich auch ich einen Blogpost geschrieben. Es ist sehr, sehr schwierig. Man muss die Dokumenttyp-Definition und die SGML-Deklaration von HTML 4 abändern, um sie quasi in XML-Syntax zu überführen, damit man überhaupt klare Regeln aufstellen und maschinell überprüfen kann. XHTML hingegen lässt sich mit vernünftigen Schemas überprüfen, was viel besser ist als die DTD-Validierung, die die einzig mögliche ist bei HTML 4.

XHTML hat seine Vorteile, aber letztlich hat es sich nicht durchgesetzt. Tim Berners-Lee, der Erfinder des Webs, ist bald zu der Einsicht gekommen: Some large communities did shift [to XML] and are enjoying the fruits of well-formed systems, but not all. Das heißt viele haben eingesehen, dass ihnen die XML-Plattform etwas bietet. Mit den wohlgeformten Systeme lässt sich robuster arbeiten als mit SGML-Sprachen wie HTML. Aber trotzdem hat sich die Idee, dass XHTML HTML ablöst, nicht durchgesetzt. XHTML war zum großen Teil ein Fehlschlag, zumindest in der Hinsicht, das XHTML im Browser als XML verarbeitet werden sollte. Nichtsdestoweniger ist XHTML sehr weit verbreitet! Aber es wird eben nicht als XML verarbeitet, sondern weiterhin als HTML-4-Tag-Soup. Das ist ein Feature von XHTML 1: Wegen der Fehlertoleranz der Browser kann man XHTML auch einfach als HTML-Tag-Soup verarbeiten. Zumindest praktisch, theoretisch gibt es diese Kompatibilität nicht. Deswegen gibt es viele Seiten, die mit einem XHTML-Dokumenttyp arbeiten, aber letztlich im Browser genauso verarbeitet werden wie HTML 4. Der Vorteil liegt eben auf der Autorenseite und der Serverseite. Dort kann man das XML-Ökosystem nutzen, also jegliche Tools verwenden zur Qualitätssicherung und zur Generierung.

XHTML hat ohne wirklichen Grund eine geschichtliche Entwicklung angestoßen, denn XHTML wurde als streng wahrgenommen. Von der Syntax her stimmt das, aber vom Sprachumfang ist XHTML 1.0 identisch mit HTML 4. Trotzdem war XHTML einer der Startimpulse für die Webstandards-Bewegung. Im Zuge dessen haben sich die Webentwickler erstmals sauberen und semantischen Code auf die Fahnen geschrieben. XHTML war dazu ein strategisches Kampfmittel, obwohl man guten und schlechten Code genauso in HTML 4 und XHTML 1 schreiben kann. Beide haben Strict und Transitional. Aber mit XHTML hat die Idee Verwendung gefunden, den Inhalt in gut strukturiertem HTML zu schreiben. Die Präsentation wird in CSS ausgelagert, das Verhalten in externen JavaScript-Dateien, anstatt alles zu vermischen. Das ist wieder die alte Idee des Generic Coding.

Erfolge von XHTML

XHTML ist nicht ganz tot, es gibt Bereiche, in denen XHTML sehr erfolgreich war. Thomas Meinecke hat mich letztens darauf hingewiesen, dass das ePub-Format, ein sehr verbreitetes Format für eBooks echtes XML ist. XHTML wurde modularisiert, sodass verschiedene kleine Sprachen enstanden, die aus dem HTML-Vokabular gebaut sind. Man kann sich Minimalsets zusammenbauen wie es eben eBooks sind. Als dieses modularisierte HTML ist XHTML erfolgreich.

Soweit zur XML-Ära. Diese ist genauso wie die SGML-Ära letztlich gescheitert, sie war ein Dead End der HTML-Geschichte.

3. XHTML 2

Nun komme ich zum dritten Kapitel, das ist eher klein ist. Es ist eine Zwischenperiode, nämlich XHTML 2. Das ist noch einmal ein ganz anderer Ansatz als XHTML 1. XHTML 1 war nichts anderes als HTML 4 plus XML-Syntax, während hingegen XHTML 2 der Versuch war, noch einmal alles auf den Kopf zu stellen, eine neue Sprache zu entwickeln, die rein auf XML basiert. Eine Abwärtskompatibilität wurde nicht angestrebt. Sowohl inhaltlich als auch technisch können die Browser XHTML 2 nicht verarbeiten und darstellen. Das Vokabular ist ähnlich zu XHTML 1 und HTML 4, aber man wollte eben nicht das alte Vokabular erweitern und bereinigen, sondern formulierte es komplett neu. Viele Elemente wurden hinübergerettet, andere wurden in ihrer Bedeutung geändert und umbenannt. Das W3C verrannte sich in diese Strategie der reinen XML-Sprache. Die zugrunde liegende Idee war wieder die Modularisierung, man splittete alle Techniken in HTML in verschiedene XML-Sprachen auf. Man nahm z.B. alle Formulare heraus. Man hatte richtig eingesehen, dass die Formulare in HTML nicht mehr können müssen. So erfand das W3C kurzerhand eine neue XML-Sprache. Und die große Idee hinter XML ist, all diese Sprachen in einem XML-Dokument über verschiedene Namensräume zusammenzuführen. Diese Sprache für die Formulare heißt XForms.

Es wurde mehrere Jahre an XHTML 2 entwickelt, aber die Browserhersteller freundeten sich nie damit an und es gab auch keine Implementierungen. XHTML 2 hatte sehr gute Ideen, die auch fortgewirkt haben. Diese waren kein totes Ende in der Geschichte, aber zumindest in diesem Kontext kamen sie nie zur Reife. Letztlich wurde XHTML 2 im Jahr 2009 komplett eingestellt. Dazu komme ich noch einmal, wenn ich über HTML5 spreche. Nachdem schon XHTML 1 nicht die Früchte trug, die man sich davon erhoffte, war XHTML 2 schließlich das komplette Scheitern.

4. HTML5 und WHATWG

Der vorletzte große Teil. Das ist die Ära, in der wir uns derzeit befinden. Was ist HTML5? Ursprünglich eine Erhebung der Browserhersteller. Während der XML-Ära war das W3C losgekoppelt und hat sein XML-Ökosystem entwickelt, ohne dass es darauf von den Browserherstellern Anworten gab. Wie gesagt, diese Techniken wurden nie implementiert. So folgte eine kleine Revolution. Die Browserhersteller stellten sich hin und sagten: Wir wollen XHTML 2 nicht, wir wollen nicht, dass das die Zukunft für das Web ist. Kurzerhand gründeten sie ihr eigenes Gremium zur Erarbeitung von technischen Standards. Dieses Gremium heißt WHATWG, Web Hypertext Application Technology Working Group. Den Titel muss man nicht zu ernst nehmen, aber darin steckt Hypertext Application. Das zeigt auch schon, wo die Entwicklung hingeht und was die Browserhersteller damit bezwecken. Sie haben ein ganz klares Ziel, sie wollen Webanwendungen bauen. Damit meinen sie in erster Linie Rich-Client-Anwendungen.

Ursprüngliche Ziele der WHATWG

  1. Ursprünglich ging es der WHATWG um etwas anderes. Sie fing mit der Frage an, wie man verschiedene Sprachen in HTML einbetten kann. Die Lösung des W3C war: Man verwendet XML-Sprachen und diese kann man einfach ineinander verschachteln. Wenn man XHTML benutzt, kann man einfach SVG (Vektorgrafiken) direkt einbinden. In XHTML stellt sich das Problem nicht, weil die XML-Plattform darunter bereits die Lösung bietet. Aber diese Lösung wollten die Browserhersteller nicht.
  2. Der zweite ursprüngliche Punkt der WHATWG war die Verbesserung der Formulare in HTML. Und zwar nicht mit der neuen separaten Sprache XForms, sondern evolutionär mit Erweiterungen zum bestehenden HTML-Vokabular. Bevor man überhaupt von HTML5 geredet hat, war die erste Spezifikation, die die WHATWG erarbeitet hat, Web Forms 2.0. Das war ein evolutionärer Verbesserungsvorschlag für Formulare in HTML.
  3. Ein weiterer wichtiger Punkt war die Standardisierung von JavaScript-Features. Zu der Zeit, als sich die WHATWG gründete, kamen gerade die Ajax-Anwendungen auf. Websites wie z.B. GMail haben JavaScript-Features benutzt, die zwar existent waren, aber noch nicht wirklich standardisiert waren.

Das waren anfänglichen Ziele der WHATWG, also HTML evolutionär weiterzuentwickeln. Für diese geschichtlichen Anfänge verweise ich auf einen Eintrag von Tim Tepaße im SELFHTML Aktuell Weblog aus dem Jahr 2006. Dieser ist immer noch aktuell, weil er die Entwicklung schildert, wie die Browserhersteller dazu kamen, eine eigene Gruppe zu gründen und eigene Spezifikationen zu entwickeln.

Umfassende Reform unter dem Begriff HTML5

Wie gesagt blieb es nicht bei diesen drei gerade aufgezählten Hauptrichtungen. Letztlich wurde der Prozess, den die WHATWG anstoß, unter dem Namen HTML5 zusammengefasst. HTML5 umfasst nicht nur evolutionäre Weiterentwicklung von HTML, sondern räumt mit dem technischen Fundament auf. Die großen beiden Ansätze für HTML, die theoretischen Fundamente, werden über den Haufen geworfen. HTML5 definiert HTML komplett neu, nämlich weder auf SGML noch auf XML basiert. Es wird von Grund auf neu und hundertprozentig genau definiert. Das bedeutet:

  1. Die Sprache selbst wird nicht mehr als DTD oder als XML-Schema festgelegt, also nicht mehr maschinenlesbar. Es gibt nicht mehr ein maschinenlesbares, normatives Format, was die einzige richtige, normative Grammatik von HTML darstellt. Stattdessen wird die Sprache als abstraktes DOM, als Dokument-Objektmodell definiert.
  2. Diese Sprache ist natürlich nicht nur völlig abstrakt im Speicher wie das DOM, sondern es gibt sogenannte Serialisierungen. Das ist das, was wir als HTML-Code bezeichnen. Der springende Punkt ist, dass HTML5 nicht nur eine Serialisierung definiert, wie es HTML 4 bzw. XHTML 1 getan haben, sondern es gibt zwei Serialisierungen, die an diese beiden anknüpfen. Die eine ähnelt SGML, aber funktioniert nach eigenen Regeln. Die andere ist XML-konform. Das heißt, HTML5 lässt sich wie HTML 4 schreiben oder wie XHTML 1. Der Anspruch ist, dass jegliches HTML im Web gemäß HTML5 verarbeitet werden kann. Was nicht HTML5 ist, ist XML, und zwar nur dann, wenn es mit dem richtigen MIME-Typ ausgeliefert wird. XHTML5, wie man die XML-Serialisierung nennt, ist nicht mehr kompatibel wie XHTML 1 war. Man kann nicht XHTML5 mit dem MIME-Typ text/html ausliefern, denn dadurch wird es definitionsgemäß zu HTML5 und kann als HTML5 verarbeitet werden. Den Unterschied macht eben der MIME-Typ. Das ist ganz anders als bei XHTML 1.
  3. Den dritten Punkt, den HTML5 definiert, ist der Parser. Weil HTML5 nicht mehr auf SGML oder XML basiert, muss es genau definieren, wie diese Serialisierungen, dieser HTML-Code geparst wird. Dieser Parser ist nicht allgemein, wie es ein XML-Parser ist, sondern genau auf HTML zugeschnitten. Für jeden einzelnen Elementyp gibt es eigene Parser-Regeln. Entscheidend ist, dass dieser Parser genau so funktionieren soll wie die Tag-Soup-Parser, die schon in den Browsern eingebaut sind. Das Problem mit den Tag-Soup-Parsern war, dass jeder nach seinen eigenen Regeln funktionierte. HTML5 ist der Versuch, diese zu vereinheitlichen. Sie sollen mit Fehlern im HTML, die es zuhauf im Web gibt, einheitlich umgehen. Es soll determiniert sein, was aus einem Quelltext wird, also welches DOM aus einem bestimmten Eingabestream geparst wird.

Grundideen von HTML5

Wie schon fast alle HTML-Spezifikationen vorher wird HTML5 den Browsern hinterhergeschrieben. Das heißt, man will kompatibel sein mit der aktuellen Verarbeitung. Die Parsing-Definition richtet sich nach den existenten Parsern. Der wichtigste Punkt ist demnach die Abwärtskompatibilität mit den vorhandenen HTML-Inhalten im Web.

Das Prinzip von HTML5 lautet Paving the Cowpaths, das heißt soviel wie Pflastern der Trampelpfade. Die vielen proprietären Techniken, die es in HTML und JavaScript gibt, sollen standardisiert werden – das macht HTML5. Es geht vor allem um JavaScript-Techniken aus dem HTML-DOM, aus dem BOM (Browser Object Model), welches vorher nur in der Dokumentation zum Netscape-Browser beschrieben war. Es wird jetzt erstmals standardisiert. Es ist schon seit 10 Jahren verbreitet und einheitlich, aber HTML5 ist der erste Standard, der es normativ aufschreibt und festlegt. Hinzu kommen Features vom Microsoft Internet Explorer, JavaScript-Features aus JScript, diese Verbreitung fanden. Gute Ideen, die andere Browserhersteller einfach nachbauten, erklärt HTML5 jetzt zum Standard und definiert genau, wie sie funktionieren sollen.

HTML5 hat keine Version

In HTML5 steckt eine Nummer im Namen. Die HTML5-Macher bestehen jedoch darauf, dass diese Nummer keine Versionsnummer ist. Deswegen soll HTML5 auch ohne Leerzeichen zwischen HTML und 5 geschrieben werden. Dahinter steckt, dass HTML5 keine feste, abgeschlossene Version sein soll. Die HTML5-Macher wollen HTML5 immer weiter verbessern und neue Features hinzufügen. Dabei bleiben sie rückwärtskompatibel, aber legen Wert auf ständige Ausbaubarkeit. Man will nicht den Fehler von HTML 4 machen, irgendwann anzuhalten und die Spezifikation nicht mehr weiterzuentwickeln. HTML5 soll immer im Fluss bleiben. Dahinter steckt de etwas wahnwitzige Idee, dass HTML5 das Ende der Geschichte ist: HTML5 sieht sich nicht als eine Version ist, wonach eine neue Version kommt. HTML5 setzt sich als Modus Operandi, wie die Zukunft weiterlaufen soll. Wenn irgendetwas Neues kommt, dann auf Basis von HTML5. Das muss man meiner Meinung nach hinterfragen, darauf werde ich am Ende noch einmal eingehen.

HTML5 als Projekt der Browserhersteller

HTML5 wird von Leuten entwickelt, die hauptsächlich bei den Browserherstellern angestellt sind hauptsächlich, zumindest auf Seiten der WHATWG. Das sind die Browserhersteller Opera, Apple und Mozilla. Mozilla steht ein bisschen außen vor, implementiert natürlich die Techniken, aber gibt nicht so viele Impulse, soweit ich das weiß. Zunehmend stark nimmt der Browserhersteller Google Einfluss. Der Hersteller des verbreitetsten Browsers, nämlich Microsoft, ist bei der HTML5-Entwicklung außen vor. Niemand kann sich erklären, warum der größte Softwarekonzern die anderen Browserhersteller machen lässt und keine Impulse setzt. Es gibt einen Microsoft-Mitarbeiter, der sich auf den einschlägigen Mailinglisten äußert, aber Microsoft nimmt nicht wie Opera, Apple und Google direkten Einfluss auf die Entwicklung von HTML5. Auf Seiten der WHATWG sind es gerade einmal 5-10 Angestellte von Browserherstellern, auf die sich die maßgeblichen Impulse zurückführen lassen. Die Community ist natürlich größer, aber die Entscheidungsträger werden von Browserherstellern bezahlt. Über diese Situation habe ich einen Artikel geschrieben, HTML5: Ein soziales Desaster?. Dieser geht darauf ein, dass HTML5 im Grunde von einer Person, nämlich dem Google-Angestellten Ian Hickson gesteuert wird. Er ist der HTML5-Editor (Herausgeber). Faktisch ist er der einzige, der Änderungen an der HTML5-Spezifikation vornimmt. Alles muss über seinen Schreibtisch und er hat einen großen Einfluss. Auch wenn er nur eine vermittelnde Rolle einnimmt, ist er die wichtigste Figur. Hinter Ian Hickson steht Google mit ganz bestimmten Vorstellungen und Interessen.

Das Web als Anwendungsplattform

Google möchte das Web zu einer Plattform für Anwendungen machen. Google hat mit großen Webanwendungen wie Google Docs, Google Maps und GMail Ajax populär gemacht und den Fat Client in das Web eingeführt. Es ist eine begrüßenswerte Entwicklung, dass HTML jetzt nicht mehr getrennt von anderen Techniken der Webplattform entwickelt wird. HTML5 ist eben nicht mehr nur eine Auszeichnungssprache, HTML5 ist dieser Sammelbegriff, der alle momentanen technischen Neuerungen bezeichnet. Ein Beispiel: HTML5 trennt die Definition von Auszeichnungssprachen-Elementen nicht mehr von der API, über die man auf diese Elemente zugreift. Das DOM ist direkt in der Definition der Sprache eingebaut. Wichtig sind ferner die zusätzlichen JavaScript-APIs, die nicht alle Teil der HTML5-Spezifikation sind, aber in der WHATWG entwickelt werden. Das Ziel von Google ist, dass die Webplattform mit Desktop-Anwendungen konkurrieren kann. Googles Betriebssystem für Netbooks, Google Chrome OS, ist dafür ein gutes Beispiel. Auf diesem Betriebssystem laufen keine klassischen Anwendungen mehr, die in C oder C++ geschrieben sind. Es laufen nur noch Webanwendungen, diese alles können sollen, was auch native Anwendungen können. Die Anwendungen sind in JavaScript geschrieben und benutzen HTML5-Techniken. Das ist die Herangehensweise von den Browserherstellern, die sie HTML5 ins Buch und in die Spezifikation schreiben.

Dies ist ein ganz anderer Ansatz, als ihn das W3C ihn verfolgt hatte. Natürlich wollte das W3C das Web auch einer Anwendungsplattform machen, aber mit anderen Techniken und einer anderen Herangehensweise. Das W3C wollte keinen Schwerpunkt auf JavaScript legen, sondern eher deklarative Ansätze verfolgen. Das W3C hat dahingehend eine andere Philosophie. Dementsprechend ist HTML5 eine riesige Spezifikation, wo alles mögliche drin steht, was zum Anzeigen von HTML im Browser bis zum Scripten mit JavaScript dazugehört. Das ist ein Abschied von der ursprünglichen Idee, dass HTML eine plattformübergreifende, abstrakte Textauszeichnungssprache ist. Nicht mehr wissenschaftliche Dokumente sind für HTML5 maßgeblich.

Neues HTML5-Markup

Ich möchte kurz darauf eingehen, was stattdessen maßgeblich für die Textauszeichnung ist, die mit HTML5 möglich ist.

  1. Eine Gruppe von neuen Elemente existiert nur, damit man über einheitliche Scripting-APIs darauf zugreifen kann. HTML 4 hatte die Idee, zum Einbetten externer Dateien wie Audio, Video, Plugins und Bildern einfach das object-Element zu nehmen. Die radikale Idee war, im Grunde alles über ein Element zu einzubetten, egal was. XHTML 2 hat diese Idee noch viel weiter getrieben, hat object abgeschafft zugunsten des src-Attributs. Damit konnte man in jedes beliebige Element jede beliebige externe Datei einbinden. Das macht HTML5 nicht, sondern definiert neue Elemente wie audio, video und canvas für ganz spezifische Zwecke, die eine ganz spezifische, vordefinierte API bieten. Das gab es vorher nicht. Vorher war Audio- und Videoeinbettung von Plugins dominiert, welche keine einheitliche Schnittstelle bieten. Man wusste nicht, welches Plugin letztlich zur Wiedergabe verwendet wurde. Es gab Quicktime, Windows Media Player, Real Player und so weiter mit ganz unterschiedlichen APIs. Um das zu vereinheitlichen, führt HTML5 spezifische Elemente ein.
  2. (…) Was der ursprünglichen Idee von HTML entspricht, sind die neuen Strukturelemente. HTML folgte wie gesagt einem Ideal von wissenschaftlichen Arbeiten, wie man sie an der Universität erstellt, also Hausarbeiten, Diplomarbeiten, die ganz klassisch aufgebaut sind. Es gibt eine hierarchische Überschriftenstruktur, so etwas wie Einleitungen, Literaturverzeichnisse usw. Bei HTML5 nimmt man als Grundlage die Textformate, die es im Web gibt. Man schaut sich an, wie Webmagazine und Blogs aufgebaut sind. Dafür gibt es jetzt die Elemente nav, article, section, header, footer, aside, menu und auch time. Dieses Vokabular entspricht der tatsächlichen Struktur von Dokumenten im Web. Das ist eine Abkehr von einem allgemeinem Markup, das für allgemeine Texte zuständig ist. Etwa bei einem eBook macht so etwas wie header und footer nur wenig Sinn, so etwas wie menu und nav gibt es nur auf Websites. HTML5 macht ein erfreulichen Schritt dahin, Textauszeichnung für Websites zu bieten.
  3. Eine weitere neue Klasse von Elementen sind die, die nur für Webanwendungen gedacht sind, genauer für Bedienelemente und Controls. progress, meter und command machen nur im Kontext von dynamischen Webanwendungen Sinn, die die Elemente per JavaScript ansprechen.
  4. Der Entwurf Web Forms 2.0 für verbesserte Formulare wurde in HTML5 aufgenommen. Es gibt neue Formularfeldtypen und man kann angeben, welche Eingaben im Formular zulässig sind. In diesem Punkt hat man viel von XForms gelernt, aber man hat es einfacher umgesetzt.
  5. Ein Punkt, der auch bei dem Entwurf von XHTML 2 eine wichtige Rolle gespielt hat, sind Metadaten, echte maschinenlesbare Semantik. Es gibt zwei große Ansätze.

    Der eine ist RDFa. RDF, das ist das Ressource Description Framework vom W3C. Das ist schon ziemlich alt und etabliert. Es ist der wichtigste Standard, um maschinenlesbare Aussagen über etwas zu machen. Man geht von einem Set an sogenannten Prädikaten aus und formuliert damit Aussagen wie zum Beispiel »der Name vom Autor dieses Dokuments ist molily«. Es wird daran gearbeitet, diese Metadaten direkt in HTML5 einzubinden.

    Ein konkurrierender Vorschlag für eingebundene Metadaten nennt sich Microdata. Dieser RDFa-Konkurrent will einfacher sein und wurde vom HTML5-Editor Ian Hickson erfunden. Manche sagen, Hickson verfolge eine Not-invented-here-Strategie. RDFa passt den HTML5-Machern nicht so recht ins Konzept. Damit haben sie nicht Unrecht, denn RDFa stammt aus dem XML-Kontext, von dem sich HTML5 programmatisch lösen will. Daher gibt es einen kleinen Formatkrieg zwischen RDFa und Microdata. Es ist jedoch ganz erfreulich, dass das W3C entschieden hat, dass beide Entwürfe weiterentwickelt werden sollen und der Markt entscheiden soll, welches Format besser ankommt. Meine Prognose ist, dass sich beide durchsetzen werden. Viele große Unternehmen unterstützen RDFa, aber Microdata mausert sich. Es gibt mittlerweile auch viele Anwendungen, wenngleich es noch nicht so etabliert ist. Ich halte es Microdata für vielversprechend und finde es nicht schlecht, dass es diese beiden Möglichkeiten gibt und man langfristig die Tools, die in der RDF-Welt schon entstanden sind, weiternutzen kann.

Das war der Überblick über die neuen Herangehensweise hinsichtlich des Vokabulars. Damit schließe ich den Teil zu HTML5 ab.

5. Gesamtfazit und Ausblick

Falls es noch nicht klar geworden ist, HTML5 hat letztendlich gewonnen. Es gab die These SGML, die Antithese XML und die Synthese von beidem, die beide auf einer höheren Ebene aufhebt, ist HTML5. Es bietet ein verbesserte SGML-artige Syntax, aber man kann es gleichzeitig als XML verarbeiten. Es steht einem frei, beides zu tun, denn HTML5 kann gleichzeitig HTML5 und XHTML5 sein. Beide Serialisierungen sind zueinander kompatibel. Insofern ist HTML5 die Synthese der beiden vorherigen Ansätze.

Im Jahr 2006 sah das W3C ein, dass sein radikaler XML-Ansatz, das Web komplett auf eine XML-Basis zu stellen, fehlgeschlagen ist. Es sah ein, dass sich XHTML 2 nicht etablieren konnte und gestand ein: Es ist richtig, HTML evolutionär weiterzuentwickeln, also auszubauen und aufzuräumen. Dafür gründete das W3C im Jahr 2007 eine neue HTML-Arbeitsgruppe, die damals noch parallel zur XHTML-2-Arbeitsgruppe lief. Diese Arbeitsgruppe übernahm den WHATWG-Vorschlag als Grundlage für das neue HTML. Das heißt, HTML5 wird heute – das erklärt einiges, was ich vorher gesagt habe – auf zwei Seiten entwickelt, gleichzeitig bei der WHATWG und in dieser W3C-Arbeitsgruppe. Letztlich stellte das W3C XHTML 2 ist im Jahr 2009 komplett ein. Sie sahen ein, dass XHTML 2 eine Sackgasse ist und entzogen der Arbeitsgruppe die finanzielle Unterstützung. Insofern hat HTML5 gewonnen.

Shipping code wins?

Damit komme ich an den Anfang zurück. Mark Pilgrims Text erzählt die Geschichte von HTML, wie auch ich sie hier zu erzählen versucht habe. Was ist nun an diesem Text biased (parteiisch)? Seine Frage war: wie funktioniert Standardisierung von HTML? Sein Fazit ist: Letztlich sind es die Browserhersteller, die die akademischen und ein wenig abgehobenen Diskussionen um die richtige Lösung weitesgehend ignorieren, einfach ein Feature erfinden und in den Browser einbauen, denn dann ist das Feature da. Pilgrim meint: The ones that win are the ones that ship. Das heißt, diejenigen Browserhersteller gewinnen, die ein Feature implementieren und damit einfach Tatsachen schaffen. Das ist eine ziemlich kritikwürdige Erklärung der Geschichte. Zunächst einmal ist es eine nüchterne Feststellung, die den Tatsachen entspricht: Diese Regel hat sich bisher bewahrheitet. Fast immer, wenn die Browserhersteller eine Technik in die Welt gebracht haben, hat sie sich mehr oder minder durchgesetzt gegenüber den akademischen Entwürfen des W3Cs, selbst wenn diese viel reiner waren und mehr Vorteile hatten. Letztlich sind die einfachen, schnell hingestellten Techniken geblieben.

Ich finde das eher problematisch. Man muss dazu sagen, dass Mark Pilgrim mittlerweile bei Google an HTML5 arbeitet. Sein Interesse ist klar, er rechnet sich dem HTML5-Lager zu. Er war einer derjenigen, die berechtigte Kritik am W3C übten, als es sich komplett auf XHTML 2 eingeschworen hatte und dachte, die Zukunft des Webs liege in einer rosigen XML-Plattform mit vielen XML-Modulen, die man miteinander auf einer Website verknüpft.

Wie gesagt besteht die HTML5-Crew größtenteils aus Angestellten von Browserherstellern und insofern muss man das als die eine radikale und verkürzte Seite sehen: Sie verständigen sich auf umsetzbare Standards, bauen sie ein und schaffen damit Fakten. Es stimmt, bisher ist das immer so passiert, aber es ist nicht ohne Probleme. Es gab einen schönen Podcast namens HTML5 is a (beautiful) mess. Der hat gezeigt, welche Kämpfe es momentan um die Zukunft des Webs gibt. Das Web, was im Zuge von HTML5 entsteht, ist ein ganz bestimmtes. Etwa die Vorstellung des W3C für das Web geht in eine ganz andere Richtung. Und meiner Meinung nach haben beide Richtungen ihre Vor- und Nachteile. Deswegen finde ich es falsch, dabei stehenzubleiben, dass die Browserhersteller durch das Ausliefern von Code immer gewinnen werden. Ich halte das nicht für die einzige Möglichkeit, wie ein Standard entstehen kann. So stellt es zumindest Mark Pilgrim dar und mit dieser Ansicht bringt er sich in HTML5 ein.

Konkurrenz der beiden HTML5-Arbeitsgruppen

Glücklicherweise gibt es noch eine Systemkonkurrenz. Die einstige große Konkurrenz zwischen dem W3C und der WHATWG gibt es zumindest noch teilweise. Einerseits gibt es die WHATWG, die weiterhin autonom arbeitet, aber es gibt auch die W3C-HTML-Arbeitsgruppe, die der WHATWG etwas entgegenstellt. Beide Parteien arbeiten gemeinsam an HTML5. Das ist wie gesagt eine Quelle der Konflikte und Zerwürfnisse. Aber es ist auch gut, dass sich hier noch zwei Gruppen gegenüberstehen, sich gegenseitig herausfordern und im Grunde zwei unterschiedliche Ansätze verfolgen. Zumindest ist das besser, als wenn es nur die eine Partei gäbe.

Wie ich auch in meinem Artikel HTML5: ein soziales Desaster? angemerkt habe, ist HTML5 eine Soap-Opera, weil es diese ständigen Konflikte gibt. Manche sagen: Weil HTML5 im Gegensatz zu anderen früheren Standardisierungsprozessen sehr offen ist, merkt die Öffentlichkeit erstmals, wie schwierig und konfliktreich es ist, einen Standard zu entwickeln. Aber man muss schon festhalten, dass ziemlich etwas faul ist am HTML5-Prozess. Es gibt viele berechtigte Kritik daran.

Die Frage, ob HTML5 ein Erfolg wird, beantworten viele schon jetzt mit Ja: HTML5 sei schon jetzt viel erfolgreicher, als es alle vorherigen HTML-Standards es waren. Das würde ich differenzierter sehen. Aus JavaScript-Sicht ist HTML5 sicher ein Erfolg und Google wird seine Webplattform bekommen. Dafür haben sie einen Masterplan, wie sie die neuen HTML5-JavaScript-Techniken in ihrem Chrome-Browser umsetzen. Es ist nur noch eine Frage der Zeit, bis HTML5 als Anwendungsplattform im Web richtig etwas kann. Das wird so sein, weil Google Ian Hickson anstellt, der die HTML5-Spezifikation schreibt.

Wird HTML5 ein Erfolg werden?

Eigentlich geht es in diesem Vortrag um HTML als Auszeichnungssprache. Wird HTML5 als Auszeichnungssprache ein Erfolg sein? Ich finde, das ist noch nicht geklärt. HTML5 versucht eine Synthesis aus den vorhergehenden Ansätzen zu sein. Ich habe aufgezählt, welche Elemente sicher ein Erfolg sein werden. Nämlich die, mit denen HTML5 Textauszeichnung genuin für das Web erfindet. Und nicht mehr Textauszeichnung für irgendwelche wissenschaftlichen Dokumente, die es im Web nur zu einem Bruchteil gibt. HTML5 als Auszeichnungssprache ist den aktuellen Mustern nachempfunden. Das ist Design by Data: Man schaute sich an, welche Strukturen es im Web gibt. Man erhob einfach Daten und schaute, welche Strukturen häufig vorkommen und goss diese in den Standard. Das ist ein typischer Ansatz von Google. Google verfolgt in vieler Hinsicht diesen Ansatz und verfolgte ihn auch bei HTML5, indem es diese Untersuchung sponserte. Google stellte Ian Hickson ein, damit er mit dem riesigen Google-Suchindex das HTML des Web untersuchen kann und existierende Strukturen suchen kann, die man standardisieren könnte.

Die Einschränkung ist momentan noch: Es gibt noch keinen HTML5-Parser, der wirklich ausgereift ist. Ein bekannter Engagierter aus der HTML5-Szene, Henri Sivonen, hat einen HTML5-Parser in Java geschrieben, der nach und nach heranreift. Dieser Parser wird automatisch von Java in C++ übersetzt und diese C++-Version wird in Gecko eingesetzt, die Browserengine, die Firefox zugrunde liegt. Der Parser kann getestet werden, indem man sich einen Firefox-Nightly-Build (eine Vorabversion) herunterlädt und eine bestimmte Konfigurationsoption anschaltet. Wenn man dann auf HTML5-Seiten surft, wird der HTML5-Parser genutzt. Das ist die erste praktische Anwendung von HTML5 als revolutionär neue Sprache, die nicht auf Tag-Soup-Parsern basiert, nicht auf SGML, nicht auf XML, sondern einen eigenen, im Detail definierten Parser verwendet. Wann diese Idee Realität sein wird, steht noch in den Sternen und wird noch Jahre dauern. Es wird noch ziemlich lange dauern, bis wir die Früchte ernten können, die HTML5 gerade sät – zumindest was HTML5 als Auszeichnungssprache angeht.

Authoring Tools und Validatoren sind auch noch in der Entwicklung. Ich glaube, der einzige HTML5-Validator wird auch von Henri Sivonen entwickelt. Den habe ich schon häufig eingesetzt, er hat einfach noch Usability-Probleme und ist noch nicht für das breite Publikum brauchbar.

HTML5 ist nicht das Ende der Geschichte

Was man hinterfragen sollte, ist das Selbstverständnis von HTML5 als Ende der Geschichte. Das muss sich noch zeigen. Daran glaube ich nicht. So alt ist das Web noch nicht und es gab jetzt schon zwei bis drei große Umbrüche. Es wird irgendeinen Umbruch geben in Zukunft, der auch HTML5 über den Haufen werfen wird. Ich bin auch nicht der Meinung, dass HTML5 die einzige Möglichkeit ist, wie man Standards baut, nämlich der Browserrealität hinterherzuschreiben und nur das zu implementieren, was gerade im Interesse der Browserhersteller steht. Die Webanwendungsschiene ist noch nicht so alt, irgendetwas wird danach kommen. Wenn HTML5 als Anwendungsplattform steht, dann muss sich das Web neue Ziele suchen. Deswegen bin ich der Meinung, dass HTML5 auch nur eine Nummer in einer Reihe ist. HTML5 wird irgendwann gehen und andere Techniken werden kommen. Irgendwann wird das, was mit HTML 2 in die Welt gebracht wurde, dieses Vokabular, diese Herangehensweise, ihr Ende haben. Dann wird es nötig sein, wie das W3C es eigentlich auch geplant hatte mit XHTML 1 und XHTML 2, eine Alternative zu schaffen, die alles über den Haufen wirft und modular von Grund auf neu macht.

Das ist meine Prognose und mein Fazit, das ich aus der Geschichte von HTML ziehe. Es steht dem entgegen, wie HTML5 momentan verstanden wird oder zumindest propagiert wird von den Machern von HTML5. Diese sehen ihre Strategie an als die, die sich historisch durchgesetzt hat, und deshalb sehen sie sich ultimativ im Recht. Sie haben auch viele gute Argumente und es stimmt in vieler Hinsicht: Deren Entwicklungsmodell funktioniert momentan, die Innovation in den Browsern galoppiert. Vor allem der JavaScript-Bereich ist momentan sehr dynamisch und wird gehyped. Interessanter fände ich eine Weiterentwicklung der Auszeichnungssprache. Wenn es möglich sein wird, das mit HTML5 zu machen, was gerade geplant ist, dann können wir noch einmal darüber reden: Das ist die native Einbettung von SVG und MathML, die Verwendung von RDFa und Microdata. Wenn diese Ideen, die im Grunde das W3C mit seinem XML-Ökosystem hatte, in HTML5 möglich sind, dann hat sich die Vision von HTML5 verwirklicht. Und das dauert meiner Vermutung nach noch ein paar Jahre.

Das war meine Erzählung der HTML-Geschichte. Vielen Dank fürs Zuhören.

Links