Das eigentliche Problem mit Bildern im Web

Bilder sind ein Problem im modernen Web. Das klingt erstmal irritierend, schließlich verwenden dank Mediendatenbanken und WYSIWYG-Editoren selbst unbedarfteste Redakteure seit Jahrzehnten unfallfrei jegliche Art von Bilden in Artikeln.

Klar, Dinge wie rechtliche Aspekte von Fotos muss man in CMS-Schulungen nochmal erwähnen, und vielleicht auch, dass gewisse Webserver verschnupft reagieren, wenn man Bilder direkt unbearbeitet aus der digitalen Spiegelreflex hochlädt. Auch von der Idee, Produktfotos selbst mit der Smartphone-Kamera zu machen, hat wohl jeder Webentwickler schon mal abgeraten.

Das ist nicht das Problem.

Responsive Bilder

Selbst responsive Bilder sind eigentlich kein Problem mehr. Wir haben den kleinen CSS-Kniff von Ethan Marcotte mittlerweile verinnerlicht, vor allem aber gibt es inzwischen „was vom W3C“ – echte responsive <img>-Elemente und das neue Element <picture>, mit dem wir kontrollieren können, welches Bild (nicht nur ein anderes Format, ein anderes Bild) auf welchem Gerät ausgegeben wird.

Diese Elemente und Attribute sind nicht mal übermäßig neu. Schon 2012 hat Christoph Zillgens sie im Adventskalender der Webkrauts vorgestellt; 2014 gab es nochmal ein Follow-Up dazu von Jens Grochtdreis.

Aber wie sieht’s mit dem Browsersupport aus?

Natürlich Stand heute – wie bei allen neuen Techniken eigentlich – eher mager. Das srcset-Attribut beherrschen immerhin schon ein paar Browser, das <picture>-Element kennen noch weniger. Aber zum einen haben beide ein sauberes Fallback, weil sie klug erdacht wurden, zum anderen gibt es Polyfills wie picturefill und respimage, die das nachrüsten.

Das ist auch nicht das Problem.

Was ist denn nun das Problem?

Das Problem sind Arbeitsabläufe, insbesondere in Content Management Systemen. Wie kann man ein – auch für technisch wenig versierte Redakteure nutzbares – Interface schaffen, um solche responsiven Bilder in einem CMS-Backend zu nutzen? Lassen wir dabei redaktionelle Entscheidungen, auf kleineren Bildschirmen komplett andere Bilder auszugeben, ruhig mal außen vor; das ist noch mal eine Nummer komplizierter. Nehmen wir mal „nur“ ein ganz „einfaches“ <img>-Element mit srcset- und sizes-Attributen, das für jede Bildschirmgröße ein halbwegs passendes Bildformat ausliefert und dabei noch HDPI-Bildschirme berücksichtigt.

Ich glaube nicht, dass Entscheidungen wie

• In welchen Dimensionen wird das betreffende Bild hochgeladen?
• Wo setzt man sinnvoll die „Umschaltpunkte“, ab denen eine größere und/oder hochauflösendere Bildversion ausgegeben wird?
• Verwendet man ein Bild in niedriger Qualität (LQIP) und/oder Lazyloading zur Performance-Optimierung?

Redakteuren überlassen sein sollten, nein: überlassen sein dürfen. Solche Fragen müssen Entwickler lösen, vor allem aber muss das System Werkzeuge und Abläufe bieten, um solche Fragen lösen zu können.

Ein Versuch im CMS

Für Processwire gibt es mittlerweile ein paar Ansätze, diese Probleme zu lösen. Dabei geht es gar nicht unbedingt darum, wie man generell responsive Bilder verwenden kann – das wäre dank der Art und Weise, wie Processwire Bilder verarbeitet, schon lange mit Handarbeit möglich gewesen, da man sich recht einfach über die API kleinere Versionen eines Bildes erzeugen kann. Aber dazu muss man eben Zugriff auf diese Bilder über die API haben, und das ist in Inhaltsfeldern, die über einen WYSIWYG-Editor befüllt werden, zumindest kompliziert.

In den aktuellen Entwicklungsversionen gibt es bereits neue Werkzeuge, um Bilder im Backend zu bearbeiten und HDPI-Versionen ausgeben zu lassen – wohlgemerkt: Bilder, die von Redakteuren im WYSIWYG-Editor verbaut werden. Das ist grundsätzlich gut, aber mein innerer Kontrollfreak zuckt irgendwie doch leicht zusammen bei der Vorstellung, dass man Redakteuren von Endkunden derart mächtige Werkzeuge in die Hand gibt.

Die bessere Lösung scheint mir derzeit das Modul Srcset Image Textformatter zu sein. Sehr vereinfacht gesagt passiert damit Folgendes: Redakteure bauen Bilder im größten verfügbaren Format, was im WYSIWYG-Editor leider zumindest merkwürdig aussieht, ein. Das Modul erzeugt anhand der – vom Entwickler gesetzten; Kontrolle! – Konfiguration Bilder in den gewünschten Ausmaßen (srcset) für die gewünschten „Umschaltpunkte“ (sizes), kann dabei sowohl LQIP als auch HDPI erzeugen und sogar data-*-Attribute und CSS-Klassen. Letzteres ist vor allem für den Einsatz mit lazysizes vorgesehen, dürfte aber eben auch die Verwendung anderer Polyfills erleichtern, zumal das Modul „polyfill-agnostisch“ ist – es erzeugt also nur das nötige Markup, bindet aber nicht die betreffenden Polyfills ein.

Das ist ein Ansatz, den ich mir praktisch vorstellen kann – abgesehen davon, dass er für Redakteure noch sehr gewöhnungsbedürftig sein dürfte, weil das Bild eben in „Großformat“ in den WYSIWYG-Editor gekippt und erst dann vom Modul verarbeitet wird. Allerdings muss man Redakteuren meines Erachtens generell die Vorstellung abgewöhnen, dass diese Editoren eine Live-Vorschau des fertigen Inhalts bieten.