Im August 2013 postete Aaron Gustafson im WaSP-Blog. Er hatte eine bittersüße Nachricht für eine Gemeinschaft, die er mitgeführt hatte
Dank der harten Arbeit unzähliger WaSP-Mitglieder und Unterstützer (wie Sie) ist Tim Berners-Lees Vision des Webs als offene, zugängliche und universelle Gemeinschaft weitgehend Realität. Zwar gibt es noch viel zu tun, aber der „Stachel“ des WaSP ist nicht mehr notwendig. Und so ist es an der Zeit für uns, The Web Standards Project zu schließen.
Wenn Gustafsons Botschaft auch nur den geringsten Anflug von wehmütigem Bedauern enthält, dann deshalb, weil das Web Standards Project während seiner über 15-jährigen Tätigkeit alles verändert hat, was auf dem Web zur Norm geworden war. Durch Hingabe und Fürsprache von Entwicklern hoben sie das Web aus einem Nest browserübergreifender Inkompatibilität und bedeutungsloser Markups zu der standardisierten und funktionsreichen Anwendungsplattform, die die meisten von uns heute kennen.
Ich habe bereits darüber berichtet, was es brauchte, um CSS ins World Wide Web zu bringen. Dies ist die andere Seite dieser Geschichte. Nur durch die Bemühungen vieler Freiwilliger, die unermüdlich im Hintergrund arbeiteten, hatte CSS überhaupt eine Chance, das zu werden, was es heute ist. Sie sind der Grund, warum wir überhaupt Webstandards haben.
Einführung in Webstandards
Webstandards waren 1998 noch keine Sache. Es gab HTML- und CSS-Spezifikationen und Entwürfe von Empfehlungen, die vom W3C verwaltet wurden, aber sie hatten eine lückenhafte und uneinheitliche Browserunterstützung, was sie zu kaum mehr als Worten auf einem Blatt Papier machte. Zu dieser Zeit standen Webdesigner am Rande dessen, was bald als Browser-Kriege bekannt werden sollte, in denen Netscape und Microsoft in einem eskalierenden Kampf um Marktanteile um exklusive Funktionen und Add-ons wetteiferten. Anstatt sich an irgendeine offizielle Spezifikation zu halten, zwangen diese Browser die Designer, entweder Netscape Navigator oder Internet Explorer zu unterstützen. Und die Designer waren damit definitiv nicht glücklich.
Die Unterstützung beider Browser und ihrer konkurrierenden Feature-Implementierungen war zwar möglich, aber auch schwierig und unzuverlässig, wie das Bauen eines Hauses auf Sand. Um sich gegenseitig zu helfen, begannen viele Entwickler, Mailinglisten zu abonnieren, um Tipps und Tricks für den Umgang mit Websites auszutauschen, die gut aussehen mussten, egal wo sie gerendert wurden.
Aus diesen Mailinglisten begann sich eine Gruppe um eine völlig neue Idee zu formieren. Das Problem, erkannte diese neue Gruppe, lag nicht am Code, sondern an den Browsern, die sich weigerten, die vom W3C herausgegebenen kodifizierten, offenen Spezifikationen einzuhalten. Browser priesen neue präsentationsbezogene HTML-Elemente wie den <blink>-Tag an, aber diese waren proprietär und boten keine Layout-Optionen. Was das Web brauchte, waren Browser, die den *Standards* des Webs folgen konnten.
Die Gruppe entschied, dass sie aktiv werden und die Browser in die richtige Richtung drängen musste. Sie nannten sich The Web Standards Project. Und da der Prozess eine gewisse Schärfe erforderte, nannten sie sich kurz WaSP.
Gründung des Web Standards Project
Im August 1998 gab WaSP seine Mission der Öffentlichkeit auf einer brandneuen Website bekannt: „Diese Kernstandards zu unterstützen und die Browserhersteller aufzufordern, dasselbe zu tun, um einfachen, erschwinglichen Zugang zu Webtechnologien für alle zu gewährleisten.“ Innerhalb weniger Stunden traten 450 Personen WaSP bei. Innerhalb weniger Monate stieg diese Zahl auf Tausende an.

