Wer den Adventskalender noch nicht kennt: Seit 2005 bringen wir Jahr für Jahr wertvolle Tipps und Tricks über Webstandards – und darüber hinaus. Siehe die Ausgaben von 2010, 2009, 2008, 2007, 2006 und 2005.

Für die Aktion hat Manuela Hoffmann dankenswerterweise wieder die Banner gebastelt. Wir freuen uns über jeden, der damit auf unseren Adventskalender hinweisen möchte.

Nach einer knackigen Einführung in die Eigenarten des Mediums Internet folgt eine Schnelleinführung in HTML und CSS. In weiteren Kapiteln wird das erste Grundwissen sodann vertieft: Layouts werden aufgebaut, Semantik genutzt, Selektoren sowie das Box-Modell erklärt. Über Hinweise zur Ordnung eines Stylesheets geht es zu einer horizontalen Navigation, der Erstellung eines Formulars und zu Tabellen.

Der Autor bespricht unterschiedliche Lösungswege, zu einem Layout zu gelangen und betrachtet dabei vor allem intensiv die Float-Eigenschaft. Das Buch wird durch einen knapp 70-seitigen Einblick in das CSS-Framework YAML abgerundet.

Peter geht grosszügig mit Testkapiteln um. Die Kapitel 3, 13 und 14 können neben dem kompletten Inhaltsverzeichnis als PDF heruntergeladen werden. Die ursprüngliche Ausgabe »Little Boxes Teil 1« kann noch immer kostenlos im Web gelesen werden.

Verlosung

Wir verlosen drei Exemplare von »Das große Little Boxes-Buch«. Um an der Verlosung teilzunehmen, hinterlasst bitte in den Kommentaren zu diesem Artikel einen Link zu einem nerdigen, geekigen und/oder witzigen Weihnachtsgeschenk. Man sollte das Geschenk aber möglichst noch dieses Jahr bestellen können. Die Kommentare können möglicherweise in der Moderationsschleife landen, werden von uns aber bis zum Teilnahmeschluss freigegeben.

Teilnahmeschluss ist der kommende Samstag, 26. November um 24 Uhr. Am kommenden Montag geben wir die drei Gewinner bekannt. Für die Benachrichtigung der Gewinner benötigen wir die E-Mail-Adresse. Bitte denkt daran, diese im Kommentar zu hinterlassen. Jeder Kommentar ohne E-Mail-Adresse nimmt nicht an der Verlosung teil.

Mitglieder der Webkrauts können leider am Gewinnspiel nicht teilnehmen.

Nachtrag: Die drei Gewinner wurden mittels eines Zufallszahlengenerators ermittelt und benachrichtigt. Vielen Dank allen Teilnehmern für die tollen Links.

Werkzeuge

• @font-face Kit Generator
• Color Scheme Designer 3
• Favicon/Icon Generator und Online Editor
• Geo-Koordinaten ermitteln (für Geo-HTML-Metadaten)
• iconlet
• Load Animation Generator
• Passwort Generator von Gaijin
• Regex Tester
• regexpal
• REDAXO CMS

Nachschlagen

• Cheat Sheets for Developers
• CSS 4 you
• PHP-Handbuch
• SELFHTML
• SitePoint Reference
• Übersicht: HTML5 & CSS3 Support
• When can I use …
• WordPress Codex
• Zend Framework Documentation

Blogs, Tutorials, Tipps und Tricks

• A List Apart
• Activetuts+ und Nettuts+
• ajaxian
• Ask the CSS Guy
• Bad Usability Calendar
• Boagworld
• bueltge.de
• Christian Heilmann’s Blog
• CSS-Tricks
• CSS3.info
• CSSRemix
• DailyJS
• David Walsh Blog
• Design Shack
• Dr.Web
• Drawar
• Elmastudio
• entwickler.com
• HTML5 Doctor
• Inspect Element
• lynda.com
• Mozilla Developer Network
• Onextrapixel
• Phly, boy, phly
• PHP hates me
• PHPBuilder.com
• Script & Style
• Sencha Blog
• SitePoint
• Six Revisions
• Smashing Magazine, vor allem Smashing Coding
• Stack Overflow
• The Styleworks
• t3n News
• Technikwürze
• Tutorialzine
• UX Booth
• Web Design Blog von Soh Tanaka
• Web Design Ledger
• WebAppers
• Webdesigner Depot
• Webmasterpro.de
• WebResourcesDepot
• WordPress Tipps, Tricks und Tutorials von dynamicinternet
• Zend Framework News

