Die wesentliche Aufgabe eines Editors und einer Entwicklungsumgebung (IDE) ist es, dem Entwickler Arbeit abzunehmen und Hilfestellung zu leisten. Das kann eine programminterne Validierung sein, das können programminterne Codeschnipsel sein. Textmate auf dem Mac ist dafür berühmt, dass es über Kurzschreibweisen in Zusammenarbeit mit der Tabulatortaste alle HTML-Elemente oder CSS-Eigenschaften und noch viel mehr zugänglich macht.

Dieses Grundprinzip macht der Russe Sergey Chikuyonok für andere Editoren nutzbar. ZenCoding nennt sich die kleine Skriptsammlung, die er über GoogleCode anbietet und die derzeit von Aptana, Coda, Espresso, editArea (online Editor), Visual Studio, TextMate, E-editor, TopStyle, Sublime, GEdit, Dreamweaver, UltraEdit, Web IDE und NetBeans in unterschiedlicher Intensität unterstützt werden. ZenCoding ist eine Mischung aus Snippets und Shortcuts, die das Coden nicht revolutionieren, aber schneller und bequemer machen.

Auf einen »Schlüssel« folgt eine Tastenkombination, die abhängig von Programm und Betriebssystem entweder Cmd+E oder Strg+E ist, aber auch individuell eingestellt werden kann. Für das einfache Erzeugen eines Absatzes ist ZenCoding zwar geeignet, aber nicht nötig. Wie sieht es aber aus, wenn ich eine Liste mit fünf Listenelementen erstellen will, die alle eine fortlaufende ID haben müssen (warum auch immer?). Für ZenCoding die gefundene Aufgabe. Die Schreibweise erinnert sehr an CSS:

ul#eineID.eineKlasse>li#test$*5

Nun einmal Cmd+E bzw. Strg+E drücken und es entsteht dieses Konstrukt:

<ul id="eineID" class="eineKlasse">
<li id="test1"></li>
<li id="test2"></li>
<li id="test3"></li>
<li id="test4"></li>
<li id="test5"></li>
</ul>

Mit html:xt wird ein grobes Template mit XHTML1-Transitional-Doctype erzeugt. Für andere Doctypes gibt es ähnliche Kürzel. Sehr hilfreich finde ich, neben der schnellen Erzeugung von Elementen mit Klassen und IDs, die Erstellung verschachtelter Konstrukte. Wenn ich mir eine Containerbox mit Headline und Absatz erzeugen möchte, kann ich folgendes schnell schreiben:

div.sidebox>h3+p+ul>li*5>a.external

Das Ergebnis sieht dann so aus:

<div class="sidebox">
<h3></h3>
<p></p>
<ul>
<li><a href="" class="external"></a></li>
<li><a href="" class="external"></a></li>
<li><a href="" class="external"></a></li>
<li><a href="" class="external"></a></li>
<li><a href="" class="external"></a></li>
</ul>
</div>

Neben HTML kann ZenCodíng auch CSS. So gibt es für alle Eigenschaften Abkürzungen. Meist sind diese aber selber so kurz, daß sich ein Auswendiglernen der Abkürzungen kaum lohnt. Trotzdem ist es nett, wenn aus einem bdt ein border-top:; wird. So richtig hilfreich sind aber Perlen wie op:ie, aus dem dann filter:progid:DXImageTransform.Microsoft.Alpha(Opacity=100); wird. Das beschleunigt die Codearbeit ungemein. Vorher sollte man sich aber intensiv mit der Materie beschäftigen und viel austesten. Durch die konstante Arbeit damit kommt man schnell auf den Geschmack.

Wer es einmal außerhalb seines Editors testen möchte, kann dies online tun. Das Projekt selber liegt bei Google Code. Viele dortige Erklärungen sind auf russisch. Eine prima Gelegenheit, um Google Translate auszutesten! Bei delicious habe ich ein paar empfehlenswerte Artikel zum Thema gesammelt, darunter ist auch der umfangreiche Überblick des Smashing Magazines.

Happy ZenCoding!

Über den Autor

Jens Grochtdreis ist freier Webentwickler und Berater. Er liebt leidenschaftlich das Medium Internet. Jens gründete die Webkrauts, um für ein besseres Medium zu streiten. Wenn er nicht gerade bloggt, twittert, surft oder codet, dann entspannt er sich bei Comics, Krimis, hört Blues oder kocht.

In letzter Zeit redigiere ich recht viele Texte. Es sind Fachartikel von Fachleuten, und niemand erwartet in diesem Zusammenhang eine blumige Reportage. Aber in vielen Texten schreibe ich immer wieder ähnliche Stellen um. Dabei ist es gar nicht so schwer, seine eigenen Texte einmal durchzusehen, um in dem einen oder anderen Satz am Stil oder der Zeichensetzung zu feilen.

Könnte man zwar, muss man aber nicht

Man kommt ziemlich viel herum. An jeder Ecke ist er zu finden. Aktuell zum Beispiel in Sätzen wie »Wenn ja, dann sollte man aus Afghanistan sofort abziehen« oder auch »50 Photoshop Pinsel, die man haben sollte«. Muss das sein?

Ich will nun nicht darauf hinaus, ganz auf das Wort »man« zu verzichten. Aber es nervt doch, wenn es im Text davon nur so wimmelt. An vielen Stellen ist es gar nicht so schwer, stattdessen einen passenderen Akteur einzusetzen, etwa »dann sollten wir aus Afghanistan sofort abziehen«, »Pinsel, die Webworker haben sollten« oder auch »Pinsel, die Sie haben sollten«. Irgendwer ist ja immer gemeint: Ich, du, Sie, Kunden, Webworker, Autoren, Designer usw.

Andere Akteure vermeiden jenen gesichtslosen »man« – und der Leser wird stärker angesprochen.

Verben, Verben, Verben

Ein beliebtes Mittel in der Politik ist der Nominalstil. Neue Gesetze und Berichte werden erst einmal mit einem Haufen Nomen vollgestopft, als ob Verben um jeden Preis vermieden werden müssten. So kommen Beamte auf schöne Titel wie »Entwurf eines Gesetzes zur Änderung des Gesetzes zur Errichtung eines Sondervermögens „Investitions- und Tilgungsfonds“«. In solchen Fällen ist es immer eine gute Idee, ein paar der Nomen durch Verben zu ersetzen. Nomen wirken sachlich, langweilig – Verben sind aktiver.

