Kapitel 7: Standards

Im Jahr 1994 trat das Web aus dem Schatten der akademischen Welt und auf die Bildschirme aller. Insbesondere die zweite Hälfte der zweiten Dezemberwoche 1994 krönte das Jahr mit drei ereignisreichen Tagen.

Mitglieder des World Wide Web Consortiums hockten am Mittwoch, dem 14. Dezember, um einen Tisch im MIT. Etwa zwei Dutzend Personen nahmen an dem Treffen teil, darunter Vertreter großer Technologieunternehmen, Browserhersteller und Web-Start-ups. Sie waren dort, um über offene Standards für das Web zu diskutieren.

Richtig gemacht, setzen Standards einen technischen Leitstern. Unternehmen mit konkurrierenden Interessen und Prioritäten können sich an einem gemeinsamen Satz vereinbarter Dokumentationen orientieren, wie eine Technologie funktionieren sollte. Konsens über gemeinsame Standards schafft Interoperabilität; Wettbewerb findet über die Benutzererfahrung statt, nicht über die technische Infrastruktur.

Das World Wide Web Consortium, oder W3C, wie es häufiger bezeichnet wird, schwebte dem Schöpfer des Webs, Sir Tim Berners-Lee, bereits 1992 vor. Er hatte sich mit einer wechselnden Liste von Experten und Beratern über eine offizielle Standardisierungsorganisation für Webtechnologien ausgetauscht. Das MIT Laboratory for Computer Science wurde bald sein enthusiastischster Verbündeter. Nach jahrelanger Arbeit verließ Berners-Lee 1994 im Oktober seinen Job am CERN, um das Konsortium am MIT zu leiten. Er hatte nicht die Absicht, ein Diktator zu sein. Er hatte starke Meinungen über die Richtung des Webs, aber er zog es immer noch vor zuzuhören.

Auf der Tagesordnung – nachdem der Tisch mit einigen grundlegenden Vorstellungen geräumt war – stand eine lange Liste administrativer Details, die geklärt werden mussten. Die Rolle des Konsortiums, seine Arbeitsweise und seine Verantwortung gegenüber dem breiteren Web waren zu Beginn des Treffens kaum mehr als skizziert. Nach und nach gingen die etwa 25 Mitglieder die Liste durch. Am Ende des Treffens war die Gruppe zuversichtlich, dass die Zukunft der Webstandards klar war.

Am nächsten Tag, dem 15. Dezember, kündigten Jim Clark und Marc Andreessen die kürzlich umbenannte Version 1.0 von Netscape Navigator an. Sie war seit mehreren Monaten als Beta-Version verfügbar, aber dieser Donnerstag markierte eine breitere Veröffentlichung. Um den wachsenden Markt zu erschließen, wurde sie zunächst kostenlos angeboten. Mehrere Monate später, nach der Veröffentlichung von Version 1.1, musste Netscape dies zurücknehmen. In jedem Fall war der Browser ein kommerzieller und technischer Erfolg und verbesserte Geschwindigkeit, Benutzerfreundlichkeit und Funktionen von früheren Browsern.

Am Freitag, dem 16. Dezember, erlebte das W3C seinen ersten Rückschlag. Berners-Lee hatte nie vor, dass das MIT der exklusive Standort des Konsortiums sein sollte. Er plante, dass das CERN, die Geburtsstätte des Webs und Heimat einiger seiner größten Befürworter, ein europäischer Gastgeber für die Organisation sein sollte. Am 16. Dezember genehmigte das CERN jedoch ein massives Budget für seinen Large Hadron Collider und zwang sie damit, Prioritäten zu verschieben. Ein neu ausgerichtetes Budget ließ wenig Spielraum für Hypertext-Internet-Experimente, die nicht direkt zum Kernprojekt der Teilchenphysik beitrugen.

Das CERN sollte nicht länger der europäische Gastgeber des W3C sein. Alles war nicht verloren. Monate später richtete das W3C seinen Sitz am französischen National Institute for Research in Computer Science and Control, oder INRIA, ein. Bis 1996 wurde auch ein dritter Standort an der japanischen Keio University eingerichtet.

Weit davon entfernt, ein Ausreißer zu sein, sollte dies nicht der letzte Rückschlag sein, den das W3C jemals erlitt oder überwand.

---

1999 veröffentlichte Berners-Lee in einem Buch mit dem Titel Weaving the Web einen autobiografischen Bericht über die Entstehung des Webs. Es ist eine prägnante und ausgewogene Geschichte, ein flotter Spaziergang durch die wichtigsten Meilensteine des ersten Jahrzehnts des Webs. Während des gesamten Buches kehrt er oft zum Thema W3C zurück.

Er bezeichnet das Web-Konsortium in erster Linie als eine Frage des Kompromisses. „Mir wurde klar, dass die Leitung des Konsortiums immer ein Balanceakt sein würde, zwischen der Zeit, die nötig ist, um so offen wie möglich zu bleiben, und dem Fortschritt in der Geschwindigkeit, die vom Ansturm der Technologie gefordert wird.“ Das Gleichgewicht zwischen gemeinsamer Kompatibilität und immer kürzeren Browser-Release-Zyklen zu finden, wurde zu einem Hauptziel des W3C.

Webstandards, so räumt er ein, gedeihen durch Spannung. Standards werden inmitten von Meinungsverschiedenheiten und hart erkämpften Verhandlungen entwickelt. Berners-Lee erinnert sich an eine Zeit kurz vor der Entstehung des W3C und bemerkt, wie der Standardisierungsprozess die Struktur des Webs widerspiegelt. „Mir fiel auf, dass diese Spannungen das Konsortium zu einem Bewährungsfeld für die relativen Verdienste von web-ähnlichen und baum-ähnlichen gesellschaftlichen Strukturen machen würden“, schrieb er, „Ich war begierig darauf, das Experiment zu beginnen.“ Ein Web-Konsortium, das aus Kompromissen geboren und durch Spannung definiert wurde, war jedoch nicht Berners-Lees erster Plan.