[Hinweis der Redaktion: Diese Linklisten wollten wir schon vor einem Jahr für euch zusammenstellen, sie sind aber leider zwischen anderen Aktionen und Diskussionen untergegangen. Da die Links aber immer noch interessant und aktuell sind, bringen wir sie jetzt - wenn auch etwas verspätet.]

Artikel und Tutorials

• HTML 5 and CSS 3: The Techniques You’ll Soon Be Using (6. Juli 2009)
• [Info] – HTML5 (17. Juli 2009)
• Understanding The Basics Of CSS3 (17. März 2010)
• Touch the future – create an elegant website with HTML5 and CSS3 (23. April 2010)
• HTML5 total (30. Mai 2010)
• t3n-Linktipps: HTML5 Link-Prefetching, Palm-Zukunft, Freeze Frame, Twitter-Statistiken, AJAX-Webinar und Geek-Drucker (3. Juni 2010)
• Taking Advantage of HTML5 and CSS3 with Modernizr (22. Juni 2010)
• How To Use CSS3 Media Queries To Create a Mobile Version of Your Website (19. Juli 2010)
• 20 Snippets You should be using from HTML5 Boilerplate (August 2010)
• On the Term »HTML5« (2. August 2010)
• Mehr als nur runde Ecken: Testumgebungen für CSS3 (6. August 2010)
• CSS3 Media Queries (18. August 2010)
• Zebra-striping rows and columns (31. August 2010)
• HTML5 – Web Development to the next level
• WTF is HTML5

Blogs und Sammlungen

• Canvas Demos
• CSS3.info

Nachschlagen

• Internet Explorer 9 Guide for Developers
• Überblick: »HTML5 & CSS3 Support«

Werkzeuge und Vorlagen

• BonBon Sweet CSS3 Buttons
• border radius
• CSS 3.0 Maker
• CSS3 Generator
• HTML5 Boilerplate
• Periodic Table of the HTML5 Elements

[Hinweis der Redaktion: Diese Linklisten wollten wir schon vor einem Jahr für euch zusammenstellen, sie sind aber leider zwischen anderen Aktionen und Diskussionen untergegangen. Da die Links aber immer noch interessant und aktuell sind, bringen wir sie jetzt - wenn auch etwas verspätet.]

Inhaltlich sind diese Artikel nach wie vor aktuell und lesenswert. Deswegen präsentieren wir sie euch an dieser Stelle noch einmal als thematisch gruppierte Linkliste. Viel Spaß beim Stöbern und Lesen!

Quelltext – allgemein

• Styling der Navigation als ungeordnete Liste (22. Dezember 2005)
• Webseiten sind keine Gemälde (1. September 2006)
• Ein Faltblatt für Internet-Ausdrucker (1. Dezember 2009)
• Spamsichere E-Mail-Adressen mit dem »Email Address Encoder« (7. Dezember 2009)
• Verliere nicht den :focus (11. Dezember 2009)
• Kürzere Ladezeiten durch CSS-Sprites (15. Dezember 2009)
• Webinhalte einfach vermischen mit YQL (17. Dezember 2009)

Quelltext – Formulare

• Verrückte Formulare (31. Mai 2007)
• Der perfekte Suchschlitz (9. Dezember 2008)
• Formularfelder richtig beschriften (20.Dezember 2009)

Quelltext – HTML5

• Objektorientiertes CSS – Eine Einführung (6. Juli 2009)
• Moderne Semantik (21. September 2009)
• Das Endoskelett einer Webseite (24 September 2009)
• Sehen und Hören (28. September 2009)
• Malen nach Zahlen (29. September 2009)
• Tipphilfen (1. Oktober 2009)
• HTML5 in der Praxis I (5. Oktober 2009)
• HTML5 in der Praxis II (6. Oktober 2009)

Quelltext – CSS3

• CSS der Zukunft (24. Dezember 2005)
• Vier CSS3-Tricks für sauberes HTML (24. Dezember 2008)
• Von Transitionen und Animationen (21. Dezember 2009)

Software

• Produktiv? Wirtschaftlich? (30. August 2006)
• IE7 – einfacher und sicherer – aber auch besser? (3. November 2006)
• Pro und Contra: CMS für kleine Webseiten? (1. Dezember 2007)
• Grundregeln für zugängliches JavaScript (5. Dezember 2008)
• Kleine Werkzeugkunde: Die API von Dreamweaver (9. August 2010)

Wirtschaftliches

• Hilfsmittel für Aufwandsschätzungen (8. Dezember 2009)
• Ergebnisse der Webkrauts Webworker-Umfrage 2008