Also statt: »Die Umsetzung des Designs erfolgt in zwei Schritten« besser »Wir setzen das Design in zwei Schritten um«. Statt »Beim Start der Programmierung kümmern wir uns gleich schon um die Barrierefreiheit« besser: »Wir programmieren hier gleich barrierefrei und…«

Über all Leer zeichen

Ist irgendwer über die »Photoshop Pinsel« im Absatz oben gestolpert? Hierzulande muss es Photoshop-Pinsel heißen. Denn im Deutschen gibt es keine Leerzeichen in zusammengesetzten Wörtern. Insofern heißt es E-Mail-Adresse, Firefox-Erweiterung, HTML-Datei und aus einem eingedeutschten CMS wird ein Content-Management-System.

Weder das Gleiche noch dasselbe

Und zum Schluss: Es gibt Wörter, die zwar ähnlich klingen, aber unterschiedliches meinen. Gewöhnt und gewohnt ist so ein Fall. Anscheinend und scheinbar ist ein anderes Beispiel. Flüchten und fliehen. Wörter und Worte.

Es kann nicht schaden, ab und zu mal nachzuschlagen, ob der verwendete Begriff tatsächlich das bedeutet, was der Autor aussagen will.

Siehe auch

• Guter Stil, klare Sprache im Webwriting-Magazin
• Flogging a dead horse im Pisto-Magazin

Zum Autor

Nicolai Schwarz arbeitet unter dem Namen textformer mediendesign als selbstständiger Designer und Webentwickler in Dortmund. Vermutlich sorgt schon der Name dafür, dass er mehr auf Texte achtet als andere Leute. Wobei auch er sich immer freut, wenn jemand bessere Formulierungen für seine Texte finden.

»Gut gebrüllt, Löwe!« steht für: Das ist treffend formuliert. Auch wenn es oft ironisch verwendet wird.

Immer wieder tauchen in Mailinglisten und Foren Fragen zu Problemen auf, die sich bei einer mediengerechten Konzeption von Webseiten vermeiden ließen. Viele dieser Probleme sind jedoch von Webdesignern hausgemacht.

Da ein Projekt-Workflow nur selten ohne Kundenabsprache möglich ist, können wir nicht von Beginn an mit HTML-Prototypen arbeiten, sondern müssen neben der Strukturierung von Seitenbereichen und -inhalten, Verhaltensweisen und Schnittstellen im Web zusätzlich Kundenwünsche und Designvorgaben berücksichtigen. Mit detaillierten Wireframes und ausgearbeiteten Grafiklayouts sind Annäherungen möglich – diese Lösungen ergeben aber keine Website, bestenfalls können sie Einzelaspekte abbilden. Genau in dieser Phase entstehen die häufigsten Fehler.

Perfide ist das Phänomen »Webdesigner's Law« bekanntlich bei kleinen und wenig lukrativen Projekten: Eine Winzigkeit nicht bedacht, schon hat man hartnäckige Darstellungs- und Verhaltensfehler bei Mikroaufträgen für gute Bekannte oder dem kleinen Handwerker, die den Stundensatz in den Nanobereich fallen lassen. Medienspezifische Konzeption ist also auch bei kleinen Projekten notwendig.

In Kategorien des Webs denken

Ihr könnt Probleme vermeiden, auch ohne immer wieder auf die gleichen Layoutvorlagen zurückzugreifen. Stellt euch bei der Konzeption von Grafiklayouts folgende medienspezifische Fragen, die teilweise auch im Kundengespräch thematisiert werden sollten:

• Werden unterschiedliche Breiten von Browserfenstern unterstützt?
• Bleiben bei Seitenskalierung die Seitenbereiche nutzbar und Hintergrundgrafiken sichtbar?
• Gilt das auch für unterschiedliche Schriftgrößen?
• Sind die Kontraste für Menschen mit Sehbehinderungen oder mit alten Röhrenmonitoren ausreichend?
• Werden sowohl lange als auch kurze Texte mit zusätzlichen Inhalten Platz finden?
• Bietet die Navigation optisch Raum für Veränderungen und Erweiterungen?
• Kann ich alle formulierten Kundenwünsche angemessen mediengerecht umsetzen?
• Entspricht das Layout den zu erwartendem Umfang und der Art gelieferter Kundeninhalte?
• Welcher Kundenwunsch könnte das Layout in der Umsetzungsphase ernsthaft gefährden?
• Werden die Ladezeiten für große Grafiken angemessen bleiben?
• Wo könnten CSS Sprites sinnvoll sein?
• Eignet sich das Farbschema für Pseudoklassen und Standortbestimmung in der Navigation?

Soll z. B. der Menüpunkt »Kontakt« kurz vor dem Launch in »Ihr Weg zu uns« und »Ihre Nachricht« geändert werden, habt ihr bei einer horizontalen Navigation schnell ein Platzproblem. Ein weiterer Klassiker ist die Darstellung und Positionierung von Logo, Beschriftung und Hintergrundgrafiken in die Kopfzeile eines flexiblen/liquiden Layouts.

Praxistipp für Grafiklayouts

Browserfunktionen oder -erweiterungen stehen euch bei der Ausarbeitung eines Grafiklayouts nicht zur Verfügung. Wie sich flexible/liquide Layouts verhalten, könnt ihr zumindest mit zwei verschiedenen Fensterbreiten simulieren.

Flexibles Layout, demonstriert durch zwei Breiten

Legt in eurem Grafikprogramm bei kleiner Standardgröße alle Seitenbereiche und Textboxen in separate Ebenen an. Prüft anschließend in einer neuen Datei mit größeren Abmessungen, wie sich die Verschiebungen auf das Layout auswirken sollen. Damit erhalten auch Entwickler mit geringer Gestaltungsaffinität eine optische Hilfestellung für das Schreiben der CSS-Datei.

Zum Autor

Nils Pooker arbeitete selbstständig im Kunstbereich und ist seit 2001 freier Webdesigner. Als Fachbuchautor hält er Vorträge und schreibt regelmäßig über Kommunikation, Wahrnehmung, Webstandards und Webdesign.

Die Vorschläge des Webkit-Teams an das W3C zur Erweiterung des CSS3-Standards sind vielfältig. Kernstück sind CSS Transforms, CSS Transitions und CSS Animations. Alle drei Standards befassen sich umfassend mit der Animation von CSS-Eigenschaften. Im Folgenden stelle ich die grundlegenden Prinzipien vor, die zur Beispieldatei geführt haben.

