Tim Berners-Lee, der Erfinder des Webs und Direktor des W3C hat gebloggt. Das alleine ist nun kein Grund, vom Stuhl zu fallen, aber er sagt etwas recht Interessantes in diesem Weblog-Eintrag

The plan is to charter a completely new HTML group.

(Mit „group“ ist eine Working Group des W3C gemeint, die Arbeitsgruppen, die sich um die Entwicklung konkreter Standards kümmern)

Warum ist das nun interessant? Eine HTML Working Group gibt es doch schon und sie ist durchaus beschäftigt, auch wenn man sich um das Ziel der Beschäftigung durchaus streiten kann. Dazu muss man etwas in der Geschichte der Spezifikationsentwicklung des W3C’ herumwühlen, insbesondere in der letzten Zeit.

Vorsichtig, es ist lang.

(X)HTML

Die bisherige Meinung beim W3C zur Entwicklungsgeschichte von HTML sieht so aus:

1. HTML 2.0, HTML 3.2 und HTML 4.01 werden in relativ rascher Folge nacheinander entwickelt. HTML 4.01 war die letzte größere Veränderung und Weiterentwicklung von HTML und es erschien 1999.
2. XML tauchte am Horizont auf, eine vereinfachte Variante des Dokumentenauszeichnungsstandard SGML. XML sollte die Zukunft des Webs sein.
3. Konsequenterweise wird HTML 4.01 in XML reformuliert, es entsteht XHTML 1.0. Dabei wurde nichts hinzugefügt, aber auch nichts wirklich wichtiges weggelassen. XHTML 1.0 ist also nur HTML 4 im XML-Gewand, dadurch wird es im wesentlichen etwas strikter und weniger fehleranfällig geschrieben und man könnte es mit jedem XML-Tool verarbeiten. Um abwärtskompatibel zu HTML zu bleiben wird ein Modus eingeführt, XHTML 1.0 so zu schreiben, dass ein HTML 4 verstehender Browser es als HTML versteht und nicht über das XML stolpert.
4. Es wird weiter an den HTML-in-XML-Spezifikationen gebastelt, XHTML wird modularisiert, d.h. in Einzelteile aufgesplittet. Die Idee dahinter ist es, das man neue XHTML-Teilmengen aus den unterschiedlichen Modulen zusammenbasteln kann, konsequenterweise wird das auch gemacht, XHTML Print ist ein XHTML für Gedrucktes, XHTML Basic ist eine XHTML für Browser auf kleinen Geräten, Mobilfunkgeräte und PDAs, insofern ist es der Nachfolger von WML.
5. XHTML 1.1 ist die Zusammenfassung aller Module aus der Modularisierung von XHTML – inklusive des Moduls Ruby. Letzteres ist für eine spezielle Schreibweise bei asiatischen Sprachen zuständig, die einzige wirklich substanzielle Neuerung seit HTML xml-isiert wurde. Der abwärtskompatible Modus ist hier nicht mehr vorhanden, XHTML 1.1 soll nur noch als XML verarbeitet werden.
6. XHTML sollte die Zukunft sein.

Zwei Dinge sind bei dieser Vision des W3C bemerkenswert, die Revolution durch XML fand nicht statt und es bleibt die Frage nach der Weiterentwicklung des (X)HTML-Sprachstandards.

XML? Wo?

Tatsächlich findet in unseren Browserfenstern so gut wie kein XML statt. Der offensichtlichste Grund ist natürlich, dass haufenweise Webseiten im Internet sich so gut wie nicht um korrektes Markup kümmern, es werden einfach Tags an Tags gehäuft und gehofft, dass der Browser das schon richtig macht. Dann gibt es haufenweise HTML-Seiten, die naturgemäß nicht XML sind.

Aber selbst wenn man seine Dokument gemäß den Regeln von XHTML, genauer den Regeln des abwärtskompatiblen Modus von XHTML 1.0 bastelt, klappt es nicht. Denn die Browser verarbeiten das abwärtskompatible XML als HTML. Im Browser hat man also kein XML, sondern HTML. Würde man das XHTML als richtiges XML schicken, macht natürlich ein Browser nicht mit, der liebe Internet Explorer. Dummerweise ist es noch der wichtigste Browser im derzeitigen Web.

