Bemerkenswert ist an der heutigen W3C-Veröffentlichung, dass es sie gibt, dass es sie unter diesem Namen gibt und darüber hinaus eine Vielzahl bemerkenswerter Details. Das W3C ist nicht zuletzt gegründet worden, um den Wildwuchs im Bereich HTML zu bändigen. Zweifellos gab es eine ganze Reihe weiterer Betätigungsfelder, aber der Status von HTML war der offensichtlichste.

Als ich zum ersten Mal mit HTML in Berührung gekommen bin (Mai 1993), gab es keine Spezifikation, die irgendeinen Stempel einer offiziellen Legitimation trug? Woher hätte dieser Stempel auch kommen sollen. Die ISO ist viel zu langsam, um im Jahre 1993 bereits auf ein vergleichsweise neues Phänomen namens »World Wide Web« oder gar »HTML« reagieren zu können. Die IETF war zum damaligen Zeitpunkt der beste Kandidat für eine Normierung in Form eines RFC. Die Frage der Zuständigkeit ist allerdings nicht so einfach. Aus heutiger Sicht scheint es ganz natürlich, dass es einen RFC für HTTP, aber keinen für HTML gibt. Auf der anderen Seite beschreiben RFCs auch den Aufbau von Mails, d.h. von SMTP-Nachrichten, warum also nicht auch den Aufbau von HTTP-Nachrichten? Nun, heute ist es müßig zu diskutieren, was hätte sein können und was nicht.

Das scheinbare Zuständigskeitsvakuum bei HTML füllte das W3C 1994 mit seiner Gründung am MIT, wo man just im Jahr zuvor das »MIT X Consortium« in eine Firma, die X Consortium Inc., ausgegründet hatte; das Know-how für Konsortien war also vorhanden. Eine der zentralen Aufgaben des W3C war in den 90er Jahren, zu Zeiten des ersten Browserkriegs, die Normierung von HTML. Bei dieser und allen weiteren Arbeiten hat das W3C stets auf ein sauberes, theoretisch abgesichertes Fundament geachtet (auch wenn das nach sachkundiger Meinung nicht immer vollständig gelungen ist). Für HTML bedeutet das: Eine Normierung auf Basis von SGML, einer ISO-Norm zur Definition von Auszeichnungssprachen. Als man SGML als zu schwerfällig für eine weitere Entwicklung angesehen hat, folgte der nächste Schritt, die Verabschiedung einer SGML-Teilmenge namens XML (zur Teilmengeneigenschaft wäre auch noch etwas zu sagen, das führt hier aber zu weit...).

Nun verhält sich die Welt nicht immer so wie Normierungsgremien es (möglicherweise) möchten. Selbst dann nicht, wenn die Normen nicht Normen sondern Empfehlungen genannt werden (Zitat: W3C Recommendations are similar to the standards published by other organizations.). Selbst dann nicht, wenn die an den Empfehlungen mitarbeitenden Organisationen (hier: Browserhersteller) die Macht haben, das Ergebnis ihrer eigenen Gremienarbeit zu implementieren.

Seit HTML 4 im Jahre 1997 ist inhaltlich kein bemerkenswerter Impuls für die Lingua franca des Web vom Consortium gekommen. Nachfolgende Spezifikationen sind entweder Neuflagen, Errata oder auf die Basis XML umgeschriebene Versionen (XHTML 1). XHTML 2 befindet sich seit August 2002 im Status eines Working Drafts. Derer gab es viele, wobei die Welt irgendwann aufgehört hat, von ihnen Notiz zu nehmen.

Und wieder tut sich ein Vakuum auf: HTML schwebt im luftleeren Raum. Kein Wunder also, dass sich mit der WHATWG eine Gruppe bildet, die die Sache in die eigene Hand nimmt.

Das, was die WHATWG als »HTML 5« in die Welt gesetzt hat, nennt sie selbst auf ihrer Übersichtsseite »Web Applications 1.0« . Schaut man in den Text (parallel beim W3C erschienen) findet man in der Tat eine Fülle von Dingen, die mit HTML nicht unmittelbar zu tun haben: DOM, Scripting, Zustandsinformation im Browser, clientseitige Datenbankspeicherung, ...

Keine neue HTML-Version

Bereits jetzt ist klar: Es handelt sich nicht um eine neue HTML-Version. Das, was WHATWG und W3C hier gemeinsam präsentieren, ist eher der Versuch, den Status quo in Sachen Browsertechniken festzuhalten und weiterzuentwickeln. Genauso hat es mit HTML auch einmal angefangen. Als das Ur-HTML einigen Protagonisten nicht mehr genügte, erschien HTML+ auf der Bühne. Das erst später gegründete Web Consortium bietet noch heute den aus dem November 1993 stammenden HTML+-Text, sowie eine neuere Version inklusive DTD an. Am Rande sei bemerkt, dass dieser Text von Dave Raggett bereits Vorkehrungen für eine Modularisierung sowie für mathematische Formeln enthält; zwei Dinge, die das W3C erst Jahre später aufgegriffen und als Recommendations verabschiedet hat.

