HTML 5: neue Features, alte Konflikte und Akzeptanzprobleme

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.