Im März 1992 flog Berners-Lee nach San Diego, um an einer Sitzung der Internet Engineering Task Force, kurz IETF, teilzunehmen. Die 1986 gegründete IETF entwickelt Standards für das Internet, die von Netzwerken über Routing bis hin zu DNS reichen. IETF-Standards sind nicht erzwingbar und völlig freiwillig. Sie werden von keiner Weltregierung genehmigt und unterliegen keiner Regulierung. Niemand ist verpflichtet, sie zu verwenden. Stattdessen stützt sich die IETF auf ein einfaches Konzept: Interoperabilität hilft allen. Das hat ausgereicht, um die Organisation seit Jahrzehnten aufrechtzuerhalten.

Da alles freiwillig ist, wird die IETF durch eine verschlungene Reihe von Regeln und rituellen Prozessen verwaltet, die schwer zu verstehen sein können. Es gibt keine formelle Mitgliedschaft, obwohl jeder beitreten kann (in ihren eigenen Worten hat sie „keine Mitglieder und keine Beiträge“). Jeder ist ein Freiwilliger, niemand wird bezahlt. Die Gruppe trifft sich dreimal im Jahr persönlich an wechselnden Orten.

Die IETF arbeitet nach einem Prinzip, das als grober Konsens bekannt ist (und oft auch laufender Code). Anstatt eines formellen Abstimmungsverfahrens müssen strittige Vorschläge zu einer Einigung gelangen, bei der die Mehrheit, wenn nicht alle, der Mitglieder einer technologischen Arbeitsgruppe zustimmt. Die Mitglieder der Arbeitsgruppe entscheiden, wann ein grober Konsens erreicht ist, und dessen Kriterien ändern sich von Jahr zu Jahr und von Gruppe zu Gruppe. In einigen Fällen hat sich die IETF des Summens bedient, um die Stimmung eines Raumes zu erfassen. „Wenn wir zum Beispiel persönliche Treffen abhalten… anstatt einer Handabstimmung, bittet der Vorsitzende manchmal jede Seite, bei einer bestimmten Frage zu summen, entweder „dafür“ oder „dagegen“.

Vor dem Hintergrund dieser eigenwilligen Regeln kam Berners-Lee im März 1992 erstmals zur IETF. Er hoffte, eine Arbeitsgruppe für jede der primären Technologien des Webs einzurichten: HTTP, HTML und URI (das später durch die IETF in URL umbenannt wurde). Im März wurde ihm gesagt, er benötige ein weiteres Treffen, dieses im Juni, um die Arbeitsgruppen formell vorzuschlagen. Irgendwann gegen Ende 1993, anderthalb Jahre nach Beginn, hatte er die IETF überzeugt, alle drei einzurichten.

Der Prozess des groben Konsenses kann langsam sein. Das Web hatte im Gegensatz dazu neu definiert, wie schnell aussehen konnte. Neue Browser-Generationen erschienen in Monaten, nicht in Jahren. Und das war noch bevor Netscape und Microsoft involviert waren.

Die Entwicklung des Webs war aus Berners-Lees Einflussbereich geraten. Inline-Bilder – ein Merkmal, das vielleicht am meisten für den Erfolg des Webs verantwortlich ist – war das Ergebnis einer nächtlichen Brainstorming-Sitzung bei Snacks und Limonade im Keller eines Universitätslabors. Berners-Lee erfuhr davon, als alle anderen es erfuhren, als Marc Andreessen es auf der www-talk-Mailingliste veröffentlichte.

Spannung. Berners-Lee wusste, dass es kommen würde. Er hatte zum Beispiel gehofft, dass Bilder anders behandelt werden könnten („Tim hat mich im Sommer 93 beschimpft, weil ich Bilder hinzugefügt habe“, sagte Andreessen später), aber das Web war nicht seins. Es war niemandes. Er hatte es so entworfen.

Mit all seinen Regeln und Ritualen schien die IETF für Webstandards nicht die richtige Wahl zu sein. In privaten Gesprächen an Universitäten und Forschungslabors begann Berners-Lee, einen neuen Weg zu erkunden. So etwas wie ein Konsortium von Interessengruppen des Webs – eine Sammlung von Unternehmen, die Browser, Websites und Software erstellen –, die zusammenkommen, um einen groben Konsens für sich selbst zu erzielen. Bis Ende 1993 hatte seine Arbeit am W3C bereits begonnen.

---

Dave Raggett, ein erfahrener Forscher bei Hewlett-Packard, hatte eine andere Sichtweise auf das Web. Er stammte nicht aus der akademischen Welt und arbeitete nicht an einem Browser (zumindest noch nicht). Er verstand fast instinktiv den Nutzen des Webs als kommerzielle Software. Etwas weniger wie ein digitales Telefonbuch und mehr wie Apples äußerst erfolgreiche Hypercard-Anwendung.

Da er seine Vorgesetzten von dem Potenzial des Webs nicht überzeugen konnte, nutzte Raggett die zehn Prozent seiner Zeit, die HP seinen Mitarbeitern für unabhängige Forschung erlaubte, um mit dem Web zu arbeiten. Er verankerte sich in der Community, wurde aktives Mitglied der www-talk-Mailingliste und war regelmäßiger Gast bei IETF-Meetings. Im Herbst 1992 hatte er die Gelegenheit, Berners-Lee am CERN zu besuchen.

Etwa zu dieser Zeit lernte er Yuri Rubinsky kennen, einen enthusiastischen Verfechter der Standard General Markup Language, kurz SGML, der Sprache, auf der HTML ursprünglich basierte. Rubinsky glaubte, dass die Einschränkungen von HTML durch eine strengere Einhaltung des SGML-Standards behoben werden könnten. Er hatte eine Kampagne gestartet, um SGML ins Web zu bringen. Raggett stimmte zu – aber bis zu einem gewissen Punkt. Er war noch nicht bereit, die Verbindungen zu HTML zu kappen.

