Kategorien
Design Responsive Design Webdesign

Responsive Images: Das Picture-Element ist endlich da!

Was lange währt, wird endlich gut. Die viel diskutierte Lösung für die Umsetzung von Bildern in responsiven Designs ist tatsächlich in der Realität angekommen. Und es ist tatsächlich das Picture-Element des W3C geworden, nachdem sich die WhatWG zuletzt für das Srcset-Attribut am Img-Element ausgesprochen hatte. Von wegen, die W3C würde nur einen statischen Schnappschuss verwalten, während die WhatWG diejenige wäre, die HTML5 als lebenden Standard, als Work in Progress betrachten.

html5-logo

Responsive Images: Ein steiniger Weg mit vielen aufgeschlagenen Knien

Ich will an dieser Stelle nicht wieder die Diskussion zu Gehör bringen, die sich in den letzten zwei Jahren intern abgespielt hat. Der Streit um die richtige Lösung für Responsive Images und andere wichtige Fragen kommender Standards hatte bekanntlich sogar dazu geführt, dass sich die Web Hypertext Application Technology Working Group (WHATWG) als einflussreichste Arbeitsgruppe innerhalb des W3C von diesem abgespalten hatte, um HTML5 künftig als lebenden Standard weit schneller fortzuentwickeln als unter der Ägide des W3C vermeintlich möglich. Wir berichteten am 23. Juli 2012 darüber.

Erst wenige Tage vorher hatte sich eben diese WhatWG auf Srcset als Lösung für Responsive Images festgelegt, wir berichteten auch darüber. Im Nachhinein wenig verwunderlich, wollte sich das W3C in Form seiner HTML Working Group mit Unterstützung der W3C Community Group so gar nicht mit diesem nassforschen Vorgehen einverstanden erklären und stellten im Herbst 2012 klar, dass das Picture-Element mitnichten tot, sondern vielmehr sehr lebendig und genau die Stoßrichtung des W3C sei. Hier berichteten wir darüber.

Dann passierte nur wenig Plakatives, wenn auch hinter den Kulissen fleißig gewerkelt wurde. Im Februar 2014 gingen wir bei Dr. Web sogar so weit eine neue JavaScript-Lösung zu empfehlen, anstelle noch länger auf Picture oder Srcset zu warten.

Responsive Images: Chrome Canary hat es schon, andere fast

Und jetzt also ist es tatsächlich so weit. In einem brandaktuellen Beitrag auf A List Apart gab Mat Marquis, der umtriebige Kopf der Responsive Images Community Group, ehemaliger Mitarbeiter im jQuery Mobile Team und hauptberuflicher Designer/Developer bei der nicht unbekannten Filament Group, die erste Browser-Implementation des Picture-Elements bekannt.

Es ist Chrome Canary, die Developer-Version des Chrome-Browsers, der ab sofort für erste Tests des Elements herangezogen werden kann, wozu Marquis naheliegenderweise direkt auffordert. Chrome Canary gibt es übrigens hier. Nach der Installation pasten Sie folgende Zeile in die URL-Leiste

chrome://flags/#enable-experimental-web-platform-features 

bestätigen mit der Enter-Taste und klicken im folgenden Fenster auf "Aktivieren". Sie brauchen sich übrigens nicht zu sorgen. Die Änderungen, die Sie im Canary vornehmen, wirken sich nicht auf eine etwa vorhandene, reguläre Chrome-Installation aus. Beide werden separat gehalten.

Als Startpunkt für eigene Tests empfiehlt Marquis die Picturefill-Demos, welche bekanntlich so ausgelegt sind, dass das Polyfill nur da einspringt, wo die nativen Browserfähigkeiten nicht ausreichen.

Ausweislich der diversen Roadmaps ist ersichtlich, dass der Firefox ebenfalls kurz vor der Implementation von Picture steht, ebenso das Webkit-Projekt. Microsoft ziert sich wie stets und führt das Picture-Element, neben dem Srcset-Attribut gleichberechtigt als "Under Consideration". Na ja, der IE ist bei mir ohnehin nur "Under Consideration", wenn er sich nicht vermeiden lässt.

So, Kämpen des Netzes. Dann mal ran. Was haltet ihr von der Umsetzung?

Übrigens funktioniert das Picture-Element in der jetzigen Implementation noch nicht voll responsiv bei Änderungen des Viewport. Also, nach Änderungen einmal kurz einen Refresh machen.

Kategorien
Design JavaScript & jQuery Programmierung Responsive Design

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