Es ist für jeden auf den ersten Blick zu erkennen: Unsere Webseite ist mittlerweile etwas, sagen wir mal, in die Jahre gekommen. Wir sind 2005 mit WordPress und den ersten Inhalten gestartet. Im Laufe der letzten Jahre gab es – mehr oder weniger – regelmäßig neue Artikel und einige Serien. Für ein Projekt, das wir alle in unserer Freizeit mit Inhalten füllen, schon nicht schlecht. Aber die Unterschiede zwischen den Inhalten der Artikel und der eigenen Webseite werden immer größer. Wissen wir.
Nun starten wir einen neuen Anlauf für einen Relaunch. Die Umsetzung soll im Februar/März erfolgen, heute öffnen wir bereits ein Türchen für eine besinnliche Vorschau auf das Design. Zunächst aber ein paar inhaltliche Überlegungen:

Inhalte finden

Wir haben hier auf webkrauts.de eine Menge älterer Artikel gesammelt, die nach wie vor gut und aktuell sind. Allein: das Blogformat macht es schwierig, diese Artikel auch zu finden. Bisher gibt es vier Möglichkeiten, zu den Inhalten zu kommen: Besucher können die Seiten einzeln durchblättern, die Suche bemühen, über die Serien gehen oder es über die (derzeit unstrukturierten) Tags versuchen. Wir werden zwei weitere Optionen hinzufügen und unsere Inhalte auch über Rubriken (HTML, CSS, Usability, Accessibility …) und Schwierigkeitsgrad (Anfänger, Fortgeschrittene, Experten) zugänglich machen. Bei der Gelegenheit bringen wir dann auch die Tags in eine ordentliche Struktur.

Neue Inhalte ermöglichen

Wir kümmern uns zwar gerne um neue Inhalte, können aber als Nebenprojekt kein regelmäßiges Magazin bieten. Das wollen und müssen wir auch nicht, schließlich gibt es andere Webseiten, die das viel besser leisten. Andererseits reduzieren sich die Aktivitäten der Webkrauts nicht nur auf Artikel hier auf der Webseite. Wir sind auf BarCamps und Konferenzen unterwegs, halten Sessions und Vorträge, schreiben Fachartikel und -bücher.

Auf diese Aktivitäten können wir besser hinweisen; deshalb erweitern wir unsere Inhalte. Unter dem neuen Menüpunkt »Bücher« werden wir sowohl echte Rezensionen von Fachbüchern als auch Bücher von Webkrauts (mit reinem Klappentext) vorstellen. Es wird für alle Besucher die Möglichkeit geben, passende Web-Termine anzulegen, Webkrauts können auf eigene Vorträge verweisen. Außerdem können wir kleine Hinweise auf Artikel in Magazinen, im eigenen Blog oder auf anderen Webseiten eintragen (»Kurz notiert«). Also eine Art internes Twittern, was wir übrigens absichtlich nicht durch automatische Feeds der Twitter-Accounts von Webkrauts regeln.

Vorschau der Startseite

Aus diesen Überlegungen heraus haben wie die Startseite umgearbeitet. Im Header besteht nun neben der Suche die Möglichkeit, unsere Inhalte nach Rubrik, Serie oder Schwierigkeit zu durchstöbern. Außerdem ein übliches Hauptmenü und Links zu Twitter und dem RSS-Feed. Darunter – hell hervorgehoben – unsere Hauptinhalte: aktuelle und in der Regel exklusive Artikel für webkrauts.de in einem jQuery-Slider. Es folgen die kurzen Notizen, Termine und Vorträge sowie ein größerer Footer.

Siehe auch den Klickdummy der Startseite

Vorschau eines Artikels

Bei den Artikeln passen wir die Typografie an und sorgen für eine bessere Lesbarkeit. Wir stellen unsere Autoren deutlicher in den Vordergrund, indem die Autoreninfo nun oben neben dem Artikel und nicht mehr am Ende angezeigt wird. Dazu kommen übliche soziale Links und Hinweise auf andere Artikel desselben Autors.

Siehe auch den Klickdummy der Artikelseite

Alles im Fluss

Bevor ihr euch der Kritik hingebt: Dies ist eine Vorschau. Bestimmte Elemente werden wir erst bei der Umsetzung im Zusammenspiel mit dem CMS hinzufügen. Das betrifft vor allem Dinge wie Responsive Design, barrierefreie Aspekte oder einige Details am Design (etwa die Kontraste oder die finale Typografie). Insofern lohnt sich im Moment eigentlich kein Blick auf das Markup.

Ansonsten sind wir auf eure Anmerkungen gespannt. Bis zum Relaunch sind es noch ein paar Wochen hin, so dass wir gute Ideen gerne noch mit aufnehmen können.
Vielleicht werden einzelne Elemente nicht allen gefallen, aber eines dürfte sicher sein: Mit diesem Ansatz sind wir inhaltlich, technisch und gestalterisch schon mal zwei, drei Schritte vorangekommen.

Zum Autor

Nicolai Schwarz arbeitet unter dem Namen textformer mediendesign als selbstständiger Designer und Webentwickler in Dortmund. Hauptsächlich arbeitet er an Drupal-Projekten. Gelegentlich schreibt er darüber, zum Beispiel für das Webstandards-Magazin, t3n oder eben auf webkrauts.de. Im September hat er »Drupal 7: Das Praxisbuch für Ein- und Umsteiger« beim Galileo Verlag veröffentlicht.

Das HTML5 Boilerplate ist eine solide Vorlage für zeitgemäße Webseiten. Webentwickler finden nicht nur Vorgaben für HTML und CSS vor, sondern auch bereits integrierte Javascript-Helfer wie jQuery und Modernizr sowie viele intelligente Voreinstellungen in der .htaccess. Passende Muster für favicon und auf Smartphones verwendete Icons, eine robots.txt sowie eine QUnit-Suite, um Javascript-Code zu testen, machen das Boilerplate zu einer umfangreichen Universalvorlage für neue Webprojekte. Es handelt sich dabei ausdrücklich nicht um eine klassisches Framework, zumal das HTML5 Boilerplate keinerlei Layout-Vorlagen mitbringt. Viel mehr bündelt und dokumentiert es bewährte und sinnvolle Vorgaben zentral und erspart Webworkern, diese von Hand zusammenstellen zu müssen.

Gleichzeitig liefert das Boilerplate aber auch ein Skript, um Webseiten vor der Auslieferung auf den Server automatisiert zu optimieren und zu prüfen.

Baustellen-Besichtigung

Das build-Skript samt aller benötigten Werkzeuge liegt im Verzeichnis build einer Kopie des Boilerplates. Die Datei build.xml ist dabei das eigentliche Skript, das mittels des Java-basierten Tools ant ausgeführt wird. Dieses funktioniert nur innerhalb des build-Verzeichnisses.

Die Batch-Datei runbuildscript.bat im build-Verzeichnis dient zur Ausführung des Skriptes unter Windows – sie stellt lediglich sicher, dass eine notwendige Pfadangabe gesetzt wird und ruft dann das eigentliche build-Skript auf. Webworker, die das Boilerplate als Fork aus dem GitHub-Repository gezogen haben, können mit dem bash-Skript createproject.sh eine lokale Arbeitskopie in einem separaten Verzeichnis erzeugen, die nur die tatsächlich benötigten Dateien, nicht aber die von git erzeugten enthält. Im »normalen« Download-Archiv sind diese bereits entfernt.

Im Verzeichnis config liegen die Konfigurationsdateien zur Einrichtung des Bauvorhabens, einerseits für Standardeinstellungen, andererseits projektspezifisch. Das Verzeichnis tools beinhaltet kleine Helferprogramme wie etwa den YUI Compressor oder Tools zur Bildoptimierung und Codeprüfung.

Vor dem ersten Bau

Auf aktuellen OSX- oder Linux-Systemen sollte das build-Skript ohne weitere Schritte funktionieren, bestenfalls müsst ihr über die jeweilige Paketverwaltung das Paket ant-contrib nachinstallieren. Windows-Systeme benötigen Win Ant, wofür zunächst das Java Development Kit installiert sein sollte. Wichtig: Das Java Runtime Environment reicht nicht aus. Alle weiteren zum Einsatz des build-Skriptes notwendigen Werkzeuge sind im Download-Archiv des HTML5 Boilerplates enthalten.

Was leistet das build-Skript?

In erster Linie optimiert es die zum Projekt gehörenden HTML-, CSS- und Javascript-Dateien, insbesondere in Sachen Performance. Es kombiniert und minifiziert eingebundenes CSS und JS, fügt also jeweils mehrere Dateien zu einer zusammen und entfernt aus dieser im Produktivbetrieb unnötige Leerzeichen und Kommentare. Kommentare entfernt es auch aus HTML-Dateien, optional beseitigt es auch in diesen unnötige Leerzeichen. Das verschlankt zum einen alle ausgelieferten Dateien, zum anderen reduziert es die Zahl der angefragten Dateien, also die Zahl der HTTP-Requests.

Um den Cache-Mechanismus von Browsern auszutricksen, ändert das build-Skript zudem bei jedem Durchlauf die Dateinamen der kombinierten CSS- und JS-Dateien nach dem Zufallsprinzip und aktualisiert die Referenzen zu diesen in den HTML-Dateien entsprechend. Da die .htaccess-Datei des Boilerplates für diese relativ lange Cache-Zeiten vorgibt, würden diese bei gleichbleibendem Dateinamen ansonsten womöglich erst Monate nach Auslieferung neu geladen.

Der Befehl ant css-split teilt die style.css des Boilerplates in fünf Dateien auf, die über @import-Anweisungen von der style.css eingebunden werden. Konkret trennt es Normalisierung, primäre Styles, @media-Queries, Helferklassen und Print-Styles in übersichtliche Module. Selbstverständlich setzt das build-Skript diese wieder zu einer kombinierten Datei zusammen. Ebenso der sauberen Trennung dient die Aufteilung des JS-Codes in plugins.js (z.B. für externe jQuery-Plugins) und script.js (für eigenen Code), auch diese fügt das build-Skript zu einer Datei zusammen.

Über die Tools jpegtran und optipng verringert das build-Skript die Dateigröße der zum Projekt gehörenden JPG- und PNG-Grafiken, u.a. indem es überflüssige Metadaten aus den Dateien entfernt. Ähnliches erledigt natürlich bereits die »Save for web«-Funktion gängiger Grafikprogramme – wundert euch hier also nicht vorschnell über mangelnde Effizienz, eventuell sind die Dateien bereits optimiert. Dazu entfernt das build-Skript Code, der nur in der Entwicklungsphase benötigt wird, sowie Referenzen auf in der Produktivumgebung überflüssige Dateien.

Zudem kann das build-Skript optional ein sogenanntes cache manifest generieren. Diese Textdatei ermöglicht es, Web-Applikationen auch offline ausführen zu können. Sie enthält eine Liste der zur Ausführung notwendigen Dateien und weist den Browser an, diese für Offline-Nutzung zu speichern.

Weitere Helferchen im tools-Verzeichnis dienen der Qualitätssicherung des CSS- und JS-Codes. JS Hint, JS Lint und CSS Lint prüfen den Code auf Fehler und mögliche Performance-Bremsen. Diese laufen auf der ebenfalls auf Java basierenden Javascript-Engine rhino. JS Hint und JS Lint könnt ihr über die Konfigurationsdateien des build-Skriptes genauer konfigurieren.

Ausführung

Neben dem bereits erwähnten Kommando zum Aufteilen der CSS-Datei bietet das build-Skript verschiedene »Ziele«, also unterschiedliche Aufgabengruppen für verschiedene Stufen der Entwicklung. Der Zweck der unterschiedlichen Stufen (Entwicklung, Testen, Produktion) ebenso wie der verschiedenen Ziele ist es, Zeit im Ablauf der build-Vorgangs zu sparen, indem zeitaufwändige Schritte wie etwa die Bildoptimierung übersprungen werden. In den meisten Fällen genügt es, wenn ihr ein ant build ausführt, soll zusätzlich der HTML-Code minifiziert werden, ist ant minify die richtige Wahl. Über ant text überspringt das build-Skript die relativ zeitraubende Optimierung von JPG- und PNG-Grafiken.

Zur Ausführung von JS Hint, JS Lint und CSS Lint müsst ihr lediglich den betreffenden Befehl an das build-Kommando anhängen, also z.B. ant build jshint. Alle drei Tools bremsen den build-Durchlauf merklich aus, Entwickler sollten sie also nicht unbedingt bei jedem build-Lauf mit ausführen lassen – JS Lint und JS Hint aber unbedingt dann, wenn sie das Javascript eines Projekts überarbeitet haben, denn dann zeigen beide zuverlässig Fehler auf.

Etwas Handarbeit

Einige Dinge kann das build-Skript (noch) nicht automatisieren. So müsst ihr jede zum Projekt gehörende HTML-Datei von Hand in die Konfigurationsdatei project.properties eintragen. Ebenfalls »bekannt machen« sollten Webworker Dateien und Verzeichnisse, die aus der Produktivumgebung ausgeschlossen werden sollen, etwa im Projektverzeichnis liegende Originale von Grafikdateien oder Stylesheets für einen CSS-Präprozessor wie SASS oder LESS.

Das build-Skript bietet eine Vielzahl weiterer Möglichkeiten, um die Arbeit mit dem HTML5 Boilerplate zu automatisieren und zu vereinfachen. Es ist im Wiki des Projektes auf GitHub ausführlich dokumentiert.

Zum Autor

Matthias Mees lebt und arbeitet in Eutin in Schleswig-Holstein. Er fühlt sich im Texteditor deutlich wohler als im Grafikprogramm und ist auch, aber nicht nur deswegen, Linux-Enthusiast.

Beim Rückblick auf das Jahr 2011 fällt positiv auf, dass HTML5 und CSS3 sich langsam auch hier in Deutschland in der Breite durchsetzen. Mit Progressive Enhancement, Polyfills und nützlichen Frameworks wie dem HTML5 Boilerplate und 320 and up sind wir gut aufgestellt, die neuesten Features in unseren Projekten sinnvoll einzusetzen.

Unterstützung erfahren wir dabei von den Browserherstellern, die nach einem (teilweise) langen Dornröschenschlaf aufgewacht sind und mit großer Begeisterung Feature um Feature implementieren. Es ist ein kleines Wettrennen, das wir in diesem Jahr beobachten konnten und das uns reichlich kreativen Aufwind beschert hat. Daher ist es nur passend, zum Jahreswechsel einen Ausblick zu wagen: Was kommt Neues mit CSS4? Gibt es schon Ansätze für Implementierungen einzelner Features in den Browsern? Können wir vielleicht schon irgendwas verwenden? Dies soll keine vollständige Abhandlung über sämtliche Neuerungen sein, sondern vielmehr eine Zusammenstellung von kleinen Tricks, die ihr jetzt schon einsetzen könnt.