Jedes Mal, wenn Mosaic eine neue Version veröffentlichte oder ein neuer Browser erschien, vergrößerte sich die Lücke zwischen der ursprünglichen HTML-Spezifikation und dem realen Web. Raggett glaubte, dass eine umfassendere Dokumentation von HTML erforderlich sei. Er begann an einer erweiterten Version von HTML und einem Browser zu arbeiten, um deren Fähigkeiten zu demonstrieren. Sein Arbeitstitel war HTML+.

Ragggets Arbeit schwappte bald auf sein Privatleben über. Er verbrachte die meisten Nächte „an einem großen Computer, der einen erheblichen Teil des Esstisches beanspruchte und seine leicht klebrige Oberfläche mit Papier, Buntstiften, Legosteinen und halb aufgegessenen Keksen teilte, die von den Kindern übrig gelassen wurden.“ Nach einem Jahr Rund-um-die-Uhr-Arbeit hatte Raggett im November 1993 eine Version von HTML+ fertig. Seine Verbesserungen an der Sprache waren alles andere als oberflächlich. Er hatte es geschafft, all die kleinen Dinge hinzuzufügen, die in Browsern Einzug gehalten hatten: Tabellen, Bilder mit Bildunterschriften und Grafiken sowie fortgeschrittene Formulare.

Mehrere Monate später, im Mai 1994, reisten Entwickler und Web-Enthusiasten aus aller Welt zu dem, was einige Teilnehmer scherzhaft als „Woodstock des Webs“ bezeichneten, der ersten offiziellen Webkonferenz, die vom CERN-Mitarbeiter und Web-Pionier Robert Calliau organisiert wurde. Von den 800 Menschen, die unbedingt teilnehmen wollten, konnte der Veranstaltungsort in Genf nur 350 aufnehmen. Viele trafen sich zum ersten Mal. „Alle schlenderten in der Lobby herum“, beschrieb der Webhistoriker Marc Weber später, „elektrisiert von demselben Gefühl, tatsächlich die Personen persönlich zu treffen, die nur Namen in einer E-Mail oder auf der www-talk-Mailingliste gewesen waren.“

Es geschah in einem Moment, als das Web am Rande der Ubiquität stand. Niemand vom Mosaic-Team hatte es geschafft (sie hatten ihre eigene konkurrierende Konferenz nur wenige Monate später), aber es gab bereits Gerüchte über Marc Andreessens neues kommerzielles Browser-Projekt, das später Netscape Navigator heißen sollte. Mosaic hatte inzwischen begonnen, seinen Browser für kommerzielle Zwecke zu lizenzieren. Eine frühe Version von Yahoo! wuchs exponentiell, da immer mehr Publikationen wie GNN, Wired, The New York Times und The Wall Street Journal online gingen.

Die Fortschritte bei der IETF waren dagegen langsam. Sie war zu akribisch, zu präzise. In der Zwischenzeit hatten Browser wie Mosaic begonnen, hinzuzufügen, was sie wollten – insbesondere zu HTML. Von Mosaic unterstützte Tags waren anderswo nicht zu finden, und Website-Ersteller mussten sich zwischen Spitzentechnologie und Kompatibilität mit anderen Browsern entscheiden. Viele entschieden sich für erstere.

HTML+ war das größte Gesprächsthema auf der Konferenz. Ein weiteres Highlight war jedoch, als Dan Connolly – ein junger, „rothaariger Texaner mit Marinehaarschnitt“, der bei dem Supercomputerhersteller Convex arbeitete – die Bühne betrat. Er hielt einen Vortrag mit dem Titel „Interoperabilität: Warum alle gewinnen“. Später, und maßgeblich wegen dieses Vortrags, wurde Connolly zum Vorsitzenden der IETF HTML Working Group ernannt.

In einem vorausschauenden Moment, der den Geist des Raumes einfing, beschrieb Connolly eine Zukunft, in der die Sprache HTML zerfallen würde. Wenn jeder Browser seine eigenen HTML-Tags implementierte, um den Wettbewerb zu übertreffen. Die Lösung, so schloss er, sei ein HTML-Standard, der mit der Geschwindigkeit der Browserentwicklung mithalten könne.

Raggget's HTML+ machte einen starken Fall dafür, dieser Standard zu werden. Er war erschöpfend und beschrieb das neue HTML, das in Browsern wie Mosaic verwendet wurde, fast perfekt detailliert. „Ich war immer der Minimalist, wissen Sie, man kann es auch damit schaffen“, sagte Connolly später, „Raggett hingegen wollte alles erweitern.“ Die beiden trafen eine Vereinbarung. Raggett würde weiterhin an HTML+ arbeiten, während Connolly sich auf ein engeres Upgrade konzentrierte.

Connollys Version wurde bald zu HTML 2 und wurde nach einem Jahr des Hin und Her und der groben Konsensfindung bei der IETF zu einem offiziellen Standard. Er hatte bei weitem nicht die Detailtiefe von HTML+, aber Connolly konnte Features offiziell dokumentieren, die Browser seit Jahren unterstützten.

Ragggets Vorschlag, der in HTML 3 umbenannt wurde, steckte fest. Um einem wachsenden Web Rechnung zu tragen, wuchs er weiter an Größe. „Konsens über einen 150 Seiten langen Entwurf zu erzielen, zu dem jeder eine Meinung äußern wollte, war, gelinde gesagt, optimistisch“, drückte sich Raggett später recht unverblümt aus. Aber zu diesem Zeitpunkt arbeitete Raggett bereits für das W3C, wo HTML 3 bald Realität werden sollte.

---

Berners-Lee sprach ebenfalls auf der ersten Webkonferenz in Genf und beendete sie mit einer Keynote-Adresse. Er erwähnte das W3C nicht explizit. Stattdessen konzentrierte er sich auf die Rolle des Webs. „Die anwesenden Personen waren diejenigen, die das Web jetzt schufen“, schrieb er später über seine Rede, „und waren daher die Einzigen, die sicherstellen konnten, dass die von den Systemen produzierten Ergebnisse für eine vernünftige und gerechte Gesellschaft angemessen waren.“

