Webstandards im Wandel

Von den ersten CSS-Ideen bis zur Fertigstellung der Spezifikationen CSS Stufe 1 und 2 1998 dauerte es nur vier Jahre. Heute ist CSS Stufe 3 eine Baustelle, und alleine die erste Überarbeitung von CSS2 (CSS 2.1) ist seit vier Jahren im Gang. Hat die CSS-Entwicklung ihren Schwung verloren?

Sicher nicht. Spezifikationen schreiben ist nur ein kleiner Teil der CSS-Entwicklung; Stylesheets schreiben ist viel wichtiger. Seit ungefähr 2000 ist CSS aus der Webseitengestaltung nicht mehr wegzudenken, und die meisten Webseiten nutzen heute CSS. Das ist eine ziemliche Errungenschaft für eine Spezifikation, die nicht zum ursprünglichen Web gehört hat; nur JavaScript hatte einen ähnlichen Erfolg.

Dass CSS erfolgreich war, wo andere Spezifikationen gescheitert sind, liegt zum Teil daran, dass sich die CSS-Arbeitsgruppe im W3C gründlich um Implementierungen und Interoperabilität kümmert. Als CSS2 1998 herauskam, war es den Implementierungen weit voraus – wahrscheinlich zu weit. Indem wir die Spezifikation reduziert haben, haben wir die Interoperabilität verbessert. Das nützt den echten Entwicklern: denen, die Stylesheets, Seiten und Anwendungen fürs Web schreiben.

Man sollte also Erfolg nicht an der Zahl der veröffentlichten W3C-Empfehlungen messen, sondern an der Verbreitung im Web.

Nichtsdestotrotz sollte ich auch erwähnen, dass ich von einigen CSS3-Spezifikationen begeistert bin. Zum Beispiel bin ich Herausgeber von Media Queries, mit denen man Inhalte für alle Arten von Geräten gestalten kann. Opera bringt das Web in eine Menge neuer Geräte und Media Queries wird uns helfen, überzeugende Inhalte zu schaffen.

Als Abonnent des W3C-Newsfeeds erfährt man fast täglich von neuen Arbeitsentwürfen, aber es gibt kaum einmal eine fertige Empfehlung. Warum hat sich die Entwicklung der Webstandards so sehr verlangsamt?

Die Entwicklung hat nicht aufgehört, es dauert einfach länger, das Empfehlungsstadium zu erreichen. Dafür gibt es zwei Hauptgründe, denke ich.

Zum Einen hat sich das Web als technische Plattform stabilisiert. Die Kerntechniken – HTML, CSS, JavaScript, DOM – werden in einer Milliarde Browser verwendet. Diese Standards evolutionär zu verändern, dauert seine Zeit. Das ist eine gute Sache. Es bedeutet, dass unsere Dokumente lange leben werden.

Zum Anderen hat sich auch das W3C entwickelt. In den alten Tagen war es eine Sache von wenigen Monaten, einen Arbeitsentwurf zu einer Empfehlung zu machen. Heute muss man zu Kommentaren aufrufen, all die Kommentare beantworten, sicherstellen, dass es zwei Implementierungen gibt und so weiter. Der formale Prozess dauert viel länger und nur Spezifikationen mit ernsthaften Befürwortern schaffen es bis zur Empfehlung.

Die meisten Änderungen von CSS2 nach 2.1 sind weggelassene Merkmale wie Textschatten oder Druckausgabe. Spart man sich die interessanten Neuheiten für CSS3 auf?

Hauptziel von CSS 2.1 ist es, die Funktionen zu beschreiben, auf die sich Webdesigner verlassen können. Leider sind Textschatten und einige andere wünschenswerte Funktionen kaum unterstützt, sodass sich die Designer noch nicht darauf verlassen können. Deshalb sind diese Funktionen in CSS3 verschoben worden, aber es gibt immer noch eine Menge Extras in CSS 2.1. Zum Beispiel gibt es fixierte Positionierung, die jetzt endlich auch der Internet Explorer unterstützt, sodass die Designer sie tatsächlich benutzen können.

Seit wir vor sechs Jahren fixierte Positionierung in Opera eingebaut haben, haben wir uns um andere Sachen gekümmert. Operas Widgets sind eine tolle Art, Webanwendungen mit Webstandards zu schreiben.