Die Revolution durch XML fand nicht statt. Tim Berners-Lee:

Some things are clearer with hindsight of several years. It is necessary to evolve HTML
incrementally. The attempt to get the world to switch to XML, including quotes around
attribute values and slashes in empty tags and namespaces all at once didn't work. The large
HTML-generating public did not move, largely because the browsers didn't complain.

HTML ist da, es wird bei uns bleiben und nicht weggehen, so sehr man sich das auch wünschen mag.

XHTML 2

Seit 1999, seit HTML 4.01 gab es keine größere substanzielle Weiterentwicklung von HTML 4 bzw. XHTML 1 mehr. Am Sprachbestand hat sich nichts verändert, außer XHTML Ruby wurden keine neuen Elemente eingeführt, bestehende Elemente wurden nicht erweitert. Dabei hätte man vieles durchaus brauchen können, stattdessen wird viel mit JavaScript gemacht. Und es werden haufenweise eigene Elemente erfunden: <div id="header">, <div id="sidebar">, etc. Wo fand die Innovation bei HTML statt?

Tatsächlich gibt es eine Weiterentwicklung von (X)HTML, XHTML 2.0, seit mindestens 2002 in der Mache und kein Ende in Sicht. Abgesehen von der langen Wartezeit – Standards brauchen durchaus Zeit – gibt es aber Probleme mit XHTML 2. Zum einen ist es wie XHTML 1.1 reines XML, d.h. man kann es nicht wirklich in derzeitigen Browsern zum Laufen kriegen, siehe IE.

Zum anderen ist es keine Weiterentwicklung im Sinne von weiter sondern eine Neuentwicklung. Diesmal wollte man es richtig machen, komisches Zeug aus HTML-Zeiten loswerden, neuen Krempel möglichst intelligent entwerfen und Spezialfälle möglichst verallgemeinern. Da gibt es durchaus nette Dinge, jedes Element kann nun ein Hyperlink sein, jedes Element kann nun ein Bild sein (und trotzdem strukturierten alternativen Inhalt enthalten), es gibt neue Elemente wie eine allgemeine Überschrift <h> …. Das ist alles nicht das Problem mit XHTML 2. Der Punkt ist, dass in XHTML 2 Dinge aus den Zeiten von XHTML 1 durch anderes ersetzt werden. Konsequenterweise ist ein in XHTML 1 geschriebenes Dokument kein richtiges (valides) XHTML-2-Dokument mehr. Und es geht nicht um eine leichte Veränderung wie Syntax wie beim Sprung von HTML 4 auf XHTML 1, sondern um richtige Elemente.

Zum Beispiel Formulare. In XHTML 2 werden nicht mehr die Formulare wie in HTML-Zeiten verwendet wie reine input-Elemente, sondern es wird eine neue Formularbeschreibungssprache genutzt, XForms. Und XForms definiert nicht einfach neue Kontrollelemente für Formulare, es ist komplexer. Man definiert (in XML) ein Modell für seine gewünschten zu sammelnden Daten, verknüpft dieses Modell mit XML Schema, um diese Daten zu validieren und bindet dieses Modell mittels XPath an XForms-Formularkontrollelemente um daraus eine XML Repräsentation des Modells mit den tatsächlichen Daten, um diese übers Kabel zu schicken. Wer den Satz bis zum Ende verstanden hat, dürfte jetzt auch an MVC denken und liegt richtig damit. Und ja, im Prinzip hat man durch XForms viele Vorteile, automatische Validierung von Formularen, mehr Kontrolle über das, was über die Leitung geht, Berechnungen von Formularinhalten und eine bessere Integration mit DOM Events bzw. XML Events.