Doch Obacht! Um die verlinkten Beispiele nachvollziehen zu können, braucht ihr die Nightlies der jeweiligen Browser. Wer also nicht nur lesen, sondern auch ausprobieren möchte, installiert jetzt:

• Firefox Nightly
• Webkit Nightly
• Opera Next

Da Webkit nur eine Engine ist und kein kompletter Browser, müsst ihr vorab Safari installieren, der dann die Webkit Nightly als Engine nutzt. Tipp: Ihr könnt alle drei Browser in eine virtuelle Maschine installieren. So haltet ihr alles schön separat von eurem Produktivsystem.

Fertig? Prima. Auf geht’s!

Mischen possible: cross-fade()

Die CSS4-Meldung, die bislang am meisten Aufsehen erregt hat, ist, dass Webkit eine teilweise Unterstützung für das Cross-Fading von Hintergrundbildern implementiert hat. Mit eurem frisch installierten Webkit Nightly könnt ihr euch zunächst das Live-Demo dazu ansehen:

Demo: cross-fade()

Hier ein Screenshot für alle, die noch keinen Webkit Nightly installiert haben:

Mit cross-fade könnt ihr zwei Hintergrundbilder ineinander überblenden. Dazu gebt ihr die URLs für zwei Hintergrundbilder an, sowie einen Prozentsatz, mit dem das vordere Bild in das hintere geblendet werden soll. Bei 0% ist nur das hintere Bild sichtbar, bei 100% nur das vordere. Dazwischen könnt ihr beliebig abstufen. 50% blendet die Bilder 1:1 ineinander. Im Demo liest sich das so:

background-image: cross-fade(
    url("logo-box.png"),
    url("logo-bare.png"),
    50%);

Dies ist besonders spannend für die Kreativen unter uns, die nun nicht mehr jedes Mal PhotoShop oder Gimp öffnen müssen, um zwei Hintergrund-Texturen miteinander zu kombinieren. Ihr könnt direkt im Browser experimentieren.

Das beste daran: Ihr könnt diesen Effekt bereits jetzt verwenden. Solange ihr ein herkömmliches Hintergrundbild als Fallback einbindet, das den anderen Browsern angezeigt wird, könnt ihr nach Belieben mit Cross-Fading spielen. Eine Holztextur mit einer Kratzertextur verbinden? Kein Problem! Und wie üblich gilt: Je mehr ihr euch mit den Features beschäftigt, die ein Browserhersteller implementiert hat, umso größer der Anreiz für die anderen Hersteller nachzuziehen. Und je mehr Browser ein Feature implementiert haben, umso größer die Wahrscheinlichkeit, dass es seinen Weg in die Spezifikation findet.

Momentan funktioniert das vierte Beispiel des Demos noch nicht, da Webkit noch keine Animation für cross-fade verwirklichen konnte. Ein animiertes Cross-Fading sieht theoretisch so aus:

background-image: cross-fade(
    url("logo-box.png"),
    url("logo-bare.png"),
    0%);
animation: fading 3s infinite;

Hier sollten die Bilder innerhalb von drei Sekunden ineinander überblenden, und die Animation würde sich unendlich oft wiederholen. Sobald dieses Feature implementiert ist, eröffnet es völlig neue Möglichkeiten für interaktive Elemente, Slideshows und vieles mehr. Das Naheliegendste ist sicher eine einmalige cross-fade-Animation bei hover/focus auf ein Element. Die Entwürfe zur Spezifikation sehen zudem vor, dass cross-fade für alle Bilder implementiert werden soll, also zum Beispiel auch für border-image. Entdecke die Möglichkeiten!

Die erste Implementierung von cross-fade wird voraussichtlich mit Chrome 17 auf den Markt kommen. Also wahrscheinlich gleichzeitig mit dem Projekt, an dem ihr gerade arbeitet.

Schnell im Bilde mit image-rendering

Bleiben wir noch einen Moment bei den Bildern. Diejenigen von uns, die bereits mit großer Begeisterung Responsive Designs konzipieren, haben sicher festgestellt, dass das Rendering von Bildern, die im Browser vergrößert oder verkleinert werden, in letzter Zeit unheimlich an Qualität gewonnen hat. Erinnert ihr euch noch an die Zeit, als jeder sofort sehen konnte, dass ein Bild im Browser verkleinert wurde? Die hakelig verpixelte Katastrophe, die dabei herauskam? Genau! Gleiches gilt für Transformationen wie Drehen oder Stauchen von Bildern. Wo anfangs noch Mausezähnchen blitzten, gibt’s heute schöne glatte Bilder, denen wir die Manipulation im Browser kaum mehr ansehen können.

Mittlerweile haben nämlich alle Browser Methoden implementiert, die in solchen Fällen die Bildqualität optimieren. Bilineares Filtern nennt sich das und entspricht dem, was in professionellen Bildbearbeitungsprogrammen beim Manipulieren von Bildern geschieht. Diese Art der Bildoptimierung ist inzwischen in allen Browsern die Standardeinstellung und sorgt dafür, dass Kanten geglättet werden und alles schön ansehnlich bleibt. Responsive Design Win!

Allerdings schlägt die Optimierung der Bildqualität auch auf die Performance: je anspruchsvoller die Bildoptimierung, desto langsamer das Rendering. Bei einem einzelnen Bild wird das kaum zu Buche schlagen. Bei einem flotten Browserspiel oder einer komplexen Canvas-Animation kann sich die Performance-Einbuße aber durchaus bemerkbar machen. Ein weiteres Problem entsteht immer dann, wenn scharfkantige Elemente auch bei der Bildmanipulation im Browser scharfkantig bleiben sollen. Das kann ein Logo sein, eine Infografik usw. – bilineares Filtern glättet auch hier die Kanten und alles wird unabsichtlich verwaschen.

Wir benötigen also einen Mechanismus, um die Voreinstellung wieder zu überschreiben. Hier kommt crisp-edges ins Spiel.

Kleiner Einschub: Zunächst sahen die Entwürfe zur Spezifikation vor, dass es für image-rendering die Optionen optimizeSpeed und optimizeQuality geben solle. Diese sind nun bereits wieder als »deprecated« gekennzeichnet. Die neuen Optionen heißen auto (Standardeinstellung, Optimierung auf Qualität) und crisp-edges (Option, Optimierung auf Detailschärfe und Geschwindigkeit). Befassen wir uns also im Folgenden mit crisp-edges.

Das Gute: alle relevanten Browser unterstützen diese Eigenschaft bereits jetzt! Firefox ist bereits seit Version 3.6 dabei, also seit 2009! Internet Explorer hatte bis Version 7 die geschwindigkeitsoptimierte Variante als Voreinstellung, seit IE8 setzt man auf Qualität. Schnelles Rendering und scharfe Kanten entlockt man aber auch dem IE8 noch mit -ms-interpolation-mode: nearest-neighbor. Opera hat vor wenigen Wochen nachgezogen und die in CSS4 vorgesehenen image-rendering Optionen implementiert.

Die Syntax lautet derzeit:

• Mozilla: -moz-crisp-edges
• Opera: -o-crisp-edges
• Webkit: -webkit-optimize-contrast
• Internet Explorer: -ms-interpolation-mode: nearest-neighbor

crisp-edges ist also ein weiteres Beispiel für eine Technik, die schon weit vor der Veröffentlichung als Spezifikation flächendeckend einsetzbar ist.

Die Beispiele von Mozilla und das interaktive Demo, auf das Opera verweist, verdeutlichen crisp-edges in der Theorie ganz gut, sind aber insgesamt etwas blutleer und wenig anschaulich. Wo sind Projekte, bei denen durch den Rendering-Modus echte Probleme gelöst werden?

Ein gutes Beispiel ist Pixel-Art; eine Kunstform, in der Bilder aus einzelnen, scharf voneinander abgegrenzten Pixeln zusammengesetzt werden. Man könnte es auch Mosaik nennen. Wenn ich nun ein solches Kunstwerk vergrößere oder verkleinere, sei es, um hineinzuzoomen, sei es, weil das Webdesign responsive sein soll, greift sofort der qualitätsoptimierte Renderingmodus der Browser. Die Folge ist, dass die Kanten geglättet werden und die einzelnen Pixel verwischen. Sinn und Zweck der Kunstform sind damit hinüber. Ärgerlich.

Die Plattform Pixeljoint wurde von der plötzlichen Bildoptimierung seitens der Browserhersteller überrumpelt und suchte nach Lösungen. Schnell entdeckte man die bis dahin proprietäre Mozilla-Lösung im Mozilla Developer Network und band sie (und das IE-Äquivalent) ins CSS ein.

img[src$=".gif"], img[src$=".png"] {
                   image-rendering: -moz-crisp-edges;         /* Firefox */
                   -ms-interpolation-mode: nearest-neighbor;  /* IE */
                 }

Wenn ihr ein beliebiges Pixel-Art-Bild auf der Pixeljoint-Webseite mit dem Firefox aufruft und mit dem + darunter vergrößert, seht ihr, dass die Pixel schön scharfkantig erhalten bleiben. Nehmt ihr das -moz-crisp-edges jedoch z.B. mit der Developer Toolbar heraus, verwischen die Pixel sofort.

Wir merken uns: image-rendering ist dein Freund, wenn du Responsive Space Invaders basteln möchtest.

Den Rahmen sprengen mit full-screen

Der Pseudo-Selektor full-screen ist zwar noch nicht Teil der CSS4-Entwürfe, sondern wird im Rahmen der Fullscreen JavaScript API entwickelt. Aufgrund der bereits weit verbreiteten Implementierung wird er aber sicher Eingang in CSS4 finden. Doch worum geht es hier genau?

Jeder von uns kennt den Fullscreenmodus eines Browsers. Beim einen ist er mit F11 erreichbar, beim anderen mit CMD+Shift+F – in jedem Falle bewirkt er, dass das Browserchrome ausgeblendet wird und der eigentliche Inhalt den gesamten Bildschirm füllt. Wir alle nutzen das gern, um Filme anzuschauen oder Spiele zu spielen oder Webseiten zu lesen, die für größere Bildschirme »optimiert« wurden als der, den wir gerade nutzen. Es ist aber ein bisschen wie bei der Knoff-Hoff-Show: man muss erstmal wissen, dass und wie es geht.

Mit der Fullscreen API gibt es nun einen Weg, die Fullscreen-Ansicht über einen simplen Button als Option bereitzustellen. Aber damit nicht genug! Was z.B. F11 macht ist, sämtlichen Inhalt einer Website im Fullscreenmodus anzuzeigen. Mit der Fullscreen API habt ihr ab sofort die Möglichkeit, einzelne Elemente wie ein Foto oder Video in den Fullscreenmodus zu heben. Denkt ihr auch gerade an eine Lightbox? Genau, sowas in der Art.

Mit dieser simplen Syntax zeigt ihr ein div im Fullscreenmodus an:

div.webkitRequestFullScreen();
div.mozRequestFullScreen();

Und mit dieser Syntax beendet ihr den Spuk wieder:

document.webkitCancelFullScreen();
document.mozCancelFullScreen();

Zugegebenermaßen hat das noch nichts mit CSS zu tun. Nun kommt aber wieder der Pseudo-Selektor full-screen ins Spiel. Und Achtung, jetzt wird’s mächtig! Mit full-screen könnt ihr nämlich alle Elemente anfassen, die sich in dem Moment im Fullscreenmodus befinden.

Denkbar ist, einen Mediaplayer Fullscreen anzuzeigen, aber im Fullscreenmodus die Bedienelemente zu verbergen. Möglich ist auch eine Bildergalerie, bei der die Bilder im Fullscreenmodus einen aufwändigen Rahmen haben, der in der normalen Ansicht nicht sichtbar ist. Der Pseudo-Selektor full-screen macht’s möglich. Unser Element kann im Fullscreenmodus komplett anders aussehen als in der normalen Ansicht.

Ihr könnt das in diesem Beispiel z. B. mit dem Google Chrome nachvollziehen: Der iFrame mit dem schönen Text »I am a lame frame« blüht im Fullscreenmodus mit Formen, Bildern und Farben auf.

Das alles mag wie Spielerei klingen, aber es gibt sogar Möglichkeiten, die Barrierefreiheit einer Webseite damit zu verbessern: Denkbar ist, eine Tabelle, die sich selbst mit cleveren Tricks nur sperrig in unser schickes Responsive Design einpassen lässt, bei Bedarf in den Fullscreenmodus zu schicken und ihr dort ein Zebramuster, einen anderen Font und eine größere Schriftgröße zu verpassen. Denkt beispielsweise an Stundenpläne, komplexe Datentabellen und so weiter.

Nicht nur das: Mit dem Pseudo-Selektor full-screen-ancestor könnt ihr darüber hinaus das Elternelement des Elementes ansprechen, das ihr in den Fullscreenmodus schickt. Dieses dann in der Art einer Lightbox einzufärben ist ein Leichtes. Und voilá, da habt ihr eine Zweizeiler-Lightbox.

Natürlich geht das alles erstmal wieder nur in den künftigen Webkit- und Mozilla-Browsern, aber was soll’s? Eine klassische Lightbox als Fallback einbinden ist auch keine große Sache. Oder ihr bietet keinen Fallback an und zeigt den Usern des IE einfach gar keine Fullscreen-Ansicht. Das hängt vom jeweilige Projekt ab. Wichtig ist nur zu wissen: es geht schon! Und andere tun es auch! Eine Implementierung des Fullscreenmodus findet ihr z. B. im Mediaplayer MediaElements.js.

CSS4 Selektoren

Im Bereich Selektoren wird sich auch einiges bewegen, z.B. werden wir endlich einen Parent-Selektor bekommen, yay! Wir werden künftig nth-columns aus Datentabellen ansprechen können, wir werden local-links stylen können und :link und :visited zu any-link zusammenfassen. Der bereits in Mozilla und Webkit implementierte Selektor :any wird seinen Einzug als :matches feiern und sicherlich bald auch mit einem Polyfill nutzbar sein, es gibt erste Überlegungen zu border-clip und vieles mehr … aber das ist ein neues Thema. Hier und heute habe ich mich auf Neuerungen beschränkt, die ihr jetzt schon einsetzen könnt.