In der CSS1-Empfehlung hieß es, dass "CSS1 ein einfacher Stylesheet-Mechanismus" ist; in der CSS2-Spezifikation dagegen fehlt das Wort "einfach". Ist CSS zu schwierig für viele Webdesigner geworden?

Einfachheit war und ist ein wichtiges Ziel. In der CSS2-Spezifikation heißt es: "CSS2 ist komplexer als CSS1, bleibt jedoch eine einfache Stilsprache, die Menschen lesen und schreiben können." Heute ist es für uns auch viel leichter als 1996, CSS zu benutzen. Heute unterstützen alle Editierwerkzeuge und alle Browser CSS. Ich schreibe immer noch den ganzen CSS- und HTML-Code in Emacs, aber manche Dinge ändern sich nie.

Viele Designer machen sich die Sache aber auch unnötig kompliziert. Wir haben das jahrelang in HTML gesehen, und jetzt sehen wir das gleiche in CSS: Schichten von historischem Code werden wieder und wieder durch die Leitungen geschickt. Viele der Tags und Stilregeln haben keine Wirkung, aber die Leute haben Angst, dass etwas kaputt geht, wenn sie sie löschen. Das macht es unnötig schwer, die Dokumente auf Empfängerseite zu debuggen.

Ein Dienst, den ich wirklich gerne im Web sehen möchte, ist ein Vereinfacher – man verschickt eine URL und er gibt eine Seite zurück, auf der überflüssige Tags, Attribute und Stile entfernt sind.

Außer CSS kann auch der W3C-Standard XSL für Layout und Design verwendet werden. Hat man hier nicht das Rad zweimal erfunden?

XSL ist eine Stylesheet-Sprache, die man oft für druckorientierte Produktionsabläufe verwendet. Trotz eines gemeinsamen Grundverständnisses bei der Formatierung sind CSS und XSL ziemlich verschieden in ihren Ansätzen. XSL ist eine Programmiersprache, CSS nicht. Braucht man beide Sprachen? Ich glaube, dass CSS die meisten Anwendungsfälle von XSL bewältigen kann. Zum Beispiel zeigt Prince, dass man wunderbare Druckpublikationen mit CSS erzeugen kann. Andere widersprechen da und meinen, dass man für manche Fälle eine Programmiersprache braucht.

Statt zwei Ansätze in eine Sprache zu zwängen, hat es meiner Meinung nach gut funktioniert, zwei verschiedene Arbeitsgruppen und zwei verschiedene Sprachen zu haben. So ist es einfacher, in der Gruppe einen Konsens zu erreichen.

Sie gehören zu den Mitgliedern der WHAT WG. Ist diese Arbeitsgruppe ein Anti-W3C? Ein Webstandards-Labor? Oder gar eine Verschwörung von Browserherstellern?

Ehrlicherweise muss ich sagen, dass die aktiven WHAT WG-Mitglieder (ich selbst eingeschlossen) einigen Haltungen im W3C skeptisch gegenüberstehen. Zum Beispiel waren wir nicht der Ansicht, dass XML für absolut jeden Zweck passt. Und wir waren nicht erfreut, als wir von einem Mitglied der HTML-Arbeitsgruppe zu hören bekamen, dass "der Browser tot" sei. Wir wollten lieber Evolution als Revolution. Statt einen harten politischen Kampf im W3C auszufechten, fanden wir es einfacher, eine Mailing-Liste einzurichten und die technische Arbeit zu leisten. Es ist eine sehr offene Gruppe – jeder kann beitreten.

In einem Gespräch mit W3C-Offiziellen vor einem Jahr habe ich die WHAT WG erwähnt – die einen kannten sie nicht, die anderen haben sie nicht ernst genommen. Jetzt schreibt Tim Berners-Lee über die "abgespaltene WHAT WG" und greift offenbar einige Ihrer Vorschläge auf. War es höchste Zeit für eine alternative Standardisierungsorganisation?

