Was High-PPI-Bildschirme fürs Webdesign bedeuten

16. März 2012

Während die einen noch ihre Achseln zucken, bin ich der Meinung, dass gerade für uns Webdesigner, Frontend-Entwickler und CMS-Konfigurierer spannende Zeiten anbrechen: Die Zeiten der doppelt hinterlegten Bilder.

Beim iPhone 4 (und Smartphones mit vergleichbarer Auflösung) ist es noch nicht so sehr aufgefallen, weil man auf diesen Bildschirmen selten eine Website in 1:1-Darstellung angesehen hat, sondern meist wild rumzoomte. Und die grafische Opulenz von nichtzoombaren, Web-App-ähnlichen Layouts hielt sich in Grenzen.

Doch mit dem iPad der 3. Generation könnte der Startschuss gefallen sein für duale Bildquellen. Denn nun haben wir es Bildschirmen zu tun, die in der CSS-Pixeldimension bei gewohnten 1024×768px Breite liegen, wo aber jeder virtuelle CSS-Pixel aus 4 Gerätepixeln gebildet wird. Und das iPad wird sicher nicht das einzige »Vollbildschirm«-Gerät bleiben, welches in Kürze den Faktor 1:1 bei CSS vs. Gerätepixeln durchbricht.

Nun haben wir die Aufgabe, unsere bestehenden (und natürlich auch zukünftigen) Websites zu untersuchen, und in verschiedene Bestandteile zu sortieren:

1. Text, vom Browser gerendert

Hier muss man eigentlich nichts machen, weil das reguläre Textrendering immer die volle Gerätepixelauflösung einbezieht.

Doch wie Oliver Reichenstein richtig anmerkt, könnte ästhetisch etwas zu tun sein: Vormals bildschirmoptimierte Schriften wie Verdana, Arial oder Georgia sehen auf einmal noch klobiger und ungelenkiger aus. Denn Retina-Auflösungen verhalten sich nicht mehr wie Bildschirme, sondern sind eher mit Offset vergleichbar. Und da wirken »Offset-Schriften« mit mehr Würze und kleinen Details oftmals schöner.

2. Text, als Grafik hinterlegt

Die größte Katastrophe. Abgesehen davon, dass man diese Textersetzungstechnik sowieso seit Jahren nicht mehr empfiehlt: Es kommt vor. Und es gilt, hier schleunigst Abhilfe zu schaffen, denn auf High-PPI-Bildschirmen erwartet der Nutzer, dass zumindest Schrift immer knackig scharf ist. Wenn es irgendwie geht, sollte man hier auf nativ gerenderten Text umstellen. Webfonts machen es möglich!

3. Grafische Schmuckelemente und Icons

Hier sollte man versuchen, sooft wie möglich mit CSS3-Techniken zu agieren, denn diese nutzen natürlich die Geräteauflösung voll aus: Abgerundete Ecken, Randlinien, Schrägstellen von Elementen usw.

Bei komplexeren Formen und vor allem Icons sieht die Sache ein wenig anders aus. Hier kann es sich lohnen, eine Version mit doppelter Auflösung separat anzufertigen und für entsprechende Clients auszuliefern. Hier eine Anleitung für die entsprechenden CSS-Media-Queries. Nichts spricht übrigens dagegen, die High-DPI-Grafiken mit in das reguläre CSS-Sprite reinzunehmen. Ihr arbeitet ja alle brav mit Sprites!

Eine Alternative (vor allem) für Icons sind vektorbasierte Formen. Entweder als monochromer Webfont oder irgendwie mit SVG-Dateien. Wobei für Letzteres immer noch keine zufriedenstellenden Best-Pratices existieren. Oder?

4. Inhaltsbilder

Tja, was machen wir mit Bildern, die nicht per CSS als Schmuckelement, sondern als inhaltliches Element per <img> eingebunden werden? Hier wird es kniffelig, weil hier zum ersten Mal auch der Redakteur eines CMS ins Spiel kommt. Folgende Thesen:

  • Rein fotografische Motive mit einer gewissen Komplexität fallen nicht so sehr als minderbepixelt auf. Bei Ihnen wäre eine Vervierfachung der Pixel auch ganz schon heftig, was die Datenmenge betrifft.
  • sehr grafische oder gar typografische Darstellungen leiden dagegen extrem unter halber Auflösung. Zum Glück lassen sich diese Art von Motiven meist ganz gut komprimieren (vor allem als PNG8), so dass das Dateigewicht sich nicht so gravierend auswirkt.
  • Es wäre vom Workflow recht einfach, alle Bildmotive stur ausschließlich in hoher Auflösung anzulegen und über die width=""- und height=""-Attribute entsprechend in halber Größe ins Layout zu setzen. Die Datenmenge für Nicht-Retina-Nutzer wird dadurch aber unnötig groß.
  • Es ist vom Workflow her schwieriger, immer zwei Versionen des Bildes vorzuhalten, und dann per serverseitiger oder clientseitiger Abfrage die jeweilige Version auszuliefern. Hier wird noch ein bisschen geforscht und programmiert werden müssen. Ich denke vor allem an entpsprechende CMS-Plugins und/oder serverseitige On-Demand-Skalierungsskripte.

Noch gibt es kaum Patentlösungen, weil das Thema erst jetzt akut wird. Dennoch hier ein paar Artikel zum Weiterlesen. Ich bleibe dran, versprochen!