Im Oktober 1994 unternahm er seinen eigenen Beitrag zur Schaffung einer gerechteren und zugänglicheren Zukunft für das Web. Das World Wide Web Consortium wurde offiziell angekündigt. Berners-Lee wurde von einer Handvoll Mitarbeitern unterstützt – zu denen sowohl Dave Raggett als auch Dan Connolly gehörten. Zwei Monate später, in der zweiten Hälfte der zweiten Dezemberwoche 1994, trafen sich die Mitglieder des W3C zum ersten Mal.

Vor dem Treffen hatte Berners-Lee eine grobe Skizze, wie das W3C funktionieren würde. Jedes Unternehmen oder jede Organisation konnte beitreten, sofern sie die Mitgliedsgebühr zahlten, eine gestaffelte Preisstruktur, die an die Größe des Unternehmens gebunden war. Mitgliedsorganisationen würden Vertreter zu W3C-Treffen entsenden, um Input in den Prozess der Standarderstellung zu geben. Indem er die W3C-Verfahren auf zahlende Mitglieder beschränkte, hoffte Berners-Lee, die Gespräche auf reale Implementierungen von Webtechnologien zu fokussieren und zu begrenzen.

Trotz einer geschlossenen Mitgliedschaft agiert das W3C nach Möglichkeit offen. Besprechungsprotokolle und Dokumentationen sind für die Öffentlichkeit zugänglich. Jeder Code, der als Teil von Experimenten mit neuen Standards geschrieben wurde, ist frei herunterladbar.

Im MIT versammelt, mussten die W3C-Mitglieder als Nächstes entscheiden, wie ihre Standards funktionieren würden. Sie entschieden sich für einen Prozess, der knapp unterhalb des groben Konsenses liegt. Obwohl sie oft als Standards bezeichnet werden, schafft das W3C keine offiziellen Standards für das Web. Die im W3C erstellten technischen Spezifikationen werden in ihrer endgültigen Form als Empfehlungen bezeichnet.

Sie sind im Wesentlichen Vorschläge. Sie beschreiben im Detail, wie genau eine Technologie funktioniert. Aber sie lassen genug offen, dass es den Browsern überlassen bleibt, genau herauszufinden, wie die Implementierung funktioniert. „Das Ziel des W3C ist es, die Interpretierbarkeit des Webs sicherzustellen, und das ist langfristig realistisch“, beschrieb die frühere Kommunikationschefin des W3C, Sally Khudairi, es einmal, „aber kurzfristig werden wir nicht die Web-Polizei für die Einhaltung spielen… wir können Mitglieder nicht zwingen, Dinge zu implementieren.“

Erste Entwürfe schaffen eine Feedback-Schleife zwischen dem W3C und seinen Mitgliedern. Sie liefern Anleitungen für Webtechnologien, aber auch während der Ausarbeitung von Spezifikationen beginnen Browser, diese einzuführen, und Entwickler werden ermutigt, damit zu experimentieren. Jedes Mal, wenn Probleme auftreten, wird der Entwurf überarbeitet, bis genügend Konsens erzielt ist. Zu diesem Zeitpunkt wird ein Entwurf zu einer Empfehlung.

Es würde immer Spannungen geben, und Berners-Lee wusste das gut. Der Trick war nicht, zu versuchen, sie zu widerstehen, sondern einen Prozess zu schaffen, bei dem sie zu einem Vorteil werden. So war die beabsichtigte Wirkung von Empfehlungen.

Ende 1995 wurde die IETF HTML-Arbeitsgruppe durch ein neu geschaffenes W3C HTML Editorial Review Board ersetzt. HTML 3.2 war die erste HTML-Version, die vollständig vom W3C herausgegeben wurde und größtenteils auf Raggget's HTML+ basierte.

---

Es gab ein Jahr in der Webentwicklung, 1997, in dem Browser von den noch neuen Empfehlungen des W3C abwichen. Microsoft und Netscape begannen, eine neue Reihe von Funktionen separat von vereinbarten Standards zu veröffentlichen. Sie hatten sogar einen Namen dafür. Sie nannten es Dynamic HTML oder DHTML. Und sie spalteten das Web fast in zwei Hälften.

DHTML wurde ursprünglich gefeiert. Dynamisch bedeutete flüssig. Eine natürliche Weiterentwicklung des anfänglich inerten Zustands von HTML. Das Web, mit anderen Worten, erwachte zum Leben.

Die Fähigkeiten hervorhebend, ein Artikel in Wired im Jahr 1997 bezeichnete DHTML als den „Zauberstab, den Web-Zauberer schon lange gesucht haben“. In seiner Begeisterung für die neue Technologie bemerkt es beiläufig, dass „Microsoft und Netscape zu ihrem Verdienst mit den Standardisierungsgremien zusammengearbeitet haben“, insbesondere bei der Einführung von Cascading Style Sheets, oder CSS, aber dass die meisten Features „ohne viel Rücksicht auf Kompatibilität“ hinzugefügt wurden.

Die Wahrheit vor Ort war, dass die Verwendung von DHTML das Anvisieren eines bestimmten Browsers erforderte, Netscape oder Internet Explorer. Einige Entwickler entschieden sich einfach, einen Weg zu wählen, indem sie ein Banner am unteren Rand ihrer Website anbrachten, das „Am besten viewed in…“ auf den einen oder anderen Browser anzeigte. Andere ignorierten die Technologie vollständig und hofften, ihre verworrene Komplexität zu vermeiden.

Die Browser hatten natürlich ihre Gründe. Entwickler und Benutzer fragten nach Dingen, die nicht in der offiziellen HTML-Spezifikation enthalten waren. Wie ein Microsoft-Vertreter es ausdrückte: „Um neue Technologien in die Standardisierungsgremien zu bringen, muss man weiter innovieren… Ich bin meinen Kunden verpflichtet, und das sind die Leute von Netscape auch.“

Ein dynamischeres Web war nichts Schlechtes, aber ein gespaltenes Web war untragbar. Für einige Entwickler sollte es der letzte Strohhalm sein.