Nicht für eine alternative Organisation, sondern für einen Kurswechsel. Tatsächlich hat das W3C dieses Jahr eine Wende eingeleitet. Es ist jetzt viel offener dafür, bestehende Standards weiterzuentwickeln als sich nur auf neue Dinge zu konzentrieren. Dieser Kurswechsel ist teilweise der WHAT WG geschuldet. Man wird sehen, ob "HTML5" vom W3C mit Unterstützung der WHAT WG herausgebracht wird oder von einer anderen Konstellation. Aber ich glaube, dass dies passieren wird.

Gibt es eine Chance, dass die WHAT WG-Konzepte ohne die Unterstützung von Microsoft weitverbreitete Standards werden?

Eine der Grundansichten der WHAT WG ist, dass Rückwärtskompatibilität wichtig ist. Und es gibt eine Menge IE-Browser da draußen. Wenn sich Inhalte nicht an ältere Browser anpassen, werden die Webdesigner sie nicht benutzen. Die WHAT WG-Spezifikationen sind im Hinblick darauf entworfen worden und verlassen sich nicht auf unrealistische Forderungen, dass jeder jetzt seinen Browser aktualisiert.

Ich hoffe jedoch, dass Microsoft in technischer Hinsicht die anderen Browser einholt. Sie haben fünf Jahre von IE6 auf IE7 gebraucht und benutzen immer noch die als "Trident" bekannte gleiche alte Rendering-Engine. Sie haben die Karosserie verschönert, aber bis jetzt ist es ein Gebrauchtwagen – ein "Capri", kein "Explorer". Darf ich stattdessen Opera empfehlen?

Misfällt der WHAT WG der W3C-Kurs der "XMLifizierung" von Webstandards? Hätten Sie lieber HTML5 als XHTML2?

Ich persönlich glaube nicht, dass XML für alle Zwecke passt. CSS ist ein Beispiel. CSS wurde vor XML entwickelt. Als XML aufkam, fragten die Leute nach einer XML-Syntax für CSS. Ich glaube, dass die CSS-Syntax für eine Stylesheet-Sprache besser passt als die XML-Syntax.

XHTML2 hat einige sehr gute Ideen, von denen ich hoffe, dass sie Teil des Webs werden. Aber es ist unrealistisch zu erwarten, dass alle Webdesigner auf eine XML-basierende Syntax umsteigen, die von den Browsern verlangt, die Dokumentverarbeitung beim ersten Fehler abzubrechen. Das drakonische Vorgehen von XML war ein Versuch, das Web aufzuräumen. Man hat das um 1996 gemacht, als eine Menge von ungültigen Inhalten ins Web gestellt wurde. CSS hat einen anderen Ansatz verfolgt: Statt zu verlangen, dass Inhalte nicht verarbeitet werden, haben wir Regeln für den Umgang mit dem Undefinierten definiert. Man nennt das "vorwärtskompatibles Parsen", was bedeutet, dass man neue Konstrukte einführen kann, ohne Altes kaputtzumachen.

Ich glaube also nicht, dass XHTML eine realistische Option für die meisten ist. HTML5 schon.

Ist Operas CTO Håkon Lie immer glücklich mit der Arbeit des W3C-Mitwirkenden Håkon Lie?

Gute Frage! Meistens ist der CTO glücklich. CSS ist eine strategische Spezifikation fürs Web und deshalb für Opera. Zwistigkeiten kommen manchmal auf über die Konsistenz von Spezifikationen und Operas ursprünglicher Implementierung. Außerdem verbringt der W3C-Mitwirkende manchmal Zeit mit Spezifikationen, die dem CTO weniger wichtig sind. Zum Beispiel ist der W3C-Mitwirkende leidenschaftlich dafür, die CSS-Fähigkeiten fürs Drucken zu verbessern. Glücklicherweise unterstützt ihn dabei eine dritte Person namens Håkon Lie, der Leiter von YesLogic. YesLogic macht den Prince-Formatierer, der mit Hilfe von CSS Webinhalte in PDF umwandelt.

Noch eine Anmerkung: Microformate sind wirklich cool. Sie erlauben den Webdesignern, bestehende Dokumente mit Semantik anzureichern, ohne vom Browser die Unterstützung neuer Spezifikationen zu verlangen. Die beste Spezifikation ist die, die man nicht schreiben muss.