Hinweis: Am 9. April beteiligen wir uns auf webkrauts.de am Naked CSS Day. Die Stylesheets sind an diesem Tag absichtlich abgeschaltet.

Webkrauts Logo

Webkrauts Webkrauts Schriftzug

- für mehr Qualität im Web

Was sind Webstandards?

Was sind Webstandards?

Mit HTML5 und CSS 3 entstehen zahlreiche neue Techniken, die breit in der Praxis eingesetzt werden, noch bevor sie als Webstandards verabschiedet werden. Mathias Schäfer erklärt, was das für die Konformität zu Webstandards bedeutet.

Die Webkrauts setzen sich für Webstandards und Best Practices ein, so heißt es in ihrem Mission Statement. Doch was ist mit Webstandards gemeint?

Webstandards im engeren Sinne sind technische Spezifikationen, die von Industriegremien herausgegeben und öffentlich weiterentwickelt werden. Ziel dieser Spezifikationen ist es unter anderem, browserübergreifend einheitlich implementiert zu werden, sodass eine standardkonforme Website auf verschiedenen Browsern robust funktionieren kann. Im Vergleich zu Websites, die lediglich auf proprietäre (herstellereigene) Techniken setzen, ist eine standardkonforme Website zukunftsfähiger.

Konformität zu Webstandards heißt dabei, sowohl die konkreten Anforderungen als auch die dahinter stehenden Prinzipien umzusetzen. Die konkrete Konformität lässt sich teilweise automatisiert mit Validatoren und Lints testen, andere Anforderungen lassen sich zumindest manuell prüfen.

W3C-Webstandards

Das wichtigste Gremium für Webstandards war bisher das World Wide Web Consortium (W3C). Es gibt die Standards für HTML und CSS heraus, sogenannte W3C-Recommendations. Die W3C-Standards folgen gewissen Designprinzipien, die auf den Idealen des W3Cs basieren.

Über eine lange Zeit hinweg waren HTML 4.01, XHTML 1.0, CSS 2.0 und DOM 2 Core/HTML die Spezifikationen, auf die sich die Webstandards-Bewegung bezog. Sie stammen größtenteils aus den Jahren 1998 bis 2000. Die darauffolgenden Jahre kämpften die Webstandards-Verfechter dafür, dass diese auch einheitlich in den Browsern umgesetzt werden.

Die Situation hat sich seitdem verkompliziert. Dies hat verschiedene Gründe, die auch mit einem geänderten Prozedere des W3Cs zu tun haben: Damit ein Dokument eine Recommendation wird, bedarf es mindestens zwei konformer Browser-Umsetzungen. Stolze 13 Jahre wurde daher an dem Nachfolger von CSS 2.0 gearbeitet. Im Juni 2011 erschien mit Version 2.1 schließlich eine fehlerbereinigte, an die Praxis angepasste CSS-Spezifikation, die sich breiter Unterstützung erfreut.

Zwei HTML5-Spezifikationen mit Unterschieden

Die Weiterentwicklung der anderen Spezifikationen geriet ebenfalls ins Stocken. Das W3C hatte zunächst die Arbeit an HTML 4 und XHTML 1 aufgegeben und arbeitete an XHTML 2, welches seitens der Browserhersteller auf Ablehnung stieß. So gründeten diese die »Web Hypertext Application Technology Working Group« (WHATWG) als Konkurrenz zum W3C, eine lose Arbeitsgruppe ohne einen formalen Rahmen. Die WHATGWG startete mit dem Ansatz, HTML 4, XHTML 1 sowie DOM 2 HTML unter dem Namen (X)HTML5 evolutionär weiterzuentwickeln. Ihr Ziel ist es, offener, pragmatischer und schneller zu arbeiten als das W3C, ihr Maßstab für Erfolg ist die Akzeptanz der Techniken bei den Browserherstellern.