Texten

• Gut gebrüllt, Löwe! (23. Dezember 2009)
• Mit den richtigen Wörtern mehr verkaufen (22. April 2010)

Konzeption

• Internetauftritte für mobile Endgeräte (22. Dezember 2006)
• Und es hat Zoom gemacht (oder: Spiel mit dem Feuer) (27. Juni 2008)
• Kontrastreiche Farbwelten (5. August 2009)
• Mediengerechte Website-Konzeption (22. Dezember 2009)
• Frühjahrsputz in einem Hochhaus (4. Mai 2010)

Philosophisches

• Webstandards erobern das Internet (25. Mai 2007)
• Frontendentwicklung ist nicht einfach! (31. Juli 2009)

Beispielhaftes

• „Maßgebend is auf’n Platz!“ – Abschlusstabelle (9. September 2007)
• Ein verspielter One-Pager I: Prelude (18. Mai 2010)
• Ein verspielter One-Pager II: Handwerk (19. Mai 2010)
• Sonnenseiten: Navigationskonzepte (17. Juni 2010)
• Sonnenseiten: Formulare (21. Juni 2010)
• Sonnenseiten: App (28. Juni 2010)
• Sonnenseiten: Photoblog-Design (1. Juli 2010)

[Hinweis der Redaktion: Diese Linklisten wollten wir schon vor einem Jahr für euch zusammenstellen, sie sind aber leider zwischen anderen Aktionen und Diskussionen untergegangen. Da die Links aber immer noch interessant und aktuell sind, bringen wir sie jetzt - wenn auch etwas verspätet.]

• Webseiten auf Basis von HTML 5
• Feinheiten im Design durch CSS3
• Responsive Design
• Barrierefreiheit (Accessibility)
• Benutzerfreundlichkeit (Usability)
• Typografie
• Bilderwelten
• Texten für das Web
• Suchmaschinenoptimierung
• Microformats / RDFa / Microdata
• Social Media für Unternehmen
• Theming für Content-Management-Systeme
• usw.

Die Basis bildet die Examplast GmbH, ein mittelständiges Unternehmen, das aus Recyclingmaterialien etwa 400 unterschiedliche Kunststoffprodukte produziert und vertreibt, zum Beispiel Bauelemente wie Rund- und Brettprofile, Zäune, Blumenkübel oder Abfallbehälter – und zwar teils in größeren Serien für Endkunden, teils spezifisch für einzelne Geschäftskunden. Auftragsvolumen, Häufigkeit der Aufträge und die Kunden variieren: Es gibt einige wenige Stamm- und Großkunden und zahlreiche Einmalkunden. Der jährliche Gesamtumsatz unseres Unternehmens beläuft sich auf ca. 50 Millionen Euro bei einem Gewinn von etwa 1 Millionen Euro.

Entstanden ist die Firma nach einer Idee von Michael Jendryschik. Von ihm stammen der Firmenname, der Hintergrund des Unternehmens und die Personas. Nicolai Schwarz brauchte ein Beispielunternehmen für sein Fachbuch »Drupal 7: Das Praxisbuch für Ein- und Umsteiger« und hat das Design und die Umsetzung des Webauftritts der Examplast GmbH übernommen.

Wer immer nun eine Beispielfirma benötigt, kann gerne auf die Examplast GmbH setzen. Das Design und die Texte haben wir unter einer Creative-Commons-Lizenz (CC-BY 3.0) veröffentlicht. Das heißt, ihr dürft diese Elemente auch in kommerziellen Projekten verwenden. Allein bei den Fotos müsst ihr auf die Rechte achten.

Weitere Infos findet ihr auf examplast.de. Dabei teilt sich die Webseite in zwei Bereiche. Die ersten Menüpunkte geben eine kleine Vorstellung von Inhalten, die die Firma tatsächlich ins Netz stellen könnte. Mit ein paar Zeilen konkretem Text, der in Blindtext übergeht. Im zweiten Bereich »Über examplast.de« geht es um das Projekt selbst, also die Examplast GmbH als Vorlage. Dort werden wir auch Beispiele sammeln, wenn Webworker die Examplast GmbH für ihre Projekte weiterentwickeln.

Die Autoren

Michael Jendryschik ist Spezialist für die Konzeption und Entwicklung von Webseiten und Benutzeroberflächen. Er leitet den Bereich Interaktionsdesign bei der itemis AG in Dortmund, ist Mitglied der German UPA und der Webkrauts.

