XHTML ist nicht tot, aber es riecht schon ein bißchen komisch. Die Meldung der Woche kam am Freitag kurz nach Redaktionsschluß: der Chef des W3C kündigt an, dass es eine neue HTML-Arbeitsgruppe im World Wide Web Consortium geben wird: Reinventing HTML.

Die alte Arbeitsgruppe, die seit der Verabschiedung von HTML 4 vor bald acht Jahren nichts wirklich neues zustande gebracht hat, besteht zunächst noch weiter und darf auch weiterhin an Entwürfen basteln, die kaum jemanden interessieren. Was Tim Berners-Lee in seinem Blog verkündet liest sich aber wie eine radikale Abkehr von der bisherigen Entwicklung:

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.

(Anm. d. Red.: Hervorhebungen hinzugefügt) 

Die logische Konsequenz ist, dass die Musik längst woanders spielt. Zum Beispiel bei der WhatWG oder bei microformats.org − beides lose Zusammenschlüsse von Leuten, die gemeinsam an einer Weiterentwicklung von HTML ohne X arbeiten. Dass XML auf der Ausgabeseite des Webs ein Fehlschlag war ist nichts neues, ähnliche Positionen lassen sich auch in alten Artikeln wie Mark Pilgrims XML on the Web Has Failed von 2004 bei XML.com (!) nachlesen. Evan Goer kam 2003 zu ähnlichen Ergebnissen: von 119 getesteten XHTML-Websites erfüllte gerade mal eine einzige die Spezifikationen vollständig und korrekt.

Nun hat das W3C auch erkannt, dass die Zeichen auf Sturm stehen, kann aber gleichzeitig doch wieder nicht aus seiner Haut. So bemängelt Berners-Lee in seinem Blogpost, dass die genannten Gruppen keinen formellen Prozessen unterliegen und es keine klaren Verantwortlichkeiten gebe. Stimmt nicht ganz, denn es gibt Prozesse, es sind nur andere als beim in Formalitäten erstarrten W3C. Wie Ian Hickson, beim Browserhersteller Opera angestellt und einer der Initiatoren der WhatWG treffend beschreibt: "i listen to people, i make a decision, i publish, rinse, repeat." Eigentlich machen diese Gruppen bereits jetzt nichts anderes als das, was Tim Berners-Lee nun auch von seiner eigenen Organisation einfordert: It is necessary to evolve HTML incrementally.

Auch der Einwand, dass die Schuld letztendlich bei den Browserherstellern zu suchen ist "The large HTML-generating public did not move, largely because the browsers didn't complain.", zeigt nur, wie sehr das W3C von der Realität entkoppelt ist. Postel's Law besteht aus zwei Teilen, beim W3C scheint jedoch nur der erste Teil zu gelten: "general principle of robustness: be conservative in what you do, be liberal in what you accept from others." Fehlertoleranz ist kein Bug, sondern ein Feature! Wo wäre das Web heute, wenn alle Webbrowser bereits beim kleinsten uncodierten Ampersand die Weiterverarbeitung verweigern würden und dem unbedarften Nutzer stattdessen eine Fehlermeldung vor die Füße werfen? Richtig: Das WWW wäre immer noch ein obskures Tool, mit dem Kernphysiker am CERN ihre Forschungsergebnisse austauschen. Das Web ist aber gerade erst durch diese Fehlertoleranz zu dem Massenmedium geworden, in dem jeder mit minimalen Vorkenntnissen seine Meinung kundtun kann.

Jedes System, dass seinen Nutzern zu viele Restriktionen auferlegt, ist von vorneherein zum Scheitern verurteilt. Der gesunde Menschenverstand sagt einem, dass Nutzer, bei SELFHTML treffend Otto Normal-Pixelschubser genannt, aufgrund solcher restriktiven Systeme Wege suchen und finden werden, diese Restriktionen zu umgehen. Meine Güte, das ist eines der grundlegenden Prinzipien des gesamten Intenets und funktioniert genauso bis runter auf die Paketebene!

Die große Masse an Inhalten und Funktionen (und das schließt gerade die großen Anbieter sehr wohl mit ein) wird immer mit den einfachsten Mitteln erstellt werden, die zur Verfügung stehen. Das werden in absehbarer Zukunft die Bordmittel von ganz normalem HTML sein, und nicht eine fehlerhafte Empfehlung wie XForms.

Dazu Ryan Paul bei ars technika:

Tim Berners-Lee claims that there "are many implementations and users of XForms."  As a developer with first-hand XForms experience, I have to say that the word "broken" best characterizes the standard. Although the concept looks great on paper, it just doesn't work for real-world projects. No widely used browser supports the standard by default, and free XForms plug-ins available for Internet Explorer and Firefox are so incomplete that they can't be used for anything other than experimentation. The standard itself also has considerable failings, and some server-side XForms implementors have actually deviated from the standard and invented new elements to work around the holes. 