Welche Ideen habt ihr zu den drei vorgestellten Techniken? Oder habt ihr sogar schon die eine oder andere Technik eingesetzt? Ich freue mich auf eure Kommentare!

Zur Autorin

Sandra Kallmeyer ist Frontendentwicklerin aus Leidenschaft. Neuerungen in den HTML- und CSS-Entwürfen erwartet sie daher mit Spannung, vor allem dann, wenn praxisnahe Tricks dabei sind.

Prinzipiell verhalten sich Browser auf mobilen Geräten genau so wie ihre großen Brüder auf dem Desktop. Vorbei sind die Zeiten, in denen eine mobile Webseite eine vereinfachte, abgespeckte Version der »echten« Webseite war. Trotzdem gibt es, bedingt durch die verschiedenen Formfaktoren von Handys und Tablets, ein paar Eigenheiten, auf die wir achten müssen, damit unsere User auch auf mobile Geräten eine gute User Experience bekommen.

Eine dieser Eigenheiten ist die Layout-Berechnung, die regelt, wie Seiten ausgelegt und angezeigt werden. Um zu verstehen, was auf mobilen Geräten passiert, und wie wir das Layout besser kontrollieren können, schauen wir uns zuerst mal an, was auf dem Desktop vor sich geht.

Layout im Desktop-Browser

Auf dem Desktop sind im Grunde genommen nur zwei Aspekte ausschlaggebend dafür, wie eine Seite ausgelegt wird: die Bildschirmgröße und die eigentliche Größe des Browser-Fensters.

Die Bildschirmgröße hängt nicht nur vom Bildschirm ab (der eine »native resolution« hat, bedingt durch die Anzahl von ansteuerbaren physischen Pixeln), sondern auch von der Auflösung, die im Betriebssystem eingestellt ist und das Verhältnis von »echten» und »virtuellen» Pixeln festlegt. Denn selbst wenn ein Monitor z.B. 1920×1080 Pixel anzeigen kann, gibt es User, die ihre Auflösung auf 1280×768 setzen – das Betriebssystem skaliert dann intern diese virtuelle Auflösung auf die physischen Pixel hoch.

Mit der Fenstergröße kennen sich Designer wohl schon gut aus: die Höhe und Breite des Browsers gibt unseren Layouts die anfänglichen Werte, die dann zur Berechnung von prozent-basierten Layouts verwendet werden. Wenn unsere Seite absolute Pixel-Dimensionen verwendet (z.B. in CSS, oder durch Elemente wie Grafiken im HTML), werden diese eins-zu-eins auf die Pixel des Betriebssystems übertragen. Ein CSS-Pixel entspricht einem Pixel im Betriebssystem. Und falls die Seiteninhalte breiter oder höher als das Fenster sind, ergeben sich Scroll-Balken.

Die Übersetzung von physischen und virtuellen Pixeln lässt sich auf dem Desktop nicht beinflussen – sie bleibt die Domäne vom Betriebssystem. Wie wir aber sehen werden, ist das Verhältnis von CSS-Pixeln und Betriebssystem-Pixeln ausschlaggebend in mobilen Browsern.

Der Kleinbildschirm der mobilen Geräte

Obwohl es mittlerweile eine Vielzahl an mobilen Geräten mit unterschiedlichen Bildschirmgrößen gibt, ist es noch immer der Fall, dass Smartphones und Handys generell ein relativ kleines Display haben. Ältere Devices wie das HTC Hero oder iPhone 3Gs haben zudem eine niedrige Pixeldichte, mit 320×480 »echten« physischen Pixeln.

So würde das Web auf Handys aussehen, wenn Browser sich nur an »echte« Pixel halten würden

Wenn mobile Browser sich in diesem Fall wie auf dem Desktop verhalten würden, wäre das Surfen auf Handys eher ein Blick durch ein kleines Schlüsselloch. Und wenn das Layout die eigentliche Fenstergröße zur Berechnung von Prozent-basierten Werten berücksichtigen würde, wären die meisten Webseiten arg verzerrt und zerdrückt.
Aus diesem Grund benutzen mobile Browser eine andere Strategie, um Webseiten anzuzeigen.

Mobile Browser lügen

Mobile Browser benutzen im Vergleich zu Desktop-Browsern einen seitenabhängigen Zoom-Faktor. Das Layout an sich wird auf ein »virtuelles« Fenster, dem Layout-Viewport, mit einer Standardbreite von ungefähr 980px ausgelegt.

Standard Layout-Viewport von 980px (Viewport Test: Standardverhalten ohne meta)

Dieser Layout-Viewport wird dann soweit verkleinert, bis er auf die physische Breite des Displays passt – dem sichtbaren Viewport für den User. Falls Inhalte größer als der anfängliche Layout-Viewport sind, wird der Layout-Viewport dementsprechend vergrößert – aber der sichtbare Viewport zoomt standardmäßig nur so weit aus, dass 980px Breite angezeigt werden. Das führt zu Scrollbalken im sichtbaren Viewport. Inhalte, die schmaler ausgelegt sind, führen zu vergeudetem Leerraum im Design.

Wo auf dem Desktop nur das Betriebssystem für die Umsetzung von physischen und virtuellen Pixeln zuständig ist, verwalten mobile Browser diese Verhältnisse selbst. Dadurch erscheinen die meisten Webseiten auch auf einem kleinen Display korrekt, aber halt – je nach Inhalt – recht klein. User müssen meistens von der anfänglichen, »ausgezoomten» Übersicht in die Seite zoomen, bevor sie diese auch lesen und benutzen können.

Das Web, wie es mobile Browser mit dem Standard-Layout-Viewport von 980px anzeigen

Diese recht komplexe Eigenheit der mobilen Browser hat wohl schon einige Designer verwirrt, die versucht haben, mittels Media Queries ein Layout auch für kleine Displays zu optimieren. Als Beispiel nehmen wir eine recht simple, zweispaltige Seite. Ohne jetzt groß in die Materie »Responsive Web Design« eintauchen zu müssen, wollen wir einfach unser Layout auf schmalen Displays einspaltig anzeigen, was wir mittels eines banalen @media (min-width: 820px) { ... } Blocks definieren. Wenn wir nun das Ganze in einem Desktopbrowser testen, sehen wir, dass bei einer schmalen Fensterbreite das Layout auf eine einzige Spalte kollabiert. Toll. Aber auf mobilen Geräten – die von Haus aus die Seite auf einen Layout-Viewport von 980px auslegen – klappt das ganze leider nicht.

Trotz @media (min-width: 820px) { ... } bleibt das Layout auf dem mobile Browser zweispaltig (Test: Media Query ohne viewport)

Dieses Standardverhalten mag wohl für die meisten Webseiten gut genug sein, aber als Designer wollen wir natürlich mehr Kontrolle darüber, wie unsere Layouts auch auf mobilen Geräten aussehen.

Kontrolle über den viewport

Wie groß der »virtuelle« Layout-Viewport ist und welchen Zoom-Faktor der Browser für unsere Seite benutzen soll, kann mittels des viewport-Meta-Elements festgelegt werden. Dazu können wir eine Handvoll an Attributen festlegen:

width und height

die Größe des virtuellen Fensters

minimum-scale, maximum-scale und initial-scale

minimaler, maximaler und anfänglicher Zoom-Faktor

user-scalable

kann das manuelle Zoomen seitens des Users unterbinden

Wenn wir also eine Webseite haben, die spezifisch auf eine Breite von 500px ausgelegt ist, sieht unser Markup konkret so aus:

<meta name="viewport" content="width=500">

Der Viewport kann mit einer Kombination von diesen Attributen sehr spezifisch definiert werden. Es ist aber zu beachten, das Browser immer versuchen werden, die verschiedenen Werte möglichst sinnvoll umzusetzen – was dazu führen kann, dass einige Attribute schlichtweg ignoriert werden. So wird zum Beispiel bei dem recht unsinnigen

<meta name="viewport" content="width=500,height=100">

das height Attribut ignoriert. Darüber muss man sich aber normalerweise keine Gedanken machen: in den meisten Fällen beschränkt sich die Benutzung des viewports lediglich darauf, die Breite der Seite festzulegen.

Um auf unser einfaches Media-Query-Beispiel von vorher zurückzukommen, sehen wir, dass wir mit <meta name="viewport" content="width=520"> das erwünschte Resultat erzielen können.

Dank viewport funktioniert nun auch die Media Query (Test: Media Query mit viewport)

Probleme bei portrait/landscape und Tablets

Nun können wir also festlegen, wie breit unsere Webseite in mobilen Browsern angezeigt wird. Leider kann uns diese explizite Kontrolle auch zum Verhängnis werden.

Nehmen wir mal als Beispiel eine einspaltige Webseite – jetzt mal ohne Media Queries, um es einfach zu halten – mit einem fixen Layout von 560px Breite. Ohne jegliche viewport-Angaben wird diese Seite auf dem standardmäßig 980px breitem Layout-Viewport angezeigt.

Unsere Seite ohne viewport (Demo Seite ohne viewport)

Um das Layout nun passgenau auf unserem Handy anzeigen zu lassen, fügen wir unser <meta name="viewport" content="width=560px"> Meta-Element hinzu.

Unsere Seite mit <meta name="viewport" content="width=560"> (Demo-Seite mit viewport width 560px)

Soweit, so gut. Was passiert aber nun, wenn wir unser Handy auf »landscape« Orientierung setzen? Der Browser hält sich immer noch strikt an unsere Anweisungen, und zoomt weiter in unsere Seite, um unsere 560px Breite auf die neue Displaybreite anzupassen.

Der 560px-viewport in »landscape«

Problematischer wird es dann, wenn wir nicht nur Handys, sondern auch Tablets betrachten. Diese halten sich auch an die viewport-Angaben, was aber auf den größeren Bildschirmen von Tablet-Devices zu einem viel zu extremen Zoom-Faktor führt.

Der 560px-viewport tritt auch auf Tablets in Kraft

Über spezifische Pixeldimensionen hinaus, können wir bei den width und height-Attributen spezielle Konstanten verwenden: device-width und device-height. So sehen wir zum Beispiel, dass

<meta name="viewport" content="width=device-width">

unseren Viewport auf verschiedene Breiten für Handys und Tablets setzt.

device-width Konstante hat auf Handys und Tablets verschiedene Werte (Viewport Test: device-width)

Natürlich heist das jetzt, dass unser Layout sich wieder (wie wir es schon vom Desktop her kennen) auf eine Vielzahl an verschiedenen Displaydimensionen anpassen muss – Thema Media Queries und »Responsive Web Design«. Eigentlich wollten wir nur unser fixed-width Layout etwas formschöner auf Handys bringen, und nicht das ganze Design umkrempeln.

Darüber hinaus muss auch noch angemerkt werden, dass, obwohl dieser etwas device-unabhängigere Ansatz gut ist, es trotzdem noch einige Tücken gibt.

Safari auf iOS setzt device-width immer auf die schmalere, und device-height immer auf die längere Seite eines iPhones oder iPads, selbst wenn das Gerät in »landscape» ist – meiner Ansicht nach ein Bug. Andere mobile Browser verhalten sich logischer – device-width und device-height beziehen sich hier auf die horizontale oder vertikale Seite, und verändern sich je nach Orientierung.

device-width bezieht sich in iOS immer auf die schmalere Seite, selbst in »portrait«-Orientierung

Devices wie das iPhone 4 und die neue Generation an Android Handys haben, im Vergleich zu ihren Vorgängern, immer höhere Pixeldichten – das Display beinhaltet eine größere Anzahl an physischen, ansteuerbaren Pixeln. Wenn wir aber device-width und device-height verwenden, stellen wir fest, dass diese höhere Pixeldichte nicht miteinbezogen wird. Beispielsweise wird selbst auf einem iPhone 4, das eine physische Auflösung von 640×960 hat, device-width und device-height auf 320×480 gesetzt – die gleichen Werte wie auf einem iPhone 3Gs. Das liegt daran, dass Browser auf high-dpi Devices noch einen zusätzlichen internen Zoom-Faktor verwenden.

Normalerweise sollte diese Eigenheit von high-dpi Geräten den Designern eigentlich egal sein. Der zusätzliche Zoom-Faktor soll auf diesen Devices verhindern, dass Layouts, Texte und Bilder nicht arg zu klein angezeigt werden – was ja wieder dazu führen würde, dass User erstmal wieder in eine Seite reinzoomen müssen, um sie überhaupt nutzbar zu machen. Wenn wir aber trotzdem diesen extra Zoom-Faktor unterdrücken wollen (um beispielsweise sicherzustellen, dass Strichgrafiken so scharf wie möglich – mit einem eins-zu-eins Verhältniss von CSS- und Device-Pixeln – angezeigt werden), können wir auf Android ein zusätzliches target-densitydpi Attribut in unserem viewport Meta verwenden:

<meta name="viewport" content="width=device-width,target-densitydpi=device-dpi">

device-width auf high-dpi Android Handys, ohne und mit target-densitydpi=device-dpi (Viewport Test: device-width und dpi)

Neue Ansätze – viewport per CSS

Das fundamentale Problem mit dem viewport Meta-Element ist, dass es sich im eigentlichen HTML-Dokument aufhält, obwohl es sich hier eigentlich eher um eine Styling-Angelegenheit handelt. Es gibt zwar verkappte Ansätze, um den Viewport mittels JavaScript doch noch auf verschiedene Situationen (»landscape« Orientierung auf Handys, grössere Displays auf Tablets, usw.) anzupassen (siehe z.B. die Diskussion hier: A fix for iPhone viewport scale bug), aber das scheint mir wirklich nicht die rechte Lösung zu sein.

Einen möglichen Ausweg aus diesem Schlamassel soll die CSS Device Adaptation Spezifikation bieten. Diese übernimmt und erweitert die Funktionalität vom viewport Meta, lagert diese aber ins CSS aus. Zur Zeit wird diese Spezifikation leider nur in Operas mobilen Browsern unterstützt (und da nur mittels -o- Vendor-Prefix), aber sie lässt erahnen, wie wir Situationen wie bei unserer Demo-Seite doch eleganter anpacken können.

So lässt sich beispielsweise nicht nur eine bestimmte Breite angeben, sondern obere und untere Grenzen mittels min-width und max-width, oder mit der width: [min] [max]; Kurzschreibweise setzen.

CSS @viewport setzt nur bei kleinen Displays die minimale Breite (Viewport Test: viewport mittels CSS)

