HTML5 ist seit einiger Zeit in aller Munde und jeder hat so seine eigene Vorstellung davon, was es eigentlich bedeutet. Sicher ist nur: HTML5 wird das, was man unter einem Webbrowser versteht, gründlich verändern und es wird mit Sicherheit kommen –Alternativen wie XHTML 2 sind aus dem Rennen. Vieles an HTML5 ist etwas komplizierter, als man von Webstandards gewohnt ist. So gibt es nicht eine HTML5-Spezifikation, sondern gleich zwei, die auch nicht identisch sind und von unterschiedlichen Arbeitsgruppen geschrieben werden. Und weil selbst das noch viel zu einfach wäre, wird ein großer Haufen sonstiger Technologien, die eigentlich nichts mit den beiden HTML5-Spezifikationen zu haben, ebenfalls gerne zu HTML5 gerechnet.
Neben der Kardinalfrage „Was kann HTML5?“ ist vor allem interessant, ab wann HTML5 einsatzbereit ist und wie es zu der schon beschriebenen, etwas chaotischen Konstellation kommen konnte. Dieser Artikel ist der Auftakt zu einer kleinen Serie, die diese Fragen erkunden soll. Was einzelne Teile von HTML5 leisten können, werden wir in den Beiträgen, die im Laufe der nächsten zwei Wochen erscheinen, erfahren. Die Frage nach einem Termin für HTML5 lässt sich hingegen in einem Satz beantworten: HTML5 ist genau genommen schon längst da und mit dem Erscheinen des Internet Explorer 9 werden alle Browser HTML5 (in unterschiedlichem Umfang) unterstützen. Die Frage nach der etwas unübersichtlichen Gesamtsituation beantwortet sich schließlich aus der Entstehungsgeschichte von HTML5, denn ein geplantes Kind ist es nicht.
HTML, SGML, XHTML, WTF?
Was viele nicht wissen, ist, dass kein Browser der letzten 20 Jahre jemals HTML so unterstützt hat, wie es eigentlich in den Standards steht. Tim-Bernes Lee hatte seine Web-Auszeichnungssprache seinerzeit als eine SGML-Anwendung konzipiert und das Verhältnis zwischen SGML und HTML muss man sich so vorstellen, wie das zwischen XML und XHTML – ersteres ist eine allgemeineren Auszeichnungssprache, mithilfe derer eine spezialisiertere Auszeichnungssprache umgesetzt wird. Doch die Kombattanten des Browserkrieges hatten besseres zu tun, als korrekte SGML-Parser zu schreiben (z.B. und JavaScript erfinden) und konstruierten stattdessen eigene Algorithmen, die sich dadurch auszeichneten, dass sie auch extrem fehlerhaftes HTML problemlos schluckten. Der so genannte Tag-Soup-Parser war geboren.
Das sind eigentlich nur technischen Details, aber natürlich steht es einem World Wide Web Consortium nicht gerade gut zu Gesicht, wenn alle Welt ihre Standards so dreist ignoriert. Also plante das W3C einen HTML-Reboot namens XHTML. Statt auf SGML sollte das Web in Zukunft eben auf XML basieren und durch den frischen Neustart sollte das Nebeneinander von HTML-Standard und gelebter Browser-Praxis ein Ende finden. Das 1997 spezifizierte HTML 4.01 wurde 2001 mit XHTML 1 ohne inhaltliche Änderungen in XML-Form gegossen und die Arbeiten an XHTML 2 begannen. Alles war also bereit für eine glorreiche XML-Zukunft im WWW, wären da bloß nicht die Browserhersteller gewesen.
Der HTML5-Aufstand
Um das Jahr 2004 herum zeichnete sich bereits ab, in welche Richtung sich das Web bis heute entwickeln würde. Das Browser-Monopol des Internet Explorer 6 würde fallen und Konkurrenten wie Apple, Mozilla und Opera würden die technische Innovation im WWW nach den langen Jahren der IE-Dominanz wieder beleben. Ebenfalls war klar, dass die HTML-Fähigkeiten des Durchnittbürgers nicht radikal weiterentwickelt hatten und es im Web auch in Zukunft fehlerhafte Dokumente geben würde. Und schließlich erscheinen die ersten Webapplikationen am Horizont, komplexe, auf HTML, CSS und JavaScript basierende Anwendungen, die die technischen Möglichkeiten von HTML 4.01 und XHTML 1 bis zum äußersten ausreizten.
Der vom W3C angestoßene Wechsel zur neuen technischen Basis XHTML schien den Browserherstellern angesichts der sich abzeichnenden Entwicklung nicht als der richtige nächste Schritt. Dringender als solch ein Umbau erschien es, HTML (und damit den Browsern) neue Fähigkeiten einzuimpfen, mit denen man für die Webapplikationen der Zukunft gerüstet wäre. Hinzu kommt, dass X(HT)ML an sich einige gravierende Nachteile mit sich bringt. Ein einziger Fehler im Dokument führt dazu, dass gar nichts angezeigt wird und Internet Explorer bis zu Version 8 können XHTML überhaupt gar nicht verarbeiten. Die Zukunftsvision des W3C wäre also für Gelegenheits-HTML-Autoren sowie Fans von Webapplikationen oder dem IE eine recht finstere gewesen.
Die Browserhersteller trugen ihre Bedenken in den W3C-Gremien vor, stießen jedoch auf wenig Gehör. So kam es, dass am 4. Juni 2004 Vertreter von Apple, Mozilla und Opera eine eigene, vom W3C unabhängige Arbeitsgruppe mit dem Namen WHATWG (Web Hypertext Application Technology Working Group) gründeten. Das Ziel der WHATWG die Entwicklung von Technologie für Webapplikationen von HTML-Basis, mündete in dem, was wir heute als HTML5 kennen.
HTML5 versus „HTML5“
WHATWG und W3C existierten seither nebeneinander und während erstere HTML5 entwickelten, entwarf man bei letzteren XHTML 2, einen nicht abwärtskompatiblen Nachfolger von XHTML 1. Bei diesem Wettstreit um die Zukunft des Webs stand das W3C freilich nach der Gründung der WHATWG auf verlorenem Posten – während die Spezifikationen für XHTML 2 ein Papiertiger blieben, bauten die Browserhersteller fleißig die in der WHATWG beschlossenen HTML5-Features ein, testeten und verfeinerten sie. So kam es wie es kommen musste – 2007 gab das W3C auf, adaptierte HTML5 und schloss zwei Jahre später auch seine XHTML-Arbeitsgruppe. Seither steht fest: HTML5 allein gehört die Zukunft im Web.
Die Frage bleibt nun, was eigentlich HTML5 genau ist, denn die “Adaption” der Spezifikationen durch das W3C bestand darin, dass die HTML5-Spezifikationen kopiert und seither parallel zu den WHATWG-Entwürfen weiterentwickelt werden. Es gibt also heute zwei (nicht identische) HTML5-Spezfikationen, eine vom W3C herausgegebene und eine aus der Feder der WHATWG – wobei interessanterweise aber beide Arbeitsgruppen vom gleichen Mann angeführt werden. Wie genau sich diese beiden Versionen zueinander verhalten und welche Fassung man unter welchen Umständen als maßgeblich ansehen könnte, würde an dieser Stelle den Rahmen sprengen und außerdem gibt es noch ein weiteres, wichtigeres Problem: Vieles was heute als “HTML5” bezeichnet wird, steht weder in den einen HTML5-Spezifikationen, noch in den anderen.
Als die Weiterentwicklung der Browser in den letzten Jahren wieder Fahrt aufnahm, wurde an allen technologischen Fronten Gas gegeben und das, was W3C und WHATWG in ihren HTML5-Spezifikationen festlegen, ist nur ein Teil davon. Wollte man eine Karte des gesamten HTML5-Universums malen, könnte sie so aussehen:
Der große blaue Kreis innen ist HTML5 nach Version des W3C. Dieser Kreis wird vom grünen WHATWG-Kreis komplett umschlossen –beide Spezifikationen sind nicht identisch, aber im Großen und Ganzen ist W3C-HTML5 eine Teilmenge von WHATWG-HTML5. Kleine blaue Kreise bezeichnen Technologien, die eigene Spezifikationen beim W3C haben. Jene, die innerhalb des grünen WHATWG-Kreises dargestellt werden, sind also wie HTML5 zwei mal spezifiziert, einmal durch das W3C und einmal als Teil von WHATWG-HTML5. Zuletzt gibt es den großen gelben Kreis, der alles versammelt, das eigentlich nichts mit HTML5 zu tun hat, aber trotzdem so genannt wird. Das ist eine (grobe und löchrige) Übersicht über den HTML5-Kosmos und jeder Kreis repräsentiert neue Features für unsere Browser.
Nun könnte man prima darüber streiten, welche Technologie nun “echtes” oder “falsches” HTML5 ist, ob W3C oder WHATWG als maßgeblich zu betrachten sind oder ob dieser Zustand überhaupt tragbar ist. Da aber auch das den Rahmen dieses Artikels sprengen würde, fragen wir uns lieber, was HTML5 uns überhaupt bringt.
Was kann HTML5?
Die Wurzeln von HTML5 liegen in einem WHATWG-Entwurf namens „Web Applications 1.0“. Damit ist schon gesagt, wohin die Reise geht – Technologien für die Entwicklung von Webapplikationen sollen geschaffen werden. Zwar enthält HTML5 auch so manches Feature, das für normale, halbwegs statische Webseiten interessant sein könnte, aber Applikationsentwicklung ist der Fokus. Browser sollen universelle Anwendungsplattformen werden und müssen daher unter anderem in das umgebende Betriebssystem integriert werden und lernen, auch ohne Internet-Verbindung zu funktionieren. In Zukunft werden wir fast unsere gesamte Computer-Arbeit in dem Surfprogramm unserer Wahl verrichten können. So selbstverständlich, wie viele Menschen heute schon ihre gesamten Texte bei Google Docs schreiben, wird in Zukunft auch Bildbearbeitung, Audioschnitt, CAD und das Bearbeiten von Videos via Internet Explorer, Firefox oder Safari stattfinden, was natürlich auch für das Computerspiel der Zukunft gelten dürfte.
Für all das müssen unsere Browser viele neue Dinge lernen – sie müssen in der Lage sein, clientseitig Binärdateien einzulesen, beliebige Grafiken hardwarebeschleunigt zu rendern und sie müssen natürlich Ton und Film wiedergeben können. Damit das alles möglich wird, bringt HTML5 (unter anderem – es gibt noch viel viel mehr) folgende Technologien mit sich:
Elemente und APIs um beliebige Raster-, 3D- oder Vektorgrafiken via JavaScript zu erzeugen und zu animieren, vom einfachen Graphen bis hin zum Computerspiel.
Neue semantische Elemente für die Strukturierung komplexerer Webseiten und -applikationen.
Elemente und APIs für Sound und Video und zwar für sowohl das Einbinden und Abspielen als auch Manipulieren von Multimedia-Dateien.
Schnittstellen für die Arbeit mit Dateien und dem Dateisystem, neue Netzwerkprotokolle und APIs, die Applikationen über mehrere Browserfenster hinweg kommunizieren lassen.
Letzte Frage: Warum sollte man denn all das, was heutzutage als normales Programm ganz wunderbar funktioniert, denn unbedingt zu Webapplikationen umbauen wollen? Neben dem Faktor Bequemlichkeit, den die Nutzer bei Webapplikationen genießen – da sich Applikation und Daten im Web befinden, sind sie jederzeit überall verfügbar – sind Webapps auch aus Prinzip cross-plattform-kompatibel. Was man mit HTML, CSS und JavaScript baut, funktioniert auf jedem Computer dieser Welt, der Internet-Anbindung und einen Browser hat. Warum eine iPhone-App programmieren, wenn man eine Läuft-Überall-Webapp haben kann? Das Ziel von HTML5 ist es, Browser soweit aufzurüsten, dass man Webapplikationen programmieren kann, die nativen Anwendungen in nichts nachstehen.
Wie geht es weiter?
Die Browserhersteller sind sich zwar auf breiter Front einig, dass Webbrowser in Zukunft keine tumben Dokumentbetrachter, sondern universelle Anwendungsapplikationen sein werden, doch noch ist es nicht so weit, dass man bis auf einen Browser sämtliche Programme von seiner Festplatte werfen kann. Die unterschiedlichen Browser unterstützen unterschiedliche Teile von HTML5 – und das auch noch unterschiedlich gut. Hinter den Kulissen gibt es auch noch offene Fragen (zum Beispiel zu Verhältnis von WHATWG und W3C) und sowohl Browserhersteller als auch Webentwickler müssen sich in der HTML-Welt erst noch einfinden.
Während dieser Findungsprozess vor sich hin läuft und die diversen Standardisierungs-Komitees die weiteren Bausteine für die Webapplikationen der Zukunft zurechtlegen (CSS3 und ECMAScript5/Harmony seien genannt) haben wir Webentwickler Stand 2011 nur ein paar wirklich universell einsetzbare HTML5-Technologien zur Verfügung und auf genau diese werden wir uns im Rahmen dieser Serie konzentrieren. Dinge wie das Canvas-Element oder die Geolocation-API funktionieren in allen aktuellen Versionen der verbreiteten Browser und werden sich wohl auch nicht mehr ändern. Sie sind also solide Bausteine für die Webapplikationen der Zukunft und auch bereits der Gegenwart.