Möchte man, wie z. B. hier: „Chili con Carne“, ein freigestelltes Bild auf einen Fond setzen, muss man im Webdesign, wenn vorhandene Transparenzen erhalten bleiben sollen, zwingend das PNG-24-Format verwenden. Das hat zweierlei Nachteile: Ältere Browser wie der Internet Explorer 6 unterstützen dieses Dateiformat nicht oder nur mit Hacks – in der Regel vernachlässigbar. Der entscheidendere Nachteil aber ist die Dateigröße: PNG-24-Dateien sind, verglichen mit JPG-Dateien, riesig, was einerseits an der verlustfreien Kompression, andererseits am zusätzlichen Alpha-Kanal liegt.
Auf dem Desktop spielt die Dateigröße von Web-Bildern wegen der zunehmend schnellen DSL-Anbindungen nicht mehr eine so bestimmende Rolle wie vielleicht noch vor fünf Jahren. Ganz anders sieht es allerdings bei mobilen Endgeräten aus.
Glücklicherweise kann man mit sehr wenig Aufwand die Dateigröße von PNG-24-Dateien erheblich reduzieren. Diese Chilischote ist als 682×416 px PNG-24-Datei satte 152 KB groß:
Dateiformat: PNG-24, Dateigröße: 152 KB
Und so geht’s:
Man erstellt in Photoshop eine Einstellungsebene „Tontrennung“ und stellt die Anzahl der Stufen (in der Eigenschaftenpalette fälschlicherweise „Tonwertkorrektur“ genannt) so niedrig, dass Unterschiede zum Original gerade sichtbar werden:
Mit einer Tontrennung von 22 Stufen ist die gleiche PNG-24-Datei unter Beibehaltung aller Transparenzen nach dem Speichern nur noch 77 KB groß – eine Reduzierung um 50%!
Dateiformat: PNG-24, Tontrennung: 22 Stufen, Dateigröße: 77 KB
8
Was die Usability von Upload-Formularen ziemlich beeinträchtigt, sind die zwei Buttons, die man benötigt: Den Dateibrowser-Button und den Submit-Button. Ich erlebe es immer wieder, dass Menschen auf den „Hochladen“-Button klicken und sich wundern, dass nichts passiert. Wenn man das Upload-Formular auch noch mit HTML 5 Drag and Drop-Fähigkeit ausstattet, ist der Submit-Button, sofern noch keine Dateien ausgewählt sind, noch überflüssiger.
So sollte ein Upload-Formular idealerweise aussehen – solange keine Dateien ausgewählt sind, ist der Submit-Button unsichtbar:
Erst wenn man per Dateibrowser eine oder mehrere Dateien ausgewählt hat, erscheint der „Hochladen“-Button:
Und wie macht man das? Ganz einfach: Der Submit-Button kommt in ein Span-Element, das per CSS unsichtbar gemacht wird:
<span id='uploadButton' style='display:none;'><input type='submit' name='hochladen' value='Hochladen' /></span>
Beim Dateibrowser-Button wird das onChange-Event abgefragt. Wenn es aktiv wird, wenn also Dateien ausgewählt wurden, wird das Span-Element, das den Submit-Button beherbergt, sichtbar gemacht:
<input type="file" name="bilddatei[]" multiple="" onchange="document.getElementById('uploadButton').style.display='block'" />
6
Was ist das überhaupt?
Der erste Menüpunkt ist linksbündig, der letzte rechtsbündig und alle dazwischen sind gleichmäßig verteilt.
Und wie macht man das?
Ein einfaches text-align:justify hilft hier erst mal nicht weiter, da sich justify (also Blocksatz) immer nur auf mehrere Zeilen auswirkt, aber nie auf die letzte Zeile.
Deshalb muss man zusätzlich zu text-align:justify nach dem letzten Menüpunkt einen Zeilenumbruch erzwingen, damit die Menü-Zeile ausgeglichen wird. Das macht man mit einem überlangen „Wort“ aus Non-Breaking-Spaces, die man entweder per Alt-Leertaste oder per HTML-Entity erzeugt.
So sieht’s aus
Schauen Sie in den Quelltext des Beispiels, bei dem auch die Adresszeile im Footer ausgeglichen ist. Verändern Sie die Fensterbreite und/oder Textgröße, um den Blocksatz-Effekt zu sehen.
Safari
In Safari werden im Gegensatz zu IE, Firefox und Opera auch Non-Breaking-Spaces (z. B. zur Gliederung einer Telefonnummer) ausgeglichen. Nehmen Sie stattdessen En-Spaces.
10
Links: PocketSlider, rechts: Method & Craft
Es gibt manchmal ganz zufällige Übereinstimmungen oder gestalterische Ähnlichkeiten bei zwei ansonsten völlig unterschiedlichen Websites. Logisch: Die Menge der gestalterischen Möglichkeiten ist (gerade im Webdesign) nun mal begrenzt. Darüber hinaus wirken visuelle Einflüsse, denen man als Gestalter unterliegt, oftmals nur im Unbewussten, so dass es sich in der Regel gar nicht um absichtliche Plagiate handelt.
Im obigen Screenshot kann man gleichwohl nicht mehr von Zufall sprechen: Nicht nur Navigationselemente und Typografie sind annähernd gleich (wobei es mir links eher nach amateurhaft gestauchter Schrift als nach einem Condensed-Schnitt ausieht), die Icons gleichen sich sogar (bis auf eine winzige Ausnahme) aufs Pixel. Keine Ahnung, wer von wem abgekupfert hat – ich hätte da allerdings eine Vermutung.
Mein bevorzugter Texteditor ist BBEdit. Damit schreibe ich sämtliche HTML-, CSS-, PHP-, XML-, SQL- und Javascript-Dateien, die bei der Webentwicklung so anfallen. Eine der größten Stärken von BBEdit ist das Suchen und Ersetzen mit Hilfe von Grep, aka RegEx bzw. Regular Expressions. Ich will hier keine ausführliche Grep-Anleitung schreiben (davon gibt es im Web genug), sondern anhand einiger Beispiele den praktischen Nutzen zeigen.
Absätze
Nehmen wir an, Sie bekommen einen Wordtext, der für eine Website mit Absatz-Tags formatiert werden muss. Der normale Weg wäre, die Tags entweder per Hand einzufügen, oder aber einen Absatz zu markieren und in der HTML-Tools-Palette auf Paragraph zu klicken. Bei langen Texten beides ziemlich mühsam.
Aber es geht einfacher: Im Find & Replace-Dialog kreuzt man Use Grep an, trägt ins Search For-Feld ein
^(.*)$
ins Replace With-Feld <p>\\1</p>
klickt anschließend auf Replace All – et voilà: Alle Absätze sind von Paragraph-Tags umschlossen.
Textteile fetten
Zweites Beispiel: Sie bekommen eine lange Handelnde-Personen-Liste in dieser Form:
Maria Adorf, die hübsche Tochter des Dorfschmieds, die sich in den Sohn des Bürgemeisters verliebt hat
Karl Faltenmeyer, der schmucke Nebenerwerbslandwirt, der sich mit gelegentlichem Zigarrenschmuggel ein Zubrot verdient
Trine Brunnenkresse, die heimtückische etc.
Alle Namen am Zeilenanfang (vor dem ersten Komma) sollen mit Hilfe von Strong-Tags fett gesetzt werden. Mit Grep überhaupt kein Problem: Suchen Sie nach
^(.*?),
und lassen Sie es ersetzen durch <strong>\\1</strong>,
(Kurzerläuterung: Das Fragezeichen macht den Suchausdruck non greedy, ansonsten würde immer das letzte Komma der jeweiligen Zeile ausgewählt.) Mit einem simplen Tastenklick auf Replace All sind nun sämtliche Namen ohne den geringsten Aufwand fett gesetzt.
Die Grep-Suche beherrscht übrigens auch TextWrangler, der kostenlose kleine Bruder von BBEdit.
Wer mehr über dieses (für mich mittlerweile unverzichtbare) Tool erfahren möchte, sollte sich das BBEdit Grep Tutorial von Cari D. Burstein anschauen.
4
Es ist ja nicht so, dass ich nicht alles versucht hätte. Aber HTML5-Video ist momentan, was die Browserunterstützung angeht, noch so dermaßen unausgereift, dass zur Zeit eben noch kein Weg an Flash vorbeiführt. So bedauerlich ich das persönlich auch finden mag.
Flash ist für Web-Videos immer noch 1. Wahl
Warum? Nun, Safari 4 und Firefox 3.6 ignorieren die Eigenschaft preload="none", was dummerweise bedeutet, dass ein eingebetteter Film bei Seitenaufruf ohne weitere User-Interaktion sofort nachgeladen wird. Was ja bei einem Film auf einer Seite noch angehen mag, bei sechs oder sieben jedoch völlig inakzeptabel ist – Stichwort Bandbreite, unnötige Wartezeiten, Serverbelastung etc. Darüber hinaus gibt es in Safari erst ab Version 5 und QuickTime 10 die Möglichkeit, HTML5-Videos bildschirmfüllend zu vergrößern – eine Sache, die mit Flash problemlos funktioniert.
Deswegen ist auf Baulefilm auch nicht die bekannte Dive into HTML5-Methode implementiert (Kurzfassung: mp4 für Safari und Chrome, ogg für Firefox und Opera, Flash-Fallback für IE und den Rest), sondern die eingebetteten Videos werden ganz klassisch mit einem Flash-Player angezeigt. Und zwar ohne überdimensionierte Javascript-Frameworks oder Libraries, lediglich swfobjects.js 1.5 (7 KB) wird eingesetzt.
Wer die Videos nicht sehen kann, kommt mit Klick auf „Direktlink“ zu einer H.264-Version, die – je nach Browser/OS-Fähigkeiten – entweder direkt angezeigt oder heruntergeladen wird.
Und was ist mit iPad und iPhone?
iPad- und iPhone/iPod-User werden natürlich nicht ausgeschlossen, sie werden per Javascript auf eine Seite umgeleitet, auf der die Videos in einer H.264-Version angeboten werden. Dort wird dann per CSS3-Media-Query noch zwischen iPad und iPhone/iPod unterschieden: das iPad bekommt wegen des größeren Bildschirms höher aufgelöste Videos.
Natürlich ist diese Lösung – obwohl man sich die Erstellung einer ogg-Version für Firefox spart – aufwändiger als die oben erwähnte mp4/ogg/Flash-Fallback, weil ja zwei HTML-Seiten programmiert bzw. gepflegt und mehrere Auflösungen bereitgehalten werden müssen. Aber wie sagte man – jedenfalls so ähnlich – schon in den 1990ern so schön: „… und immer an die User denken!“
Hier noch mal alles zusammengefasst und mit Codebeispielen:
Videos ganz normal (oder mit dem oben erwähnten swfobjects) in die HTML-Datei einbetten, mit einem selbst programmierten oder einem Flash-Videoplayer seiner Wahl (z. B. JW Player oder Flowplayer).
In den Headerbereich der HTML-Datei folgendes Script einfügen, damit iPad/iPhone/iPod auf iPadPhone.html umgeleitet werden:
<script type="text/javascript">
if ((navigator.userAgent.indexOf('iPhone') != -1) || (navigator.userAgent.indexOf('iPod') != -1) || (navigator.userAgent.indexOf('iPad') != -1)) {
document.location = "/pfad/zu/iPadPhone.html";
}
</script>
In der zuständigen CSS-Datei die Klassen iPad und iPhone anlegen, iPhone verbergen:
.iPad {
display:block;
}
.iPhone {
display:none;
}
In der gleichen CSS-Datei per CSS3-Media-Query die (Un-)Sichtbarkeit der beiden eben angelegten Klassen für iPhone/iPod vertauschen:
@media only screen and (max-device-width: 480px) {
.iPad {
display:none;
}
.iPhone {
display:block;
}
}
Die Videos in iPadPhone.html mit HTML5 einbetten, dabei für die iPad und iPhone/iPod-Versionen entsprechende DIVs anlegen:
<div class="iPad">
<video poster="pfad/zu/meinfilm-poster.jpg" width="468" height="264" src="pfad/zu/meinfilm-iPad.mp4">
</div>
<div class="iPhone">
<video poster="pfad/zu/meinfilm-poster.jpg" width="100%" src="pfad/zu/meinfilm-iPhone.mp4">
</div>
Et voilà: Sämtliche Desktop/Laptop-User (mit installiertem Flash-Plugin, versteht sich) sehen die Filme über den Flash Player, iPad/iPhone/iPod-User sehen die für ihre Auflösung optimierten H.264-Versionen.
In meinen Augen zur Zeit die beste Lösung für Video im Web. Aber nächstes Jahr, wenn IE9 verbreitet ist und Mozilla.org endlich eine H.264-Lizenz für Firefox 5 erworben hat, sieht sicher alles wieder ganz anders aus.
5