WaSP verfolgte im Grunde einen zweigleisigen Ansatz. Das erste war öffentlich, wobei die gesammelte Welle der Entwicklerunterstützung genutzt wurde, um für eine bessere Einhaltung von Standards in Browsern zu lobbyieren. Mit Basis-Taktiken und gezielter Ansprache schickte WaSP seine Mitglieder oft auf „Missionen“, wie z. B. das Versenden von E-Mails an Browser, in denen ihre Schwierigkeiten im Umgang mit einem Mangel an konsistenter Webstandard-Unterstützung detailliert erläutert wurden.
Sie veröffentlichten auch vernichtende Berichte, die Browser bloßstellten, und hoben alle Wege hervor, auf denen Netscape oder Internet Explorer die notwendige Unterstützung nicht hinzufügten, bis hin zur Ermutigung von Benutzern, alternative Browser zu verwenden. In diesen Berichten machte das Projekt seinem Akronym wirklich alle Ehre. Man muss nur ein Zitat aus WaSPs scharfer Abrechnung mit dem Internet Explorer als Beispiel für seine Fähigkeit, zu „stechen“ ansehen.
Hör auf, bevor die Arbeit getan ist, und der Flammenwerfer ist die einzige Antwort. Denn das ist unsere Aufgabe. Wir sprechen für Tausende von Webentwicklern und durch sie für Millionen von Webnutzern.
Der zweite Zweig von WaSPs Ansatz umfasste die private Kontaktaufnahme mit leidenschaftlichen Entwicklern in Browser-Teams. Das Problem für große Unternehmen wie Netscape und Microsoft war nicht, dass Ingenieure gegen Webstandards waren. Ganz im Gegenteil. Viele Browser-Ingenieure glaubten tief an die Mission von WaSP, wurden aber immer wieder durch wahrgenommene Geschäftsinteressen und bürokratische Hürden behindert. Infolgedessen arbeitete WaSP oft mit Browser-Entwicklern zusammen, um den besten Weg nach vorne zu finden und sich gegebenenfalls für sie bei den Vorgesetzten einzusetzen.
Alles zusammenhalten
Um WaSP bei der Navigation durch seine Missionen, Berichte und Öffentlichkeitsarbeit zu unterstützen, wurde ein Lenkungsausschuss gebildet. Dieser Ausschuss half bei der Festlegung der Projektziele und wandte sich an die Community, um Unterstützung zu sammeln. Sie waren die Vorboten eines bald kommenden besseren Tages, und nicht wenige einflussreiche Mitglieder sollten ihre Reihen durchlaufen, bevor das Projekt vorbei war, darunter: Rachel Cox, Tim Bray, Steve Champeon, Glenn Davis, Glenda Sims, Todd Fahrner, Molly Holzschalg und Aaron Gustafson, unter vielen, vielen anderen.
An der Spitze stand ein Projektleiter, der den Ton für die Gruppe vorgab und den Entwicklern eine einheitliche Stimme gab. Die Position wurde zunächst von George Olsen, einem der Gründer des Projekts, bekleidet, aber bald von einem anderen Gründungsmitglied übernommen: Jeffrey Zeldman.
Ein Netzwerk von lose verbundenen Satellitengruppen, die um den Lenkungsausschuss kreisten, half Entwicklern und Browsern gleichermaßen, die Bedeutung von Webstandards zu verstehen. Es gab beispielsweise eine Accessibility-Gruppe, die das W3C mit Browserherstellern verband, um sicherzustellen, dass das Web für alle offen und zugänglich war. Dann gab es die CSS Samurai, die Berichte über die CSS-Unterstützung (oder häufiger deren Fehlen) in verschiedenen Browsern veröffentlichten. Sie waren diejenigen, die den Box Acid Test entwickelten und Browsern Anleitungen anboten, während sie daran arbeiteten, die CSS-Unterstützung zu erweitern. Todd Fahrner, der mit dem Doctypes-Switching zur Rettung von CSS beigetragen hat, zählte sich zu den CSS Samurai.
Auswirkungen erzielen
WaSP war riesig und wuchs ständig. Seine Mitglieder waren leidenschaftlich und nach und nach kamen Cluster der Community zusammen, um Veränderungen zu bewirken. Und genau das geschah.
Die Veränderungen fühlten sich anfangs eher klein an, bald aber grenzten sie an massiv. Als Netscape mit der Idee eines neuen Rendering-Engines namens Gecko herumspielte, der eine deutlich bessere Unterstützung von Standards im Allgemeinen beinhalten sollte, hätte die ursprüngliche Zeitplanung Monate gedauert. Aber die WaSP-Mitglieder strömten herbei, schrieben E-Mails und kontaktierten Netscape, um Druck auf sie auszuüben, Gecko früher zu veröffentlichen. Es funktionierte und bei der nächsten Veröffentlichung wurde Gecko (und bessere Webstandards) ausgeliefert.
Tantek Çelik war ein weiteres Mitglied von WaSP. Die Community inspirierte ihn, bei seiner täglichen Arbeit als leitender Entwickler von Internet Explorer für Mac Stellung zu Webstandards zu beziehen. Durch die Ermutigung und Unterstützung von WaSP veröffentlichten er und sein Team Version 5 mit voller CSS Level 1-Unterstützung.