Spannende Fragen

So wie damals HTML+ ist auch »HTML 5« entstanden. Aus der Community. Nur dass die Community heute einen völlig anderen Charakter hat, und dass es damals kein Consortium als HTML-Gralshüter gab. Eine spannende Frage ist also, ob sich neben dem W3C eine neue Strömung etablieren kann, die die technische Weiterentwicklung des Webs in die Hand nimmt. Derzeit ist das nicht anzunehmen. Anders lässt sich die gemeinsame Veröffentlichung von WHATWG und W3C nicht deuten. Wie allerdings der »HTML 5« genannte Text in die W3C-Welt passen soll, ist eine ebenso spannende Frage. Warum?

An vielen Stellen steht der Text im Widerspruch zur fundierten, abgesicherten Vorgehensweise des W3C, bei der ein Standard auf einem früheren aufbaut. Eine Reihe von Beispielen (ohne Anspruch auf Vollständigkeit) sollen das belegen:

  • In Abschnitt 8.1.1 heißt es: »A DOCTYPE is a mostly useless, but required, header.« Dort wo das W3C alles auf XML aufbaut, ist die Doctype-Deklaration hier »meistens nutzlos« .

  • Gleich im folgenden Abschnitt tauchen auf einmal wieder RCDATA-Elemente auf. Dieser Begriff war bereits mit SGML in Vergessenheit geraten. Wer einnert sich schon noch an Replaceable Character Data oder hat diese Funktion gar selbst benutzt. An dieser Stelle sei bemerkt, dass der Verzicht auf RCDATA in XML durchaus schmerzhaft für mich war. In SGML erlaubt eine RCDATA-Section, Text so zu schützen wie die bekanntere CDATA-Section, allerdings werden Entities noch aufgelöst, was ich selbst gerne für die Inklusion von Markup-Beispielen in SGML-Dokumente verwendet habe.

  • Es folgen viele Beispiele, die wie Rückschritte erscheinen. So gibt es eine Liste von optionalen Tags, in der in Prosa aufgeführt ist, unter welchen Bedingungen ein End-Tag entfallen kann. Eigentlich ein klassisches Beispiel für eine (SGML-)DTD...

Neben zahlreichen innovativen Vorschlägen z.B. für neue HTML-Elemente, was einen eigenen Blog-Artikel wert wäre, liegt der besondere Wert von »HTML 5« in dem Versuch, die aktuelle Realität im Web zu beschreiben. Zum Beispiel: Der Abschnitt 8.2 enthält Parsing-Regeln (auch) für »schmutzige HTML-Dokumente« : »This specification defines the parsing rules for HTML documents, whether they are syntactically valid or not.« Das ist schön für alle, die Programme entwickeln, um HTML-Daten aus dem Web zu lesen und zu verarbeiten. Sollen die gelesenen und damit geparsten Daten aber anschließend auch noch einem Browser präsentiert werden, ist offen, ob der Browser die Seite noch wie erwartet darstellt. Jeder, der bereits einmal mit Programmen wie tidy oder tagsoup HTML-Code »gereinigt« und anschließend im Browser angezeigt hat, weiß, dass das Reinigen zu unerwünschtem Darstellungen führen kann.

The same procedure as every year.

In solchen Fällen gilt, was immer galt: Erst wenn die Browser, und zwar alle, sich an einen(!) Standard, und zwar irgendeinen, halten, verschwindet die leidige Diskussion um Standards, Cross-Browser-Techniken und so weiter. Ob ein solcher Standard dann vom W3C oder der WHATWG oder sonstwem kommt, ist (zumindest mir) ziemlich egal. Da die Browserhersteller augenscheinlich nicht an einem Strang ziehen, kann ich den Artikel nicht besonders hoffnungsvoll beenden. Uns Nutzern, Autoren und Programmieren bleibt nur die Einflussnahme über die Wahl des Browsers. Wenn wir unseren bevorzugten Browser tatsächlich danach wählen, ob er einem etablierten Standard folgt, können wir die Richtung mitbestimmen. Doch das haben schon zuviele vor mir geschrieben (und ich selbst auch bereits einige Male), als dass ich daran glauben könnte. Und so gehe ich davon aus, dass das Spiel unverändert bleibt. Immer wieder werden neue, interessante Features und Techniken auftauchen. Und immer wieder werden wir uns fragen: »Kann der andere Browser das auch?«