Responsive Images
Optimiert für Groß und Klein
Responsive Webdesign macht seit geraumer Zeit die Runde. Während sich langsam Best Practices und sinnvolle Techniken etablieren, gibt es einen Bereich, der etwas kniffliger zu lösen ist: Die Rede ist von Responsive Images – reaktionsfähigen Bildern, für die an einer HTML-Erweiterung gearbeitet wird.
HTML-Nachschub für reaktionsfähige Bilder
Dieser Artikel ist zu großen Teilen ein Auszug aus dem Responsive-Webdesign-Buch, das im Oktober 2012 erschienen ist. Weitere Informationen zum Buch gibt’s auf rwd-buch.de
Bilder sind von Natur aus starre Objekte und so ist es nicht verwunderlich, dass sich im Zusammenhang mit Responsive Webdesign ein paar Probleme auftun.
Durch folgende Anweisung werden Bilder flexibel und passen sich der Größe ihres umgebenden Containers an.
- img {
- height: auto; /* Falls Dimensionsangaben im HTML vorhanden sind */
- max-width: 100%;
- }
Zwar hilft dieser einfache Trick, sie im Rahmen eines flexiblen Webdesigns gefügig zu machen. Während das browserübergreifend problemlos funktioniert, bleiben aber noch einige Probleme ungelöst:
- Datenmenge: Jedes Bild hat eine bestimmte Dateigröße, die auch bestehen bleibt, wenn der Browser ein Bild runterskaliert. Hier wäre es gut, je nach Bildschirmgröße passende Bilder ausliefern zu können.
- Datenrate: Im mobilen Kontext haben wir es oft mit geringer Bandbreite zu tun, der Downloadvorgang dauert entsprechend länger. Auch hier wäre es wünschenswert, bei schlechter Datenverbindung ein kleineres Bild (bezogen auf die Dateigröße) herunterladen zu können.
- Bildaussage: Wird ein Bildmotiv stark verkleinert, ist es möglicherweise nicht mehr wie gewünscht zu erkennen. Besser wäre es dann, je nach Bildschirmgröße ein Motiv mit passendem Bildausschnitt bereitstellen zu können.
- Retina Displays: Für hochauflösende Bildschirme, wie die Retina Displays von Apple, müssen Bilddaten mit entsprechend höherer Auslösung ausgeliefert werden.
Um diese Herausforderungen zu lösen, bedarf es mehrerer Schritte: Zum einen brauchen wir eine Technik, die die Bildschirmgröße auslesen (ähnlich wie Mediaqueries in CSS) und darauf abgestimmt ein anderes Bild laden kann. Ebenso benötigen wir eine Möglichkeit, die aktuelle Download-Geschwindigkeit auszulesen und daraufhin mit angepassten Bilddaten zu reagieren. Ist das Bildmotiv nicht für alle Bildschirmgrößen geeignet, müssen wir darüber hinaus noch in der Lage sein, »manuell« für die unterschiedlichen Bildschirmgrößen einen alternativen Bildpfad mit dem passenden Bildausschnitt im HTML zu hinterlegen.
Die Schwierigkeit dabei: HTML ist nicht dazu konzipiert worden, derartige Problemstellungen zu bewältigen. Bisher galt immer der Grundsatz, dass die Inhalte von Designentscheidungen getrennt sind und sich davon nicht beeinflussen lassen. Jeder Nutzer soll unabhängig von Layout oder Gerät auf die gleiche Inhaltsbasis zugreifen können. Zu allem Unglück sind moderne Browser auch so konstruiert, dass bei einem Seitenaufruf möglichst viele Dateien parallel heruntergeladen werden und Bilder als größte Datenblöcke einer Website dabei bevorzugt geladen werden. Weil das passiert, bevor wir mit irgendwelchen clientseitigen Scripten darauf reagieren können, ist es natürlich doppelt schwer, das Laden nicht benötigter Bilder zu verhindern.
Viele haben sich bisher daran gemacht, mithilfe von JavaScript und serverseitigen Scripten den oben genannten Herausforderungen zu begegnen. Allerdings mit der Einschränkung, dass immer nur Teilprobleme beseitigt werden. Mittlerweile ist dabei eine beachtliche Liste mit über 20 Vorschlägen zusammengekommen, die Chris Coyier und Christopher Schmitt in einem Google-Dokument gesammelt haben In einer Tabelle werden die verschiedenen Lösungen anhand markanter Eigenschaften vergleichend gegenüber gestellt. Recht bekannte und verbreitete Lösungen sind zum Beispiel Adaptive Images oder Responsive Enhance. Alle vorgestellten Methoden haben ihre eigenen Vor- und Nachteile, allen gemeinsam ist aber die Tatsache, dass es sich um Behelfsscripte handelt.
Viel schöner wäre es jedoch, wenn wir solche Scripte durch einen HTML-Standard ersetzen können. Dadurch könnten wir uns auf eine Sprache (HTML) beschränken und so die Dinge für uns Webworker vereinfachen.
Neues HTML braucht das Land
Einen lesenswerten Artikel von Anselm Hannemann, der den Hergang dieser Thematik beschreibt, findet ihr in Peter Kröners Blog. Ebenso hat er einen Vortrag auf der Fronteers gehalten mit entsprechenden Slides dazu. Eine ausführliche (englischsprachige) Beschreibung der zugrunde liegenden Problematik liefert Matt Wilcox.
Auf dem Weg zu einer möglichen HTML-Erweiterung für reaktionsfähige Bilder wurde im letzten Jahr heftig diskutiert, mit teils großer Verärgerung seitens der Entwicklergemeinde über die (zwischenzeitlich) getroffenen Entscheidungen.
Lassen wir hier aber die politischen Diskussionen außen vor und konzentrieren uns auf das Ergebnis. Was ist also dabei herum gekommen?
Das srcset-Attribut
Seitens der WHATWG, der initialen Arbeitsgruppe hinter HTML5, wurde folgender Vorschlag ins Rennen geschickt:
- <img alt="Bildbeschreibung" src="/path/to/fallbackimage.jpg"
- srcset="/path/to/image.jpg 800w 400h 1x, /path/to/high-res-image.jpg 2x">
Dabei wird das img
-Element um ein neues srcset
-Attribut ergänzt, das kommagetrennt weitere Bildquellen bereitstellt. Die Einheiten w, h stehen dabei für die Breite, Höhe des Bildschirms, für die die entsprechende Bildquelle geladen werden soll. Das x gibt den Faktor für die Auflösung an, 2x bedeutet also für Geräte mit doppelter Auflösung, z.B. Retina-Displays. Ältere Browser, die das srcset
-Attribut nicht verstehen, binden einfach das normale Bild aus dem src
ein. Das Gute an dieser Lösung ist die prägnante Schreibweise, die vor allem dann zum Tragen kommt, wenn viele Bilder auf einer Seite vorhanden sind.
Demgegenüber stehen aber auch einige Nachteile. So wird innerhalb des srcset
-Attributs eine komplett neue Mikrosyntax erschaffen, die nicht leicht zu verstehen ist. Ungeübte könnten auf den naheliegenden Gedanken kommen, dass sich die Werte 800w oder 400h auf die Bilddimensionen beziehen, wie wir es zum Beispiel von den width
- und height
-Attributen aus HTML kennen. Sie beziehen sich in diesem Fall stattdessen aber wie oben erwähnt auf die Bildschirmbreite bzw. Bildschirmhöhe in Pixeln. Ob es sich dabei aber um Mindest- oder Maximalwerte handelt, geht ebenso nicht aus der Schreibweise hervor. Verwirrung und Fehler sind also vorprogrammiert.
Das picture-Element
Die Responsive Images Community Group hingegen hat unter Mitwirkung einiger namhafter Webentwickler folgenden Vorschlag zutage gefördert:
- <picture alt="Bildbeschreibung">
- <source src="mobile.jpg" />
- <source src="medium.jpg" media="min-width: 600px" />
- <source src="fullsize.jpg" media="min-width: 900px" />
- <img src="mobile.jpg" /><!-- Fallback für ältere Browser -->
- </picture>
Dieser Vorschlag lehnt sich an die bekannte Syntax für Video- und Audioelemente an und ist daher für Neulinge leichter verständlich. Ebenso gewohnt wie selbsterklärend ist die Verwendung von Mediaqueries für die Abfrage der Bildschirmbreite. Darüber hinaus kann, anders als bei der srcset
-Methode zwischen Mindest- und Maximalbreite unterschieden werden.
Aber auch diese Methode hat Nachteile. Der benötigte Quellcode für ein einziges Bild ist schon gewaltig. Für mehrere Bilder kommt außerdem hinzu, dass der Mediatest bezüglich der Fensterbreite für jedes einzelne Bild durchgeführt wird.
Beide Methoden haben außerdem noch gemeinsame Nachteile. Sowohl srcset
als auch picture
haben den Test bezüglich der Bildschirmdimensionen im HTML integriert. Dadurch leidet die Performance, außerdem steigt der Pflegeaufwand, weil Mediatests sowohl im CSS als auch im HTML integriert sind. Außerdem können beide nicht auf langsame Netzwerkgeschwindigkeiten eingehen.
Quintessenz: eine gute Mischung
Florian Rivoal von Opera hat eine Mischung der beiden letztgenannten Methoden vorgeschlagen, die einige Vorteile bietet. Dieser Vorschlag sieht wie folgt aus:
- <picture alt="Bildbeschreibung">
- <source srcset="small.jpg 1x, small-highres.jpg 2x">
- <source media="(min-width: 18em)" srcset="med.jpg 1x, med-highres.jpg 2x">
- <source media="(min-width: 45em)" srcset="large.jpg 1x, large-highres.jpg 2x">
- <img src="small.jpg" alt="Description of image subject.">
- </picture>
Wir haben jetzt also einige Elemente beider Varianten kombiniert und uns fällt direkt auf, dass der Code leider noch umfangreicher geworden ist. Dafür haben wir aber auch mehr Möglichkeiten für eine verbesserte Bildausgabe: Im srcset
-Attribut wird nur noch ein Faktor 1x, 1.5x oder 2x an die Bildquellen geheftet, der für die richtige Bildausgabe je nach Bildschirmauflösung sorgt. Die Abfrage der Bildschirmdimension wird an das media
-Attribut geknüpft und kann so Minimal- und Maximalwerte aufnehmen. Als Fallback für weniger fähige Browser ist zudem das altbekannte img
-Element enthalten.
Dank eines JavaScript-Polyfill von Mathew Marquis auf Basis der Vorgängerversion von Scott Jehl können wir die gerade beschriebene Kombilösung bereits heute im Browser verwenden.
Damit haben wir auch den Nutzungsfall für veränderte Bildausschnitte eingeschlossen, den wir weiter oben erläutert haben. So kann gezielt für kleinere Bildschirme ein Hochformat angegeben werden, weil wir ja gezielt für einzelne Umbruchpunkte eine andere Bildquelle angeben können.
Mathew zeigt die Funktionsweise auf einer Beispielseite, die zum Vergleich anschließend auch das Original-PictureFill von Scott Jehl enthält. Den Unterschied stellt man fest, wenn man mit einem Retina-Display-Gerät die Seite ansteuert, dann wird das obere Bild durch die Highres-Version ersetzt, die im unteren picture
-Element fehlt.
Der aktuelle Stand
Sowohl das srcset
-Attribut als auch das picture
-Element wurden als Erweiterung in die HTML5-Spezifikation vom W3C aufgenommen. Damit ist schon mal ein großer Schritt getan, dass sie als offizieller Webstandard in künftige Browserversionen implementiert werden.
Um zu demonstrieren, wie die vorgeschlagenen Erweiterungen auch nativ im Browser funktionieren können, hat Yoav Weiss einen Chromium-Fork mit entsprechender Funktionserweiterung erstellt. Jetzt gilt es, die Browser-Hersteller von einer möglichst schnellen Einbindung zu überzeugen, damit wir schon bald die Vorteile der HTML-Erweiterung nutzen können.
Wenn ihr die aktuellen Geschehnisse rund um Responsive Images verfolgen möchtet, könnt ihr das auf der offiziellen Website tun.
Fazit
Es sieht gut aus für eine native HTML-Erweiterung für Responsive Images mit picture
-Element und srcset
-Attribut. Damit können wir fast alle der eingangs beschriebenen Herausforderungen abdecken. Was noch aussteht, ist eine verlässliche Methode zur Ermittlung der Netzwerkgeschwindigkeit, um anhand der zur Verfügung stehenden Datenrate ein geeignetes Bild auszugeben.
Bis das picture
-Element einsatzfähig ist, helfen uns eine Reihe von Scripten wie Adaptive Images oder Responsive Enhance, dem Problem Herr zu werden.
Die Geschichte rund um das picture
-Element zeigt vor allen Dingen, dass es möglich ist, aus der Webworker-Gemeinde heraus Einfluss auf die Weiterentwicklung der Webstandards zu nehmen und eben nicht alles in den Händen der Browser-Hersteller liegt.
Kommentare
Pepo
am 01.12.2012 - 10:32
Danke für deinen Artikel!!
rbq
am 01.12.2012 - 11:48
Eine Frage zum Verständnis: Ist mit "Bildschirm" in diesem Artikel durchgängig der Viewport gemeint? Das ist etwas irritierend.
Heinz Prange
am 01.12.2012 - 11:49
Besten Dank für den Beitrag.
Der Inhalt deiner vier Zeilen im letzten Absatz des Artikels sollte man – meiner Meinung nach – möglichst oft in Beiträgen zum heutigen Thema und verwandten Themen veröffentlichen oder zitieren.
stooni
am 01.12.2012 - 12:03
Auf den Punkt gebracht! Einfach und klar!
----stooni
Gunnar Bittersmann
am 01.12.2012 - 22:10
IMHO ist weder picture noch @srcset das, was man will. Man will ein Bild (welches in verschiedenen Varianten existiert) mit bestimmtem Inhalt verlinken. Bestimmter Inhalt im Web – ein bestimmter URI (für alle Varianten). Also
<img src="my-image" alt="my image"/>
.Dazu könnte dieselbe Technik genutzt werden, die seit Ewigkeiten zur Verfügung steht und für Inhalte in verschiedenen Sprachvarianten genutzt wird: Inhaltsvereinbarung (content negotiation). Dazu müsste im HTTP-Header ein Feld zur Angabe der bevorzugten Bildauflösung(en) eingeführt werden und deren Werte standardisert werden (analog zu den Sprachkürzeln). Dann würde MultiViews genügen und der Server könnte je nach Browseranfrage my-image.lores.jpg, my-image.midres.jpg bzw. my-image.hires.jpg ausliefern.
Vorteil: nur ein generischer URI für einen bestimmten Inhalt; einfaches Markup.
Als Gegenargument bekam ich sowohl von Michael Smith (W3C, HTML WG) als auch von Mathew Marquis und Bruce Lawson (Responsible Images CG) zu hören, dass Frontendentwickler keine serverseitigen Technologien wollen.
Hm, ich will.
Gunnar Bittersmann
am 01.12.2012 - 22:36
Auf die HTML WG des W3C vielleicht, aber auf die WHATWG? Die Geschichte rund um das picture-Element hat auch gezeigt, wie borniert die WHATWG ist, die sich in diesem Zusammenhang den Namen WTFWG verdient hat.
Die aktuelle Diskussion um das main-Element zeigt auch, dass es fast unmöglich ist, aus der Webworker-Gemeinde heraus Einfluss auf die Weiterentwicklung der Webstandards zu nehmen. „Im WHATWG-Prozess ist es so: Wenn Hixie klar und deutlich nein sagt, ist die Entscheidung klar.“ (Maciej Stachowiak)
Die WTFWG ist eine One-Man-Band mit einem schlechtem Frontmann.
Gunnar Bittersmann
am 14.12.2012 - 10:18
Es ist wieder Bewegung in die Diskussion ums main-Element gekommen. Tantek Çelik hat seine Meinung geändert. Fehlt nur noch Hixie.
Christoph Zillgens (Autor)
am 07.12.2012 - 10:58
So, erst mal sorry wegen der späten Rückmeldung, Krankheitsbedingter Ausfall …
@Pepo Gerne!
@rbq Ja, Bildschirmgröße bezieht sich genauer gesagt auf den Viewport, wie auch bei CSS-Mediaqueries. Das hätte ich genauer ausdrücken können.
@Gunnar Wenn ich mir den Code für ein Bild ansehe, gebe ich dir Recht, der Weisheit letzter Schluss ist das noch nicht.
@Gunnar Wenn Webautoren sich einig sind, bestimmte Dinge anzuwenden oder nicht anzuwenden kann auch die WHATWG nichts machen. Die Vorschläge der WHATWG sind kein Dogma. Dass der Webstandardsprozess kein Spaziergang ist, ist auch klar, aber unterm Strich gibt's keinen Grund, den Kopf in den Sand zu stecken :)
Die Kommentare sind geschlossen.