Im August 2001, nach Jahren öffentlicher Berichte, privater Kontaktaufnahmen und Entwicklervertretung, provozierte der WaSP-„Stachel“ seismische Veränderungen in Internet Explorer, als Version 6 mit CSS Level 1-Unterstützung und den neuesten HTML-Funktionen veröffentlicht wurde. Die Upgrades waren zu einem großen Teil der Arbeit des Web Standards Project und ihrer Zusammenarbeit mit engagierten Mitgliedern des Browser-Teams zu verdanken. Es schien, dass Standards tatsächlich zu gewinnen begannen. Die Mission von WaSP mag sogar vorbei gewesen sein.
Aber anstatt aufzugeben, änderten sie ihre Taktik ein wenig.
Standards einer neuen Generation vermitteln
In den frühen 2000er Jahren änderte WaSP radikal seinen Ansatz in Bezug auf Bildung und Entwickler-Outreach.
Sie begannen mit der Einführung der Browser Upgrade Campaign, die Benutzer aufklärte, die zum allerersten Mal online kamen und absolut nichts über Webstandards und moderne Browser wussten. Website-Besitzer wurden ermutigt, etwas JavaScript und ein Banner auf ihren Websites hinzuzufügen, um diese Benutzer anzusprechen. Infolgedessen wurden Benutzer, die mit älteren Versionen standardkonformer Browser wie Firefox oder Opera auf eine Website surften, von einem Banner begrüßt, das sie einfach zur Aktualisierung aufforderte. Benutzer, die die Website mit einem sehr alten Browser wie einem Pre-IE5 oder Netscape 5 besuchten, wurden auf eine völlig neue Seite weitergeleitet, auf der erklärt wurde, warum ein Upgrade auf einen modernen Browser mit Standardunterstützung in ihrem besten Interesse lag.