Schließlich entschied sich das W3C im Jahr 2006, die Arbeit der WHATWG als Grundlage für den kommenden W3C-HTML-Standard zu verwenden. Seitdem entwickeln gleich zwei Arbeitsgruppen parallel am wichtigsten Webstandard: Die HTML-Arbeitsgruppe des W3Cs und die weniger scharf umgrenzte WHATWG. Die Spezifikation liegt in zwei Versionen vor, die sich aufgrund inhaltlicher Differenzen voneinander unterscheiden können. Auch in anderen Bereichen werden Spezifikationen jeweils von einer W3C-Arbeitsgruppe und der WHATWG gleichzeitig betreut.

Die gegenwärtige Lage der Webstandards ist nicht zu verstehen, wenn man diese Spaltung und ihre Auswirkungen nicht kennt. Die WHATWG arbeitet an einem versionslosen, nie abgeschlossenen »Living Standard«, der gleichermaßen aus sehr stabilen und bereits implementierten wie aus rein experimentellen Techniken besteht. Konsequenterweise trägt HTML auf Seiten der WHATWG keine Versionsnummer mehr. Hingegen strebt das W3C an, ihre HTML5-Version schnell abzuschließen und als Recommendation zu veröffentlichen. Zu diesem Zweck werden strittige, instabile und optionale Teile ausgeklammert. Am 2. August 2011 lief die »Last Call«-Phase ab, für 2014 ist die Verabschiedung der Spezifikation vorgesehen.

Die neue Unsicherheit

Von HTML5 als Webstandard zu sprechen, ist also nicht unproblematisch: Zwar wird eine traditionelle W3C-Recommendation erarbeitet, interessante Teile fehlen darin jedoch und sind auf W3C-Seite höchstens als Zusatzmodule ausgelagert.

Was CSS betrifft, so haben wir es mit zahlreichen proprietären Eigenschaften und W3C-Entwürfen zu tun, die sich noch stark im Fluss befinden. Die Hersteller haben ihre Erfindungen als Entwürfe beim W3C eingereicht. Deren CSS-Arbeitsgruppe arbeitet sie langsam ab und kodifiziert, was die Browser experimentell längst unterstützen. Dabei können sich durchaus noch Änderungen ergeben. Erst wenige Module von CSS 3 haben es bisher zu Candidate Recommendations, Proposed Recommendations oder gar Recommendations geschafft.

CSS 3 bedeutet also, ständig Eigenschaften mit Hersteller-Präfixen zu notieren. Uneinheitliche Browserunterstützung und proprietärer Code ist damit zur Regel geworden – genau das, was die Webstandards-Bewegung eigentlich abschaffen wollte.

Im JavaScript-Bereich lichtet sich langsam das Dunkel. Die HTML5-Spezifikation definiert nicht nur die Auszeichnungssprache, sondern auch gleich die zugehörigen JavaScript-Schnittstellen. Diese existieren teilweise seit den Anfangstagen von JavaScript, wurden vorher aber in keinem Standard normativ festgelegt. Techniken wie XMLHttpRequest sind Gegenstand weiterer W3C Working Drafts. Auch hier kann man mehr von einem anhaltenden, nachholenden Standardisierungsprozess sprechen, als von fertigen, etablierten Webstandards.

Standardkonformität als Qualitätsmerkmal

Lange dienten die W3C-Standards als Qualitätsmaßstab. W3C-Konformität schaffte Vertrauen gegenüber Kunden, denn das Industriegremium genoss eine hohe Autorität. Mittlerweile hat das W3C seine Autorität verloren. Browserhersteller wollen die Fähigkeiten des Webs als Anwendungsplattform rapide ausbauen und entschließen sich zunehmend, die Sache selbst in die Hand zu nehmen. Sie arbeiten bloß aus taktischen Gründen mit dem W3C zusammen: Wenn ihnen das W3C dienlich ist, so nutzen sie es als Vehikel, um ihre Techniken zu etablieren, anderweitig entziehen sie sich dessen formalisierten Verfahren.