Nicolai Schwarz arbeitet unter dem Namen textformer mediendesign als Designer und Webentwickler in Dortmund. Hauptsächlich beschäftigt er sich mit Drupal-Projekten. In dieser Woche erscheint das besagte Fachbuch – »Drupal 7 – Das Praxisbuch für Ein- und Umsteiger« – beim Galileo Verlag.

Das BGG ist ein deutsches Bundesgesetz und die BITV 2.0 eine Verordnung, die sich auf dieses Bundesgesetz bezieht. Die BITV 2.0 gilt für Webangebote und öffentlich zugängliche Intranetangebote sowie für sonstige grafische Programmoberflächen der Bundesverwaltung. Die BITV 2.0 verwendet als technischer Standard die Web Content Accessibility Guidelines (WCAG) 2.0 des W3C und enthält eine Übersetzung dieser Webstandards in Anlage 1.

Unterschiede zwischen WCAG 2.0 und BITV 2.0

Es ist zu begrüßen, dass die BITV 2.0 endlich veröffentlicht wurde. Damit wird die Vorgängerversion aus 2002 außer Kraft gesetzt, und die bereits 2008 veröffentlichten WCAG 2.0 werden als Maßstab für Internetangebote des Bundes herangezogen. Es gibt allerdings Unterschiede zwischen WCAG 2.0 und BITV 2.0, die durchaus praktische Probleme mit sich bringen können. Einige markante Aspekte sind:

• Die WCAG 2.0 enthält als Webstandard neben den konkreten Anforderungen für ein barrierefreies Webdesign etliche weitere normative Bestimmungen, die in der BITV 2.0 nicht aufgenommen wurden. Sie finden sich bestenfalls in der Begründung zur BITV 2.0. Beispielsweise enthalten die WCAG 2.0 auch Konformitätsbedingungen; ein Verstoß bedeutet, dass eine Konformität zur WCAG 2.0 gar nicht mehr möglich ist. Nach Konformitätsbedingung 5 wird z.B. der Gedanke des progressive Enhancement (fortschreitende Entwicklung) postuliert, in der BITV 2.0 findet sich diese Voraussetzung der Barrierefreiheit nicht wieder.
• In der WCAG 2.0 gibt es drei Konformitätsstufen (A, AA und AAA) und in der BITV 2.0 finden sich zwei Prioritäten wieder: Priorität I umfasst die Anforderungen der Konformitätsstufen A und AA und Priorität II umfasst die Anforderungen der Konformitätsstufe AAA. Grundsätzlich ist hiergegen nichts einzuwenden, denn die Bundesregierung verpflichtet sich dadurch zur Erreichung der Konformitätsstufe AA. Allerdings wird das Konzept der Konformitätsstufen nicht übernommen. Während nach der WCAG 2.0 die Barrierefreiheit in der Erreichung einer bestimmten Konformitätsstufe ausgedrückt wird, fehlt dieses Konzept in der BITV 2.0. Die Überprüfung bzw. die Zertifizierung der Barrierefreiheit wird somit aus der BITV 2.0 hinaus katapultiert.
• Kern der WCAG 2.0 sind natürlich die 61 Erfolgskriterien. Diese wurden weitgehend in der BITV 2.0 als Bedingungen übernommen. An zwei Stellen gibt es deutliche Abweichungen: In Erfolgskriterium 3.1.5 wird das Thema "Leseniveau" durch "einfache Sprache" ersetzt und Erfolgskriterium 2.4.8 erhält die Priorität I, obwohl es sich bei dieser Bedingung um ein Erfolgskriterium der Konformitätsstufe AAA handelt. Ansonsten ist die Übersetzung der WCAG 2.0 in der Anlage 1 der BITV 2.0 vergleichbar mit der offiziellen deutschen Übersetzung der WCAG 2.0 des W3C. Allerdings sind die normativen Anmerkungen der WCAG 2.0 in die Begründung der BITV 2.0 verschwunden. Einige weitere Abweichungen hat Kerstin Probiesch kommentiert.
• Noch ein Konzept der WCAG 2.0, das in der BITV 2.0 nicht übernommen wurde, ist die Einbeziehung nicht normativer Inhalte. Zu jedem Erfolgskriterium der WCAG 2.0 gibt es Links zu zusätzlichen Dokumenten, in der Techniken beschrieben und Erläuterungen geboten werden. Diese zusätzlichen Dokumente sind informativ und werden regelmäßig aktualisiert, d.h. dort wird der technische Fortschritt berücksichtigt, und neue Technologien werden aufgenommen, sobald sie barrierefrei umgesetzt werden können. Die WCAG 2.0 ist somit langfristig angelegt. Die BITV 2.0 verweist allerdings nicht auf diese Dokumente und bietet keine Perspektive, eine solche, durchaus sinnvolle und erforderliche Dokumentation aufzubauen.
• Die BITV 2.0 umfasst in Anlage 2 weitere Anforderungen zur Leichten Sprache und zur Gebärdensprache. Da es sich bei der BITV 2.0 um eine Selbstverpflichtung des Bundes zur Barrierefreiheit handelt, können diese zusätzlichen Anforderungen nur begrüßt werden. Kritisch ist nur anzumerken, dass die Anforderungen der Anlage 2 im Gegensatz zu den Bedingungen größtenteils nicht überprüfbar sind.

