Peter Kröner, Webtechnologie-Erklärbär

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.

Kurze Durchsage: Die E-Book-Version des HTML5-Buchs ist wegen der großen Nachfrage schon jetzt zu haben. Das Ganze kommt als PDF daher, andere Formate (EPUB etc.) wird es wohl erst ab der nächsten Auflage geben – hierfür muss das ganze Markup der Texte umgebaut werden und dafür war diesmal noch keine Zeit. Fragen zum Inhalt des HTML5-Buchs beantwortet die Website zum Buch, wo es auch eine Leseprobe und das komplette Inhaltsverzeichnis zum Download gibt.

Möchte man eine mehrsprachige Website mit MODx (dem bekanntermaßen besten CMS der Welt) umsetzen, geht das ganz einfach mit mehreren Kontexten – das hatten wir schon mal besprochen. In jenem Artikel habe ich auch ein Snippet gezeigt, das Inhalt je nach gewähltem Kontext ausgibt. Das ist besonders praktisch, wenn man gewisse Chunks oder Snippets je nach Kontext unterschiedlich einbinden möchte, doch auch wenn man einfach nur eine kleine Zeichenkette in z.B. einem Template übersetzen möchte, kann man dieses Snippet verwenden. Im Sinne des Erfinders ist das freilich nicht, denn mit dem sogenannten Lexikon und einem entsprechenden Template-Tag hat MODx bereits ein sehr fähiges Übersetzungstool an Bord.

Legt man einen neuen Kontext an, so verpasst man diesem in seinen Einstellungen sinnvollerweise einen sogenannten Culture Key, der die Sprache des Kontexts festlegt; man legt zum Beispiel für den Kontext für die englische Seite eine neue Einstellung namens cultureKey an, trägt als Wert en ein und schon ist der Kontext als englischsprachig markiert. Das sollte man eigentlich immer machen, doch für die Verwendung des Lexikons und seiner Übersetzerfähigkeiten, ist ein ordnungsgemäßer Culture Key Voraussetzung. Die Kontext-Einstellungen findet man unter System → Kontexte.

Das Lexikon ist eine Sammlung von Zeichenketten, zu finden unter System → Lexikon-Verwaltung. Diese Zeichenketten sind Name-Wert-Paare und sind nach Namensräumen getrennt, damit es zum Beispiel keine Kollisionen zwischen den Zeichenketten für den MODx-Manager und denen für die verschiedenen Plugins und Snippets gibt. Außerdem gibt es noch als Unterscheidungsmerkmal ein Thema und – für uns interessant – Sprache! Es ist uns also möglich, unter dem gleiche Schlüssel im gleichen Namensraum mehrere Zeichenketten anzulegen und diese nur anhand der Sprache zu trennen. Möchte man zum Beispiel erreichen, dass im Template einer Seite ein Text im deutschen Kontext als „Allgemeine Geschäftsbedingungen“ und im englischen als „Terms & Conditions“ auftaucht, legt man einfach zwei entsprechende Zeichenketten unter dem gleichen Schlüssel an; einmal für deutsch, einmal für englisch.

Auf diesem Screenshot wird also gerade der der englische Text „Terms & Conditions“ unter dem Schlüssel agb_text für die englische Sprache eingetragen. Es ist sinnvoll, vorher einen eigenen Namensraum anzulegen (System → Namensräume). Hat man den deutschen wie auch den englischen Text unter dem gleichen Schlüssel eingetragen, ist es ein leichtes diesem in einem Template oder Chunk zu verwenden:

<p>
    Sonstiges HTML
    <br>
    agb_text
    <br>
    Sonstiges HTML
</p>

Der -Tag erlaubt den praktischen Direktzugriff auf das Lexikon, so dass man nur den Schlüssel unserer Einträge, agb_text anzugeben braucht und als Parameter den Namespace übergibt, aus dem die Zeichenketten zu beziehen sind. Falls man auch ein Thema verwendet, so kann man dieses über den Parameter &topic=`meinThema` angeben und falls man es mal gezielt auf eine bestimmte Sprache abgesehen hat, geht dies mit &language=`en`.

Der Schlüssel zur erfolgreichen Übersetzung ist, dass die vom Kontext vorgegebenen Standardwerte benutzt werden, wenn man Parameter auslässt! So erbt beim gezeigten Beispiel der language-Parameter seinen Wert von der Culture-Key-Einstellung unseres Kontexts und für topic gilt default, was der systemweiten Standardeinstellung entspricht. Und wir haben uns eine bequeme Möglichkeit geschaffen, einzelne Zeichenketten in Templates und Chunks zu übersetzen. Culture Key für Kontexte eintragen, einen Namensraum anlegen, Lexikon-Einträge schreiben, -Tag verwenden, fertig! Auch in Snippet-Code kann man das Lexikon natürlich nutzen – wie das geht, erklärt die MODx-Dokumentation.