WaSP wollte das Web auf den neuesten Stand bringen, selbst wenn es das eine Person nach der anderen tun musste. Vielleicht hat niemand dieses Gefühl besser formuliert als Molly Holzschalg, als sie im Februar 2002 „Raise Your Standards“ schrieb. In dem Artikel erläuterte sie, was Webstandards sind und was sie für Entwickler und Designer bedeuteten. Sie feierte die Arbeit, die Browser und die Community geleistet hatten, um Webstandards überhaupt erst zu ermöglichen.
Aber, argumentierte sie, das Web sei noch lange nicht fertig. Es sei nun an den Entwicklern, die Verantwortung für die Standards selbst zu übernehmen, indem sie diese in all ihren Websites implementieren. Sie schrieb:
Das Konsortium hat mit seinen eigenen internen Problemen zu kämpfen, und seine Handlungen – obwohl fast immer im besten Interesse professioneller Webautoren – werden gelegentlich politisiert.
Daher sind wir als Webautoren persönlich dafür verantwortlich, Implementierungsentscheidungen im Rahmen der Markup-Anforderungen einer Website zu treffen. Es ist unsere Aufgabe, Empfehlungen nach besten Kräften zu verwalten.
Das wäre jedoch nicht einfach. Es würde erneut die gebündelten Bemühungen von WaSP-Mitgliedern erfordern, sich zusammenzutun und dem Web eine neue Art des Codierens beizubringen. Einige begannen, Tutorials auf ihren persönlichen Blogs oder auf A List Apart zu veröffentlichen. Andere erstellten einen standardbasierte Online-Lehrplan für Webentwickler, die neu in diesem Bereich waren. Einige Mitglieder bildeten sogar brandneue Task Forces, um mit beliebten Software-Tools wie Adobe Dreamweaver zusammenzuarbeiten und sicherzustellen, dass Standards auch dort unterstützt wurden.
Die Neugestaltung von ESPN und Wired, die jahrelang als Zeugnis und Beispiel für standardbasierte Designs dienten, wurde teilweise unternommen, weil Mitglieder dieser Teams von der Arbeit, die WaSP leistete, inspiriert waren. Sie hätten diese entscheidenden ersten Schritte nicht tun können, wenn nicht die Beispiele und Tutorials, die ihnen von wohlwollenden WaSP-Mitgliedern kostenlos zur Verfügung gestellt wurden.
Deshalb sind Webstandards für viele Webentwickler heute im Grunde zweite Natur. Deshalb haben wir auch einen so freien Geist des kreativen Austauschs in unserer Branche. Alles begann, als WaSP beschloss, den richtigen Weg, Dinge richtig zu tun, offen zu teilen.
Blick über Webstandards hinaus
Es war diese Offenheit, die WaSP in die späten 2010er Jahre trug. Als Holzschlag die Leitung übernahm, setzte sie sich für Transparenz und Zusammenarbeit zwischen Browserherstellern und der Web-Community ein. Holzschlag erkannte, dass der WaSP nicht mehr notwendig war und von innen heraus erledigt werden konnte. Zum Beispiel knüpfte sie Verbindungen zu Microsoft, um Webstandards zu einer Top-Priorität in deren Browser-Team zu machen.
Mit jeder nachfolgenden Veröffentlichung holten die Browser die neuesten Standards des W3C ein. Browser wie Opera und Firefox konkurrierten tatsächlich um die Unterstützung der neuesten Standards. Google Chrome nutzte Webstandards als Verkaufsargument, als er ursprünglich etwa zur gleichen Zeit veröffentlicht wurde. Die anderthalb Jahrzehnte Arbeit von WaSP zahlten sich aus. Browserhersteller hörten auf das W3C und die Web-Community und experimentierten sogar mit neuen Standards, bevor sie offiziell zur Empfehlung veröffentlicht wurden.
Im Jahr 2013 veröffentlichte WaSP seine Abschiedserklärung und schloss endgültig die Pforten. Es war eine schwierige Entscheidung für diejenigen, die lange und hart für ein besseres, zugänglicheres und offeneres Web gekämpft hatten, aber sie war notwendig. Es gibt immer noch eine Reihe von Schlachtfeldern für das offene Web, aber dank der Bemühungen von WaSP wurde das für Webstandards gewonnen.
Mögen Sie mehr über Webgeschichte erfahren? Jay Hoffmann hat einen wöchentlichen Newsletter namens The History of the Web, für den Sie sich hier anmelden können.
Spulen wir vor bis heute und wir schreiben HTML in JS.
Das Internet ist wieder kaputt…
Nicht nur das, sondern wir (das königliche „wir“, nicht wir persönlich) codieren mit browser-spezifischem Code (kommt das bekannt vor?) und testen nur in diesem Browser (Chrome ist im Grunde jetzt das neue IE und das sage ich schon seit Jahren). Große Produktionswebsites verwenden browser-spezifische (wieder Chrome) Entwurfs-JavaScript-Spezifikationen, und wir sind sogar an den Punkt gelangt, an dem ein erstaunlicher Browser, der oft an der Spitze großartiger Ideen stand (Tabbed Browsing, Barrierefreiheits-Stylesheets, Quickdial-Homepage), gezwungen war, seine Rendering-Engine auf Webkit umzustellen, damit Websites, die speziell auf Webkit abzielen, nicht kaputt aussehen! Wirklich, wir gehen rückwärts. Ich gebe schlechten Entwicklern, faulen Entwicklern die Schuld. Browser sollten versuchen, neue Funktionen zu implementieren, aber als Entwickler sollten wir uns bewusst sein, was Entwurf und was endgültig ist, und auch, was geprägte Funktionen abgeschlossene Spezifikationen haben.
Meiner Meinung nach waren und sind Webstandards die wichtigste Angelegenheit bei der Entwicklung/Gestaltung für das WWW. Leider scheinen sie nicht mehr dieselbe Bedeutung zu haben. Die heutigen Designer erstellen fantastische Websites, solange JavaScript aktiviert ist. Ich amüsiere mich oft damit, durch all die CSS-Galerien und ihre preisgekrönten Websites zu surfen, nur um zu sehen, dass die meisten von ihnen auf JavaScript basieren (ohne jeglichen Fallback). Wenn ich JavaScript deaktiviere, erhalte ich einen weißen Bildschirm. Nichts funktioniert. Und das ist preisgekrönt??? JavaScript ist heute das Flash von gestern.