Das Problem dabei ist, dass XForms einen ganzen Rattenschwanz von Techniken nach sich zieht, XPath, XML Schema, XML Events und natürlich leben alle XForms-Elemente in einem eigenen XML-Namensraum. Für XML-Erfahrene und Programmierer ist dies weniger ein Problem; Otto Normal-Pixelschubser wird allerdings vor einigen Hürden und einer großen Lernkurve stehen. Das einfache (X)HTML-Formular, das er eben noch geschrieben hat, kann er beim hypothetischen Umstieg auf XHTML 2 nicht einfach so lassen oder gar erweitern, nein, er muss es neu schreiben und dies ganz anders als gewohnt, und um XForms effizient nutzen zu können, braucht er sehr viel mehr Wissen.

Diese Nicht-Abwärtskompabilität und Ersetzung von gewohnten Konzepten ist in XHTML 2 gewünscht. Frames? Ersetzt durch XFrames. Access-Keys? Ersetzt durch ein ganz neues Element, dass seine Ziele mit XPath oder mit WAI-Rollen adressiert. Die einfachen on-*-Attribute? Ersetzt durch eine neue XML-Sprache, XML Events, die besser mit dem DOM Event Konzept harmonieren. Es ist eben eine Neuentwicklung.

XHTML 2 ist ein großes, komplexes Biest, auf das man nicht man eben so mit seinen (X)HTML-Dokumenten umsteigen kann, man müsste ziemlich viel dazulernen, was man bisher ignorieren konnte. Konsequenterweise ist auch so gut wie kaum was davon, nur Einzelteile, in den Browsern implementiert, bzw. es wird versucht, Dinge zu implementieren. Das sieht nicht gerade toll auf Seiten des W3C aus.

WHAT?

Tatsächlich hat das W3C in den letzten Jahren sehr viel Kritik einstecken müssen; Stagnation, Wolkenkuckuckskonsortium und Ignoranz der tatsächlichen Realitäten gehörten dazu. Mathias Schäfer beschreibt diese ausführlicher im Artikel Mikrofortschritte und stellt unter anderem auch vermeintliche Konkurrenzgruppen vor. Die hervorstechendste dürfte die Web Hypertext Application Technology Working Group sein, kurz WHAT WG. Diese ist ein Zusammenschluss von Herstellern moderner Browser, genauer Mozilla, Opera und Apple und derzeit zahlt Google dem Editor der WHAT WG sein Gehalt. Durchaus beachtliche Mitspieler im Web. Und man sieht die Entwickler der diversen Browser durchaus auf der Mailingliste. Die Gruppe gründete sich im Juni 2004 als Reaktion auf einen Workshop des W3Cs zum Thema Web Applications, der entgegen der Ansichten von Mozilla und Opera sich auf ein Modell von Web Applications versteifte, das nicht auf dem bekannten HTML/CSS und JS aufbaute, sondern wieder neuere Techniken und vor allem XML-Techniken nutzte. Revolution im Sinne von XHTML 2 statt Evolution bestehender Standards.

Die WHAT WG begann damit, eine Alternative zu den bereits bemängelten XForms zu entwickeln, WebForms 2.0. WebForms ist eine Erweiterung der bereits existierenden Formulare von HTML um neue Möglichkeiten der Eingabe wie kalendarische Daten (<input type="date">), spezielle Strings (<input type="email">), um Minima und Maxima (<input type="number" min="3" max="10">), Reguläre Ausdrücke für Texteingabefelder und mehr. Im Wesentlichen all die Werte, die man heutzutage noch mit JavaScript überprüft. Weitere Datentypen in HTML zu spezifizieren hat aber den Vorteil, dass der Browser zusätzlich spezielle Varianten der Eingabe dieser Daten anbieten kann, für kalendarische Daten einen Kalender oder für Nummern in einem definierten Abschnitt einen Slider.

Noch schöner ist es, dass WebForms 2.0 abwärtskompatibel ist, soll heißen, ein bestehendes (X)HTML-Formular ist auch immer ein richtiges WebForms-2.0-Formular. Man könnte also Schritt für Schritt seine bestehenden HTML-Dokumente erweitern. Abwärtskompatibilität und Kompatibilität zu bestehenden Standards ist für die WHAT WG wichtig. Das merkt man auch in dem Entwurf für HTML 5.

HTML 5

