Dieter Petereit 7. Februar 2014

Responsive Images: Mit rwd.images.js machen oder auf den Standard warten?

Das leidige Thema "Responsive Images" ist noch lange nicht vom Tisch. Soll es nun das Picture-Element werden, wie das W3C es vorsieht, oder ist doch das Srcset-Attribut der WHATWG das Mittel der Wahl? Abseits jeglicher Streitereien um Standards muss die Design-Community schlichtweg das Problem lösen. Denn, ob die Gremien nun zur Verabschiedung gelangen oder nicht, responsive Bilder werden jetzt und nicht erst in ein paar Jahren benötigt. Das Mittel der Wahl ist naheliegenderweise JavaScript. Ein ganz frisches Script aus der Feder des Australiers Matt Stow hat das Potenzial zur besten, bisher verfügbaren, clientseitigen (Zwischen-)Lösung zu werden…

html5-logo

Die Problematik Responsive Images

Ich spare mir an dieser Stelle lange Abhandlungen zum Thema und beschränke mich auf das Wesentliche. Weiter unten sind auch ältere Beiträge aus dem Dr. Web Magazin zum nochmaligen Nachlesen verlinkt. Wer sich mit Responsive Images beschäftigt, sieht sich mit folgenden Problemen konfrontiert:

  • Es ist nicht sinnvoll, ein Bild, das für die Anzeige auf einem HiDPI-Display optimiert ist, auf die Größe einer wesentlich kleineren Auflösung runter zu skalieren. Umgekehrt ist es noch weniger sinnvoll. Ziel ist also, jede Zielauflösung mit einem dafür optimierten Bild zu bedienen.
  • Ebenfalls nicht bewährt hat sich die Verwendung extrem starker Kompressionsfaktoren, um wenigstens die Bandbreitenverwendung bei zu großen Bildern zu begrenzen.
  • Das IMG-Element wird von Browsern jeden Alters zuverlässig verarbeitet, dabei aber mit verschiedenen Maßnahmen je nach Browser vorbehandelt (Prefetching etc.). Bilder responsiv über das SRC-Attribut auszutauschen, ist von daher nicht konsistent und in jedem Falle zuverlässig möglich. Zumindest sorgt es für mehrfache Requests. Ältere Browser zeigen weitere Fehlverhalten. Die Vermeidung des SRC-Attributs wäre ein guter Weg, die Browser von Vorbehandlungstechniken abzuhandeln und multiple Requests zu vermeiden.
  • Häufig ist es nicht sinnvoll, auf kleineren Displays das gesamte Bild anzuzeigen. Mittels sog. "Art Direction" sollte man in der Lage sein, den Anzeigebereich des Bildes zu kontrollieren. So könnte man sich etwa vorstellen, dass ein Onlineshop für Hundenahrung in der großen Desktopvariante eine Hundefamilie zeigt, während die mobile Version lediglich den Kopf eines der Tiere darstellt. Das ist kein trivialer Task und das Hauptargument gegen Srcset, den Ansatz der WHATWG. Genau diesen Anwendungsbereich kann das Attribut nicht abdecken, Picture, der Vorschlag des W3C hingegen schon.

Mit JavaScript ist bekanntlich nahezu alles möglich. Die Zahl verfügbarer Scripte für Responsive Images ist entsprechend hoch. Kaum eines jedoch adressiert alle Problempunkte. Zudem bringt JavaScript als solches wieder einige eigene Probleme mit. Das größte dabei: Was passiert, wenn der Nutzer JavaScript abgeschaltet hat oder – wahrscheinlicher – JavaScript nicht funktioniert. Letzteres ist umso häufiger der Fall, je mehr Scripts, wohlmöglich noch aus unterschiedlichsten Quellen, eingebunden sind. Ein Script zur Behandlung von Responsive Images sollte daher stets eine Noscript-Lösung mitbringen.

rwd.images.js: Das Beste bis zur Verabschiedung des Picture-Elements?

Das erst seit wenigen Tagen auf Github verfügbare Script rwd.images.js des Australiers Matt Stow ist auf die Vermeidung aller genannten Problembereiche getrimmt. Im Einzelnen fängt Stow folgendes ab:

  • Das SRC-Attribut wird nicht dem Element mitgegeben, sondern in einem Data-Attribut versteckt. So vermeidet Stow Prefetching und andere Techniken, sowie multiple Requests.
  • Mittels Noscript kann ein Bild im Falle des Nichtfunktionierens von JavaScript gesetzt werden.
  • Art Direction, also die Veränderung von Bildfokus, Zoom und Ausschnitt, wird unterstützt.

Weitere Features bestehen etwa darin, dass Pixelwerte in ems umgerechnet werden können, HiDPI-Varianten bei Einhaltung einer Namenskonvention unterstützt werden und einiges mehr. So sieht das Script, das minifiziert und gezippt auf unter 1,7 kb kommt, im Einsatzbeispiel aus:




Über die Klasse rwdimage wird das Script auf das entsprechende Bild getriggert, alles andere wird über das Data-Attribut `data-rwdimage‘ und dessen Derivate geregelt. Sämtliche Anweisungen, die man ansonsten im Stylesheet machen würde, werden über das Data-Attribut übergeben.

Das ist im Grunde auch schon mein einziger Kritikpunkt, besonders mit Blick auf die Zukunft. Perspektivisch kommt eine ganze Menge Arbeit auf Designer zu, die jetzt intensiven Gebrauch von den Möglichkeiten des Scripts machen. Jegliche Änderung am CSS muss wieder inline erfolgen. Andererseits, wenn es letztlich das Picture-Element würde (oder eben doch Srcset) und man seine Projekte in den standardkonformen Zustand bringen will, muss man eh erneut ran.

Insofern darf rwd.images.js aktuell als eine der vollständigsten Lösungen für das Responsive-Images-Problem gelten. Nachdem es über keinerlei Abhängigkeiten verfügt, ist die Tauglichkeit schnell getestet und rückstandsfrei entfernt bei Nichtgefallen.

Links zum Beitrag

Dieter Petereit

Dieter Petereit

ist seit 1994 im Netz unterwegs, aber bereits seit über 30 Jahren in der IT daheim. Seit Anfang des neuen Jahrtausends schreibt er für diverse Medien, hauptsächlich zu den Themenfeldern Technik und Design. Man findet ihn auch auf Twitter und Google+.
Dr. Webs exklusiver Newsletter
Hinweise zum Datenschutz, also dem Einsatz von Double-Opt-In, der Protokollierung der Anmeldung, der Erfolgsmessung, dem Einsatz von MailChimp als Versanddienstleister und deinen Widerrufsrechten findest du in unseren Datenschutzhinweisen.

10 Kommentare

  1. Habe dazu mal eine Frage: wie sieht Google Bot die Sache? Verstehe ich es richtig, dass Bilder nicht mehr indexiert werden? Wäre eine ziemlich schlechte Nachricht für SEO’s…

    • Der Crawler ist seit gut zwei Jahren in der Lage, auch Inhalte, die per iFrame, Ajax und Javascript geladen werden, zu indexieren. Prinzipiell kann er natürlich auch Noscript-Inhalte erfassen, nur entspricht das nicht der Google-Philosophie…

  2. „Ebenfalls nicht bewährt hat sich die Verwendung extrem starker Kompressionsfaktoren“. Bilder stark komprimieren stand ja wohl nie ernsthaft zur Diskussion, es sei denn, hier ist das von Thomas Fuchs propagierte Verfahren gemeint, Bilder in doppelter Grösse und mit hoher Kompression zu verwenden. Damit habe ich allerdings tatsächlich gute Erfahrungen gemacht. Das geht so: Bild wird z.B. 600x400px benötigt. Eine HiDPI-Variante hätte also 1200×800. Man nehme nun 2400×1600 und komprimiere das so brutal, dass es in 1:1-Darstellung ziemlich ungeniessbar wäre. Es wird damit leichter als eines halber Grösse, das man eigentlich braucht. Da es aber für die Darstellung um 50% verkleinert wird, gewinnt es unter dem Strich in Qualität UND Gewicht. Ich war zunächst skeptisch, als ich davon las, habe es aber ausprobiert und es funktioniert tatsächlich. Unter retinafy.me gibts die Details.

    • Ja klar. Was aber, wenn der Nutzer das Bild runterlädt?

      • Für Fälle wo man Bilder zum Download anbieten will, muss man dann wohl noch eine zweite Bildversion bereitstellen. Die darf dafür dann aber jede noch so hohe Auflösung haben, weil man da ja keine Bandbreiten-Kompromisse eingehen muss.

        Der Pfad zu dieser Datei könnte in einem Data-Attribut untergebracht werden und der Download über JavaScript initialisiert.

        Ich würde aber sagen, dass es in den vielen Fällen ja nicht darum geht die Bilder zum Download zur Verfügung zu stellen, sondern einfach anzuzeigen und dafür ist Thomas Fuchs‘ Verfahren gut geeignet. Und wenn man so will ist es sogar ein gewisser Bilder-Kopierschutz.

        Nicht dass das jetzt die perfekte Lösung für alle Anwendungsfälle wäre, aber für so manches meiner Kundenprojekte hat es sich gut bewährt.

    • das ist ja interessant. Könntest Du bitte näher erläutern, was Du mit „komprimiere das so brutal, dass es in 1:1-Darstellung ziemlich ungeniessbar wäre“ meinst oder besser gesagt wie du das machst. Vielen Dank.

    • Recht herzlichen Dank für die Testseite! Wirklich sehr nett! Eine sehr interessante Methode. Nochmals danke

  3. Endlich mal wieder ein interessanter Artikel! Vielen Dank dafür!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Kennst du schon unseren Newsletter?

Hinweise zum Datenschutz, also dem Einsatz von Double-Opt-In, der Protokollierung der Anmeldung, der Erfolgsmessung, dem Einsatz von MailChimp als Versanddienstleister und deinen Widerrufsrechten findest du in unseren Datenschutzhinweisen.