Ich muss mich entschuldigen – dieser Blogpost kommt viel zu spät, aber ich war leider die letzten Tage echt ekelhaft krank und damit außer Betrieb. Aber wer aufmerksam mittwittert, der weiß bereits seit einiger Zeit: Die zweite Auflage des HTML5-Buchs ist fertig, bereits vorbestellbar und wird am 28. Februar erscheinen. Sie enthält 194 neue Seiten und vier neue Kapitel (insgesamt 592 Seiten, 14 Kapitel) auf dem Stand vom Anfang Februar 2011 – also inklusive Internet Explorer 9 und Firefox 4. Fast alles, was nicht völlig neu ist, wurde aktualisiert, erweitert oder mit zusätzlichen begleitenden Infos (Links, Polyfills) ausgestattet. Es ist ein neues Buch geworden.

Was steht Neues drin?

Es gibt 194 Seiten mit neuem Stoff, wobei eins der vier neuen Kapitel nur entstanden ist, weil ein altes Kapitel wegen überbordender Länge gesplittet werden musste. Auch in den alten Kapiteln hat sich einiges getan. Insgesamt gibt es folgende größere Neuheiten:

• Neue Kapitel über Web­ Wor­kers, die File API sowie Er­ken­nung und Nach­rüs­ten von HTML5-Fea­tures
• Ak­tua­li­sier­te Brow­ser-Kom­pa­ti­bi­li­täts­ta­bel­len für In­ter­net Ex­plo­rer 9 und Firefox 4
• Enthält alle jün­ge­ren Ent­wick­lun­gen vom Streit und Mul­ti­me­dia-Co­decs bis hin zur Zukunft der Web­stan­dards
• Über­ar­bei­te­ter Ein­stieg, zu­sätz­li­che Bei­spie­le und neue Tech­ni­ken für se­man­ti­sches HTML5
• Er­wei­ter­ter Anhang mit zu­sätz­li­chen Co­de­bei­spie­len, detaillierteren Ta­bel­len sowie neuen Listen, Links und Po­ly­fills

Alle übrigen Kapitel wurden aktualisiert und teilweise erheblich erweitert oder umstrukturiert. Sämtliche sonstigen Infos zum Buch (also auch all das, was schon vorher drin stand) sind zusammen mit Code-Downloads, dem kompletten Inhaltsverzeichnis und einer aktualisierten Leseprobe auf dem überarbeiteten html5-buch.de zu finden.

FAQ

Ich hab schon die erste Auflage. Sollte mich die zweite Auflage interessieren?

Nur wenig von dem, was in der ersten Auflage steht, hat im Jahr 2011 noch uneingeschränkte Gültigkeit. Fast alles hat sich in irgendwelchen Details geändert, und das betrifft auch nicht nur die nerdigen JS-APIs –zum Beispiel sind ein paar weitere semantische HTML-Tags hinzugekommen und fast keiner hat es gemerkt. Ich würde die erste Auflage echt nur noch mit größter Vorsicht aufschlagen, denn das Teil ist einfach veraltet.

Gibt es ein preisgünstigeres Upgrade für Besitzer der ersten Auflage?

Leider nein. Der Hauptgrund dafür ist, dass sich mehr als nur die neuen Seiten und Kapitel geändert haben. Bis auf wenige Abschnitte, in denen es in den letzten 12 Monaten keine umwälzenden Entwicklungen gab (Canvas, Drag&Drop), hat sich auf so ziemlich jedem Kapitel etwas getan. Veraltete Informationen wurden entfernt, neue Tricks und Hinweise eingefügt, Erklärungen ausgeweitet, Fehler korrigiert und so weiter. Da wäre ein Upgrade auch nur 50 Seiten weniger dünn als das komplette Buch.

Warum ist das Buch teurer geworden?

Daran sind einfach die zusammen mit der Seitenanzahl angestiegenen Material- und Transportkosten schuld.

Ich möchte das Buch in meinem Blog/Podcast/Magazin besprechen oder verlosen!

Einfach bei peter[AT]peterkroener[DOT]de melden. Postadresse und Link zu Blog/Podcast/Magazin nicht vergessen

Was kommt in der dritten Auflage?

Falls es auch in Zukunft noch Interesse am Thema gibt, würde ich ganz gerne Kapitel über barrierefreies HTML5 und Web Sockets schreiben. Außerdem wird es Zeit, die Passagen über die Internet Explorer 6 bis 8 so langsam irgendwie auf das Abstellgleis zu schieben … sie vielleicht noch nicht löschen, aber irgendwie in einen Extra-Anhang auslagern oder so. Die stören sonst nur bei der Arbeit. Und ich bin natürlich für Vorschläge offen!

PS.: Sobald ich die letzten Reste meiner Bazillen losgeworden bin, werde ich auch wieder bloggen wie früher™. Versprochen!