Somit lässt sich unsere einspaltige Seite, die wir nur auf kleinen Displays etwas passender anzeigen wollen, recht einfach umdefinieren:

@-o-viewport { width: 560px auto; resolution: device; }

Auf Handys wird der Viewport auf eine minimale Breite von 560px festgelegt. Sobald das Display größer als diese untere Grenze ist (z.B. ein Handy im »landscape« Modus oder ein Tablet), überlassen wir die Wahl des besten Layout-Viewports einfach dem standardmäßigen Verhalten des Browsers. Um sicherzustellen, dass auf high-dpi Geräten die Pixel nicht nochmal skaliert werden, erzwingen wir auch noch mittels resolution:device ein eins-zu-eins Verhältnis von physischen und CSS Pixeln.

Unsere Demo-Seite, jetzt mit CSS @viewport (Demo-Seite mit CSS viewport)

Fazit

Mobile Browser sind von Haus aus so ausgerichtet, dass sie die meisten Webseiten im wilden Web relativ korrekt anzeigen können. Designer können mit dem viewport Meta-Element beinflussen, wie ihre Seiten angezeigt werden, aber es kann schnell zu Problemen führen, wenn wir jenseits von Handys im Portrait-Modus gehen. Viewport-Definition mittels CSS ist zwar momentan nur in Opera möglich, aber wenn andere Browser diese neue Spezifikation umsetzten, werden uns hoffentlich bessere Tools zur Verfügung stehen, um unsere Layouts doch gezielter an eine Vielzahl an Geräten bestens anzupassen.

Weiterführende Link

• Peter-Paul Koch: A tale of two viewports – part two
• James Pearce: First, understand your screen
• Andreas Bovens: An introduction to meta viewport and @viewport

Zum Autor

Patrick H. Lauke ist Web Evangelist im Developer Relations team von Opera Software ASA. In einem früheren Leben arbeitete er als Web Editor an einer britischen Universität, wo er in 2003 im Alleingang eine der ersten Standards-basierten Websites des Sektors implementiert hat. Patrick ist seit 2001 in der Diskussion rund um Standards und Barrierefreiheit engagiert – mit regelmässigen Vorträgen auf Konferenzen und Teilnahme an einer Veilzahl von Webentwicklungs- und Accessibility-Mailinglisten und Initiativen wie das Web Standards Project und die Webkrauts. Seine persönliche Ecke im Netz findet man unter http://www.splintered.co.uk

Im Adventskalender 2009 hat Eric Eggert über »Transitionen und Animationen« geschrieben und darüber, was in der Zukunft mit neuen CSS-3-Eigenschaften möglich sein wird. Vor zwei Jahren waren Webworker auf die Webkit-Browser Safari und Chrome beschränkt, wenn sie eine Transition umsetzen wollten. Opera und Firefox haben nachgezogen und unterstützen heute ebenfalls animierte Inhalte. Für den aktuellen Praxistest wurden die Versionen Opera 11, Internet Explorer 9, Firefox 8, Safari 5 und Google Chrome 14 berücksichtigt.

Das Transitions-Modul des CSS-3-Standards ist mit fünf Eigenschaften überschaubar. Im Gegensatz zu Animationen und Transformationen ist der Einsatz einfach, die einzelnen Eigenschaften intuitiv und sicher der leichteste Einstieg in den Bereich der animierten Inhalte.

Eine Transition *) ist als die fließende Veränderung einer CSS-Eigenschaft auf einer Zeitachse zu verstehen. Wo sich bislang bei einem Mouseover eine Farbe wie auf Knopfdruck änderte, kann sich diese über eine Transition langsam in die andere Farbe verwandeln.

Mindestangaben für eine Transition

Pflichtparameter sind transition-property und transition-duration. Über transition-property geben Webworker die CSS-Eigenschaft an, die sie mit einer Transition versehen wollen. Über transition-duration definiert er die Zeit, die eine fließende Veränderung dauern soll. Eine Minimalangabe sieht beispielsweise so aus (weiter unten findet ihr die Schreibweisen für die einzelnen Browser. Alle Eigenschaften sind erst mal in der Standardschreibweise des W3C gezeigt):

div {
    background-color: red;
    transition-property: background-color;
    transition-duration: 1.5s;
}

oder auch als Kurzschreibweise (Shorthand):

div {
    background-color: red;
    transition: background-color 1.5s;
}

Für die Transition ist immer ein Anfangs- und Endzustand notwendig. In diesem Beispiel ist der Endzustand über das Pseudo-Attribut :hover definiert, kann aber auch über eine Klasse angegeben sein, die über JavaScript einem HTML-Element zugewiesen wird.

div:hover {
    background-color: blue;
}

   transition: background-color

.beispiel-1: Die Hintergrundfarbe der Box wechselt beim überfahren mit der Maus in 1,5 Sekunden von rot auf blau (im Internet Explorer ohne Übergang, da Transitions nicht unterstützt werden).

Parameter für eine Start-Verzögerung

Als weitere Eigenschaft steht transition-delay zur Verfügung, welche die Transition entsprechend verzögert.

Sowohl für transition-duration als auch für transition-delay werden Zeitwerte erwartet, entweder in Sekunden oder Millisekunden mit den Abkürzungen für die Einheiten s oder ms, z.B. 1.5s oder 1500ms (was hier dieselbe Zeit ist). Das W3C hat eine Liste mit Zeitangaben zusammengestellt: http://www.w3.org/TR/css3-values/#time.

Unterschiedliche Geschwindigkeiten auf der Zeitachse

Die wahrscheinlich umfangreichste Eigenschaft ist transition-timing-function. Darüber wird das Geschwindigkeitsverhalten bestimmt, mit der sich die Transition verhält. Für die »Zeitfunktion« stehen folgende Werte zur Verfügung:

• Schlüsselworte (Keywords)
  • ease (Standard): Die Transition beginnt verlangsamt, nimmt schnell Geschwindigkeit auf und endet langsam. Zwei Drittel der Transition ist nach der halben Zeit dargestellt.
  • ease-in: Die Transition beginnt langsam, endet schnell.
  • ease-out: Die Transition startet schnell, endet langsam.
  • ease-in-out: Die Transition beginnt und endet langsam, in der Mitte ist die Geschwindigkeit am höchsten.
  • linear: Gleichbleibende Geschwindigkeit, keine Verlangsamung am Anfang oder Ende der Transition.
• cubic-bezier()
  • cubic-bezier(x1, y1, x2, y2) steuert die Transition nach eigenen Angaben. Die ersten zwei Werte bestimmen die Startgeschwindigkeit, der dritte und vierte Wert die Endgeschwindigkeit. Der Geschwindigkeitsverlauf ergibt sich aus der Kurve, welche Start- und Endpunkt verbindet. Alle vier Parameter sind Pflichtparameter.
  • cubic-bezier() ist die Formel, auf deren Grundlage der Geschwindigkeitsverlauf berechnet wird. Hinter allen Schlüsselworten verbirgt sich eine cubic-bezier()-Definition mit konkreten Werten. Webdesigner, die sich für das mathematische Modell von cubic-bezier() interessieren, finden unter folgendem Link weiterführende Information: developer.mozilla.org/en/CSS/timing-function
• steps()
  • bestimmt keinen fließenden, sondern einen Übergang über Zwischenstadien, vergleichbar mit einer Uhr, die von Sekunde zu Sekunde springt, und dort jeweils eine Sekunde verharrt.
  • steps(nr, [start|end]) benötigt immer zwei Parameter:
    • Als erster wird die Anzahl der Schritte definiert, in denen die Transition angezeigt werden soll.
    • Der zweite Parameter hat die möglichen Werte start oder end. Damit wird bestimmt, ob ein Schritt vor oder nach einem Zeitintervall dargestellt werden soll. Was kompliziert klingt, ist anhand eines Beispiels leichter zu erklären: Ihr habt einen Lichtschalter, den ihr in fünf Sekunden anschalten sollt. Allerdings nur am Anfang oder Ende der fünf Sekunden. step (1, start) bedeutet, ihr schaltest den Schalter sofort an und es ist sofort hell. Oder ihr wartet fünf Sekunden und schaltest das Licht dann an, das wäre step(1,end). Beides Mal ist es nach fünf Sekunden hell, nur das »ab wann« wird durch den zweiten Parameter in steps() bestimmt.
    • step-start ist ein Schlüsselwort und entspricht steps (1,start)
    • step-end ist ebenfalls ein »Keyword« und entspricht steps (1,end). Beide Schlüsselworte sind also fest definiert auf einen Schritt in der Transition.
  • steps() ist W3C nur im Entwicklungsbereich des Standards zu finden, im »Working Draft« des W3C taucht dieser Parameter für die transition-timing-function noch nicht auf. Allerdings werden sie bereits von Firefox, Safari und Chrome unterstützt.
• Eine sehr anschauliche Darstellung der transition-timing-function ist unter http://peter.sh/experiments/css3-transition-timing-functions/ zu finden.

Beispiel für steps()

An folgendem Beispiel wird das Verhalten von steps() deutlich (die Mehrfachangabe innerhalb einer Eigenschaft wird weiter unten beschrieben).

.beispiel-2 {
    background-color: #FFFF00;
    width: 200px;
    transition-property: width, background-color;
    transition-duration: 5s, 5s;
    transition-timing-function: steps(10,start), steps(5,end);
}
.beispiel-2:hover {
    width: 600px;
    background-color: #ff0000;
}

.beispiel-2: Die gelbe Box wird in 10 Einzelschritten auf eine Breite von 600px gedehnt, die Farbe wechselt in 5 Steps. Internet Explorer unterstützt generell keine Transition, Opera kennt die steps() nicht und stellt den Übergang mit der Zeitfunktion ease dar.

Kurzschreibweise transition

Über die Kurzschreibweise transition werden die Werte für Eigenschaft, Dauer, Zeitfunktion und Verzögerung in einem Ausdruck geschrieben. Die einzelnen Parameter werden durch Leerzeichen voneinander getrennt. Dabei können die einzelnen Parameter fast in beliebiger Ordnung notiert werden. Lediglich die Reihenfolge der Zeitangaben ist nicht beliebig und für die Darstellung relevant: Der erste Zeitwert in der Kurzschreibweise wird als Dauer, der zweite wird als Verzögerung umgesetzt.

Gültige »shorthand«-Beispiele können so aussehen:

transition: width 3s linear100ms;

/* oder */
transition: 1s 1.5s padding-bottom ease-in;

/* oder auch nur */
transition: color 2s;

Pflichtangabe ist die CSS-Eigenschaft, die mit einer Transition versehen werden soll, Sinn macht die Angabe erst mit der Zeitangabe. Ohne diese wird die Transition mit einer Zeit von 0 Sekunden (Standard für transition-duration) angezeigt, der Endzustand wäre also sofort erreicht.

Mehrere Transitions gleichzeitig definieren

Neben der Kurzschreibweise ist es möglich, mehrere Transitions in einem Ausdruck zu definieren.

Dabei werden die einzelnen Werte über ein Komma (,) getrennt geschrieben. Sind die Angaben über die einzelnen Eigenschaften definiert, werden die Werte entsprechen ihrer Position in der Definition zusammengeführt: Die erste CSS-Eigenschaft aus transition-property wird mit einer Dauer des ersten Eintrags aus transition-duration und jeweils den ersten Werten für Zeitfunktion und Verzögerung dargestellt. Gleiches gilt für die jeweils zweiten und dritten Angaben.

div {
    background-color: #caffee;
    color: blue;
    width: 200px;
    transition-property: background-color, color, width;
    transition-duration: 3s, 2s, 3000ms ;
    transition-timing-function: linear, ease-in, ease;
    transition-delay: 0s, 2500ms, 0s;
}
div:hover {
    background-color: blue;
    color: yellow;
    width: 100%;
}

    transition-property: background-color, color, width;
    transition-duration: 3s, 2s, 3000ms ;
    transition-timing-function: linear, ease-in, ease;
    transition-delay: 0s, 2500ms, 0s;
    

.beispiel-3: Kombination mehrerer Transitions: Der Hintergrund verfärbt sich sofort von rot in blau, die Veränderung des Textes selber ist mit einer Verzögerung konfiguriert. Bei der Breite schafft es nur der Firefox, diese von einem Pixel-Wert zu einem Prozent-Wert umzuwandeln – Opera, Safari und Chrome ignorieren beim Wechsel der Einheiten die Transition für width.

Kurz und knapp: Mehrfachangaben in Kurzschreibweisen

In der Kurzschreibweise wird eine Transition über [Eigenschaft][Dauer][Timing-Funktion][Verzögerung] definiert, eine zweite Transition mit allen Angaben wird auch hier mit einem Komma (,) von der ersten Definition getrennt, so können (theoretisch) beliebig viele Übergänge über nur ein transition definiert werden:

div {
    transition: background-color 3s linear ,  color 2s linear 2s ;
}

Unterschiedliche Geschwindigkeit für »hin und zurück«

Die Darstellung der Transition läuft in beide Richtungen mit den gleichen Einstellungen. Allerdings können unterschiedliche Parameter die Darstellung zur Enddefiniton hin und für die rückläufige Transition definiert werden. Wie ihr im folgenden Beispiel sehen könnt, stehen im Endstatus div:hover andere Zeiten als im div, in dem die Ausgangssitution definiert ist.

div {
    padding: 10px;
    background-color: white;
    transition: padding 300ms ,background-color linear  300ms 0s;
}
div:hover {
    padding: 10px 200px;
    background-color: #00f000;
    transition: padding 3s ,background-color linear  1s 2s;
}

.beispiel-4: Beim Mouseover werden die Zeitwerte aus der :hover-Angabe verwendet, die Box zieht sich langsam auf und ändert mit einer Verzögerung die Hintergrundfarbe. Bein Mouseout greifen die Werte aus der ersten Regel, Box und Farbe schnellen in 0.3 Sekunden auf die Ursprungsdarstellung zurück.

Browserunterstützung

Transition-Eigenschaften werden in der Standardschreibweise von noch keinem Browser unterstützt. Internet Explorer bis zur Version 9 unterstützt Transition gar nicht, die anderen benötigen das jeweilige Vendor-Präfix:

• Firefox: -moz-
• Opera: -o-
• Safari und Google Chrome: -webkit-
• Internet Explorer: -ms- (ab Version 10)

So kann eine komplette Regel, um alle potentiellen Browser zu »erwischen«, schon mal recht umfangreich sein:

#beispiel {
    margin-top: 100px;
    opacity: 0;

    /* Firefox */
    -moz-transition-property:    margin-top, opacity;
    -moz-transition-duration:    1s,0.5s;
    -moz-transition-delay:       1.0s,0s;

    /* Safari / Chrome */
    -webkit-transition-property: margin-top, opacity;
    -webkit-transition-duration: 1s,0.5s;
    -webkit-transition-delay:    1.5s,0s;

    /* Opera */
    -o-transition-property:      margin-top, opacity;
    -o-transition-duration:      1s,0.5s;
    -o-transition-delay:         1.5s,0s;

    /* Standard */
    transition-property:         margin-top, opacity;
    transition-duration:         1s,0.5s;
    transition-delay:            1.5s,0s;
}

Auch wenn die Standardschreibweise noch nicht unterstützt wird, sollte sie in der Regel nicht fehlen. Dieser Ausdruck sollte am Ende stehen, damit dieser greift, sobald ein Browser die Implementierung auf die Standardschreibweise umstellt.

Neben der Frage, welche Browser Transition unterstützen, steht aktuell aber auch wie Frage, welche CSS-Eigenschaften konkret unterstützt werden.

Was kann mit einem Übergang versehen werden?

Eine Liste der Eigenschaften, die mit einer Transition versehen werden können, ist beim W3C zu finden. Dabei werden die meisten Eigenschaften tatsächlich unterstützt. Ausnahmen sind beispielsweise vertical-algin oder border-spacing. Dort finden sich Eigenschaften wie visibility oder z-index, für die erst mal kein fließender Übergang sinnvoll klingt. visibility zum Beispiel springt bei einer Transition von visible zu hidden am Ende der Zeit auf hidden um. Im Zusammenhang mit anderen Transitions ist aber das Umschalten nach einer bestimmten Zeit oder Verzögerung durchaus denkbar.

Auf der Übersicht von transitionierbaren Eigenschaften ist jede Box mit einer anderen CSS-Eigenschaft zu sehen. Dort könnt ihr euch einen Eindruck verschaffen, wie sich die Transitions auswirken.

Was wie unterstützt wird, kann nur in einer Tendenz ausgedrückt werden: Alle Browser (außer dem Internet Explorer) unterstützen weitgehend alle definierten Eigenschaften. Safari, Chrome und Firefox sind dabei sicher am stärksten. Einschränkungen tauchen dann auf, wenn Regeln nicht sauber definiert sind. Opera, Safari und Chrome schaffen es beispielsweise nicht, eine Breite von 200px auf 100% umzuwandeln.

Kurzschreibweisen wie padding oder margin stellen für Opera Probleme dar. Obwohl Opera Eigenschaften wie margin-left oder padding-bottom in einer Transition darstellen kann, scheitert er bei der Angabe von margin bzw. padding in der Angabe von -o-transition-property. Die Webkitbrowser und Firefox haben mit Kurzschreibweisen keine Probleme.

Viele Transitions gleichzeitig zwingen den Browser gerne etwas in die Knie. Die komplexen Beispiele am Seitenende lassen Opera »stark arbeiten«, die Transition werden nicht in der Geschwindigkeit angezeigt, wie dort angegeben. Auch hier kommen Firefox und vor allem Safari und Chrome wesentlich besser hinterher.

Je nach Eigenschaft entsteht der Eindruck des Ruckelns. Dies hängt allerdings auch von der Eigenschaft ab. Ein font-weight kann zwar mit einer Transition versehen werden, allerdings sind die meisten Schriften auf den Rechnern in »normal« und »bold« hinterlegt. Eine Transition für font-weight von 100 zu 900 kann zwar definiert werden, wenn die Schrift jedoch nur in zwei Varianten vorliegt, kann eine Transition auch nur zwei Zustände darstellen. Ein fließender Übergang wird hier nicht entstehen.

An den Ausführungen wird deutlich, dass ein Urteil über »richtig« oder »falsch« nicht eindeutig getroffen werden kann. Vieles ist möglich, im Einzelfall muss der Webworker browserübergreifend intensiv testen.

Vorteile von Transition

• Es ist ein reines Layout-Modul und kann von daher als »hübsche« Ergänzung eingesetzt werden, ohne dass ein Browser, der keine Transition unterstützt (mit Ausnahmen des Surf-Erlebnisses) in der Funktionalität eingeschränkt ist.
• Transition erfordert kein JavaScript und kein Flash-Plugin, und hat von daher das Potential, (auf einen Browser beschränkt) 100% der Darstellung anzubieten, ohne dass sich der Frontendler Gedanken über das (lästige) Fallback für die 3% oder 5% machen muss, die JavaScript eventuell deaktiviert haben.

Nachteile von Transition

• Der Nachteil liegt in der heute noch mangelnden Browserunterstützung, vor allem durch den Internet-Explorer. Solange ein großer Teil aller Surfer (und das unabhängig davon, welcher Browser das ist) eine Eigenschaft nicht unterstützt.

Experiment – Navigation mit Transition

Das komplette CSS-File mit den vollständigen Angaben für die folgenden, aber auch die Transtions auf dieser Seite, sind im transition.css zu finden.

Über eine UL wird folgende Navigation aufgebaut:

.beispiel-5: Auf Mouseover wird der Linkstext über ein text-indent nach links raus gezogen. Im link ist ein span mit dem gleichen Text, dieses wird über die Kaskade .beispiel-5 ul li a:focus span, .beispiel-5 ul li a:hover span ausgelöst und nach oben gezogen. Der Effekt klappt auch mit der Tastatur. Das funktionert gut im Firefox, Safari und dem Chrome; Opera verliert schon mal die Höhen, wenn die Navigation schnell und häufig mit der Mouse überfahren wird.

Experiment – Bilderrätsel

Das folgende Foto ist mit 150 DIVs überlagert, die jeweils 30 Pixel hoch und breit sind.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

.beispiel-6: Beim überfahren mit der Maus werden die DIVs durchsichtbar (opacity) und werden über 7.5 Sekunden wieder schwarz. Das CSS dafür besteht nur aus wenigen Zeilen. Auch hier kommt der Opera in der Darstellung der Transitions nicht hinterher. Das Beispiel funktioniert nicht über die Tastatur.

Weiterführende Links

• Umfangreiche Beispielsammlung: http://www.olivergast.de/wp-content/demos/transitions/index.html
• Beispielsammlung für Safari und Chrome: http://www.html5-portal.de/css3-special.html
• W3C Working Draft: http://www.w3.org/TR/2009/WD-css3-transitions-20091201/
• W3C Editor's Draft: http://dev.w3.org/csswg/css3-transitions/#transition-timing-function

*) Transition ist mit »Übergang«, »Überleitung« oder »Wechsel« zu übersetzen. Im Gegensatz zu den verwandten Modulen Animations und Transformations, die im Deutschen auch ohne Übersetzung verständlich klingen – und vor allem auch als Verb ausgedrückt werden können (ein HTML-Element wird animiert oder transformiert), ist es schwierig, für Transition einen vergleichbaren Ausdruck in Deutsch zu finden, geschweige denn ein Verb, welches das Verhalten treffend beschreibt.
Gleichzeitig ist es wichtig, die drei Module klar voneinander zu trennen. Klar, eine Transition animiert ebenfalls ein HTML-Element, im Kontext von CSS ist es jedoch sinnvoll, auch sprachlich die klare Abgrenzung zu berücksichtigen. Von daher wird auf dieser Seite das Verb »animiert« gemieden und der Ausdrücke wie »mit einer Transition versehen« verwendet – auch wenn es etwas umständlich klingt.

Autoreninfo

Stephan Heller [daik.de] arbeitet seit 2004 als Freelancer. Er bietet als HTML und CSS Spezialist Frontend-Entwicklung, als ZEND Certified Engineer ebenso Backend-Entwicklung mit PHP und MySQL an.
Aktuell arbeitet er an einer umfassenden CSS-Referenz, welche alle CSS 2.1 und CSS 3 Eigenschaften bündelt: www.css-wiki.com.

Webseiten mit CSS3-Eigenschaften aufzuhübschen, ist gerade groß in Mode. Reden wir an dieser Stelle von solchen dekorativen Eigenschaften, sind in erster Linie border-radius, box-shadow, border-image, linear-gradient, text-shadow, multiple Backgrounds und rgba-Farbwerte gemeint. Deren Verwendung kann dem Webdesigner einige Stunden Arbeitszeit ersparen. Die Wartbarkeit der Projekte nimmt enorm zu, denn der Webworker muss im Falle einer Änderung oder Anpassung nicht mehr diverse Grafiken erneuern, sondern lediglich ein paar Zeilen Code ändern.

Aber CSS3 sollte mit Bedacht implementiert werden, damit die Internetseiten in alten Browsern nicht unbrauchbar werden. Ältere Browser können zwar diverse Effekte mit Javascript-Bibliotheken nachempfinden, diese können jedoch den Browser ausbremsen. Daher solltet ihr immer überlegen, ob eine intelligente Fallback-Lösung nicht die bessere Alternative ist.

Vorüberlegung: Progressive Enhancement und Fallback-Lösungen

Jeder Webdesigner, der CSS3 in seinem Projekt einsetzen will, wird sich vorher über die Browserkompabilität der entsprechenden Eigenschaften informieren wollen. Dafür gibt es eine Vielzahl von Checklisten im Internet – eine sehr ausführliche, übersichtliche und aktuelle Liste ist When can I use….

Beim Studieren der Browserkompabilitäten wird schnell klar, dass ihr CSS3 zur Zeit nur unter Vorbehalt eingesetzen könnt. Zuviele alte Browser sind noch im Umlauf, die CSS3 nur teilweise oder gar nicht interpretieren.
Ob nun runde Ecken im alten Browser eckig erscheinen, dürfte der Benutzbarkeit der Internetseite keinen Abbruch tun; allerdings könnte das bei einem verschwundenen halbtransparenten Hintergrund und der Lesbarkeit des darüber liegenden Textes schon anders aussehen. Das Prinzip von Progressive Enhancement bietet sich hier an: die Internetseite für Browser ohne CSS3 konzipieren und für die modernen Browser mit CSS3 erweitern.
Die andere Variante stellen durchdachte Fallback-Lösungen dar. Hier ein Beispiel:

Freizeitler.de in einem modernen Browser

Freizeitler.de ohne Unterstützung von rgba im IE 8

CSS3 PIE – Progressive Internet Explorer

Für den Fall, dass Fallback-Lösungen nicht ausreichen und der IE ebenfalls ein adäquates Ergebnis abliefern soll, besteht die Option, auf Javascript-Lösungen zurückzugreifen. Eine, die sich etabliert hat, ist CSS3 PIE von Jason Johnston. CSS3 PIE befindet sich zu diesem Zeitpunkt noch in der Version 1.0beta5.

PIE ist unkompremiert 40K groß (mit Gzip nur noch 16K) und unterstützt folgende, dekorative CSS3-Eigenschaften:

• Border-Radius
• Box-Shadow
• Border-Image
• Multiple Background Images
• Linear-Gradient (gerade Verläufe) als Background Image

CSS3 PIE richtig ins Stylesheet einbinden

Die Einbindung ist denkbar einfach und geschieht im Stylesheet. Über behavior: url(Pfad/PIE.htc); wird die Datei asynchron aufgerufen und das dann auch nur vom Internet Explorer selbst, denn andere Browser interpretieren behavior gar nicht. Der Pfad muss immer relativ zur HTML-Datei angegeben werden, da das Javascript im DOM des HTML arbeitet. Die Implementierung im Stylesheet sieht dann zum Beispiel so aus, wenn die HTML-Datei und die PIE.htc im selben Verzeichnis liegen:

#adventskalender {
	-moz-border-radius: 10px;
    	-webkit-border-radius: 10px;
    	border-radius: 10px;
	}
#krippe {
	-moz-box-shadow: 6px 6px 12px #222222;
	-webkit-box-shadow: 6px 6px 12px #222222;
	box-shadow: 6px 6px 12px #222222;
}
#adventskalender, #krippe {
	behavior: url(PIE.htc);
	}

Den Aufruf der .htc-Datei hängt ihr einfach an den Block der CSS3-Anweisungen an. PIE reagiert nur auf die standard-konformen Angaben – Eigenschaften mit Vendor-Prefixes dürfen nie am Schluss des CSS3-Blocks stehen.
Der veranwortungsvolle Anwender von PIE sollte außerdem immer darauf achten, dass die Anzahl der Aufrufe der .htc-Datei so gering wie möglich gehalten wird und wirklich nur die unmittelbar betroffenen Elemente behandelt werden. Immerhin haben wir es hier mit einem Javascript zu tun, das den Explorer extrem ausbremsen wird.

Weil der IE nicht alle Werte beim Parsen von einigen CSS-Eigenschaften Preis gibt, muss für diese ein eigenes Präfix geschaffen werden. Für CSS3-Background-Eigenschaften zum Beispiel lautet das PIE-Präfix -pie-background: linear-gradient(#CCC, #EEE);.

CSS3 PIE verstehen und die Schwächen kennen

Um die simulierten CSS3-Eigenschaften zu rendern, erstellt das Javascript von PIE über das DOM einen Container (<css3-container/>). Dieses neue Element wird als Sibling (Schwestern-Element) vor dem Zielelement kreiert und mit position: absolute auf denselben Koordinaten und mit demselben z-index platziert. Da PIE die nicht unterstützten CSS3-Eigenschaften mit VML-Objekten nachzeichnet, werden diese in dem neuen Container untergebracht.

Aus dieser Vorgehensweise resultieren auch die meisten bekannten Probleme wie z. B. verschwundene Hintergründe, Border oder Schlagschatten. Das hängt mit der Tatsache zusammen, dass der generierte Container mit position: absolute hinter dem Zielcontainer mit position: static verschwindet. In diesem Fall müsst ihr dann den statischen in einen relativ positionierten Container umgewandeln und mit z-index: -1 nach hinten schieben. Wieder einmal wird position: relative zum Problemlöser des Internet Explorers.

Für CSS3-Background-Eigenschaften wendet ihr das oben beschriebene Präfix von PIE an. Sollen mehrere Hintergründe eingebunden werden (multiple backgrounds), muss der Pfad zu den Bildern immer relativ zur HTML-Datei angegeben werden.

Ein bekannter Bug tritt auf, wenn transparente Hintergründe in Tateinheit mit Schlagschatten verwendet werden. Der Schlagschatten wird von PIE nämlich auf den gesamten Hintergrund des Containers gelegt und scheint dann durch die transparente Fläche hindurch. In diesem Fall sollte sich der Webdesigner gegen PIE und für pures CSS3 mit einer Fallback-Lösung entscheiden – die Angabe einer blickdichten Hintergrundfarbe auf herkömmliche Weise, die von allen Browsern interpretiert wird. In diesem Beispiel in Verbindung mit Modernizr.js (vgl. die Klasse .rgba):

#adventskalender 	{
	background: #fff;
	-moz-box-shadow: 5px 4px 4px rgba(0, 0, 0, .1);
	-webkit-box-shadow: 5px 4px 4px rgba(0, 0, 0, .1);
	box-shadow: 5px 4px 4px rgba(0, 0, 0, .1);
	-moz-border-radius: 40px 10px 10px 10px;
	border-radius: 40px 10px 10px 10px;
	position: relative;
	}