---

Nach der Veröffentlichung von HTML 3.2 und mit der rasanten Weiterentwicklung der Browser wurde das HTML Editorial Review Board in drei Teile aufgeteilt. Jedem wurde ein separater Aufgabenbereich zugewiesen, um unabhängig voneinander Fortschritte zu erzielen.

Dr. Lauren Wood wurde Vorsitzende der Document Object Model Working Group. Als ehemalige theoretische Kernphysikerin war Wood Director of Product Technology bei SoftQuad, einem Unternehmen, das vom SGML-Verfechter Yuri Rubinsky gegründet wurde. Dort half sie bei der Arbeit am HoTMetaL HTML-Editor. Die DOM-Spezifikation schuf eine standardisierte Methode für Browser zur Implementierung von Dynamic HTML. „Man muss eine Möglichkeit haben, seine Daten und seine Programme miteinander zu verbinden“, beschrieb Wood es, „und das Document Object Model ist dieser Klebstoff.“ Ihre Arbeit am Document Object Model und später an XML würde einen nachhaltigen Einfluss auf das Web haben.

Die Cascading Style Sheets Working Group wurde von Chris Lilley geleitet. Lilley hatte einen Hintergrund in Computergrafik als Lehrer und Spezialist in der Computer Graphics Unit der University of Manchester. Lilley hatte bei der IETF an der HTML 2-Spezifikation sowie an einer Spezifikation für Portable Network Graphics (PNG) gearbeitet, aber dies wäre seine erste Teilnahme als Leiter einer Arbeitsgruppe.

CSS war 1997 noch ein relativer Neuling. Es war seit Jahren in Arbeit, aber hatte noch keine große Veröffentlichung gesehen. Lilley würde mit den Schöpfern von CSS – Håkon Lie und Bert Bos – zusammenarbeiten, um den ersten CSS-Standard zu erstellen.

Die letzte Arbeitsgruppe war für HTML, die unter der Schirmherrschaft von Dan Connolly verblieb und seine Position von der IETF fortsetzte. Connolly war fast so lange im Web dabei wie Berners-Lee. Er gehörte zu den Leuten, die im Oktober 1991 zusah, als Berners-Lee das Web einer kleinen Gruppe unbeeindruckter Leute auf einer Hypertext-Konferenz in San Antonio vorführte. Tatsächlich traf er auf dieser Konferenz zum ersten Mal die Frau, die später seine Frau werden sollte.

Nach seiner Rückkehr nach Hause experimentierte er mit dem Web. Er schickte Berners-Lee einen Monat später eine Nachricht. Es waren nur drei Worte: „You need a DTD.“

Als Berners-Lee die Sprache HTML entwickelte, lehnte er deren Konventionen an einen Vorgänger an, SGML. IBM entwickelte in den frühen 1970er Jahren die Generalized Markup Language (GML), um es Tippern zu erleichtern, formatierte Bücher und Berichte zu erstellen. Sie geriet jedoch schnell außer Kontrolle, da die Leute Abkürzungen nahmen und beliebige Versionen der Tags verwendeten, die sie wollten.

Da entwickelten sie die Document Type Definition, oder wie Connolly es nannte, eine DTD. DTDs sind das, was GML das „S“ (Standardisiert) hinzufügte. Mit SGML können Sie einen standardisierten Satz von Anweisungen für Ihre Daten, ihr Schema und ihre Struktur erstellen, damit Computer verstehen können, wie sie interpretiert werden. Diese Anweisungen sind eine Dokumenttypdefinition.

Beginnend mit Version 2 fügte Connolly eine Typdefinition zu HTML hinzu. Sie beschränkte die Sprache auf eine kleinere Anzahl vereinbarter Tags. In der Praxis behandelten Browser dies eher als lose Definition und implementierten weiterhin ihre eigenen DHTML-Funktionen und Tags. Aber es war ein erster Schritt.

1997 begann die HTML Working Group, nun innerhalb des W3C, an der vierten Iteration von HTML zu arbeiten. Sie erweiterte die Sprache und fügte der Spezifikation weitaus fortgeschrittenere Funktionen, komplexe Tabellen und Formulare, bessere Zugänglichkeit und eine klarere Beziehung zu CSS hinzu. Aber sie spaltete HTML auch von einem einzigen Schema in drei verschiedene Dokumenttypdefinitionen, die Browser übernehmen sollten.

Die erste, Frameset, wurde typischerweise nicht verwendet. Die zweite, Transitional, war dazu da, die Fehler der Vergangenheit einzubeziehen. Sie erweiterte eine größere Teilmenge von HTML, die nicht standardmäßige, präsentationsorientierte HTML enthielt, die Browser seit Jahren verwendeten, wie z. B. <font> und <center>. Dies wurde als Standard für Browser festgelegt.

Die dritte DTD wurde Strict genannt. Unter der Strict-Definition wurde HTML auf nur seine standardmäßigen, nicht-präsentationsorientierten Funktionen reduziert. Sie entfernte alle einzigartigen Tags, die von Netscape und Microsoft eingeführt wurden, und ließ nur strukturierte Elemente übrig. Wenn Sie heute HTML verwenden, zieht es wahrscheinlich seine Grundlage aus denselben Tags.

Die Strict-Definition zog eine klare Grenze. Sie sagte: *Das* ist HTML. Und sie gab den Entwicklern endlich eine Möglichkeit, einmal für jeden Browser zu codieren.

---

In der Augustausgabe 1998 von Computerworld – versteckt zwischen großen Artikeln über die drohende Untergangszeit von Y2K, das zügellose Potenzial des Rechnungsgeschäfts im World Wide Web und Kartellbedenken hinsichtlich Microsoft – gab es eine kleine Ankündigung. Die Schlagzeile lautete: **„Browserstandards im Visier.“** Es ging um die Gründung einer neuen Basisorganisation von Webentwicklern, die darauf abzielte, die Unterstützung von Webstandards in Browsern zu etablieren. Sie nannte sich The Web Standards Project.