Auch aus dem Hause WHAT WG ist der Entwurf Web Applications 1.0, auch als (X)HTML 5 bekannt. HTML 5 ist eine Spezifikation, die versucht das bisherige Gemisch von HTML 4/XHTML 1 und den für HTML verantwortlichen DOM-Spezifikationen zu nehmen, zu integrieren, bestehende Quasi-Standards (XMLHttpRequest) mit zu integrieren und dieses abwärtskompatibel zu erweitern. Das klingt nach viel, es ist auch viel. HTML 5 definiert …

• DOM-Interfaces für alle Elemente
• DOM-Interfaces für bestehende Konventionen wie innerHTML
• neue DOM-Interfaces für nützliche Dinge, wie die Abspeicherung von Daten im Browser für Sessions oder für Domains
• HTML-Attribute und DOM-Interfaces, die man nutzen kann, um Elemente editierbar (contenteditable) oder mittels Drag-and-Drop verschiebbar zu machen
• Einen simpleren Modus des Parsens von HTML – eine Reaktion auf die Tatsache, dass kein Browser HTML wirklich streng nach den Regeln von SGML parst.
• und natürlich neue Elemente wie <nav>, <header>, <m> für markierten Text, <progress> für Fortschrittsbalken …

HTML 5 ist eine chaotische Spezifikation, ständig im Umfluss, ständig in der Veränderung, kein Wunder, ist es doch erstmal nur ein Working Draft. Und es zieht auch wegen vermeintlicher Kurzsicht der Autoren Kritik auf sich. Joe Clark kritisiert in der für ihn typischen Polemik How not to fix HTML teilweise zu Recht den Technozentrismus der Autoren, er wünscht sich mehr aus dem Leben gegriffenen Neuerungen, Elemente wie Annotationen und Fußnoten – all die Möglichkeiten des Ausdrucks, die man auch im Print hat. Allerdings: Es ist ein Working Draft, alles ist noch möglich.

HTML 5 und die WHAT WG hat den Vorteil, dass die Browser-Hersteller dahinter stehen und mitwirken. Teilweise werden Dinge der WHAT WG schon implementiert. Opera 9 hat eine rudimentäre Implementierung von WebForms, Firefox 2 hat das DOM Storage Interface aus HTML 5 implementiert.

Und das W3C?

Das W3C hat im November 2005 drei neue Working Groups gegründet, darunter besonders interessant die Web API WG mit ihrem schönen Beta Logo. Diese WGs haben zur Aufgabe, Techniken rund um Rich Web Clients zu spezifizieren, also das, was mit Web Anwendungen im Browser zu hat und dort nützlich sein kann. Spezifikationen, die dort unterwegs sind:

• XMLHttpRequest, die Spezifikation des beliebten Ajax-Objektes und dessen Verhaltens.
• Die Spezifikation des window-Objektes, das jeder nutzt, für das es aber bislang noch keine authorative Quelle gab.
• Die Spezifikation einer Selectors API - die in etwa dasselbe macht wie die beliebte Javascript-Bibliothek jQuery, nämlich HTML-Elemente mittels CSS-Selektoren zu identifizieren.
• Die Spezifikation des Dateiübertragungsmechanismus inklusive Manipulationsmöglichkeiten durch JavaScript.
• und mehr ist in Planung.

Einige dieser Spezifikationen haben ihren Ursprung in HTML 5, tatsächlich sind die Spezifikationen und ihre Autoren im Wesentlichen von der WHAT WG zum W3C gewandert. Man kann die WHAT WG insofern nicht als Konkurrenz zum W3C betrachten, sondern als Vorarbeiter. Als ein Platz, wo von den Browserherstellern (und Nutzern) angedacht wird, was nützlich wäre und in Gedankenspielen experimentiert wird. Reift etwas oder liegt es auf der Hand, dass etwas sinnvoll ist, wird damit dann zum W3C gegangen. Tatsächlich ist das auch die Intention der WHAT WG:

Many of the members of this working group are active supporters and members of the W3C
and other standardization bodies. Parts of the work have already been submitted to the W3C,
and we intend to work more closely with the W3C in future. The technical work is currently
focused on developing the specifications to levels appropriate for the W3C Last Call stage.