.rgba #adventskalender {
	background: rgba(255, 255, 255, 0.5);
	}
#adventskalender {
	behavior: url(PIE.htc);
	}

Hier werden die CSS3-Angaben von den alten Browsern ignoriert und die Eigenschaft background: #fff; kommt zum Tragen. Die Lesbarkeit des Textes wäre gerettet.

PIE bringt neben den oben erwähnten noch ein paar bemerkenswerte zusätzliche Features mit:

-pie-watch-ancestors

Erkennt On-The-Fly-Änderungen an Objekten (z. B. durch JavaScript) und kann diese umsetzen.

PNG-Alpha-Transparenz

Rendert die Alpha-Transparenz von .png-Dateien im Internet Explorer 6. Sie wird ebenfalls einfach über das PIE.htc script initiiert. Macht die Verwendung anderer Alpha-Transparenz-Skripte überflüssig (z. B. DD_belatedPNG)

Lazy Initialization (-pie-lazy-init)

Gibt man Elementen die -pie-lazy-init:true; Eigenschaft, so werden sie zu Gunsten der Performance erst gerendert, wenn sie in den Viewport wandern.

Layout Polling (-pie-poll)

Mit -pie-poll:true; wird die Abfrage für Zustandsänderungen eines Elements erhöht, um so Rendering-Fehler durch Größen- und Positionsänderungen zu vermeiden.

CSS3 PIE Implementierungen

CSS3 PIE wird von dem CSS Authoring Framework Compass implementiert. Das Modul befindet sich aktuell noch in der Beta.

Zum Schluß noch ein Hinweis auf IE-CSS3

Eine Alternative zu PIE ist IE-CSS3 von Nick Fetchak. Dieses Skript arbeitet zwar ähnlich wie PIE – am Ende der CSS3-Deklarationen wird mit behavior: url(ie-css3.htc); die Datei aufgerufen – aber IE-CSS3 unterstützt zur Zeit nur border-radius, box-shadow und sogar zusätzlich text-shadow. Wer also nicht das volle Programm von PIE und/oder lediglich text-shadow benötigt, ist mit dieser Lösung sicher auch ganz gut beraten. Sie ist auf jeden Fall wesentlich schlanker.

Über den Autor

Henry Zeitler ist gelernter Mediengestalter und arbeitet seit 2006 als Webproducer und HTML-Trainer in Düsseldorf. Frontend-Entwicklung, Codeoptimierung, Semantik und Zugänglichkeit haben sich zu seiner Leidenschaft entwickelt, die über das berufliche Engagement hinaus geht. Unter www.freizeitler.de veröffentlicht er Experimente und Erkenntnisse.

Suchmaschinenoptimierung ist ein wichtiger Aspekt bei vielen Webprojekten. Deswegen lohnt es sich für Webworker, diejenigen SEO-Basics zu kennen, die Einfluss auf grundlegende Webseiten-Aspekte wie die Informationsarchitektur haben. Im ersten Teil des Artikels ging es um den ersten der vier Schritten für einen suchmaschinenoptimierten Internetauftritt: die Keyword-Analyse. Im zweiten Teil erfahrt ihr, wie Keywords und Inhalte zu einer sinnvollen Informationsarchitektur zusammenfinden.

Schritt 2: Keywords und Inhalte zusammenbringen

Aus der Keywordliste eine funktionierende Struktur für den Internetauftritt zu entwickeln, ist häufig gar nicht so leicht. Denn schließlich ist Suchmaschinenoptimierung nicht der einzige Faktor, der bei der Informationsarchitektur berücksichtigt werden muss. Die Ziele und ggf. die Geschäftsprozesse des Webseitenbetreibers wollen ebenso abgebildet werden. Dazu kommen Usability-Überlegungen und in vielen Fällen die Conversion-Optimierung. Gibt es bereits Wünsche oder Vorgaben für das Design der Webseite, so spielen auch diese eine Rolle, besonders im Hinblick auf Navigationselemente.

Meiner Erfahrung nach ist es sinnvoll, erst einmal die Anforderungen aller beteiligten Disziplinen zu sammeln. Beginnen wir mit dem SEO-Part. Suchmaschinen mögen am liebsten monothematische Inhaltsseiten, bei denen der Bewertungsalgorithmus einer Suchmaschine klar »erkennen« kann, um welches Thema sich die Seite dreht. Das bedeutet: Eine einzelne Inhaltsseite sollte im Idealfall nur auf ein Keyword bzw. eine Keyword-Kombination hin optimiert werden. In der Praxis ist allerdings oft auch die Optimierung auf mehrere, thematisch verwandte Keywords möglich. Mehr als drei Keywords pro Seite sollten es dennoch nicht sein. Unter Berücksichtigung dieser Faustregeln ist es nicht schwer, aus der finalen Keyword-Auswahl eine Liste der (aus SEO-Sicht) benötigten Inhaltsseiten zu erstellen.

Als nächstes kommt die interne Sicht des Kunden bzw. Webseitenbetreibers an die Reihe. Die Vorgehensweise ist hier sehr unterschiedlich. Denn manche Kunden haben nur eine vage Ahnung von den aus ihrer Sicht notwendigen Inhalten ihres Internetauftritts. Andere Kunden dagegen haben eine sehr genaue Vorstellung von der Art und Strukturierung ihrer Inhalte und kommen bereits mit detailliert ausgearbeiteten Sitemap-Vorschlägen in eine Besprechung zur Webseitenstruktur. Eine Sitemap, die die Anforderungen und Wünsche des Kunden bzw. Webseitenbetreibers widerspiegelt, sollte das Ziel dieses Projektschritts sein. Für die weitere Bearbeitung ist die Erstellung der Sitemap mit einer Mindmap-Software am praktischsten.

Nun kommt der spannende Teil. Es ist in den meisten Fällen ein langsames Vortasten und Ausprobieren: Welche aus SEO-Sicht notwendige Inhaltsseiten sind in der Sitemap bereits enthalten oder müssen noch hinzugefügt werden? Lassen sie sich integrieren oder wäre aus SEO-Sicht ein anderer struktureller Aufbau sinnvoller? Finden in diesem Struktur-Gegenvorschlag noch immer alle Inhalte aus der ursprünglichen Sitemap ein geeignetes Plätzchen? Was ist mit herausragenden Seiten, wie der Startseite? Sie sollten auf keinen Fall »unoptimiert« bleiben und damit Potenzial verschenken.

Ob ihr während dieses ganzen Ausprobierens und Hin- und Herschiebens auch gleich Usability- und Design-Aspekte im Hinterkopf haben wollt, bleibt euch überlassen. Ich blende diesen Teil der Informationsarchitektur zu diesem Zeitpunkt bewusst aus. Zunächst möchte ich zu einer Sitemap gelangen, die eine sinnvolle Struktur widergibt und bei der hinter den meisten Seiten Keywords für die spätere Optimierung vermerkt sind. Danach wird erarbeitet, wie sich dieses Konstrukt in eine angenehm bedienbare Webseite überführen lässt.

Schritt 3: Technische Optimierung

An dieser Stelle gehe ich nur auf einige Punkte der technischen Suchmaschinenoptimierung ein, die in engem Zusammenhang mit der Informationsarchitektur stehen. Viele weitere Anregungen findet ihr in Moritz Gießmanns Artikel »On-Site-Suchmaschinenoptimierung« sowie im bereits erwähnten E-Book »Grundlagen der Suchmaschinenoptimierung« von Thomas Promny.

Besondere Aufmerksamkeit sollte bei der technischen Suchmaschinenoptimierung der JavaScript-Verwendung geschenkt werden. Bis vor kurzem konnten Suchmaschinen-Crawler mit JavaScript nicht viel anfangen. Inhalte, vor allem natürlich Texte und Links, die nicht direkt im HTML-Quellcode standen, waren für Suchmaschinen praktisch unsichtbar. Erst vor kurzem konnte ich mitverfolgen, wie eine Internetagentur die frisch renovierte Agentur-Webseite dank exzessiver und alternativloser JavaScript-Spielereien nahezu komplett aus dem Google-Index befördert hat. Das soll jetzt anders werden: Am 10. November 2011 gab Google offiziell bekannt, ab jetzt AJAX-Requests auszuführen, um Internetseiten komplett darstellen zu können. Details und Best-Practice-Beispiele könnt ihr im deutschen Google Webmaster Central Blog nachlesen.

Neben der technischen Zugänglichkeit der Inhalte ist die interne Verlinkung der einzelnen Inhaltsseiten ein wichtiges Thema. Denn die internen Links sorgen einerseits dafür, dass Suchmaschinen-Crawler auch wirklich alle Inhaltsseiten finden. Andererseits gilt für interne Links dasselbe wie für Links von anderen Webseiten: Der Linktext sollte möglichst gut zur Zielseite passen, das heißt deren Keyword enthalten. Beispielsweise können nichtssagende Produktbezeichnungen in Navigationen oft recht einfach um solche Gattungsbegriffe oder erklärende Zusätze ergänzt werden, auf die die Zielseiten optimiert wurden. Positiver Nebeneffekt: Auch Nicht-Fachleute finden sich besser auf der Webseite zurecht.

Gerade bei umfangreichen Internetauftritten mit tiefen Navigationsstrukturen empfiehlt es sich, zusätzlich zur Hauptnavigation möglichst viele thematisch passende Querverweise einzufügen. Denn das erleichtert dem Suchmaschinen-Crawler die Arbeit beim Durchdringen der Struktur. Außerdem sorgt es für zusätzliche Keyword-relevante Verlinkung. Neben Links aus Fließtexten heraus sind Boxen mit »Verwandten Artikeln« sehr gut geeignet – in Blogs und Seiten mit vielen redaktionellen Inhalten auch Kategorie- und Tag-Seiten, denn sie werden häufig Keyword-relevant verlinkt. Wichtig ist dabei jedoch, dass solche Artikel-Auflistungen immer nur Teaser-Texte beinhalten. Die vollständigen Artikel gehören ausschließlich auf die Artikel-Einzelseiten. Denn Google mag keine doppelten Inhalte. Wenn von zehn Artikel-Teasern einer Kategorieseite nur jeder zweite das Kategorie-Keyword in der Überschrift oder im Teaser-Text enthält, ist die Seite so gut wie von selbst optimiert.

Schritt 4: Inhaltliche Optimierung

Diesen Punkt möchte ich nur kurz anschneiden, denn die redaktionelle Befüllung gehört nicht mehr zur Informationsarchitektur. Kurz gesagt: Bei der Optimierung der Inhalte geht es darum, die Keywords, für die eine Seite optimiert werden soll, an bestimmten Stellen unterzubringen.

Das Keyword einer Seite sollte im Seitentitel enthalten sein und je weiter vorne desto besser. Denn einem Keyword im Title-Element misst Google bei der Bewertung der Seite mehr Gewicht zu als einem Keyword, das im Fließtext steht. Gleiches gilt für Haupt- und Zwischenüberschriften, die natürlich korrekt mit h1 bis h6 ausgezeichnet sein müssen. Auch Keywords, die über strong oder em ausgezeichnet sind, zählen etwas mehr. Natürlich soll die Leserlichkeit nicht darunter leiden. In diesem Zusammenhang schadet es nicht, sich mit den auf Blickverläufen basierenden Gestaltungsempfehlungen für Werbebriefe vertraut zu machen. Im klassischen Direktmarketing gibt es nämlich umfangreiche Erfahrungen mit dem richtigen Maß an Hervorhebungen in einem Text. In den Texten einer Seite sollte das Keyword der Seite einige Male enthalten sein, am besten möglichst gleichmäßig über den Text verteilt. Nicht mehr so eng gesehen wird die Keyword-Dichte. Eine gute Faustregel ist immer drei bis fünf Prozent.

Mit ein wenig Fantasie lassen sich außerhalb des Hauptinhalts viele Stellen finden, an denen das Einfügen von Keywords nicht nur aus SEO-Sicht sinnvoll ist. Ein Beispiel: Nehmen wir an, ein Hersteller von Gartengeräten pflegt in seinem Internetauftritt für jeden Gerätetyp eine eigene Inhaltsseite. In der Seitenspalte gibt es eine Box mit den Kontaktinfos des jeweiligen Produktmanagers. Ist diese Kontaktinfo-Box nicht nur mit »Ihr Ansprechpartner« betitelt, sondern beispielsweise mit »Ihr Ansprechpartner für Rasenmäher«, ist die Seite ohne großen Aufwand um eine weitere Keyword-Erwähnung in einer Überschrift reicher. Solche Keyword-Einschübe lassen sich im Übrigen mithilfe von Zusatzfeldern im CMS-Backend und entsprechend gestalteten Templates recht gut automatisieren. Das nimmt Webseitenredakteuren ein wenig Arbeit ab. Webentwickler, die diese Technik einsetzen, müssen lediglich darauf achten, dass die automatisch eingefügten Keyword-Nennungen so umgesetzt sind, dass sie auf der Seite nicht unnatürlich oder störend wirken.

Zum Autor

Michael van Laar arbeitet als Online-Kommunikationsberater und Webentwickler bei talkabout communications in München. Wenn er sich nicht gerade über WordPress und TYPO3 ärgert oder über MODX freut, ist er Ab-und-zu-Blogger und Gelegenheitsmusiker.

Suchmaschinenoptimierer erhalten immer wieder Anfragen, die in etwa so lauten: »Wir haben vor kurzem unseren Internetauftritt neu machen lassen. Jetzt möchten wir auch bei Google gut gefunden werden.« Wenn ich mich bei einer solchen Anfrage ein wenig genauer über den bisherigen Projektverlauf erkundige, bestätigt sich meistens mein Verdacht, dass etwas grundlegend schief gegangen ist.