Glenn Davis, Mitschöpfer des Projekts, wurde in der Ankündigung zitiert. „Das Problem ist, dass sich die Browserhersteller mit jeder Browsergeneration weiter von der Unterstützung von Standards entfernen.“ Entwickler, die jahrelang gezwungen waren, für verschiedene Browser unterschiedlichen Code zu schreiben, hatten einfach die Nase voll. Ein paar beiläufige Gespräche in Mailinglisten hatten sich zu einer voll ausgewachsenen Bewegung entwickelt. Bei der Einführung hatten sich bereits 450 Entwickler und Designer angemeldet.

Davis war kein Neuling im Web und verstand dessen Herausforderungen. Seine erste Erfahrung im Web reichte bis ins Jahr 1994 zurück, kurz nachdem Mosaic Inline-Bilder eingeführt hatte, als er die Galerie-Website Cool Site of the Day erstellte. Jeden Tag präsentierte er eine einzelne Homepage einer interessanten, ausgefallenen oder experimentellen Website. Für die immer noch kleine Gemeinschaft von Webdesignern war es ein sofortiger Erfolg.

Es gab keine Kriterien außer den Websites, die Davis für würdig hielt. „Ich habe immer nach Dingen gesucht, die die Grenzen ausreizen“, definierte er es später. Davis half, die Erwartungen des frühen Webs neu zu definieren, indem er das Schlagwort cool als Kurzform für viele Möglichkeiten verwendete. Die Autorin von Dot-com Design und Medienprofessorin **Megan Ankerson weist darauf hin, dass „dieses Ökosystem cooler Seiten auf die schiere Bandbreite dessen hinwies, was das Web sein konnte: seine zeitlichen und räumlichen Verschiebungen, seine Unterscheidung von und Erweiterung von Mainstream-Medien, sein Versprechen als Vehikel für Selbstveröffentlichung und die unglaubliche Mischung aus Persönlichem, Alltäglichem und Außergewöhnlichem.“ Für eine Weile im Web war Davis der Schiedsrichter der Coolness.

Mit der Zeit verwandelte Davis seine Seite in Project Cool, eine Ressource für die Erstellung von Websites. In der Zeit von DHTML boten die Tutorials von Davis' Project Cool konstruktive und praktische Techniken, um das Beste aus dem Web herauszuholen. Und ein guter Teil seiner Texte widmete sich der Erklärung, wie man Code schreibt, der sowohl in Netscape Navigator als auch in Microsofts Internet Explorer verwendbar war. Er erreichte schließlich einen Bruchpunkt, ebenso wie viele andere. Ende 1997 veröffentlichten Netscape und Microsoft ihre 4.0-Browser mit lückenhafter Standardunterstützung. Es war bereits klar, dass die bevorstehenden 5.0-Versionen noch stärker auf ungleiche und widersprüchliche DHTML-Erweiterungen setzen würden.

Davis verlor die Geduld und half zusammen mit George Olsen und Jeffrey Zeldman bei der Einrichtung einer Mailingliste. Die Liste begann mit zwei Dutzend Leuten, gewann aber schnell an Unterstützung. The Web Standards Project, bekannt als WaSP, startete offiziell von dieser Liste im August 1998. Sie begann mit wenigen hundert Mitgliedern und Ankündigungen in Zeitschriften wie Computer World. Innerhalb weniger Monate hatte sie Zehntausende von Mitgliedern.

Die Strategie von WaSP war es, Browser – öffentlich und privat – zur Unterstützung von Webstandards zu drängen. WaSP sollte kein hyperbolischer Name sein. „Das W3C empfiehlt Standards. Es kann sie nicht erzwingen“, sagte Zeldman einmal über die Strategie der Organisation, „und es wird sicherlich keine öffentlichen Wutausbrüche wegen Nichtkonformität geben. Das machen wir.“

Als prominenter Designer und Standard-Befürworter hatte Zeldman einen bleibenden Einfluss auf die Macher des Webs. Er würde WaSP später in einigen seiner einflussreichsten Jahre leiten. Seine Website und Mailingliste, A List Apart, würden zu einem Treffpunkt für Designer werden, denen Webstandards und die Nutzung der neuesten Webtechnologien am Herzen lagen.

WaSP änderte während seiner anderthalb Jahrzehnte währenden Tätigkeit mehrmals seinen Fokus. Sie drängten Browser, HTML und CSS besser zu nutzen. Sie brachten Entwicklern bei, wie man standardkonformen Code schreibt. Sie setzten sich für größere Zugänglichkeit und Tools ein, die Standards sofort unterstützten.

Aber ihre Mission, am ersten Tag des Starts auf ihrer Website veröffentlicht, würde niemals ins Wanken geraten. „Unser Ziel ist es, diese Kernstandards zu unterstützen und die Browserhersteller zu ermutigen, dasselbe zu tun, um so einen einfachen, erschwinglichen Zugang zu Webtechnologien für alle zu gewährleisten.“

WaSP war bei einigen frühen Gelegenheiten erfolgreich in seiner Mission. Einige Browser, insbesondere Opera, hatten von Anfang an Standards eingebaut; ihre Bemühungen wurden von WaSP gelobt. Aber die beiden Browser, die zusammen die Mehrheit der Webnutzung ausmachten – Internet Explorer und Netscape Navigator –, brauchten etwas Arbeit.

Ein vier Milliarden Dollar Verkauf an AOL im Jahr 1998 reichte Netscape nicht aus, um mit Microsoft zu konkurrieren. Nach der Veröffentlichung von Netscape 4.0 verdoppelten sie ihre kühne Strategie und beschlossen, den gesamten Code des Browsers als Open Source unter dem Mozilla-Projekt zu veröffentlichen. Alltagsverbraucher konnten ihn kostenlos herunterladen; Codierer wurden ermutigt, direkt beizutragen.

Mitglieder der Community bemerkten bald etwas in Mozilla. Es hatte eine neue Rendering-Engine, oft als Gecko bezeichnet. Im Gegensatz zu geplanten Veröffentlichungen von Netscape 5, das bestenfalls lückenhafte Standardunterstützung hatte, unterstützte Gecko eine ziemlich vollständige Version von HTML 4 und CSS.

