Im Interview mit ZDNet spricht HTML-5-Entwickler Ian Hickson über die besten Features - und welche die meisten Diskussionen auslösen dürften. Außerdem erklärt er, für welche Probleme HTML 5 eine Lösung bereithalten könnte.
Ian Hickson, Herausgeber der HTML-5-Spezifikation[1], stand per Online-Chat Rede und Antwort zur Entwicklung von HTML 5. Das Interview gibt einen Einblick in die Entwicklung des neuen Webstandards sowie den Standard-Schreibprozess und zeigt, worauf sich Web-Entwickler einstellen müssen.
ZDNet: Mr. Hickson, es ist knapp zehn Jahre her, dass HTML 4 als Spezifikation veröffentlicht wurde - ungefähr genauso lange dauerte es, bis HTML 4 endlich vollendet war. Inwiefern wird diese Zeitleiste Ihrer Meinung nach die Arbeit an HTML 5 beeinflussen?
Hickson: Standard- und Software-Entwicklung sind zwei verschiedene Paar Stiefel. HTML 5 wird jetzt bereits von vielen Leuten implementiert, und viele Elemente von HTML 5 werden schon längst genutzt werden, bevor HTML 5 offiziell "vollendet" ist. Es gibt viele Elemente in HTML 5, zum Beispiel das Canvas-Element oder den postMessage-Mechanismus, die bereits in mehreren Browsern implementiert sind.
Deswegen sind die Zeitpläne für Spezifikationen häufig ein Streitthema. Die Arbeit an HTML 5 begann ja 2003. Als das W3C im November 2006 um ein Feedback zu dem Plan bat, den die HTML Working Group erstellt hatte, da habe ich den folgenden Zeitplan vorgeschlagen:
- erster W3C-Arbeitsentwurf im Oktober 2007
- Last-Call-Arbeitsentwurf im Oktober 2009
- Call für Beiträge zur Testsuite 2011
- Candidate Recommendation 2012
- erster Entwurf der Testsuite 2012
- zweiter Entwurf der Testsuite 2015
- endgültige Version der Testsuite 2019
- Reissued-Last-Call-Arbeitsentwurf 2020
- Proposed Recommendation 2022
Im Frühjahr 1997 wurde mit der Arbeit an HTML 4 begonnen. Allein in die Spezifikation wurden etwa zweieinhalb Jahre investiert, bevor sie schließlich Ende 1999 erschien. Währenddessen fingen auch die Arbeiten zu XHTML an, das war 1998. Die offizielle Fertigstellung war dann 2000.
Um die HTML-DOM-Spezifikationen hat sich eine separate Arbeitsgruppe gekümmert: DOM1 wurde 1997 gestartet und 1998 veröffentlicht. Kurz darauf, gegen Jahresende 1998, begannen die Arbeiten an DOM2 HTML, die 2003 abgeschlossen wurden. Großzügig überschlagen wurde an den Spezifikationen also von 1997 bis 2003 gearbeitet, das sind rund sechs Jahre. Denselben Zeitraum habe ich von 2003 bis 2009 angesetzt, bis HTML 5 den "Last Call" erreicht.
Allerdings waren die Spezifikation von HTML 4 und DOM2 HTML sehr ungenau. So manches blieb damals offen, insbesondere die Fehlerbehandlung. Neben zahlreichen neuen Features und den Regeln zu vielen bislang unspezifizierten Features - etwa zum Windows-Objekt beziehungsweise zum Parsen von HTML - führt HTML 5 detailliert aus, wie diese Funktionen technisch ausgeführt werden und was bei möglichen Fehlern zu tun ist. Das ist ein weitaus umfassenderer Ansatz. Aus diesem Grund sind auch die drei zusätzlichen Jahre vom "Last Call" 2009 bis zur "Candidate Recommendation" 2012 notwendig: Wir erwarten neben den tausenden von Kommentaren, die bereits eingegangen sind, noch viele weitere Rückmeldungen. Es wird einfach seine Zeit dauern, bis die alle durchgearbeitet sind.
Außerdem haben wir etwas vor, was es bei keiner der zuvor genannten Spezifikationen gab: eine umfassende Testsuite. Sie muss erst einmal von mindestens zwei Browsern unterstützt werden, ehe wir uns zufriedengeben.
Wer versucht, eine solche Testsuite für HTML 4 und DOM2 HTML zu schreiben, wird feststellen, dass es nicht einen Browser gibt, der diese Spezifikationen vollständig implementiert, geschweige denn zwei. Wir legen die Latte so hoch, damit wir erst dann sagen "Alles klar, die Spezifikation ist fertig", wenn auch wirklich feststeht, dass HTML 5 wie beschrieben implementiert werden kann. Es gibt Elemente in HTML 4 und DOM2 HTML, die von Browsern niemals so wie angegeben implementiert werden. Denn das würde beispielsweise bedeuten, dass existierende Webseiten nicht wie von den Autoren erwartet gerendert werden könnten. Wenn sich bei HTML 5 solche Probleme ergeben sollten, können wir die Spezifikation anpassen. Aber um diese Schwierigkeiten auszumachen, müssen wir umfangreiche Testsuites schreiben, und das dauert einfach seine Zeit. Dafür sind die letzten zehn Jahre des Zeitplans veranschlagt.ZDNet: Unsere persönlichen HTML-5-Favoriten sind die Tags <audio> und <video>. Denn dadurch müssen HTML-Entwickler nicht mehr mit Flash, <object>, <embed> und so weiter arbeiten. Welche anderen Vorzüge wird HTML 5 noch haben?
Hickson: Ich gehe davon aus, dass das iframe-Sandboxing-Feature ein echter Segen für Entwickler sein wird, wenn es läuft. Mein persönlicher Favorit ist die Web Sockets API. Sie ermöglicht die Kommunikation mit dem Server in beiden Richtungen, so dass Spiele, Chatten, Fernbedienungen und vieles mehr implementiert werden können.
Einige Punkte, bei denen HTML 5 aber wirklich Abhilfe schafft, sind viel schwieriger zu beschreiben. Wir definieren jetzt beispielsweise ganz genau, wie ein HTML-Dokument geparst werden muss, egal, ob es voller Fehler steckt oder auch nicht. Das heißt, dass vier verschiedene Browser bei einem vergessenen Abschluss-Tag nun nicht mehr vier verschiedene Verhaltensweisen an den Tag legen. Ebenso definieren wir exakt die Funktionsweise sämtlicher kleiner APIs wie window.history, location.href oder setTimeout(). Das sind APIs, die jeder benutzt, ohne darüber nachzudenken. Vor HTML 5 wurden sie aber niemals definiert. Wenn die Funktionsweise dieser APIs klar festgelegt ist, dann werden wir auch in der Lage sein, einige seltsame Browser-Bugs auszumerzen, mit denen Autoren seit Jahren zu kämpfen haben.
ZDNet: Welche Änderungen in HTML 5 werden Ihrer Meinung nach am heftigsten umstritten sein?
Hickson:HTML legt mehr oder minder neue Bedeutungen für die Elemente <b>, <i> und <small> fest. Ich hatte eigentlich damit gerechnet, dass sich das als großes Streitthema entwickeln würde. Doch es gingen nur ein paar einzelne Beschwerden ein.
Stattdessen wurde über Dinge gestritten, von denen ich es nie erwartet hätte. Irgendwann einmal habe ich die Spezifikation um einen Abschnitt erweitert. Darin stand, dass wir auf der Suche nach einem lizenzfreien Video-Codec seien, der noch nicht patentiert ist und bei dem auch nicht die Gefahr besteht, dass er für den Einsatz auf U-Booten patentiert wird. Über Nacht ging eine Rekordzahl an E-Mails bei uns ein: Jede Nachrichtenseite im Internet betrachtete das scheinbar als Anzeichen für den Weltuntergang.
Wir erhielten auch jede Menge Feedback, als öffentlich wurde, dass wir <acronym> zu Gunsten von <abbr> aufgeben. Viele beschwerten sich darüber. Aber nur wenige waren sich einig, wie sich die zwei Elemente unterscheiden müssten, falls wir beide behielten.
In letzter Zeit gab es zwei große Themen. Bei beiden bin ich der Meinung, dass es sich dabei um absolut unwichtige Elemente von HTML handelt, wenn man das Gesamtpaket betrachtet. Das erste war das <img>-Element und sein alt-Attribut. HTML 4 verlangt alt, gibt jedoch keinerlei Hinweise, wie es zu verwenden ist. Bei HTML 5 habe ich einen ausführlichen Abschnitt hinzugefügt, in dem exakt beschrieben wird, wie es zu verwenden ist. Darin steht, dass es in manchen Fällen (zum Beispiel bei Webcams) vielleicht keinen brauchbaren Ersatztext gibt und dass es daher in solchen Fällen (und nur in solchen Fällen) in Ordnung ist, das Attribut wegzulassen. Daraufhin traten sogenannte Accessibility-Experten einen wahren Proteststurm los. Einige waren sogar der Meinung, dass Flickr - eine von vielen Sites, auf denen heute Bilder zu sehen sind, die aber nicht immer passenden alternativen Text haben - von den Fotografen verlangen sollte, zu jedem Bild auch gleich detaillierte Beschreibungen hochzuladen.
Ich versuchte, die Gemüter wieder etwas zu beruhigen, und schlug vor, stattdessen das alt-Attribut zu fordern, aber eine spezielle Syntax zuzulassen, um auszudrücken, dass es keinen alternativen Text gibt. Doch damit waren sie auch nicht einverstanden, und außerdem gibt es auch da wieder Schwierigkeiten. Was genau wir nun machen werden, steht noch in den Sternen. Aber ich persönlich tendiere dazu, wieder den ersten Vorschlag aufzugreifen. Der war zwar nicht ideal, aber zumindest einfacher.
Der zweite große Streitpunkt in der jüngsten Vergangenheit war die Erweiterbarkeit. Einige haben den Wunsch geäußert, dass man es den Leuten doch erlauben solle, HTML zu erweitern, ohne mit den beteiligten Ausschüssen darüber reden zu müssen. Wir haben einige Mechanismen dafür zur Verfügung gestellt: die Attribute class und rel, die data-*-Attribute, das <meta>-Element für seitenweite Metadaten, das <script>-Element für Nicht-Script-Daten und das <embed>-Element für Plug-ins. Doch manche wollen einfach ihre eigenen Elemente und Tag-Bezeichnungen erstellen können. Bislang ist es uns gelungen, das zu verhindern. Es bleibt abzuwarten, ob wir das auch weiterhin schaffen.ZDNet: Obwohl HTML 4 bereits seit knapp zehn Jahren eine Spezifikation ist, halten sich noch immer viele Webseiten nicht daran oder verwenden immer noch veraltete Tags. Glauben Sie, dass HTML 5 besser und schneller angenommen wird als HTML 4?
Hickson: Ja und nein. Bislang hält sich nur ein Bruchteil der Internetseiten an HTML 4. Anhand der Informationen, die ich von Google bekomme, habe ich eine kleine Studie durchgeführt: Stichproben in mehreren Milliarden Dokumenten ergaben, dass etwa 90 Prozent davon irgendeinen Syntaxfehler aufwiesen. Und dabei habe ich noch nicht einmal darauf geachtet, ob die richtigen Elemente ineinander verschachtelt wurden oder nicht. In HTML 5 wurden einige Dinge verändert, um die Syntax etwas zu vereinfachen. Zum Beispiel haben wir nun die von XML eingeführten Vereinfachung "/>" zugelassen. Außerdem dürfen IDs und Klassenbezeichnungen nun jedes beliebige Zeichen enthalten, denn die Einschränkungen waren für niemanden wirklich von Nutzen. Aber abgesehen von diesen oberflächlichen Veränderungen gehe ich ehrlich gesagt nicht davon aus, dass die Leute mit HTML 5 besseren HTML-Code schreiben werden.
ZDNet: Wird HTML 5 erfolgreich sein?
Hickson: Was die Akzeptanz anbelangt: Nehmen wir einmal nur die wirklich neuen Features, die HTML 5 mitbringt, dann kann man das nicht so pauschal sagen. Blogs werden diese neuen Elemente wohl bereits in wenigen Jahren nutzen, wenn Templates aktualisiert werden und Browser diese neuen Elemente allmählich unterstützen. Anstelle von unzähligen <div>-Elementen mit Klassen können alle dann Elemente wie <article>, <footer> und so weiter benutzen. Auch für Webanwendungen werden die neuen HTML-Features zuhauf verwendet werden. Ursprünglich hieß die HTML-5-Spezifikation ja sogar einmal "Web Applications 1.0", da der Schwerpunkt in erster Linie auf der Einführung von Features für Webanwendungen wie Yahoo Mail oder Google Calendar lag. Eine durchschnittliche Webseite über die Imkerei im Mittelalter wird aber wohl mit keinem der neuen Features etwas anfangen können. Daher ist es wirklich schwer zu sagen, ob die Autoren solcher Seiten HTML 5 wirklich akzeptieren werden oder nicht.
Aber ehrlich gesagt glaube ich auch nicht, dass das eine Rolle spielt. HTML 5 ist bereits jetzt ein großer Erfolg. Denn dadurch wurden Browser-Hersteller zusammengebracht, und viele Probleme von HTML 4 konnten behoben werden, etwa die fehlenden Parsing-Regeln für ungültige Dokumente. Was auch immer als Nächstes geschieht - bislang hat sich HTML 5 ausgezahlt.ZDNet: Die HTML 5-Spezifikation ist auf mehrere verschiedene Gruppen ausgerichtet: Browser-Hersteller, HTML-Autoren, Entwickler von HTML-Editoren, Web-Entwickler, Entwickler von nicht browserbasierten Benutzeragenten, etwa Suchmaschinen, und so weiter. Jede dieser Gruppen hat ihre ganz eigenen Bedürfnisse und Meinungen, die sich teilweise sogar widersprechen. Wie können Sie diese sinnvoll zusammenbringen?
Hickson: Natürlich nur ganz behutsam. Das ist ein sehr schwieriger Balanceakt. An erster Stelle müssen immer die Benutzer stehen, und gleich danach kommen die Webautoren. Das Problem ist jedoch folgendes: Sollten wir jemals etwas spezifizieren, womit die Browser-Hersteller nicht einverstanden sind, dann werden sie die Spezifikation einfach nicht beachten. Also können wir das dann auch bleiben lassen. Denn wenn wir eine Spezifikation erstellen, die letztlich ignoriert wird, dann produzieren wir nur einen Haufen bedrucktes Papier.
Hinzu kommt, dass Benutzer und Autoren oft ihre wahren Bedürfnisse selbst nicht erkennen. Häufig kommen Webautoren und sagen etwas in der Art wie: "Da müsste noch ein zusätzliches Feature her, damit X möglich ist." Weist man sie dann darauf hin, dass es bereits ein Feature für X gibt, dann kommt die Antwort: "Ja schon, aber es wird von den Browsern nicht implementiert." Das ist natürlich Quatsch, denn warum sollten sie das neue Feature implementieren, wenn sie noch nicht einmal das alte implementiert haben? Oder aber Autoren verlangen Features, um Bugs in anderen Features zu umgehen - statt einfach darum zu bitten, den Bug zu beseitigen. Einen Großteil meiner Zeit verbringe ich damit, die Anfragen und Wünsche der Leute zu analysieren und so umzuformulieren, dass klar wird, was sie eigentlich wollen.
ZDNet: Es scheint, als säße ein erheblicher Anteil der Gruppenmitglieder, die aktiv an HTML 5 mitarbeiten, auf verschiedenen Kontinenten. Sie müssen mit Menschen auf der ganzen Welt zusammenarbeiten, häufig in Echtzeit. Wie schaffen Sie es da, noch ausreichend Zeit fürs Privatleben zu haben?
Hickson: Mittlerweile ist es eigentlich so, dass ich meinen Arbeitstag in zwei Schichten geteilt habe. Ich arbeite etwa vier Stunden am Nachmittag und dann noch einmal rund vier Stunden nach Mitternacht. Dadurch bin ich fast zu jeder Zeit online, wenn die Kollegen irgendwo auf der Welt gerade wach sind. Und abends kann ich mich um mein Privatleben kümmern. Doch zum Glück ist meine Art von Arbeit nicht allzu sehr an bestimmte Arbeitszeiten gebunden. Außerdem wird viel per E-Mail kommuniziert. Wenn ich wach bin, dann überprüfe ich mein Postfach regelmäßig.
ZDNet: In der HTML 5-Spezifikation gibt es einige Verbesserungsansätze bei Punkten wie Semantic Web, Barrierefreiheit, Internationalisierung und Lokalisierung - Stichwort: I18N, L12N -, AJAX und andere Web-2.0-Aspekte. Was wird insgesamt in der Praxis am besten angenommen und am meisten verwendet werden? Und was wird Ihren Erwartungen zufolge nicht so stark genutzt werden, wie das vielleicht der Fall sein sollte?
Hickson: Ich habe keine Ahnung. Wenn mich die umfangreichen Forschungsarbeiten für HTML 5 eine Sache gelehrt haben, dann, dass Autoren insgesamt gesehen sehr überraschend handeln und mein Bauchgefühl selten richtig liegt.
Die Features, die am Ende keiner nutzt, werden gestrichen. Im Laufe der Jahre haben wir schon so manches wieder herausgenommen. Viele der Elemente im Vorschlag zu den Web Forms 2.0, die etwas mit Formularen zu tun haben und eigentlich in HTML 5 mit eingebunden werden sollten, werden wir wahrscheinlich wieder streichen. Beispielsweise wird der Vorschlag zu Wiederholungsvorlagen mit an Sicherheit grenzender Wahrscheinlichkeit wieder fallen gelassen.
ZDNet: Welches sind die fünf größten Fallstricke oder Überraschungen für HTML-Autoren in der HTML-5-Spezifikation?
Hickson: Ich wünschte, ich könnte sagen, dass es gar keine gibt. Und wüssten wir von einem oder einer, dann würden wir sie entfernen.
Die meisten "Fallstricke" in HTML 5 stammen aus dem Vermächtnis des Web. Das <address>-Element beispielsweise ist für Kontaktinformationen gedacht, nicht für eine Postanschrift. Das <br>-Element sollte nur dann verwendet werden, wenn man etwas schreibt, das wirklich einen Zeilenumbruch hat, etwa ein Gedicht. Ansonsten sollte man eher <p> statt <br> verwenden. Vorsicht ist auch beim Schreiben von URLs geboten, denn hier muss man die "&"-Zeichen maskieren, indem man an jedes amp; anhängt.
Allerdings haben wir auch selbst für einige unglückliche Features gesorgt. Zum Beispiel darf das <a>-Element zur Angabe von Links nun zwar komplette Absätze und Listen umfassen. Doch das kann mit Browsern wie Firefox zu Problemen führen, die den Parser-Algorithmus von HTML 5 noch nicht implementiert haben. Außerdem kann es zwar sogenannten "flow content" beinhalten, aber nicht einzelne Listenelemente oder Tabellenzeilen einfassen.
ZDNet: Wenn Sie die Uhr noch einmal bis zur ersten HTML-Spezifikation zurückdrehen könnten, was würden Sie dann ändern, damit heute das Web besser funktionieren könnte?
Hickson: Wenn ich dann die Möglichkeit hätte, mich mit Tim [Berners-Lee] zu unterhalten, dann würde ich ihn vor allem um eine klare Fehlerbehandlung von Anfang an bitten. Ich glaube, wir hätten so manchen Tag-Salat vermeiden können, den wir heute haben, wenn wir von Anfang an zumindest bei einfachen Problemen einen klaren Lösungsweg angegeben hätten.
ZDNet: Es scheint, als müsse man als leitender Herausgeber eines so großen Projekts viele verschiedene Meinungen unter einen Hut bringen, mit so vielen Softwareunternehmen wie nur möglich zusammenarbeiten, die jedoch in enormer Konkurrenz zueinander stehen, und noch viele andere undankbare Aufgaben erledigen. Welcher Teil Ihrer Arbeit bringt Ihnen die meiste Befriedigung?
Hickson: HTML 5 hat einen enormen Einfluss auf das Web und die Web-Standards-Community. Wir haben die Latte ziemlich hoch gelegt, was eine Spezifikation leisten muss, um ernst genommen zu werden. Wir haben gezeigt, dass es absolut möglich ist, Web-Technologien vollkommen offen zu entwickeln. Wir haben Innovation und Wettbewerb in der Browser-Welt vorangetrieben. Und wir haben gezeigt, dass eine offene und anbieterneutrale Technologie mit geschlossenen, auf einen Anbieter begrenzten Technologien mithalten kann. Es ist ein tolles Gefühl, zu wissen, dass ich daran beteiligt bin.
Außerdem macht mich die Gemeinschaft, die um die WHATWG[2] herum entstanden ist, wirklich glücklich. Viele Leute haben sich gemeldet und mitgemacht. Sie haben nicht nur ihre Meinung zu Vorschlägen geäußert, sondern auch bei der Infrastruktur aktiv mitgeholfen, das Blog gepflegt, das Wiki, die Foren, Neumitglieder unterstützt und so weiter. Es macht einfach riesigen Spaß.
Schlussbemerkung
Noch einmal herzlichen Dank an Ian Hickson, dass er sich trotz seines vollen Terminkalenders Zeit für dieses Interview genommen hat.
Als ein Beispiel dafür, wie schnell sich Dinge in diesem Prozess ändern können, wurden am alt-Attribut, das Ian bereits als sehr umstritten bezeichnete, seit diesem Interview schon einige Änderungen vorgenommen. In den Mailinglisten-Archiven[3] kann jeder nachlesen, wie mit dem Problem verfahren wurde.
URLs in diesem Artikel:[1] = http:/
[2] = http:/
[3] = http:/