Zur Zeit ihrer Verabschiedung waren HTML 4 und CSS 2 die normativen Referenzen für Qualität im Webdesign. »Der Code validiert gemäß XHTML 1.0 Strict und CSS 2.0« war zusammen mit weiteren Coding- und Design-Guidelines Bestandteil vieler Pflichtenhefte. Bezüglich HTML5 und CSS 3 lassen sich solche harten Kriterien nicht mehr aufstellen. Es gibt zwar einen HTML5-Validator, der sich jedoch nach dem »Living Standard« der WHATWG richtet. Das bedeutet, dass sich die Anforderungen – zumindest theoretisch – andauernd ändern können. Einen praxistauglichen CSS-3-Validator gibt es nicht, der W3C-CSS-Validator kann mit experimentellen Eigenschaften und Werten nicht umgehen.

Der Wegfall der einfachen Validierbarkeit ist problematisch, denn die Verwendung von HTML5 und CSS 3 kann die Qualität einer Website definitiv steigern, wie eine Vielzahl an Artikeln der Webkrauts gezeigt hat.

Ambivalente Innovationen

Für Webentwickler erweist sich die gegenwärtige Situation als ambivalent. Es gibt einen rasanten technischen Fortschritt. Browser implementieren ständig neue experimentelle Techniken, die die Webentwicklung vereinfachen und neue Möglichkeiten schaffen sollen. Für Webentwickler stellt die Aufsplittung in dutzende Spezifikationen und die oft undurchschaubare Browserunterstützung in erster Linie eine Herausforderung dar.

Zudem folgt die Standardisierung nicht mehr einheitlichen, absehbaren Verfahren. Einerseits haben wir es mit Spezifikationen zu tun, die zum Teil noch instabil und im Fluss sind. Andererseits sind viele Techniken schon praktisch nutzbar und für moderne Websites von entscheidendem Vorteil. Standardisierung kommt heutzutage nachher: »Paving the Cowpaths« (Pflastern der Trampelpfade) lautet das Credo der WHATWG. Es ist nicht zu erwarten, dass die Innovationsgeschwindigkeit nachlässt und der Großteil der verwendeten Techniken zu klassischen Recommendations »abkühlt«.

Progressive Enhancement als neues Ziel

Aus diesen Gründen wurde die Konformität zu abgeschlossenen, festen Standards bereits weitgehend abgelöst durch Progressive Enhancement: Webentwickler nutzen Techniken bereits zu ihrem Vorteil und zum Vorteil ihrer Besucher, selbst wenn sie noch keine Standards im strengen Sinne sind und noch nicht einheitlich umgesetzt werden.

Beim Progressive Enhancement rechnet man damit, dass eine Website in Browsern mit unterschiedlichen Fähigkeiten unterschiedlich aussieht und gegebenenfalls ein wenig anders bedienbar ist. Ein verwandtes Konzept ist das Responsive Design, welches ein besonderes Augenmerk auf die Vielfalt der Webzugangsgeräte und deren Bedürfnisse legt.

Progressive Enhancement heißt derweil nicht, sämtliche Qualitätsansprüche und bewährte Verfahren zu verwerfen und beliebige proprietäre und inkompatible Techniken zu verwenden. Es bedeutet, auf vielversprechende Techniken zu setzen, die sich gerade in der Standardisierung befinden und bereits eine gewisse Praxistauglichkeit und Interoperabilität erreicht haben. Techniken, für die es klare Strategien der Anwendung und der Abwärtskompatibilität gibt, für die Polyfills oder Fallback-Lösungen existieren. Der Unterschied einer Website mit Progressive Enhancement zu einer achtlos inkompatiblen und nicht anpassungsfähigen Website liegt darin, dass die alternativen und reduzierten Versionen bewusst geplant wurden und ihre User Experience stimmig bleibt.

Fazit

Die anhaltende technische Innovation hat eine klassische Auffassung von Webstandards-Konformität weitesgehend obsolet gemacht. Es ist für Webentwickler schwerer geworden, sich im Dschungel von entstehenden Standards zurecht zu finden. Sie müssen selbst in Erfahrung bringen, wie sie Techniken sicher und kompatibel verwenden können. Doch sie stehen nicht orientierungslos da: Es wurden längst neue Best Practices entwickelt, die den sinnvollen und robusten Einsatz neuer Techniken ermöglichen.

Links

Die Kommentare sind geschlossen.