WaSP lenkte seine formidable Mitgliedschaft auf die Aufgabe, Netscape zu drängen, Gecko in seine nächste Hauptversion aufzunehmen. Eine bekannte WaSP-Taktik war das Roadblocking. Einige seiner Mitglieder arbeiteten bei Publikationen wie HotWired und CNet. WaSP würde Artikel in mehreren Publikationen gleichzeitig koordinieren, die zum Beispiel Netscapes Vernachlässigung von Standards angesichts einer vollkommen vernünftigen Lösung in Gecko kritisierten. Dadurch konnten sie oft die Aufmerksamkeit mindestens eines Nachrichtenzyklus auf sich ziehen.

WaSP unternahm auch direktere Maßnahmen. Mitglieder wurden gebeten, E-Mails an Browser zu senden oder Petitionen zu unterzeichnen, die breite Unterstützung für Standards zeigten. Überwältigender Druck von Entwicklern war gelegentlich genug, um Browser in die richtige Richtung zu bewegen.

Teilweise dank WaSP stimmte Netscape zu, Gecko in Version 5.0 aufzunehmen. Beta-Versionen von Netscape 5 enthielten tatsächlich standardkonformes HTML und CSS, aber es gab andere Probleme. Es würde Jahre dauern, bis eine Veröffentlichung erschien. Bis dahin wäre Microsofts Dominanz auf dem Browsermarkt fast vollständig.

Als eines der größten Technologieunternehmen der Welt war Microsoft besser vor Basisdruck geschützt. Die bodenständigen Taktiken von WaSP erwiesen sich als weniger erfolgreich, wenn sie gegen den Technologiegiganten eingesetzt wurden.

Aber innerhalb der Mauern von Microsoft hatte WaSP mindestens einen treuen Anhänger, den Entwickler Tantek Çelik. Çelik kämpfte unermüdlich für Webstandards, so weit seine Webkarriere zurückreicht. Er würde später Mitglied des WaSP Steering Committee und Vertreter für eine Reihe von Arbeitsgruppen des W3C werden, die direkt an der Entwicklung von Standards arbeiteten.

Çelik leitete ein Team innerhalb von Internet Explorer für Mac. Obwohl es den gleichen Namen, das gleiche Branding und allgemeine Funktionen wie sein weitaus allgegenwärtiger Windows-Pendant hatte, lief IE für Mac auf einer separaten Codebasis. Çeliks Team wurde in einer kolossalen Organisation mit anderen Prioritäten weitgehend sich selbst überlassen, die an einem Browser arbeiteten, den nicht viele Leute benutzten.

Mit der weitgehend ihm überlassenen Richtung des Browsers begann Çelik, sich mit Webdesignern in San Francisco in Verbindung zu setzen, die an der Spitze der Webtechnologie standen. Durch einen glücklichen Zufall wurde er mit mehreren Mitgliedern des Web Standards Project verbunden. Er besuchte sie und fragte, was sie im Mac IE-Browser sehen wollten. „Die Antwort: bessere Unterstützung von Standards.“

Sie halfen Çelik zu erkennen, dass seine Arbeit an einem kleineren Browser wirkungsvoll sein könnte. Wenn er Standards, wie sie vom W3C definiert wurden, unterstützen könnte, könnte dies als Basis für den Code dienen, den die Designer schrieben. Sie hatten genug Sorgen mit fehlerhaften Standards in IE für Windows und Netscape, mit anderen Worten. Sie mussten sich nicht auch noch um IE für Mac kümmern.

Das war alles, was Çelik hören musste. Als Internet Explorer 5.0 für Mac im Jahr 2000 auf den Markt kam, bot er eine breite Unterstützung für Webstandards; HTML, PNG-Bilder und am beeindruckendsten war eine der ehrgeizigsten Implementierungen der neuen Cascading Style Sheets (CSS)-Spezifikation.

Es würde Jahre dauern, bis die Windows-Version auch nur annähernd die gleiche Unterstützung erreichen würde. Selbst ein halbes Jahrzehnt später, nachdem Çelik zum Suchmaschinenunternehmen Technorati gewechselt war, holten sie immer noch auf.

---

Gegen Ende des Jahrtausends befand sich das W3C an einer Weggabelung. Sie blickten in ihre noch junge Vergangenheit und sahen diese gefüllt mit umstrittener Unterstützung für Standards – Inkompatible Browser mit eigenen Prioritäten. Dann blickten sie in die andere Richtung, in ihre überragende Zukunft. Sie sahen ein Web, das sich bereits über die Grenzen von Personal Computern hinaus entwickelte. Eines, das bald auf Fernsehern, in Mobiltelefonen und auf Geräten existieren würde, die wir uns noch nicht einmal vorgestellt hatten, in Paradigmen, die noch erfunden werden mussten. Ihre Vergangenheit und ihre Zukunft waren unvereinbar. Und so reagierten sie.

Yuri Rubinsky hatte eine ungewöhnliche Gabe, Verbindungen zu knüpfen. In seiner Zeit als Verfechter von Standards, Entwickler und Führungskraft bei einem großen Softwareunternehmen hatte er es geschafft, Zeit zu finden, um einige der einflussreichsten Verfechter des Webs miteinander zu verbinden. Leider starb Rubinsky 1996 plötzlich und in jungem Alter, aber sein Einfluss würde nicht lange vergessen werden. Er trug eine ansteckende Energie und ein Händchen für Überzeugungsarbeit bei sich. Sein Freund und Kollege Peter Sharpe sagte bei seinem Tod: „Wenn man mit Menschen aus allen Gesellschaftsschichten sprach, die Yuri kannten, gab es ein gemeinsames Thema: Yuri war in ihr Leben getreten und hatte es für immer verändert.“

