In meinem heute veröffentlichten Artikel Was sind Webstandards? bei den Webkrauts vertrete ich die These, dass die Ära der Konformität zu Webstandards ein Ende gefunden hat: Die Webstandards der kommenden Generation werden keine abgeschlossenen, festen Standards mehr sein, wie es einmal HTML 4, XHTML 1 und CSS 2 waren. Sie werden gleichzeitig oder nachträglich zu den Browser-Implementierungen erarbeitet. Während WebautorInnen die Techniken schon produktiv einsetzen, befinden sich die Spezifikationen im Status des »Working Drafts« oder eines nie abgeschlossenen »Living Standards«. Unter diesen Bedingungen von Webstandards-Konformität zu reden, ist nur noch schwer möglich, so meine Argumentation.
Eine weitere These ist, dass das W3C als Standardisierungsgremium mehr und mehr an Relevanz und Autorität verliert. Ich möchte das an einem jüngeren Beispiel erläutern.
Rich-Text-Editing mit execCommand, contentEditable und designMode
Microsoft hat einst die JavaScript-Techniken document.execCommand, document.queryCommand sowie contentEditable und designMode erfunden. Diese sollen eine mittlerweile enorm wichtige Funktion bereitstellen: Sie erlauben das Editieren und Formatieren von Texten auf einer Website. Ein solches Rich-Text-Editing findet sich in fast jeder Blogsoftware, jedem CMS und natürlich in Webanwendungen zur Textverarbeitung wie Google Docs oder Etherpad. Die anderen Browserhersteller haben die Wichtigkeit dieser Techniken erkannt und das Microsoft-Modell per Reverse-Engineering kopiert.
Da bis dato keine detaillierte Spezifikation existierte und die anderen Browserhersteller nicht in den Quellcode des Internet Explorers schauen konnten, fielen die Implementationen inkompatibel aus. So inkompatibel, dass meines Wissens keines der großen Rich-Text-Editing-Scripte auf execCommand setzt, sondern die Funktionalität manuell nachbaut. Die WHATWG nahm sich schließlich der Standardisierung von execCommand an. Von da an enthielt die HTML5-Spezifikation der WHATWG und des W3Cs einen Abschnitt, der execCommand beschreibt.
Fork eines Abschnitt der HTML5-Spezifikation
Ende Juli 2011 jedoch teilte der Google-Mitarbeiter Aryeh Gregor mit, dass er seit Februar 2011 an einer detaillierteren, gesonderten Spezifikation für execCommand und verwandte Techniken arbeite, welche den Abschnitt der HTML5-Spezifikation ablösen soll. Derweil befand sich die W3C-HTML5-Spezifikation in der Last-Call-Phase, welche am 2. August auslief. Was soviel bedeutet wie: Seine Änderungen werden es nicht mehr in HTML5 schaffen.
Nicht nur diese plötzliche Veröffentlichung einer weit gereiften Spezifikation zu einem ungünstigen Zeitpunkt sorgte für Unverständnis bei Aktiven der W3C-HTML-Arbeitsgruppe. Aryeh Gregor sagte gleichzeitig, er beabsichtigte nicht, die Spezifikation dem W3C vorzulegen, damit sie deren Standardisierungsprozess durchlaufe. Vielmehr beantragte er bei der W3C-Arbeitsgruppe, die entsprechenden veralteten Abschnitte zu entfernen (1, 2).
In einem langen Kommentar auf Google Plus erläuterte Gregor seine Entscheidung for not wanting to do anything at the W3C
. Zunächst einmal beklagte er, seitens des W3Cs nur auf Ablehnung zu stoßen. Während die WHATWG-Aktiven wertvolles technisches Feedback gegeben hätten, so drehten sich die restlichen Antworten um procedural and political issues without any concern for the technical work that I spent six months on
. Seine Abneigung gegenüber dem W3C begründet er darin, dass »Implementors«, also vor allem Browserhersteller, die alleinigen Adressaten von Webstandards sein sollten. Alle anderen hingegen hätten bloß eine idealistische anstatt eine pragmatische Herangehensweise und wären nicht direkt betroffen. Sein Schluss daraus ist, dass – eine Meinung, die auch der WHATWG-Gründer Ian »Hixie« Hickson vertritt – niemand außer den Browserherstellern selbst Entscheidungsgewalt über die Spezifikation haben sollte:
An explicit non-goal of any of my standards work is giving non-implementers any binding say in the decision-making process. The only real goal I have is interoperability of implementations, and the only ones whose opinion matters for that goal are implementers.
Vernichtende W3C-Kritik
Insbesondere kritisiert Gregor die Entscheidungsfindung beim W3C, bei der es eine ganze Kaskade von EntscheidungsträgerInnen gibt. Darunter die Mitglieder der Arbeitsgruppe, welche demokratisch abstimmen dürfen, die Vorsitzenden der Arbeitsgruppe, die nach einer Abstimmung die Entscheidung fällen und schließlich der W3C-Direktor Tim Berners-Lee, welcher bei Einsprüchen schlichtet. Letztlich entscheide nicht die Community demokratisch, sondern – genau wie bei der WHATWG – eine Einzelperson willkürlich. In der W3C-Bürokratie, die dieses Machtverhältnis seiner Meinung nach nur verschleiere, sieht Gregor keinen Vorteil, sodass er lieber selbst die Entscheidungsgewalt über seine Spezifikation behalten wolle.
Schließlich wies Gregor darauf hin, dass seine Entscheidung eine persönliche gewesen sei und nicht von seinem Arbeitgeber Google gefällt wurde. Außerdem veröffentlichte er seine Spezifikation unter der Public-Domain-Lizenz, sodass jemand anderes sie bei einer Standardisierungsorganisation einreichen könne – gleichzeitig machte er klar, dass weder er noch der gegenwärtige HTML5-Editor Ian »Hixie« Hickson dazu bereit stünden.
In einem weiteren Kommentar auf Google Plus (bitte herunterscrollen, der Kommentar ist leider nicht direkt verlinkbar) attestierte Gregor dem W3C, dass es nur noch deshalb toleriert werde, da es durch seine Patentpolitik einen rechtlichen Rahmen garantiere und dass Microsoft über das W3C zur Mitarbeit gebracht werden könne. Langfristig tauge das aber nicht zum Fortbestehen, da die meisten Spezifikationen schon von WHATWG-Aktiven geschrieben werden und auch das WHATWG an einer Patentrichtlinie arbeite. Auf die Frage, wie sich das W3C verändern könnte, antwortete er, dass es sich darauf beschränken sollte, was die WHATWG tut – lediglich den technischen und organisatorischen Rahmen zur Arbeit an Webstandards bereitstellen:
So if you want to make people like me actually happy to work at the W3C, you're going to have to make it exactly like the WHATWG: give me a public mailing list and a public bug tracker and a wiki and a place to put the spec, and let me do things however I want with no one allowed to tell me what to do.
Gregor beendete seinen Kommentar damit, dass das W3C keinem einzigen guten Zweck mehr diene.
Plötzliche Wendung: Beide Seiten lenken ein
Durch den Fork der Editing-API-Spezifikation war eine schwierige Situation entstanden. Mitglieder der W3C-Arbeitsgruppe kritisierten, dass damit Teile aus der W3C-Spezifikation herausgerissen werden und nur noch bei der WHATWG weiterentwickelt werden – damit also dem W3C-Standardisierungsprozess entzogen werden. Es wäre nach DOM Range, DOM Parsing and Serialization die dritte Spezifikation von wichtigen JavaScript-APIs gewesen, welche nicht gleichzeitig bei der WHATWG und dem W3C entwickelt wird.
Doch überraschenderweise kam alles anders. Just am 16. August 2011 verkündete das W3C, neben den regulären Working Groups auch sogenannte Community and Business Groups zuzulassen. Während Working Groups klassische Recommendations erarbeiten, so können Community Groups auf eigene Faust Spezifikationen und Test-Suites entwickeln. Sie werden dabei vom W3C unterstützt und können von den Patentrichtlinien des W3Cs profitieren, sind aber nicht an dessen Standardisierungsverfahren gebunden und die Entscheidungsfreiheit bleibt bei den Akteuren selbst.
Aryeh Gregor änderte angesichts dessen teilweise seine Meinung und schrieb auf Google Plus: For the first time, I'm optimistic about the possibility that the W3C is willing to institute enough changes that the WHATWG will no longer be necessary.
Kurzerhand entschied er sich, die Editing-API-Spezifikation in einer neu gegründeten HTML Editing APIs Community Group unter Schirmherrschaft des W3C weiterzuführen. Damit wurde der Weg frei, dass unter anderem der execCommand-Abschnitt in der gegenwärtigen HTML5-Spezifikation durch einen Verweis auf Gregors gesonderte Editing-API-Spezifikation ersetzt werden kann.
Ende gut, alles gut?
Ich habe die obige W3C-Kritik größtenteils unkommentiert gelassen. An der Einzelkämpfer-Mentalität mancher WHATWG-Aktiven und der Abneigung gegenüber den formalisierten W3C-Entscheidungsverfahren wäre sicher einiges auszusetzen. Tatsächlich sind die klassischen W3C-Entscheidungsverfahren bürokratisch. Sie sollen garantieren, dass jeder Einspruch Gehör finden kann und jede Anfrage, jeder Änderungswunsch stoisch nach gleichem und fairem Prozedere abgearbeitet wird. Der Idee nach soll dadurch Willkür ausgeschlossen werden. Prinzipiell kann jede/r Interessierte, auch Nicht-»Implementors«, der W3C-HTML-Arbeitsgruppe beitreten.
Es ist korrekt, dass bei strittigen Fragen nicht im Konsens oder per Mehrheit entschieden wird, sondern die drei Vorsitzenden (Paul Cotton, Microsoft; Sam Ruby, IBM; Maciej Stachowiak, Apple) »Working Group Decisions« fällen. Es stimmt ebenso, dass die Entscheidungsverfahren bei der WHATWG nicht prinzipiell anders aussehen: Jede/r kann Feedback einbringen und Meinungen äußern, am Ende entscheidet Ian »Hixie« Hickson oder der jeweilige Editor – wenn auch weniger formalisiert.
Besonders perfide finde ich die Auffassung, dass letztlich nur das Feedback der »Implementors« zähle. Das bedeutet, dass die kurzfristigen wirtschaftlichen Interessen einiger weniger Browserhersteller die Entwicklung der Webstandards regieren, anstatt eine langfristige Strategie, nach welcher das Web fortentwickelt wird. Es kommt nicht von ungefähr, dass wichtige Grundsätze wie die Accessibility bei manchen HTML5-Techniken bisher schlicht ausgeklammert wurden: Für manche Browserhersteller ist das nur »idealistischer« Ballast. Sie wollen schnell Techniken für ihre Webanwendungen etablieren, um mit Desktop-Software konkurrieren zu können.
Die Entwicklung von HTML5 hat gezeigt, dass ein brauchbarer technischer Standard nur unter Beteiligung der betroffenen Communities entstehen kann: Das sind bei execCommand beispielsweise EntwicklerInnen von CMS, Publishing-Software, Textverarbeitungen und Rich-Text-Editing-Scripten sowie Accessibility- und Usability-ExpertInnen.
Offiziell beziehen sich die meisten Browserhersteller noch auf das W3C, während ihre MitarbeiterInnen sich längst über die WHATWG organisieren und in ihren Blogs, auf Twitter, auf Google Plus und im WHATWG-IRC-Channel offen verkünden, dass das W3C besser heute als morgen verschwinden sollte. Bei aller berechtigter Kritik am W3C scheinen mir die gegenwärtigen Alternativen nicht erstrebenswerter. Diese Mentalität widerspricht eklatant derjenigen kollegialen Zusammenarbeit, die sich die Webstandards-Community über ein Jahrzehnt hinweg mühsam aufgebaut hat.