HTML 5: neue Features, alte Konflikte und Akzeptanzprobleme

Ian Hickson, Herausgeber der HTML-5-Spezifikation, 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

Das mag zwar ziemlich lächerlich erscheinen – 2003 bis 2022, das sind 19 Jahre. Doch man sollte das einmal in Relation zu HTML 4, DOM2 HTML und XHTML1 sehen. Denn HTML 5 soll diese drei Spezifikationen ja schließlich aktualisieren und ersetzen.

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.

Page: 1 2 3 4 5

ZDNet.de Redaktion

Recent Posts

Gefahren im Foxit PDF-Reader

Check Point warnt vor offener Schwachstelle, die derzeit von Hackern für Phishing ausgenutzt wird.

11 Stunden ago

Bitdefender entdeckt Sicherheitslücken in Überwachungskameras

Video-Babyphones sind ebenfalls betroffen. Cyberkriminelle nehmen vermehrt IoT-Hardware ins Visier.

11 Stunden ago

Top-Malware in Deutschland: CloudEye zurück an der Spitze

Der Downloader hat hierzulande im April einen Anteil von 18,58 Prozent. Im Bereich Ransomware ist…

11 Stunden ago

Podcast: „Die Zero Trust-Architektur ist gekommen, um zu bleiben“

Unternehmen greifen von überall aus auf die Cloud und Applikationen zu. Dementsprechend reicht das Burg-Prinzip…

1 Tag ago

Google schließt weitere Zero-Day-Lücke in Chrome

Hacker nutzen eine jetzt gepatchte Schwachstelle im Google-Browser bereits aktiv aus. Die neue Chrome-Version stopft…

1 Tag ago

Hacker greifen Zero-Day-Lücke in Windows mit Banking-Trojaner QakBot an

Microsoft bietet seit Anfang der Woche einen Patch für die Lücke. Kaspersky-Forscher gehen davon aus,…

1 Tag ago