Diese Liste ist nicht erschöpfend, zeigt aber einige Defizite der BITV 2.0 auf. Praktisch gesehen kommen Webentwickler nicht an den Techniken zur WCAG 2.0 vorbei, wenn sie Barrierefreiheit nach dem Stand der Technik umsetzen wollen. Solange die Techniken nicht aus den Augen verloren werden steht einer Erreichung der Konformitätsstufe AA der WCAG 2.0 (Priorität I der BITV 2.0) nichts im Wege.

Drohende Fragmentierung in Deutschland

In der Zeit nach dem Inkrafttreten der ursprünglichen BITV wurden in Deutschland nicht nur Landesgleichstellungsgesetze verabschiedet, sondern auch länderspezifische IT-Verordnungen. Teilweise weichen die anzuwendenden Standards der Länder-Verordnungen von der Bundes-BITV ab. Diese Fragmentierung von Regelwerken ist grundsätzlich kontraproduktiv. Nicht zuletzt sind die Nutzer mit Behinderungen mit unterschiedlichen Qualitätsniveaus von Webseiten konfrontiert.

Während manche Bundesländer ein automatisches Update in der Länder-BITV haben und die aktuelle Bundes-BITV übernehmen, müssen in den meisten Bundesländern eine neue BITV mit aktuellen anzuwendenden Standards erlassen werden. Hoffentlich muss die Diskussion nicht nochmal von vorne begonnen werden.

In den deutschen Bundesländern sollte die BITV 2.0 bzw. die Anlage 1 der BITV 2.0 übernommen werden. Die WCAG 2.0 stellt die objektiv bessere Wahl dar, aber wenn schon auf Bundesebene zur WCAG 2.0 abgewichen wird, dann würden Abweichungen auf Länderebene im Vergleich zur Bundesebene die Fragmentierung weiter fördern. Wenn nicht weltweit, dann sollte zumindest auf nationaler Ebene die Harmonisierung der Regelwerke angestrebt werden.

Zum Autor

Jan Eric Hellbusch ist Spezialist für barrierefreies Webdesign und Co-Autor
des Buchs Barrierefreiheit verstehen und umsetzen.

Einige bekannte Sprecher werden in Frankfurt zu sehen sein, u.a. Webkraut Jan Eric Hellbusch (Accessibility-Evangelist), Peter Kröner (Spezialist für HTML5 / CSS3), Christian Kuhn (Spezialist für Webdesign auf Tablets). Einige Sessions sind noch nicht vergeben. Aktuelles gibt es bei Twitter.

Natürlich ist für das leibliche Wohl gesorgt, und es gibt in den zwei Tagen viele Möglichkeiten, neue Kontakte zu knüpfen und bestehende zu intensivieren. Die Teilnehmerzahl ist beschränkt auf 75 Plätze. Weitere Informationen findet ihr auf der Seite der Webedition e.V..

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

• Ergänzungsartikel: Die jüngsten Konflikte zwischen W3C und WHATWG
• Übersicht über HTML5-Spezifikationen und -Literatur
• Spezifikationen der W3C-HTML-Arbeitsgruppe
• Spezifikationen der W3C-Web-Apps-Arbeitsgruppe
• Übersicht bei Microsoft über den aktuellen Stand der Standardisierungen
• Übersicht über CSS-3-Spezifikationen
• Blog der CSS-Arbeitsgruppe mit Entscheidungen und Aktualisierungen

Zum Autor

Mathias Schäfer (molily) arbeitet als Web- und Software-Entwickler für 9elements.

Und bevor sich irgendwer wundert: Das heißt im Zweifel auch, dass wir nur diese Details herausgreifen und beim Rest Fünfe gerade lassen sein werden. Auch wenn in einzelnen Fällen mal ein anderes Detail oder gar der Code schöner sein könnten. Siehe auch die Sonnenseiten der letzten Jahre.