Vor wenigen Tagen wurde die Einigung über das HTML5 <picture>-Element bekannt. Damit ist eine langjährige Diskussion abgeschlossen und der Weg für „responsive“ Bilder frei. Warum dabei aber erst ein winziger Teil des Weges zurückgelegt ist und noch viele Herausforderungen warten, möchte ich in diesem Artikel behandeln.
Responsive Images?
Responsive Images werden seit langem als wichtige Ergänzung und Bestandteil des mittlerweile etabliertem „Responsive Webdesign“ gesehen.
Responsive Images sollen dabei zwei Fliegen mit einer Klappe schlagen: Einerseits werden auf kleineren Devices Bilder auch nur in kleinerer Auflösung ausgeliefert, was vor allem bei Smartphones und Tablets zu einer starken Reduktion der Webseitengröße führen kann.
Andererseits können auf diesen Geräten damit aber auch andere Bildausschnitte gewählt werden, um wichtige Bildelemente auch auf kleinen Bildschirmen nicht aus dem Fokus zu verlieren.
Das <picture>-Element
Seit längerem gibt es bereits viele Ideen, wie man das <img>-Element – mittlerweile auch schon 20 Jahre alt – um eine dynamische Komponente erweitern könnte. Nachdem Developer und Browserhersteller lang über die Implementierung diskutierten, gibt es nun die ersten Drafts dazu:
<picture> <source srcset="pic1x.jpg 1x, pic2x.jpg 2x, pic4x.jpg 4x"> <img alt="A rad wolf" src="pic1x.jpg" width="500" height="500"> </picture>
Das <picture>-Element ist vom Aufbau her mit dem HTML-5 <video>-Element vergleichbar. Im Element befindet sich ein Fallback auf ein Standardkonformes <img>-Element mit einer normal aufgelösten Version des Bildes. Zusätzlich dazu können beliebig viele source-Elemente eingefügt werden, die anhand bestimmter Faktoren (z.B. Auflösung oder Bildschirmgröße) das richtige Bild für das jeweilige Device in das <img>-Element laden.
Ein weiteres Beispiel für das neue picture-Element ist Folgendes:
<picture> <source media="(min-width: 45em)" srcset="large.jpg"> <source media="(min-width: 18em)" srcset="med.jpg"> <img src="small.jpg" alt="The president giving an award."> </picture>
Hier ist neben dem srcset-Attribut ebenfalls das media-Attribut vorhanden, das in ähnlicher Form auch bei Media Queries in CSS vorkommt. Dabei wird dem Browser mitgeteilt, ab welcher Bildschirmbreite welches Bild geladen werden soll.
Der lange Weg zur vollständigen Implementierung
Wie im Web üblich wird es noch lange dauern, bis das <picture>-Element voll einsatzfähig ist. Neben der vollständigen Unterstützung durch Browser (bis dahin gibt’s einen JavaScript-Polyfill) wird es aber im Fall des <picture>-Elements noch eine weitere Hürde geben: Die Unterstützung durch Content-Management-Systeme. Um das Element wirklich sinnvoll einsetzen zu können, muss es in Zukunft auch Workflows und Möglichkeiten geben, verschieden aufgelöste Bilder mit gegebenenfalls unterschiedlichen Bildausschnitten im System zu hinterlegen.
Das ist einerseits eine Herausforderung für die Entwickler der Systeme, die dafür eine einfache Möglichkeit schaffen müssen. Viel wichtiger ist aber noch, dass damit zusätzliche Verantwortung auf die Redakteure von Webseiten zukommt, weil diese in Zukunft auch vermehrt Zeit mit der Auswahl und Bearbeitung von Bildern in verschiedenen Formaten und Größen verbringen müssen.
Das <picture>-Element ist ein wichtiger Schritt, um Websites in Zukunft dynamisch und maßgeschneidert auf das Device des Users anzupassen. Anders als bei anderen neuen HTML-Elementen, die hauptsächlich Ansprüche an die Entwickler von Seiten stellen, muss im Fall des <picture>-Elements aber auch Bewusstsein für den Sinn und Nutzen bei Personen geschaffen werden, die für die redaktionelle Befüllung von Webseiten verantwortlich sind.
Du willst mit jemanden über das Thema plaudern?
Einen kostenlosen Termin mit CEO Susanne vereinbaren!Automatische Accessibility Audits – Wie wir mit unserem A11y-Testing-Tool Barrieren aufspüren
Barrierefreiheit im Web ist längst kein Nice-to-have mehr, sondern eine Notwendigkeit. Nicht nur, weil Gesetze wie die EU-Richtlinie 2016/2102 oder der kommende European Accessibility Act es vorschreiben, sondern auch, weil eine barrierefreie Webseite mehr Nutzer:innen erreicht und die UX verbessert. Doch manuelle Audits sind zeitaufwendig. Um Accessibility-Probleme effizient zu identifizieren, haben wir ein leistungsfähiges A11y-Check-Tool entwickelt – basierend auf Nuxt 3, Puppeteer und Axe-Core mithilfe der AI-unterstützten IDE Cursor.
Jetzt lesenUX SNACKS Episode #2 mit Markus Pirker
In Episode 2 hat Susanne Markus, CEO von Userbrain & Host UX Heroes Podcast zu Gast.Markus teilt seine Erfahrungen aus über 15 Jahren im UX-Bereich und erklärt, warum User-Testing mit echten Menschen noch immer unersetzlich ist, wie man [...]
Jetzt anhören