Wenn Agenturen Suchmaschinenoptimierung (SEO) als integralen Bestandteil des Projekts einbeziehen, ist nicht nur der Kunde glücklicher. Auch der beteiligte Webworker oder die Agentur können daran mehr verdienen – anstatt einen Teil des Kuchens einem SEO-Dienstleister zu überlassen. Zudem muss der Kunde in der Summe sehr wahrscheinlich weniger bezahlen, weil bestimmte Arbeiten nicht unnötigerweise doppelt anfallen. Deswegen lohnt es sich für Webworker, diejenigen SEO-Basics zu kennen, die Einfluss auf grundlegende Webseiten-Aspekte wie die Informationsarchitektur haben.

Vereinfacht dargestellt besteht SEO aus drei Bereichen, die jeweils aufeinander aufbauen:

1. Auswahl der »richtigen« Suchbegriffe für die Optimierung
2. Inhaltliche und technische Optimierung des Internetauftritts selbst (On-Page-Optimierung)
3. Dafür Sorge tragen, dass die Webseite ausreichend oft und gut im Web verlinkt ist (Off-Page-Optimierung bzw. Linkaufbau)

Zwar sind Quantität und Qualität der Links das wesentliche Kriterium für die Position in den Suchergebnisseiten. Doch die ersten beiden Punkte sind nicht weniger wichtig. Denn sie sind die notwendige Basis, ohne die es in der Regel nicht sinnvoll ist, Geld und/oder Zeit in den Linkaufbau zu investieren. Mehr über die verschiedenen Einflussfaktoren auf das Suchmaschinen-Ranking findet ihr in Jens Meierts Artikel »SEO kompakt« oder in Thomas Promnys E-Book »Grundlagen der Suchmaschinenoptimierung«.

In vier Schritten zum suchmaschinenoptimierten Internetauftritt

On-Page-Optimierung ist eng mit der inhaltlichen und technischen Struktur einer Webseite verbunden. Daher ist die Entwurf- oder Relaunch-Phase der ideale Zeitpunkt, um sich Gedanken über On-Page-Optimierung zu machen. Das folgende Vorgehen hat sich bewährt:

1. Recherche, Bewertung und Auswahl der Suchbegriffe (Keywords)
2. Aufbau einer Inhalts-/Navigationsstruktur, die sowohl die Ziele des Webseitenbetreibers (= Innensicht) als auch SEO und Usability (= Außensicht) berücksichtigt
3. Technische Suchmaschinenoptimierung
4. Optimierung der Inhaltsseiten, meist im Zuge der ohnehin notwendigen Inhaltserstellung oder -überarbeitung

Den vierten Punkt werde ich in diesem Artikel allerdings nur kurz anschneiden. Denn es soll hier hauptsächlich um die Struktur des Internetauftritts geht und nicht um die redaktionelle Befüllung dieser Struktur.

Schritt 1: Keyword-Recherche

Selbst die handwerklich beste Suchmaschinenoptimierung bleibt wirkungslos, wenn auf Suchbegriffe hin optimiert wird, die nur selten gesucht werden oder die nicht die gewünschte Zielgruppe auf die Webseite bringen. Deswegen geht es bei der Keyword-Recherche nicht nur um die Suche, sondern auch um die Bewertung von Suchbegriffen.

Relevante Keywords und Keyword-Kombinationen lassen sich einerseits durch klassische Methoden wie Brainstorming, Wettbewerbsbetrachtung oder Thesauren finden. Andererseits gibt es spezielle Hilfsmittel für keywordbasierte Online-Marketing-Formen. Das wohl bekannteste ist das Google Keyword-Tool. Weitere nützliche Hilfsmittel sind Google Trends, Google Insights for Search, das Long-Tail Keyword-Tool und der MetaGer-Web-Assoziator. Eine relativ schnelle und praktische Vorgehensweise für Webworker, um gemeinsam mit ihren Kunden eine sinnvolle Keyword-Liste zusammenzustellen, beschreibt Rishi Lakhani in »Building Bricks: Keyword Discovery Process for Small Businesses«.

Nach der Sammlung möglicher Suchbegriffe, müssen diese hinsichtlich des Verhältnisses von Optimierungsaufwand zu Erfolgschancen bewertet werden. Geeignete Bewertungskriterien für eine schnelle Analyse sind die Keyword-Relevanz für die Zielgruppe, das Suchvolumen und die Mitbewerberdichte. Vollzeit-Suchmaschinenoptimierer, die in umkämpften Keyword-Umfeldern arbeiten, beziehen zwar noch wesentlich mehr Kriterien in die Analyse ein. Für unsere Zwecke reichen diese drei Kriterien jedoch völlig aus.

Die Keyword-Relevanz für die Zielgruppe wird meistens der Webseitenbetreiber einschätzen können. Wer etwas mehr Aufwand nicht scheut, unterhält sich zudem mit einigen Repräsentanten der anvisierten Zielgruppe. Gerade Marketingmitarbeiter neigen nämlich erfahrungsgemäß dazu, das Vokabular ihrer Zielgruppe falsch einzuschätzen, weil sie durch die firmeneigenen Werbesprech-Kunstbegriffe ein wenig betriebsblind sind.

Eine sehr grobe, aber an dieser Stelle ausreichende Schätzung über die Suchhäufigkeit liefert das Google Keyword-Tool. Hier wählt ihr am besten nur die Keyword-Option »Exakt« aus (siehe Screenshot), damit sich die Angaben der Suchvolumina nur auf die exakten Suchanfragen und nicht auf ähnliche Begriffe beziehen. Für ausschließlich national agierende Unternehmen gibt die Spalte »Monatliche lokale Suchanfragen« Aufschluss über die monatliche Suchhäufigkeit im ausgewählten Land (siehe Screenshot).

Über die Mitbewerber-Dichte im SEO-Bereich gibt die normale Google-Suche Auskunft. Das Google Keyword-Tool hilft hier leider nicht weiter, weil sich dessen »Wettbewerb«-Spalte auf die bezahlte Suchmaschinenwerbung bezieht. Wer bei Google nach dem gewünschten Keyword (zu diesem Zweck am besten immer in Anführungszeichen eingeschlossen) sucht, kann direkt auf der Ergebnisseite die Anzahl der gefundenen Ergebnisse ablesen. Das ist die Konkurrenz im weiteren Sinne. Die direkte »SEO-Konkurrenz« lässt sich durch die Google-Suche nach intitle:"keyword" abschätzen. Hierbei werden nur Seiten berücksichtigt, deren Seitentitel das gewünschte Keyword enthält. Das lässt den Schluss zu, dass es auf diesen Seiten tatsächlich hauptsächlich um das gewünschte Thema geht, und das Keyword nicht nur beiläufig irgendwo im Text erwählt wird. Außerdem ist »Keyword im Seitentitel« das wichtigste On-Page-Optimierungskriterium.

Es empfiehlt sich, die gefundenen Bewertungskriterien für alle Keywords in einer Excel-Tabelle zusammenzufassen, um sie für die weitere Auswertung nach Belieben sortieren und für die Endauswahl kennzeichnen zu können. Ich füge häufig noch eine zusätzliche Spalte in diese Excel-Tabelle ein, in der ich einen »Eignungsindex« berechnen lasse. Dieser soll für jedes Keyword das Verhältnis von Chancen und Aufwand widergeben. Je höher der Index-Wert, desto geeigneter ist das Keyword – so lautet zumindest die Theorie. In der Praxis ist dieser Wert allerdings nur in Kombination mit den anderen Kriterien aussagekräftig, weil er die Keyword-Relevanz für die Zielgruppe nicht berücksichtigt. Wen es trotzdem interessiert, ich verwende zurzeit folgende Formel:

Wie umfangreich eine finale Keyword-Liste ausfallen muss, lässt sich pauschal nicht sagen. Im Idealfall gibt es für jedes Keyword eine eigene Inhaltsseite. Sind die personellen Ressourcen für die Inhaltserstellung knapp bemessen, ist es sinnvoll, sich für den Anfang auf eine kleine Auswahl der erfolgversprechendsten Keywords zu beschränken.

Morgen erfahrt ihr im zweiten Teil des Artikels, wie Keywords und Inhalte zusammenkommen und wie daraus eine suchmaschinenoptimierte Webseite wird.

Zum Autor

Michael van Laar arbeitet als Online-Kommunikationsberater und Webentwickler bei talkabout communications in München. Wenn er sich nicht gerade über WordPress und TYPO3 ärgert oder über MODX freut, ist er Ab-und-zu-Blogger und Gelegenheitsmusiker.

Ein Tool für alles. CodeKit erspart euch die Kommandozeile, diverse Webapps und einzelne Tools indem es alles, was ihr euch als Frontendentwickler wünscht, in einer Oberfläche versammelt. Und vielleicht sogar noch ein bisschen mehr.

Die Benutzung könnte einfacher nicht sein: Per Drag and Drop ein vorhandenes Webprojekt hinzufügen und schon kann es losgehen. CodeKit analysiert die Dateien und kann mit den folgenden Dateitypen umgehen und euch die Arbeit erleichtern:

• Sass (CSS Preprocessor)
• Less (CSS Preprocessor)
• Stylus (CSS Preprocessor)
• CoffeeScript (Javascript »Metasprache«)
• Javascript
• JPEG und PNG

Der einzige Wermutstropfen: CodeKit ist Mac Nutzern vorbehalten und wird es laut dem Entwickler auch bleiben.

Sass, LESS oder Stylus

Die drei unterstützten CSS Preprocessor haben eine unterschiedliche Herkunft und unterscheiden sich geringfügig in Syntax und Features (siehe auch unseren Zweiteiler über Sass und Compass). Doch sie haben die folgenden Gemeinsamkeiten, die euch »herkömmlichem« CSS gegenüber vor allem redundante Schreibarbeit abnehmen.

• Nutzung von Variablen, um CSS Eigenschaften zu speichern.
• Mixins – Erweiterte Variablen. Hierin lassen sich mehrere Deklarationen speichern.
• Möglichkeit der Verschachtelung von CSS-Regeln.
• Unterstützung einfacher Rechenoperationen.

Auch ohne sich mit dem Terminal und Ruby oder Node.js anfreunden zu müssen, könnt ihr jede dieser »dynamischen« CSS Erweiterungen einfach ausprobieren, indem ihr sie benutzt. CodeKit überwacht die Dateien und auf Wunsch wird daraus eine herkömmliche CSS-Datei generiert, sobald ihr speichert.

Der Einfluss auf die Kompilierung unterscheidet sich je nach gewähltem CSS Preprocessor. Die Option, CSS direkt bei der Erzeugung zu minifizieren (Whitespaces und Zeilenumbrüche entfernen) ist bei allen dreien gegeben.

Ebenfalls besteht unabhängig vom gewählten CSS-Dialekt die Möglichkeit, das generierte CSS direkt im Anschluss von Bless »verarbeiten« zu lassen. Damit könnt ihr automatisiert die Falle des »CSS Selector Limit« von 4095 Selektoren pro CSS Datei umgehen. Dieses Limit gilt »natürlich« nur für den Internet Explorer, dafür aber bis mindestens Version 9.

CoffeeScript

Auch CoffeeScript kann euch dabei helfen, weniger tippen zu müssen. Es handelt sich hierbei im Prinzip um eine alternative Javascript-Syntax, die zu »gewöhnlichem« Javascript kompiliert wird, welches wie gewohnt in eure Seiten eingebunden und im Browser ausgeführt wird. CoffeeScript verzichtet z.B. auf geschweifte Klammern und Semikolons und nutzt stattdessen Whitespaces und Einrückungen um Codeblöcke auseinanderzuhalten.

Genau wie bei den CSS-Erweiterungen verhält es sich mit CoffeeScript. Sobald ihr speichert, wird aus der CoffeeScript- eine Javascript-Datei erzeugt. Bei der Kompilierung gibt es nur eine Option: Ihr könnt darauf verzichten, um den eigentlichen Code eine sich selbstaufrufende anonyme Funktion zu legen. Hierbei handelt es sich um eine Javascript Best Practice, die dafür sorgt, dass der globale Scope nicht unnötig »missbraucht« wird. Denn Variablen und Funktionsdeklarationen aus dieser Funktion sind außerhalb des Gültigkeitsbereiches nicht erreichbar.

Ansonsten gleichen die Möglichkeiten zur »Weiterverarbeitung« denen von Javascript.

Javascript

Für Javascript könnt ihr wählen, was beim Speichern automatisch angestoßen werden soll.

1. Fehlerüberprüfung
2. Komprimierung
3. Zusammenführung

Fehlerüberprüfung

Zur Wahl stehen JSLint und JSHint. Beide könnt ihr in ihrer Fehlertoleranz konfigurieren. JSHint ist dabei weniger anstrengend. Es bietet zum Beispiel per Default die Option »jQuery« und validiert somit auch Aufrufe von jQuery-Methoden.

Eines dieser Tools zur Überprüfung von Syntaxfehlern zu nutzen, sollte zum Pflichtprogramm bei Benutzung von Javascript gehören. Denn es hilft z.B. auch Fehler zu vermeiden, die Chrome oder Firefox ignorieren, sich aber im Internet Explorer durchaus bemerkbar machen können.

Komprimierung

Mit UglifyJS bietet CodeKit einen modernen Javascript Kompressor, der Dateien ordentlich, schnell und sicher schrumpfen lässt. Die Kompressionsraten liegen zwischen »YUI Compressor« und dem »Google Closure Compiler«, dafür ist UglifyJS jedoch wesentlich schneller als letzterer.

Dateien zusammenführen

Um die Ladezeiten einer Webseite so gering wie möglich halten, solltet ihr neben den Dateigrößen auch die Anzahl der Anfragen an den Server so gering wie möglich halten. Dabei unterstützt euch CodeKit nicht nur bei CSS-Dateien, sondern auch bei Javascript.

Das funktioniert dadurch, dass es CodeKit ermöglicht, Javascript-Dateien ineinander zu importieren. Dadurch könnt ihr Javascript Dateien zusammenführen und dem Browser letztendlich nur eine einzige ausliefern. Beim Import könnt ihr festlegen, ob die zu importierende Datei am Anfang oder am Ende eingefügt wird. Importiert eine Datei mehrere andere, lässt sich per Drag und Drop die Reihenfolge beeinflussen. Das Importieren selber lässt sich ebenfalls per Drag und Drop, oder durch einen speziellen Kommentar innerhalb einer Javascript bzw. Coffeescript Datei initiieren.