Die Antwort der Arbeitsguppe auf die Frage nach der Abwärtskompatibilität war, dass es an der Zeit sei, HTML und den IE6 von der Roadmap zu streichen. Kann man sich noch weiter von der Realität entfernen?

Tim Tepasse schreibt zu XForms im SELFHTML-Weblog:

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. 

Sind Sie noch da?

Attribute zur Definition von Pflichtfeldern und die Validierung von Eingaben in XForms hören sich toll an, aber sie sind auch als Erweiterungen in HTML 4.02 oder HTML 5 oder wie auch immer das heissen wird denkbar. Oder glaubt das W3C ernsthaft, dass ein durchschnittlicher Webentwickler in Zukunft XHTML 2 einsetzen wird, nur weil es eine intellektuelle Herausforderung darstellt?

Was wir also brauchen sind nicht neue Standards, die radikal mit Altem brechen, sondern modernisierte Versionen etablierter Standards, die auf der bestehenden Infrastruktur und auf den Möglichkeiten der vorhandenen Inhalte aufbauen.

Nehmen wir einen Vergleich aus dem richtigen Leben: ein bekannter bayrischer Automobilhersteller arbeitet seit geraumer Zeit und mit immensem Aufwand am Wasserstoffauto. Eine prima Sache und ein toller Technologieträger, nur mit einem entscheidenden Fehler behaftet: es fehlt die Infrastruktur an der Tanke. Und da niemand willens und bereit ist, die vorhandene Infrastruktur komplett über den Haufen zu werfen oder parallele Strukturen aufzubauen wird es wohl dabei bleiben: eine Spielwiese für Ingenieure ohne Aussicht auf Markterfolg (mal abgesehen davon dass Wasserstoff keine Energiequelle, sondern nur ein Energieträger ist, aber davon erzählen wir in der nächsten Folge).

Bemerkt jemand die Parallelen zu XHTML 2? Auch im real existierenden Web gibt es eine Abstimmung mit den Füßen (oder besser: mit der Tastatur). Und die läuft eindeutig zu Gunsten eines toleranteren Webs. Um für die Zukunft gerüstet zu sein brauchen wir also keine noch strikteren Regeln, sondern eindeutige Regeln zur Fehlertoleranz, an die sich die maßgeblichen Browserhersteller halten können. Dazu braucht man Testcases, die das W3C bisher aber für kaum einen seiner Standards mitgeliefert hat. Und das ganze muss auf- und vor allem abwärtskompatibel zu den real existierenden Implementierungen sein, ansonsten hat es keine Aussicht auf Erfolg ausserhalb des Elfenbeinturms.

Die Weiterentwicklung und Verabschiedung von Standards ist immer auch eine Übung im Ausgleich von Partikularinteressen. Nur war die größte Interessensgruppe in den Prozessen des W3C bisher deutlich unterrepräsentiert oder auch gar nicht vorhanden: Diejenigen, die das alles umsetzen müssen − wir, die Webentwickler. Ein wesentlicher Teil des Problems ist offensichtlich, dass die bisherige HTML-Arbeitsgruppe von Mitgliedern dominiert wird, die primär ihre Produkte mit Implementierungen von SVG, XML/XHTML oder XForms verkaufen wollen und das W3C als Vehikel zur Standardisierung ihrer höchst eigenen Ansätze nutzen.

Webentwickler sind hingegen unterrepräsentiert bis abwesend, und drei von vier verbliebenen Browserherstellern haben dem W3C längst den Rücken zugekehrt und arbeiten aktiv in der WhatWG mit (und implementieren deren Entwürfe bereits, was man von vielem der W3C-Empfehlungen aus den letzten Jahren nicht behaupten kann). Ein Teil der Arbeiten findet dann spaßigerweise den Weg zurück zum W3C, so kürzlich der Web Forms 2.0-Entwurf der WhatWG und die neu installierte Web API Working Group.

Ob und wie die Arbeit der WhatWG in die neuen Arbeitsgruppen und deren Resultate eingebunden wird bleibt abzuwarten. Ob wir dann hinterher mit zwei konkurrierenden und zueinander inkompatiblen Standards leben müssen steht in den Sternen. Tim Berners-Lee dazu:

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.

Ob das W3C wirklich in der Lage sein wird, inkrementelle Veränderungen in HTML ohne Kollision mit Firmeninteressen durch seine stark formalisierten Prozesse zu bringen darf man zumindest bezweifeln. Zu wünschen wäre es. Viva la Evolucion!