Achtung! Dieser Artikel behandelt zukünftige Standards, die noch nicht in allen Browsern implementiert sind. Im Artikel benutzen wir die Notation, wie sie vorgeschlagen ist, in den Beispielen werden natürlich Vendor Prefixes genutzt. Das Beispiel funktioniert momentan nur in Webkit-Browsern, also Safari und Chrome.

Transformationen

Um Elemente auf der Fläche zu transformieren, gibt es einige neue Attribute; das wichtigste ist wohl das transform-Attribut, das als Werte so genannte Transformationsfunktionen haben kann. So können wir zum Beispiel beliebige Elemente skalieren oder rotieren.

transform:
  rotate(-3deg)
  scale(0.5);

Diese Transformation dreht das Element um -3 Grad und verkleinert es um die Hälfte.

Transitionen

Bei Transitionen wird nur definiert, in welcher Art sich CSS-Eigenschaften verändern sollen, wenn sie geändert werden. Dabei ist die Art der Änderung völlig egal, das kann per JavaScript direkt oder durch das zuweisen einer Klasse sein, per :hover/:focus-Pseudo-Klassen oder durch Veränderungen im Webinspektor. Die Transition interessiert sich dafür nicht.

Syntaxbeispiel: transition: width 1s linear;

Die Breite des Elements wird linear animiert, bis die Breite der Breite entspricht, die gerade durch CSS festgelegt wurde. Wird die Breite von 100 auf 200 gesetzt, wird das Element pro Millisekunde um einen Pixel breiter. Anstatt linearer Animation sind auch die Werte ease (Bis 25% der Animation langsamere Beschleunigung, ab 75% der Animation deutliches abbremsen), ease-in (Bis 42% der Animation beschleunigen), ease-out (Ab 58% der Animation abbremsen), ease-in-out (Bis 42% der Animation beschleunigend, ab 58% der Animation abbremsend) möglich, sowie die Festlegung einer eigenen Animationsart (Beschleunigung und Abbremszeitpunkt sind frei wählbar). Auch Transformierungen können so animiert werden:

a {
	transform: rotate(-3deg) scale (1);
	transition: transform 1.5s linear;
}

a:focus, a:hover, a:active {
	transform: rotate(363deg) scale (1.5);
}

Beim Überfahren mit der Maus dreht sich der Link einmal um die eigene Achse und ist statt nach links nach rechts geneigt. Außerdem wird er 1.5 mal so groß (Im Beispiel anschauen).

Animationen

Die Möglichkeit, Transitionen zu verketten und hintereinander abzurufen, bieten CSS-Animationen. Man beschreibt inwiefern die Animation angewendet werden soll:

div {
	position:absolute;
	top:10px; left:10px;
	width:50px; height:50px;
	background-color:red;
	animation-name: meine-animation;
	animation-duration: 20s;
	animation-iteration-count: infinite;
}

Auf das div wird die Animation meine-animation angewendet, die an anderer Stelle beschrieben ist. Die Animation soll 20 Sekunden dauern und unendlich oft wiederholt werden.

@keyframes meine-animation {
	from { top:10px; left:10px; }
	25% { top:100px; left:100px; }
	50% { top:10px; left:200px; }
	75% { top:100px; left:300px; }
	to { top:10px; left:400px; }
}

Diese Animation lässt das rote Quadrat über die Seite wandern, am Ende verschwindet das Quadrat und springt wieder an den Anfang. Wird animation-direction:alternate spezifiziert, wandert das Quadrat auf dem gleichen Weg zurück. from und to sind dabei Ausgangs- bzw. Endwerte, die Prozentangaben beziehen sich auf die Zeit in der gesamten Animationsdauer, die ja direkt beim anzusprechenden Element angegeben ist. Im Beispiel werden Animationen benutzt um Schneeflocken aus Asterisken (aka Sternchen) zu animieren.

Seiten, die bereits Transitionen oder Animationen nutzen:

• For A Beautiful Web
• Tim Van Damme
• Analog

Über den Autor

Eric Eggert ist freier Webentwickler. Dabei spezialisiert er sich auf sehr gut nutzbare User Interfaces und barrierefreie, standardkonforme Webseiten. Er gibt sich nicht mit dem Status Quo in den Browsern zufrieden sondern erforscht deren Grenzen und reizt ihre Fähigkeiten aus.

Formulare sind neben Links wohl diejenigen Konstrukte, mit denen wir es beim täglichen Surfen und Arbeiten im Web am häufigsten zu tun haben. Und doch passieren hier bei der Entwicklung viele Fehler. Diese führen dann zu einer eingeschränkten Barrierefreiheit oder anderen Problemen bei der Validierung oder Projektübergabe. Dieser Artikel soll helfen, häufige Fehler zu vermeiden und bietet als Bonus am Ende noch ein bisschen moderne Würze.

Das label-Element

Die meisten Formularfelder wie Textfelder, Aufklapplisten oder Kontrollkästchen benötigen eine Beschriftung, damit der Anwender weiß, was er in das jeweilige Feld eintragen oder auswählen muss oder was das Ankreuzen oder Abhaken des Kontrollkästchens bewirkt. In HTML gibt es viele Möglichkeiten, Texte visuell Formularfeldern zuzuordnen. Aber nur eine ist syntaktisch korrekt und führt zu einem positiven Abhaken bei einer Barrierefreiheits-Checkliste. Dies ist das label-Element. Dieses fasst den Text ein, der ein bestimmtes Eingabeelement (input, textarea, select usw.) beschreibt.

Weiterhin muss dieses label-Element das Attribut for enthalten, welches als Wert die ID des Eingabeelements bekommt, welches beschrieben wird. Ein häufiger Fehler hierbei ist, dass dem input-Element statt des id-Attributs das name-Attribut gegeben und dieses dann als Wert für das for-Attribut des label-Elements angegeben wird. Dies ist syntaktisch nicht korrekt.

Ein korrekt codiertes einfaches Adressformular hat diesen Quelltext:

<form action="post.php" method="post">
<fieldset><legend>Adressangaben</legend><br />
<label for="vollerName">Vor- und Zuname:</label><input id="vollerName" /><br />
<label for="strasse">Straße</label> <label for="hausnummer">und Hausnummer:</label><input id="strasse" /> <input id="hausnummer" /><br />
<label for="plz">PLZ:</label><input id="plz" maxlength="10" /> <label for="ort">Ort:</label><input id="ort" />
</fieldset>
</form>

Und so sieht's aus (noch ohne besonderes Styling).