Rubinsky widmete seine Karriere der Zugänglichkeit von Technologie. Er glaubte, dass Technologie ohne gleichberechtigten Zugang nicht gebaut werden lohnte. Das motivierte all seine Arbeit, einschließlich seiner langjährigen Verfechtung von SGML.

SGML ist eine Metasprache und „Sie verwenden sie, um Ihre eigenen Computersprachen für Ihre eigenen Zwecke zu erstellen.“ Wenn Sie ein Dokument an einen Computer übergeben, ist SGML der Weg, wie Sie diesem Computer Anweisungen geben können, wie er es verstehen soll. Es bietet eine standardisierte Methode, die Struktur von Daten zu beschreiben – die Tags, die es verwendet, und die Reihenfolge, in der es erwartet wird. Der Besitz von Daten wird daher nicht auf einer unbekannten Ebene gesperrt und definiert, sondern jedem gegeben.

Rubinsky glaubte an diese Art des universellen Zugangs, eine Welt, in der Maschinen in perfekter Harmonie miteinander sprachen und Datensätze zwischen ihnen austauschten, strukturiert, geordnet und für ihre Benutzer formatiert. Sein Unternehmen, SoftQuad, baute Software für SGML. Er organisierte und sprach auf Konferenzen darüber. Er schuf SGML Open, ein Konsortium, das dem W3C nicht unähnlich ist. „SGML bietet eine international standardisierte, herstellergestützte, vielseitige, unabhängige Möglichkeit, Geschäfte zu tätigen“, beschrieb er es einmal, „Wenn Sie es heute nicht nutzen, werden Sie es nächstes Jahr tun.“ Er hatte fast Recht.

Auch im Web hatte er eine Mission. HTML basiert tatsächlich auf SGML, verwendet aber nur einen kleinen Teil davon. Rubinsky begann, Gespräche mit Mitgliedern des W3C wie Berners-Lee und Raggett zu führen, um eine umfassendere Version von SGML ins Web zu bringen. Er schrieb sogar ein Buch namens SGML on the Web, bevor er starb.

In den Fluren von Konferenzen und in Thread-basierten Mailinglisten nutzte Rubinsky seine einzigartige Überzeugungskraft, um mehrere Leute für das Thema zusammenzubringen, darunter Dan Connolly, Lauren Wood, Jon Bosak, James Clark, Tim Bray und andere. Schließlich zogen diese Gespräche in das W3C ein. Sie bildeten eine formelle Arbeitsgruppe und im November 1996 wurde eXtensible Markup Language (XML) formell angekündigt und dann als W3C Recommendation verabschiedet. Die Ankündigung fand auf einer jährlichen SGML-Konferenz in Boston statt, die von einer Organisation geleitet wurde, deren Vorstand Rubinsky angehörte.

XML ist SGML, abzüglich einiger Dinge, umbenannt und als Websprache neu verpackt. Das bedeutet, dass es weit über die Möglichkeiten von HTML hinausgeht und Entwicklern eine Möglichkeit gibt, ihre eigenen strukturierten Daten mit völlig einzigartigen Tags zu definieren (z. B. ein <ingredients>-Tag in einem Rezept oder ein <author>-Tag in einem Artikel). Im Laufe der Jahre ist XML zum Rückgrat weit verbreiteter Technologien wie RSS und MathML sowie von serverseitigen APIs geworden.

XML war für die Betreuer von HTML, einer Sprache, die sich allmählich als ziemlich vollständig anfühlte, attraktiv. „Als wir HTML 4 veröffentlichten, war die Gruppe im Grunde geschlossen“, beschrieb Steve Pemberton, damaliger Vorsitzender der HTML-Arbeitsgruppe, die Situation. „Sechs Monate später, als XML aber lief, kamen die Leute auf die Idee, dass es vielleicht eine XML-Version von HTML geben sollte.“ Die Verschmelzung von HTML und XML wurde als XHTML bekannt. Innerhalb eines Jahres war es der Hauptschwerpunkt des W3C.

Die ersten Iterationen von XHTML, die 1998 entworfen wurden, unterschieden sich nicht wesentlich von dem, was bereits in den HTML-Spezifikationen vorhanden war. Der einzige wirkliche Unterschied war, dass es strengere Regeln für die Autoren gab. Aber diese kleine Einschränkung eröffnete neue Möglichkeiten für die Zukunft, und XHTML wurde zunächst gefeiert. Das Web Standards Project gab am Tag seiner Veröffentlichung eine Pressemitteilung heraus, in der seine Fähigkeiten gelobt wurden, und Entwickler begannen, die strengeren Markup-Regeln zu nutzen, die im Einklang mit der bereits von Connolly geleisteten Arbeit mit Document Type Definitions standen.

XHTML repräsentierte ein Web mit tieferer Bedeutung. Daten würden den Erstellern des Webs gehören. Und gemeinsam könnten Computer und Programmierer ein vernetzteres und verständlicheres Web schaffen. Diese Bedeutung wurde Semantik genannt. Das Semantische Web sollte die größte Ambition des W3C werden, und sie würden es fast ein Jahrzehnt lang verfolgen.

Nachfolgende Versionen von XHTML führten noch strengere Regeln ein und setzten stärker auf die Struktur von XML. Die im Jahr 2002 veröffentlichte Spezifikation XHTML 2.0 wurde zum Vorboten der Sprache. Sie entfernte die Abwärtskompatibilität mit älteren HTML-Versionen, obwohl Microsofts Internet Explorer – zu diesem Zeitpunkt der mit Abstand führende Browser – sich weigerte, sie zu unterstützen. „XHTML 2 war eine wunderschöne Spezifikation philosophischer Reinheit, die absolut keine Ähnlichkeit mit der realen Welt hatte“, sagte Bruce Lawson, damals HTML-Evangelist für Opera.

Anstatt Standards unter einer gemeinsamen Flagge zu vereinen, drohten XHTML und die Weigerung großer Browser, es vollständig zu implementieren, das Web dauerhaft zu spalten. Es würde etwas Kühnes brauchen, um die Webstandards in eine neue Richtung zu lenken. Aber das lag noch Jahre entfernt.