WebForms 2.0 wurde bereits als Submission beim W3C eingereicht, auch wenn der Kommentar des W3C angesichts der Existenz von XForms eher lau war. Aber das W3C erkennt langsam durchaus an, dass es einen Bedarf an Weiterentwicklung anhand des realen Webs und anhand der realen Bedürfnisse von Webentwicklern gibt. Dies mit einer besonderen Betonung auf Weiterentwicklung im Gegensatz zu ständigen das Rad neu erfindenden Neuentwicklungen.

Zurück zu Sir Tim

Mit der Ankündigung von Tim Berners-Lee wird diese Anerkennung auch auf HTML ausgeweitet, ging es vorher immer nur um kleinere Legosteine, ist hier ein großer Block zur Weiterentwicklung zur Verfügung gestellt, HTML. Er sagt da einige interessante Dinge:

The plan is to charter a completely new HTML group. Unlike the previous one, this one will be
chartered to do incremental improvements to HTML, as also in parallel xHTML.

HTML wird weiterentwickelt und zwar inkrementell, hier bedeutet das soviel wie abwärtskompatibel, in kleinen, verdaubaren Schritten. Gleichzeitig auch XHTML, aber vermutlich nur die Variante XHTML 1, denn:

There is also a plan for a separate group to work on the XHTML2 work which the old “HTML
working group” was working on. There will be no dependency of HTML work on the XHTML2
work.

XHTML 2 bleibt weiterhin eine komplett neue, für sich stehende Entwicklung ohne großen Bezug zu HTML 4+ und XHTML 1+. Aber immerhin, das bestehende HTML soll weiterentwickelt werden. Auch die Formulare:

There will also be work on forms. This is a complex area, as existing HTML forms and XForms
are both form languages. HTML forms are ubiquitously deployed, and there are many i
implementations and users of XForms. Meanwhile, the Webforms submission has suggested
sensible extensions to HTML forms. The plan is, informed by Webforms, to extend HTML
forms. At the same time, there is a work item to look at how HTML forms (existing and
extended) can be thought of as XForm equivalents, to allow an easy escalation path. A goal
would be to have an HTML forms language which is a superset of the existing HTML language,
and a subset of a XForms language with added HTML compatibility.

Soll heißen: HTML-Formulare werden inspiriert durch WebForms weiterentwickelt. Etwas problematischer ist der zweite Aspekt, zu gucken, ob man WebForms mit XForms vereinheitlichen kann. Dies dürfte tatsächlich auf einen Vorschlag von IBM zurück gehen. Im Prinzip klingt das paradiesisch, die einfache Nutzung von WebForms mit der Mächtigkeit von XForms vereint. Dennoch dürfte dabei wahrscheinlich eine komplexere Variante von XForms herauskommen, wie Henri Sivonen anmerkt. Dennoch denke ich, dass das W3C diesen Pfad weiter verfolgt, schließlich ist es ein Industriekonsortium und IBM ist durchaus an XForms interessiert, soweit ich das mitbekommen haben.

Aufbruch

Es wäre auch illusorisch zu glauben, das W3C würde nun einfach die Vorschläge der WHAT WG übernehmen, schon allein weil HTML 5 kein durchgereifter, konzeptionell in sich abgeschlossener Vorschlag ist, sondern vielmehr eine Ideensammlung, die durchaus Kritik verträgt. Ich denke nicht, dass das W3C HTML 5 als Vorlage, denn mehr als Inspiration nehmen wird. Wichtiger ist, dass das W3C die konzeptionellen Gedanken hinter der Arbeit der WHAT WG übernimmt, Abwärtskompatibilität, die Realisation des real existierenden Webs und vor allem die Zusammenarbeit mit Browserherstellern:

We have strong Support for this group, from many pople we have talked to, including browser makers.

Ich denke, den Internet Explorer kann man wie gewohnt hier ausklammern. Dennoch ist es ein Zeichen der Bewegung im W3C, dass sich zu lange auf große monolithische Neuerfindungen des Rades konzentriert hat. Man kann nur hoffen, dass daraus auch etwas wird.