• Die erste Zeile innerhalb des Fieldsets ist einfach: Es gibt ein Textfeld für den vollständigen Namen.
• In der zweiten Zeile wird die vollständige Bezeichnung der Zeile an den Anfang geschrieben, es wird jedoch explizit auf zwei Textfelder verwiesen, um genau zu definieren, dass in das erste die Straße und in das zweite nur die Hausnummer einzutragen sind.
• In der dritten zeile schließlich wird jedes label-Element wieder einem input-Element zugeordnet, und die Elemente wechseln sich ab, stehen lediglich nebeneinander.

Dieses Hörbeispiel (MP3-Datei) zeigt , wie das Formular von NVDA, Window-Eyes (beide Windows) und VoiceOver (Mac OS X) vorgelesen wird, wenn man mit Tab von Element zu Element springt.

Ein häufiger Fehler ist, dass die Beschreibungen für Straße und Hausnummer in einem Label stehen, welches dann nur dem ersten input-Element zugeordnet wird. Das zweite steht daneben, hat aber keine Bezeichnung. Benutzer von Bildschirmleseprogrammen hören dann für das erste Eingabefeld eine vollständige Bezeichnung und tragen fälschlicherweise sowohl Straße als auch Hausnummer in dieses erste Feld ein, nur um dann festzustellen, dass die Hausnummer eigentlich ins zweite Feld sollte. Im schlimmsten Fall wird ihnen das Fehlen der Hausnummer erst nach dem Abschicken des Formulars mitgeteilt.

Die obigen Richtlinien gelten analog für select- oder textarea-Elemente (z. B. bei durch Aufklapplisten realisierte Geburtstagsangaben).

Kennzeichnung erforderlicher Felder

Häufig kommt es vor, dass nicht alle Felder eines Formulares ausgefüllt werden müssen. Entweder kennzeichnet ihr also nun diejenigen Felder, die absolut erforderlich sind, indem ihr ein Wort wie "erforderlich", ein Sternchen "*" o. ä. der Beschriftung hinzufügt, oder ihr kennzeichnet diejenigen Felder, die nicht absolut erforderlich sind, mit dem Wort "optional". Gern wird auch für erforderliche Felder ein anderer Stil (z. B. eine andere Hintergrundfarbe) verwendet, dies funktioniert jedoch nicht für alle Benutzergruppen und sollte daher nur zusätzlich, nicht ausschließlich, verwendet werden.

In neueren Projekten findet man auch häufiger die Verwendung des WAI-ARIA-Attributes aria-required, das zusätzlich verwendet werden kann, um erforderliche Felder zu kennzeichnen. Es wird dem jeweiligen input-Element hinzugefügt, und sein Wert wird auf "true" gesetzt. Beispiel: <input id="vollerName" aria-required="true" />. Aktuelle Versionen von Bildschirmleseprogrammen, wie NVDA 2009.1 oder JAWS 10 und höher, werten dies aus, um von sich aus spezielle Hinweise auf die Erforderlichkeit eines solchen Eingabefeldes zu signalisieren.

Weiterführende Beschreibungen

Manchmal kommt es vor, dass eine Erklärung oder Ergänzung nicht in ein label-Element passt, sondern getrennt von diesem z. B. unterhalb des Eingabefeldes angegeben wird. Ausschließlich durch WAI-ARIA kann auch dieser Text dem input-Element zugewiesen werden und dann von Bildschirmleseprogrammen als zusätzliche Information automatisch gesprochen werden. Ihr geht dazu folgendermaßen vor:

1. Fasst den Text mit der weiterführenden Erklärung in ein Element ein, dem ihr eine ID über das id-Attribut gebt.
2. Dem eigentlichen input-Element fügt ihr das Attribut aria-describedby hinzu, welches als Wert die im obigen Schritt vergebene ID bekommt.

Hinweis: input-Element steht hier synonym auch für alle weiteren Formularfeldelemente.

Zum Autor

Marco Zehe arbeitet für die Mozilla Corporation in der Qualitätssicherung für Barrierefreiheit. Er verfügt über zehn Jahre Erfahrung im Bereich Bildschirmleseprogramme für Blinde und deren Umgang mit Webinhalten. Er ist selbst von Geburt an blind und nutzer solcher Zusatzprogramme.

Wer kennt es nicht, das heillose Durcheinander in der Sammlung von Screenshots, Bookmarks und Best-Practices, nur um sich von der Arbeit Anderer für das eigene Schaffen inspirieren zu lassen. Für Lesezeichen gibt es Social-Bookmarkdienste ala Delicious oder Mister-Wong. Bei der Sammlung an großartigem Webdesign gestaltet sich das Thema schon etwas schwieriger. Zwar gibt es CSS-Galerien und Showcases wie Sand am Meer, aber der eigenen Ordnung folgen diese zumeist nicht. Das Gesuchte ist oftmals die vielzitierte »Nadel im Heuhaufen«.

Abhilfe im kreativen Chaos könnte hier eine Kombination aus Littlesnapper und dem Dienst Ember schaffen.

Littlesnapper ist ein Programm, das unter Mac OSX die Verwaltung von Screenshots einzelner Seiten, oder nur Teilen dieser, erleichtert und durch viele Funktionen auch für die spätere Verwendung aufbereitet. Die wichtigsten Funktionen im Überblick: Die Bilder lassen sich komfortabel in der Seitenleiste mit Kommentaren, einem Stern-Bewertungs-System oder mit Hilfe von Schlagworten aufwerten und sortieren. Auch Ordner und Kollektionen zu speziellen Themen lassen sich einfach anlegen. Ganz von alleine erkennt Littlesnapper, ob es sich dabei um einen Screenshot des Desktops oder einer Webseite oder nur um ein Foto handelt. So lässt sich schnell z.B. eine Sammlung von Bildern zu Farbkombinationen oder zu »Registrierungsformularen« anlegen. Des Weiteren bietet Littlesnapper einen integrierten Browser, eine filterbare Suchfunktion sowie grundlegende Möglichkeiten der Bildbearbeitung. Hinzufügen lassen sich neue Elemente über die Menübar, wo eine Auswahl zwischen verschiedenen Screenshotfunktionen das »Capturen« erleichtert. Entgegen der Mac-eigenen Funktionen können in Littlesnapper ganze Seiten unabhängig von Scrollbalken im Browser gespeichert werden. Hat man seine Inspirationsquellen auf der eigenen Festplatte unter Kontrolle, ist es ein Leichtes, diese entweder bei Flickr oder bei Ember hochzuladen, um diese mit anderen zu teilen oder seinem Team zur Verfügung zu stellen.