Nun müsst ihr nur noch entscheiden, ob die Dateien beim Speichern nur zusammengeführt, oder zusätzlich noch komprimiert werden sollen.

Frameworks

Die Funktionalität der »Frameworks« geht noch einen Schritt weiter. Hierunter verbirgt sich die Möglichkeit, Dateien, die projektunabhängig genutzt werden, CodeKit einmalig als »Framework« bekannt zu machen. Ist dies geschehen, lassen sich die Dateien in jedem Projekt nutzen. Frameworks können LESS-, Sass-, Stylus-, Javascript- und Coffeescript-Dateien beinhalten.

Der Vorteil hiervon ist, dass ihr z.B für sämtliche Projekte nur noch einmal jQuery auf eurer Festplatte benötigt, welches ihr in eure Projekte importieren könnt. Frameworks lassen sich auch wunderbar dafür nutzen, wiederverwertbaren Code zu erzeugen. Beispielsweise durch Erstellung eines eigenen CSS Boilerplates auf Basis von z.B. LESS.

Bilder komprimieren

Mit einem Klick lassen sich alle JPEG und PNG Bilder eines Projektes in CodeKit verlustfrei komprimieren. Hiermit könnt ihr bei PNGs je nach Bild bis zu 30% an Dateigröße einsparen (verglichen mit Photoshops »Für Web und Geräte speichern«).

Weitere Information zum Thema Website Performance findet ihr in den Website Performance Best Practices.

Auto-Reload

Auch das automatische Neu-Laden des Browsers, sobald sich eine Datei ändert, übernimmt CodeKit. In der aktuellen Beta-Version zunächst in Google Chrome und Safari.

CodeKit herunterladen

CodeKit befindet sich zurzeit in einer offenen Beta-Phase und läuft stabil. Die Beta-Version könnt ihr direkt auf der Website des Entwicklers herunterladen und bis zum 20. Dezember 2011 nutzen. Die finale Version wird voraussichtlich für etwa 10 Dollar in Apples App Store zu kaufen sein.

Zum Autor

Michael Kühnel ist seit Netscape 4.7.8 im Geschäft und freut sich, dass dank Webstandards seitdem alles immer besser wird. Er bezeichnet sich selbst als Nerd und macht inzwischen fast ausschliesslich Frontendprogrammierung. Ab und an verfasst er einen Tweet.

Nicht immer und nicht immer sofort wollen Anbieter oder Projektleiter einen ausführlichen Test der Barrierefreiheit beauftragen, geschweige denn selber durchführen. Manche wollen »erstmal sehen«, wo ihr Webangebot steht, ob sich ein ausführlicher Test auf Konformität mit den Web Content Accessibility Guidelines 2.0 (WCAG 2.0) »überhaupt lohnt« oder der beste nächste Schritt ist. Dabei geht es vor allem um die Frage nach dem ersten Eindruck. Gestellt wird sie in den unterschiedlichsten Situationen: am Telefon, auf Tagungen oder bei einem Erstgespräch. In diesen Situationen steht dem Ideal einer ausführlichen Analyse die mangelnde Zeit gegenüber. Und: Nicht immer ist es der Barrierefreiheitsprofi, der sich oder dem Fragesteller einen ersten Eindruck verschafft. Projektleiter, Anbieter und Entscheider benötigen einfache Werkzeuge und schnelle Tests, z.B. um mit dem Ergebnis der beauftragten Webagentur auf die Finger zu klopfen oder ein Projekt in die richtige barrierefreie Richtung zu lenken.

Nur: was sind sie, die wesentlichen Barrieren? Wie »schnell« ist schnell und welche Barrieren können unter den oben skizzierten Rahmenbedingungen in kurzer Zeit und hauptsächlich mit Bordmitteln festgestellt werden?

Überlegungen

Eine Antwort auf die Frage nach »wesentlichen Barrieren« zu finden, hört sich zunächst leicht an. Tatsächlich hängt die Ermittlung »wesentlicher Barrieren« von unterschiedlichen Perspektiven ab. Während blinde Surfer fehlende Alternativtexte als wesentlich bezeichnen würden, sind diese für sehende Tastaturbenutzer weder eine wesentliche, noch überhaupt eine Barriere. Für beide Nutzergruppen gilt jedoch, dass eine fehlende Tastaturbedienbarkeit eine wesentliche Barriere ist; für unseren geplanten Schnelltest gilt: sie kann mit Bordmitteln geprüft werden. Damit hätten wir den ersten Prüfschritt identifiziert, dem wir aus rein pragmatischen und zudem leicht testbaren Erwägungen heraus noch den sichtbaren Fokus beifügen.

Natürlich ließe sich die Frage nach den »wesentlichen Barrieren« auch auf der Basis von Richtlinien und Verordnungen beantworten. So könnten auf Basis der WCAG 2.0 alle Erfolgskriterien der Konformitätsstufe A herangezogen und daraus ein Schnelltest gestrickt werden. Bereits beim ersten Erfolgskriterium ergäben sich jedoch erste Probleme: Alternativtexte können meist weder gerade »mal eben« getestet, noch in einem direkten kurzen Gespräch schnell erklärt werden. Ihre Bewertung ist zudem abhängig von reichlich Know-how und Testpraxis. Eines jedoch geht schnell: Browser und Betriebssystem in den Kontrastmodus schicken und testen, ob Grafiken über CSS eingebunden sind. Solcherart eingebundene Grafiken verschwinden bei benutzerdefinierten Bildschirmeinstellungen. Handelt es sich um reine Layoutgrafiken ist das natürlich unproblematisch; bei informativen Grafiken dagegen entstehen für mehrere Nutzergruppen Probleme: Zwar können blinde Nutzer bei einem vorhandenen Text im title-Attribut den Sinn und Zweck der Grafik erfahren. Ist jemand jedoch mit eigenen Bildschirmeinstellungen im Web unterwegs, wird das Auffinden solcher Grafiken zur Glückssache und sehenden Tastaturbenutzern ist der Inhalt des title-Attributs ohne JavaScript nicht zugänglich. Damit hätten wir einen weiteren Prüfschritt identifiziert, der jedoch eine zumindest kurze Sichtung der Seite voraussetzt. Er eignet sich also nicht als zweiter Prüfschritt.

Soweit einige Überlegungen, die für diesen Schnelltest eine Rolle spielten. Weitere waren: Der Test sollte zumindest nach kurzer Übungsphase nicht länger als eine halbe Stunde dauern und die Bordmittel von Browser und Betriebssystem sollten, abgesehen von maximal einem kostenlosen und leicht installierbaren Prüftool, genügen. Natürlich stellte sich die Frage nach der Anzahl der Testschritte ebenso wie die Frage, ob und welche Kriterien verschiedener Konformitätsstufen zusammengelegt werden können?

Herausgekommen ist ein Test mit fünf plus einem optionalen Prüfschritten, der unter Windows mit Firefox und Internet Explorer, der Erweiterung HeadingsMap für Firefox und in ca. 30 Minuten durchgeführt werden kann. Natürlich sollen weder Ergebnis noch Test den Eindruck erwecken, dass schon alles getan sei. Der Schwerpunkt liegt zudem nicht auf das Abarbeiten einer Checkliste, wenngleich sich natürlich eine solche erstellen ließe.

Schnelltest V. 0.1

Sind die Browser geöffnet und die HeadingsMap installiert, dann öffnet die Startseite des zu testenden Webangebots sowohl im Internet Explorer als auch im Firefox. Zwischen beiden Browsern könnt ihr bequem mit der Tastenkombination Alt+Tab wechseln. Nach Aktivierung der HeadingsMap wechselt zunächst in den Internet Explorer. Dies mag ungewöhnlich sein, dient – so die Überlegung – jedoch dazu, dass bereits hier ein erster Eindruck gewonnen werden kann, denn die HeadingsMap zeigt sofort die Überschriftenstruktur der Seite an.

Schritt 1: Tastaturbedienbarkeit

Navigiert mit der Tabulatortaste durch die Seite. Entspricht die Tabreihenfolge der sichtbaren Anordnung der Inhalte? Wisst ihr beim Durchtabben durch einen Farbwechsel oder andere sichtbare Merkmale immer, wo ihr euch befindet? Falls Videos vorhanden sind: Könnt ihr diese mit der Tastatur ansteuern, bedienen (z.B. Starten und Stoppen) und verlassen? Wechselt in den Firefox und wiederholt diesen Schritt. Achtet dabei sowohl auf Links zur Kontaktseite sowie zur Suche bzw. erweiterten Suche und auf grafische Links. Diese werden in weiteren Schritten geprüft.

Schritt 2: LABEL-Elemente korrekt verwendet

Bleibt im Firefox und ruft – sofern vorhanden – die erweiterte Suche und/oder und ein Kontaktformular auf. Klickt auf die Beschriftungen von Eingabefeldern, Radiobuttons und Checkboxen. Springt der Fokus in das zugehörige Eingabefeld, werden Radiobuttons oder Checkboxen aktiviert? In diesem Fall sind die Beschriftungen korrekt mit den Formularelementen verknüpft und können von Screenreadern ausgewertet werden.

Schritt 3: Aussagekräftige Seitentitel

Bleibt im Firefox und schaut euch die/den Seitentitel der Formularseite/n an. Sind Angaben zum Webangebot sowie zur aufgerufenen Webseite enthalten? Ruft eine weitere Seite aus der Hauptnavigation heraus auf und vergleicht Seiteninhalt mit Seitentitel. Wisst ihr anhand des Seitentitels, worum es auf der Webseite geht?

Schritt 4: Überschriften

Schaut euch nun die Einträge in der HeadingsMap an. Sie enthält alle Überschriften, die mit dem H-Element ausgezeichnet sind. Sie können von Screenreadern ausgewertet und von blinden Nutzern über die H-Taste direkt angesprungen werden. Gleicht die Einträge in der HeadingsMap mit eurem visuellen Eindruck von der Webseite ab. Enthält die HeadingsMap alle Überschriften und Zwischenüberschriften und sind sie für sich gelesen aussagekräftig?

Wenn ihr an das Inhaltsverzeichnis eines Buches denkt: Ist die Gliederung des Dokuments logisch oder werden Ebenen übersprungen? Ist euch bereits bei den ersten drei Prüfschritten aufgefallen, dass Einträge rot hinterlegt sind? Diese Hinterlegungen kennzeichnen ausgelassene Ebenen, die zusätzlich an den Nummern der Einträge erkennbar sind.

Ruft die bisher besuchten Seiten auf, bis ihr euch wieder auf der Startseite befindet und gleicht jeweils die Seiteninhalte mit den Einträgen in der HeadingsMap ab.

Schritt 5: Informative Grafiken sichtbar

Durch die ersten vier Prüfschritte haben wir nun einen recht guten Eindruck von den bisher getesteten Seiten. Im ersten Schritt haben wir zudem bereits etwaige grafische Links identifiziert. Diese sind Thema des letzten Schrittes unseres Schnelltests. Dabei gilt: grafische Links sind immer informativ und benötigen ein alt-Attribut. Ist dieses vorhanden, dann ist die Grafik auch im Kontrastmodus immer sichtbar. Bevor ihr den Kontrastmodus mit linkeALT+linkeUMSCHALT+DRUCK aktiviert, wechselt in den Internet Explorer.

Sind grafische Links und andere informative Grafiken noch sichtbar (z.B. Logos, verlinkte Teaserbilder, als Schriftgrafiken ausgeführte Navigationseinträge)? Ist auch das Eingabefeld einer vorhandenen Suche sichtbar? Wechselt zu einer der im zweiten Schritt ausgewählten Formularseiten. Sind die Eingabefelder, Radiobuttons und Checkboxen sichtbar oder begegnet euch nur eine schwarze Fläche? Deaktiviert den Kontrastmodus mit der oben genannten Tastenkombination wieder.

Je nach Rahmenbedingung kann diesem Prüfschritt ein sechster folgen, der ebenfalls mit Bordmitteln getestet werden kann. Dieser eignet sich auch, wenn weder die Installation der HeadingsMap, noch die Installation eines Bookmarklets möglich ist. Selbstverständlich spricht nichts dagegen, im Anschluss Alternativtexte zu testen; die ersten Informationen wurden bereits im fünften Prüfschritt gewonnen. Seid ihr jedoch kein Barrierefreiheitsprofi und habt wenig Erfahrung mit der Bewertung von Alternativtexten, dann ist der folgende Schritt eine sinnvolle Ergänzung.

Optionaler Schritt 6: Bei Zoom auf 200% lesbar

Vergrößert die aufgerufene Seite mit dem Page Zoom auf 200%, indem ihr vier Mal die Tastenkombination Strg und + drückt oder die Zoomfunktion (unten rechts) verwendet.

Sind noch alle Texte leserlich oder werden einzelne Texte von anderen Inhalten überlagert? Schreibt einen kurzen Text in ein Eingabefeld. Könnt ihr diesen problemlos lesen oder wird er oben oder unten abgeschnitten? Achtet auch auf die Einträge in Haupt- und Unternavigationen. Ruft anschließend die Startseite auf und prüft, ob ihr auch hier alle Texte problemlos lesen könnt.

Dokumentation und Grenzen

Auf einer Tagung oder am Telefon wird die Vermittlung der Ergebnisse sicherlich während des Schnelltests, zumindest aber mündlich, erfolgen. Projektleiter sollten Probleme schriftlich dokumentieren, wobei je nach Übung und Qualität der Webseiten eine halbe Stunde möglicherweise nicht ausreicht. Eine Dokumentation sollte dabei so genau wie formuliert werden und in die Projektdokumentation integriert werden.

Nicht geeignet ist der Schnelltest für das Bezeugen einer Konformität nach WCAG 2.0 oder anderen Richtlinien bzw. Verordnungen. Das gilt sowohl für den Fall, dass keine Probleme gefunden werden als auch für den Fall, dass die mit diesem Schnelltest gefundenen Barrieren behoben werden.

Hinweis:Der vorgestellte Schnelltest kann frei verwendet und nach eigenen Bedürfnissen abgewandelt, jedoch nicht für kommerzielle Zwecke als Produkt oder spezielle Dienstleistung angeboten werden.

Die Autorin

Kerstin Probiesch ist freiberufliche Beraterin für barrierefreies Webdesign.Sie berät Unternehmen und Behörden und schult Programmierer und Webredakteure. Kerstin prüft als freie Accessibility-Spezialistin Webseiten auf WCAG 2.0-Konformität, schreibt Fachartikel und begleitet beratend die Entwicklung barrierefreier Webangebote von der Konzeptionsphase an.