Gerade Ember bietet einen interessanten Ansatz, um von überall auf die eigene Sammlung zugreifen zu können, auch wenn man gerade nicht am eigenen Rechner zu Gange ist. Ember ist im weitesten Sinne ein soziales Netzwerk rund um Bilder, Illustrationen und Screenshots, um zu inspirieren und sich inspirieren zu lassen. Anmelden können sich hier natürlich nicht nur Mac-Besitzer. Allerdings bietet Ember durch die Verbindung mit Littlesnapper ein paar Vorteile. So werden alle Daten zu einem Stück aus der Sammlung beim Upload übernommen und sind somit komplett online verfügbar. Ember bietet alle Funktionen, die ein Onlinedienst heute haben sollte. Die Vernetzung zu Freunden und Kollegen und deren Kollektionen steht dabei im Vordergrund. Zusätzlich zu der eigenen »Sammlung« bietet Ember eine hilfreiche Katalogisierung zu Teilbereichen wie z.B. »Sign Up Forms« , Blogs, Portfolios oder Logo-Design an, um das gesamte Netzwerk nur zu einem Bereich durchsuchen zu können. Der Dienst kann sowohl kostenfrei (mit monatlicher Uploadbeschränkung), als auch in einer Bezahlvariante genutzt werden. Mit dem dazugehörigen App kommen iPhone-Besitzer auch mobil auf ihre Kosten.

Welche Vorteile ergeben sich nun aus der Nutzung beider Tools? Erstens ist es sehr einfach möglich, aus der losen Sammlung eine Art Katalog für Best-Practices zu generieren, und zweitens diese dann Kollegen zur Verfügung zu stellen oder einfach nur von überall auf einen Inspirationspool zugreifen zu können.

Bereits bestehende Sammlungen auf Ember:

• Meine Sammlung
• Stefan Nitzsche
• Manuela Hoffmann
• Tim Van Damme
• Paul Boag

Autoreninfo

Fabian Tempel arbeitet als Frontend Developer bei Bild digital GmbH & Co. KG in Berlin. Er ist Fan des CSS-Frameworks YAML, Befürworter von Progressive Enhancement.

Eine Website muss natürlich auch bei abgeschalteten Bildern lesbar bleiben. Dies wird dann knifflig, wenn Schrift auf einem Bild steht und die Schriftfarbe dieselbe wie die Hintergrundfarbe ist. In den meisten Fällen können wir uns jedoch mit einem kleinen Trick behelfen.

Die Ausgangssituation

Nehmen wir als Beispiel einen Text, der in weißer Schrift auf einem Foto steht und dieses wiederum auf weißem Hintergrund.

Bild 1: normale Ansicht mit Bildern

Das Problem

Schauen wir uns dies nun ohne Bilder an, bleibt etwas übrig, das an die ostfriesische Nationalflagge erinnert, nämlich weiße Schrift auf weißem Grund. Von unserer liebevoll getexteten Bildunterschrift keine Spur. Lediglich der Alternativtext des Bildes ist zu sehen.

Bild 2: Ansicht ohne Bilder

Wir brauchen also eine Möglichkeit, die Hintergrundfarbe zu ändern, sobald keine Bilder angezeigt werden.

Die Lösung

Um die Hintergrundfarbe zu ändern, sobald wir die Bilder abschalten, erzeugen wir die Hintergrundfarbe einfach mit einem Bild. Wir bauen uns in diesem Fall also eine schneeweiße Hintergrundkachel. Wir setzen die eigentliche Hintergrundfarbe auf Schwarz und legen darüber unsere weiße Kachel.

background: url(kachel.gif) #000;

Schalten wir nun die Bilder ab, verschwindet auch die weiße Kachel, der schwarze Hintergrund wird sichtbar und unsere weiße Schrift ist darauf großartig lesbar!

Bild 3: Ansicht ohne Bilder mit schwarzem Hintergrund

Leider ist nun unser Alternativtext „Schafherde im Schnee“ nicht mehr zu sehen. Zum Glück können wir diesem jedoch auch eine Farbe zuweisen, in unserem Beispiel Weiß:

img { color: #fff; }

Das dürfen wir bedenkenlos tun, weil wir diesen Text sowieso nur bei abgeschalteten Bildern zu sehen bekommen. Das Ergebnis sieht dann so aus:

Bild 4: Ansicht ohne Bilder mit schwarzem Hintergrund und weißem Alternativtext

Da so viel Schwarz ziemlich trüb wirkt, können hier noch kreativ werden und stattdessen für unsere Schafe ein saftiges Grün wählen. Wir müssen dabei nur sicher stellen, dass der Kontrast zur Schriftfarbe noch ausreicht, z.B. mit der Juicy Studio Accessibility Toolbar.

Wer mag, kann sich am Alternativtext bei der Gelegenheit auch noch typografisch austoben, um die bilderlose Ansicht ein wenig aufzupeppen:

img { font: italic small-caps bold 2em/5 Georgia, serif; color: #fff; }

Nicht alle Angaben werden von allen Browsern interpretiert. Das macht aber nichts, da dies ja nur dazu dient, alles ein wenig hübscher zu machen. Im Firefox 3.5 schaut das fertige Beispiel so aus:

Bild 5: Ansicht ohne Bilder mit grünem Hintergrund

Wir merken uns: bei weißem Schaf auf weißem Grund: Schneedecke abtauen, Wiese sichtbar machen!

Viel Spaß beim Ausprobieren!

Über die Autorin

Sandra Kallmeyer alias ScreenOrigami ist in einem Netzwerk aus Freelancern und Agenturen die Spezialistin für standardkonforme Umsetzung von Webdesigns.

Es ist verblüffend, wieviele Angebote es im Internet gibt, die einem als Entwickler die Arbeit erleichtern. Flickr speichert Terabytes von Fotos und verkleinert diese automatisch in verschiedene handliche Formate. Flickr erkennt auch Personen in den Fotos, erlaubt es, Fotos geographisch zu platzieren und sogar online zu verändern. YouTube macht Ähnliches mit Videos; LinkedIn oder Xing erlauben seinen Lebenslauf im Netz zu pflegen, Delicious verwaltet Favoriten und so weiter und so fort.

Alle diese Arbeiten müssen wir nicht mehr von Hand erledigen, da alle diese Angebote uns mittels Application Programming Interfaces – oder kurz APIs – Zugriff auf unsere Daten erlauben. Eine API funktioniert, indem wir mittels Parametern bestimmte Daten anfordern und in verschiedenen Formaten zurück bekommen.

Das Problem dabei ist, dass jeder API-Anbieter eine andere Idee davon hat, was denn sinnvolle Parameter und Datenformate sind. Mehrere APIs in einem Produkt zu verwenden, wird damit zu einem Problem, da man sich mehr damit beschäftigt, Dokumentationen zu lesen als zu programmieren.

Ein einfacherer Zugang zu APIs

Was wir als Entwicker brauchen sind Bibliotheken und Systeme, die unsere Arbeit erleichtern. Bibliotheken wie jQuery und YUI machen Webdesign einfacher, da sie Browserprobleme und Fehler beheben und es uns erlauben, uns auf das Programmieren zu konzentrieren anstatt für den Browser zu arbeiten. Genau das gleiche Prinzip steckt hinter der Yahoo Query Language oder YQL. YQL erlaubt es einem, APIs und Daten im Netz in einer einfachen und einheitlichen Sprache zu erreichen und weiter zu verwenden. Die Syntax dieser Sprache ist ähnlich wie die Datenbanksprache SQL.

Select * from web (und gib mir nur zurück, was ich wirklich brauche)

YQL ist ein Web-Service der nur ein paar einfache Eingabeparameter erwartet:

• Eine Datenanfrage (query) die angibt, welche API man ansprechen will
• Das Ausgabeformat, was XML oder JSON (mit den Unterformaten JSON-P und JSON-P-X) sein kann und
• Den Namen einer Funktion, die aufgerufen werden soll, wenn die Daten geladen sind (nur für JSON-P oder JSON-P-X sinnvoll).

Am einfachsten ist es, YQL mal auszuprobieren. Eine Anfrage wie select * from flickr.photos.search where text="santa" geht zu Flickr und sucht nach Fotos mit dem Text »Santa«. Diese Anfrage an den Datenendpunkt von YQL geschickt und gibt uns die Daten der Fotos als XML.

Um die Arbeit mit YQL ganz einfach zu gestalten, gibt es eine Konsole. In diesem Interface kann man Beispielsanfragen sehen, alle Datenquellen abfragen und erfahren, welche Art von Daten erhältlich sind und komplexe Anfragen einfach zusammenklicken. In diesem Artikel will ich allerdings aufzeigen, dass die Konsole zwar praktisch ist, aber nicht unbedingt nötig. Wir können die gleichen Ergebnisse mit PHP erzielen.

Als Beispiel wollen wir eine kleine Seite erstellen, die alle möglichen Daten einer Person aus dem Netz holt und in einem Interface darstellt. Die Daten sind Fotos von Flickr, Videos von YouTube, Blogeinträge und Favoriten von Delicious.

Die Seite ist hier zu sehen, und der Quellcode ist auf GitHub erhältlich.

<?php
  /* YouTube RSS Ausgabe */
  $query = 'select description from rss(5) where url=" »
     http://gdata.youtube.com/feeds/base/users/ »
     chrisheilmann/uploads?alt=rss&v=2 »
     &orderby=published&client=ytapi-youtube-profile";';

  /* Flickr Suche nach user id */
  $query .= 'select farm,id,owner,secret,server,title from »
     flickr.photos.search where user_id="11414938@N00";';

  /* Delicious RSS Ausgabe */
  $query .= 'select title,link from rss where url=" »

http://feeds.delicious.com/v2/rss/codepo8?count=10";';

  /* Blog RSS Ausgabe */
  $query .= 'select title,link from rss where url=" »

http://feeds.feedburner.com/wait-till-i/gwZf"';

  /* Der Datenendpunkt von YQL mit JSON als Ausgabeformat */
  $root = 'http://query.yahooapis.com/v1/public/yql »
     ?format=json »
     &env=store%3A%2F%2Fdatatables.org%2Falltableswithkeys';

  /* Zusammenfügung der Anfrage */
  $query = "select * from query.multi where  »
     queries='".$query."'";
  $url = $root . '&q=' . urlencode($query);

  /*
    Eine Anfrage mittels cURL ist genau das gleiche wie die
    Daten in einem Browser einzugeben. cURL lädt die
    Daten und gibt sie zurück.
  */
  $ch = curl_init();
  curl_setopt($ch, CURLOPT_URL, $url);
  curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
  $output = curl_exec($ch);
  curl_close($ch);
  $data = json_decode($output);
  $results = $data->query->results->results;

  /* YouTube HTML */
  $youtube = '<ul id="youtube">';
  foreach($results[0]->item as $r){
    $cleanHTML = undoYouTubeMarkupCrimes($r->description);
    $youtube .= '<li>'.$cleanHTML.'</li>';
  }
  $youtube .= '</ul>';

  /* Flickr HTML */
  $flickr = '<ul id="flickr">';
  foreach($results[1]->photo as $r){
    $flickr .= '<li>'.
       '<a href="http://www.flickr.com/photos/codepo8/'.
       $r->id.'/">'.
       '<img src="http://farm' . $r->farm .
       '.static.flickr.com/' . $r->server . '/' .
       $r->id . '_' . $r->secret . '_s.jpg"
       alt="'.$r->title.'"></a></li>';
  }
  $flickr .= '</ul>';

  /* Delicious HTML */
  $delicious = '<ul id="delicious">';
  foreach($results[2]->item as $r){
    $delicious .= '<li><a href="'.$r->link.'">'.$r->title.'
       </a></li>';
  }
  $delicious .= '</ul>';

  /* Blog HTML */
  $blog = '<ul id="blog">';
  foreach($results[3]->item as $r){
    $blog .= '<li><a href="'.$r->link.'">'.$r->title.
       '</a></li>';
  }
  $blog .= '</ul>';

  /* Layout Tabellen in 2009? Echt, Google??? */
  function undoYouTubeMarkupCrimes($str){
    $cleaner = preg_replace('/555px/','100%',$str);
    $cleaner = preg_replace('/width="[^"]+"/','',$cleaner);
    $cleaner = preg_replace('/<tbody>/','<colgroup><col  »
       width="20%"><col width="50%"><col width="30%">  »
       </colgroup><tbody>',$cleaner);
    return $cleaner;
  }
?>

Ziemlich einfach, eigentlich. Alles, was wir hier machen, sind verschiedene YQL-Anfragen zu erstellen und mittels der query.multi-Tabelle als eine einzelne Anfrage an YQL zu schicken. Jede dieser Anfragen ist auch einzeln in YQL möglich. Die folgenden Links öffnen die einzelnen Anfragen in der YQL Konsole:

• YouTube
• Flickr
• Delicous
• Blog

Der Vorteil der query.multi-Anfrage ist, dass wir nur eine Datenanfrage an YQL schicken und der Rest der Anfragen an die verschiedenen Datenquellen erfolgt auf der YQL-Serverfarm. Da diese schneller im Netz unterwegs ist als unser Server, bedeutet das, dass unsere Seite schneller lädt und damit glücklichere Endnutzer hat.

Wir schicken unsere Anfrage an den YQL-Endpunkt und verwenden cURL, um die Daten zu laden. Einfach gesagt ist cURL ein Browser in PHP – wir können alles das, was wir im Browser laden, von einem Programm aus erledigen. Nach einer erfolgreichen Abfrage gibt uns cURL die Daten als JSON zurück und mittels json_decode können wir diese in ein PHP verständliches Format bringen.

Alles, was wir dann noch machen müssen, ist die Daten in ein sinnvolles HTML-Format zu bringen und in einem Template anzuzeigen. Fertig.

Mehrere Datenquellen vermischen und HTML als Datenquelle

Das erste Beispiel war relativ einfach, da die meiste Arbeit von uns in PHP erledigt wurde. Richtig interessant wird YQL allerdings, wenn wir in einer Anfrage mehrere APIs und Datenquellen vermischen. Als Beispiel werden wir nun die neuesten Nachrichten der BBC Webseite abrufen und aus den Titeln Schlüsselwörter erstellen. Dadurch kann man eine Liste von derzeit interessanten »Hot Topics« erstellen.

Um das zu erreichen brauchen wir zwei Datentabellen in YQL: Die HTML-Tabelle, die es erlaubt HTML von Seiten zu laden und per XPATH auf das Notwendigste zu reduzieren, und die Yahoo Term Extractor API (eine API die aus Texten Schlüsselwörter extrahiert). Um mehrere APIs in YQL zu verwenden, müssen wir den in() Befehl aufrufen:

select * from search.termextract where context in (
  select content from html where url="http://news.bbc.co.uk"  »
     and xpath="//table[@width=800]//a"
)

Hier kann man die Abfrage in der Konsole sehen und die Ergebnisse der Abfrage sind auch erhältlich. Auf Deutsch bedeutet die Anfrage:

1. Gehe nach http://news.bbc.co.uk und gib mir das HTML zurück
2. Konvertiere das HTML mit HTMLTidy um eventuelle Markup-Probleme zu beheben
3. Gib mir alle Links innerhalb der Tabelle mit einem width-Attribut und einem Wert von 800
4. Extrahiere den Textinhalt (content) der inviduellen Links und schicke den Textinhalt als context an die Yahoo Term Extractor API.

Wenn wir JSON-P als Ausgabeformat verlangen, können wir das Ergebnis der Anfrage direkt in JavaScript weiterverwenden (hier zu sehen und hier als Quellcode):

<ul id="hottopics"></ul>
<script type="text/javascript">
function hottopics(o){
  var res = o.query.results.Result,
      all = res.length,
      topics = {},
      out = [],
      html = '',
      i=0;
  /* create hash from topics to prevent repetition */
  for(i=0;i<all;i++){
    topics[res[i]] = res[i];
  };
  for(i in topics){
    out.push(i);
  };
  html = '<li>' + out.join('</li><li>') + '</li>';
  document.getElementById('hottopics').innerHTML = html;
};
</script>
<script type="text/javascript" src="  »
http://query.yahooapis.com/v1/public/yql?q=select  »
%20content%20from%20search.termextract%20where%20context  »
%20in%20(select%20content%20from%20html%20where%20url%3D  »
%22http%3A%2F%2Fnews.bbc.co.uk%22%20and%20xpath%3D%22%2F%2F  »
table%5B%40width%3D800%5D%2F%2Fa%22)&format=json&  »
callback=hottopics"></script>

Natürlich kann man JSON auch in PHP verwenden, was bedeutet, dass jeder Besucher die »Hot Topics« sehen kann und nicht nur die, die JavaScript verwenden können (Beispiel hier und Quellcode bei GitHub):

<ul id="hottopics"><li>
<?php
$url = 'http://query.yahooapis.com/v1/public/yql?q=select'.
       '%20content%20from%20search.termextract%20where'.
       '%20context%20in%20(select%20content%20from%20html'.
       '%20where%20url%3D%22http%3A%2F%2Fnews.bbc.co.uk%22'.
       '%20and%20xpath%3D%22%2F%2Ftable%5B%40width%3D800%5D'.
       '%2F%2Fa%22)&format=json';
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
$output = curl_exec($ch);
curl_close($ch);
$data = json_decode($output);
$topics = array_unique($data->query->results->Result);
echo join('</li><li>',$topics);
?>
</li></ul>

Zusammenfassung

Dieser Artikel kann aufgrund seiner Länge nur einen Bruchteil davon aufzeigen, was YQL einem Entwickler ermöglicht. Durch YQL kann man nicht nur APIs lesen, sondern auch schreiben. Wir können zum Beispiel Twitter updates verschicken, neue Artikel in WordPress Blogs einpflegen oder eine Webadresse mit bit.ly verkürzen. Mittels Open Tables können wir jeden Datenendpunkt im Netz zu YQL hinzufügen und JavaScript auf dem Server ausführen, was zum Beispiel sehr sinnvoll ist, um Flickr-Fotos als HTML zu erhalten oder HTML-Inhalte von Seiten zu lesen, die POST-Daten benötigen.

Das Web der Daten ist hier und YQL erlaubt es jedem teilzunehmen – nicht nur den Webservice-Experten.

Anmerkung der Redaktion

Dieser Artikel ist die deutsche Übersetzung von Christians Beitrag für die Seite 24ways. Dieser Adventskalender bietet noch viele weitere interessante Beiträge, alle in englischer Sprache.

Zum Autor:

Christian Heilmann arbeitet als Developer Evangelist bei Yahoo! in London, England. Er trägt überall auf der Welt auf Konferenzen vor, und bloggt unter andere darüber. Zuletzt veröffentlichte er sein Handbuch für Developer Evangelists.

Wenn ein Layout für eine Webseite mit Photoshop erstellt und vom Kunden abgenommen wurde, beginnt ein Arbeitsschritt, der es mitunter in sich haben kann – was man meist aber erst später festellt: Der Export der einzelnen Bestandteile.

Dafür wird das gesamte Bild erstmal in sog. Slices aufgeteilt, wobei diese jeden einzelnen Bestandteil, bzw. Region der späteren Seite darstellen. Diese Slices können sowohl Bilder, als auch Text beinhalten.
Ein Text kann direkt in das Textfeld des Slice-Optionen-Fensters eingeben werden.

An dieser Stelle behelfen wir uns mit einem kleinen Trick, um die Standardkonformität zu 100 Prozent zu gewährleisten und fügen ein Paragraph-Tag ein und schließen es am Ende wieder, da Photoshop nur DIVs als Container-Form kennt.

Slice Options

Bei den Slice-Optionen eines Bild-Slices ist eigentlich nur die Benennung wichtig: Voreingestellt ist ein Namensmix aus Dateiname des Layouts und der fortlaufenden Slice Nummerierung, die Photoshop von oben links nach unten rechts verteilt.

Schritt 2 ist dann der eigentliche Export aus Photoshop nach HTML und CSS: »Datei – für Web speichern«

Nachdem das Dateiformat der Bilder ausgewählt wurde (JPEG, GIF oder PNG), kommt der spannendste Teil des gesamten Prozederes: »Speichern«, Dateityp: »HTML und Bilder«

Wichtigster Bestandteil des nun erscheinenden Kontextmenus ist der Punkt »Einstellungen«.
Hier legt man die wichtigsten Eigenschaften der zukünftigen (Web-)Struktur fest, beginnend mit »Andere« im Auswahlmenü, falls man noch keine Einstellungen (»Eigene«) gespeichert hat.

Insgesamt befinden sich vier Optionen im Dropdown unter den Einstellungen:

Vier Optionen bei den Einstellungen

• »Datei speichern«: Dateibenennung festlegen und den Bildern einen Ordner wie »img«, »images« oder »Bilder« zuweisen.
• »HTML«: hier gibt es einige kleine aber feine Möglichkeiten den Output zu steuern, wie Code Einrückungen und die Wahl zwischen ISO 8859-1 und UTF-8, welches mittlerweile als Standard gelten dürfte.
• »Hintergrund«: Pfad zu einem HG Bild
• »Slices«: zwischen Tabellen und DIVs wählen. Hier fällt sicherlich die Wahl meist auch nicht so schwer…

Beim Slices Unterpunkt »CSS generieren« kann man wählen, ob IDs, Klassen oder Inline-Styles generiert werden sollen. Auch das ist keine große Frage: Ein globales Layout beschränkt sich ja meist nur auf die wesentlichen Bestandteile einer Site, also IDs.

An dieser Stelle findet sich leider der einzige Punkt, der spätere Nacharbeit erfordert, weil hier lediglich numerische Namensgebung wie »#1« usw. möglich ist.

Fertig und los.

Die Styles landen jetzt erstmal im Kopf des HTML Dokuments. Man braucht sie hier nur ausschneiden und in eine separate CSS-Datei kopieren, verlinken und fertig ist ein validierendes Webdokument.

Über den Autor

Maxx Hilberer arbeitet seit 2001 als Webdesigner; seit 2004 in eigener Regie für Agenturen und Endkunden. Bei seiner Arbeit belegen Standardkonformität und ein hohes Maß an Nutzbarkeit und Zugänglichkeit stets die vordersten Startpositionen auf den virtuellen Parcours des WWW.

Sprites sind eine CSS-Technik die bislang eher für Hovereffekte, in den letzten Jahren aber mehr und mehr zur Verkürzung der Ladezeiten einer Website genutzt werden. Sie reduzieren die Anzahl der benötigen HTTP-Requests, was wiederum der Performance der Seite zugute kommt. Anstelle von vielen verschiedenen Grafiken, die einzeln auf einer Seite eingebunden werden, kombiniert der Entwickler möglichst viele in einer Datei. Diese wird dann mit der CSS-Eigenschaft background-position an die gewünschte Position »verschoben«.

Zwei Beispiele

CSS-Sprite von Facebook

CSS-Sprite von Google

Warum verbessert das die Performance?

Nun, der Flaschenhals der Ladezeiten ist, dank der fast flächendeckenden Verbreitung von DSL-Anschlüssen, über die letzten Jahre weg von der Übertragungsgeschwindigkeit hin zu der Anzahl an HTTP-Requests gewechselt. Der Grund hierfür ist, dass bei jedem Request wertvolle Zeit für das Senden von Metadaten und die Latenzzeiten der Webserver verloren geht. Wenn wir nun die Gesamtanzahl der Request verringern, wobei die Grafiken meist einen Großteil davon ausmachen, verbessert sich auch die Performance.

Wie baue ich mein Sprite auf?

Natürlich ist es, gerade bei größeren Projekten, unsinnig alle verwendete Grafiken in eine Datei zusammen zufügen. Es gibt verschiedene Faktoren, welche Grafik überhaupt und in welcher Art von Sprite gesetzt werden sollte.

Wichtig ist, dass man sich darüber im Klaren ist, dass diese Grafiken auf allen Seiten geladen werden. Muss ein Icon, das auf einer Seite vorkommt, die nur von 2% aller Besucher ausgerufen wird, auch von den restlichen 98% geladen werden oder kann diese Seite einen zusätzlichen Request vertragen? Auch die Methode der Einbindung sollte beachtet werden. Wenn die Dimensionen des Elements, welches das Sprite in den Hintergrund erhalten soll, in Breite und Höhe begrenzt sind, können die einzelnen Grafiken neben und untereinander positioniert werden. Soll allerdings beispielsweise ein Icon an der linken, oberen Ecke einer Box erscheinen, muss das Sprite entsprechend Weißraum in horizontaler und vertikaler Richtung aufweisen. Ein rein vertikales oder horizontales Sprite ist in diesem Fall wohl der beste Weg. Hierbei ist auch noch die mögliche Änderung der Dimensionen zu beachten, bei flexiblen Layouts oder bei Schriftvergrößerung können sich Breiten und Höhenangaben auch nach dem Rendern einer Seite noch ändern.

Ausgehend von dem Ziel, eine möglichst kleine Datei zu erzeugen, empfiehlt sich außerdem die Sortierung nach Farben. Denn hier lässt sich die Dateigröße noch ein bisschen mehr reduzieren. Bei der Verwendung von PNG-8 oder GIF ist die Anzahl der unterschiedlichen Farben auf 256 beschränkt. Sobald die Anzahl unter den Maximalwert sinkt, verringert sich auch die Dateigröße. So ist es möglich, durch geschicktes Zusammenfügen ein Sprite ohne sichtbare Farbunterschiede auf fünfzig bis hundert Farben reduzieren.

Zum Autor

Tobias Otte arbeitet als Frontend Engineer bei der XING.com Neben seinem täglichen Kampf mit HTML/CSS und JavaScript interessiert er sich für Web Accessibility, Usability, Typografie und Webstandards.