Das <picture>-Element rendert nichts selbst, sondern fungiert als Entscheidungs-Engine für ein inneres <img>-Element und teilt ihm mit, was gerendert werden soll. <picture> folgt einem Präzedenzfall, der bereits durch die Elemente <audio> und <video> festgelegt wurde: ein Wrapper-Element, das einzelne <source>-Elemente enthält.
<picture>
<source …>
<source …>
<img …>
</picture …>
Das innere <img> bietet Ihnen auch ein zuverlässiges Fallback-Muster für ältere Browser ohne Unterstützung responsiver Bilder: Wenn das <picture>-Element vom Browser des Nutzers nicht erkannt wird, wird es ignoriert. Die <source>-Elemente werden dann ebenfalls verworfen, da der Browser sie entweder überhaupt nicht erkennt oder ohne das übergeordnete <video>- oder <audio>-Element keinen sinnvollen Kontext für sie hat.
Das innere <img>-Element wird jedoch von jedem Browser erkannt – und die in der zugehörigen src angegebene Quelle wird wie erwartet gerendert.
„Art-Directed“-Bilder mit <picture>
Das Ändern des Inhalts oder des Seitenverhältnisses eines Bildes basierend auf der Größe des Bildes auf der Seite wird in der Regel als "kunstorientierte" responsive Bilder bezeichnet. srcset und sizes sind so konzipiert, dass sie unsichtbar funktionieren und die Quellen nahtlos ersetzen, wenn dies vom Browser des Nutzers vorgegeben wird.
Manchmal möchten Sie jedoch Quellen über Haltepunkte hinweg ändern, um den Inhalt besser hervorzuheben, genauso wie Sie Seitenlayouts anpassen.
Beispielsweise kann ein Kopfzeilenbild in voller Breite mit kleinem Fokus in einem großen Darstellungsbereich gut funktionieren:
Wenn sie jedoch auf kleine Darstellungsbereiche verkleinert werden, kann der zentrale Fokus des Bildes verloren gehen:
Das Subjekt dieser Bildquellen ist dasselbe. Um dieses Motiv jedoch besser visuell hervorzuheben, sollten sich die Proportionen der Bildquelle über Haltepunkte hinweg ändern. Wenn Sie z. B. einen stärkeren Zoom in der Bildmitte festlegen und einige Details an den Rändern herausschneiden:
Ein solches „Zuschneiden“ kann mit CSS erzielt werden, allerdings würde der Nutzer alle Daten, aus denen das Bild besteht, anfordern, auch wenn er es am Ende vielleicht nie sehen würde.
Jedes source-Element hat Attribute, die die Bedingungen für die Auswahl dieses source-Elements definieren: media, das eine Medienabfrage akzeptiert, und type, das einen Medientyp (zuvor als "MIME-Typ" bezeichnet) akzeptiert. Die erste <source> in der Quellreihenfolge, die dem aktuellen Browserkontext des Nutzers entspricht, wird ausgewählt und der Inhalt des srcset-Attributs auf dieser source wird verwendet, um die richtigen Kandidaten für diesen Kontext zu ermitteln. In diesem Beispiel wird die erste source mit einem media-Attribut, das mit der Größe des Darstellungsbereichs des Nutzers übereinstimmt, ausgewählt:
<picture>
<source media="(min-width: 1200px)" srcset="wide-crop.jpg">
<img src="close-crop.jpg" alt="…">
</picture>
Du solltest das innere img-Objekt immer an letzter Stelle in der Reihenfolge angeben. Wenn keines der source-Elemente den Kriterien media oder type entspricht, dient das Bild als „Standardquelle“. Wenn Sie min-width-Medienabfragen verwenden, sollten Sie die größten Quellen zuerst einsetzen, wie im vorherigen Code gezeigt. Bei max-width-Medienabfragen sollten Sie die kleinste Quelle an den Anfang stellen.
<picture>
<source media="(max-width: 400px)" srcset="mid-bp.jpg">
<source media="(max-width: 800px)" srcset="high-bp.jpg">
<img src="highest-bp.jpg" alt="…">
</picture>
Wenn eine Quelle anhand der von Ihnen angegebenen Kriterien ausgewählt wird, wird das srcset-Attribut von source an die <img> weitergegeben, so als wäre es in <img> selbst definiert. Das bedeutet, dass Sie sizes auch zur Optimierung von Bildquellen mit spezieller Ausrichtung verwenden können.
<picture>
<source media="(min-width: 800px)" srcset="high-bp-1600.jpg 1600w, high-bp-1000.jpg 1000w">
<source srcset="lower-bp-1200.jpg 1200w, lower-bp-800.jpg 800w">
<img src="fallback.jpg" alt="…" sizes="calc(100vw - 2em)">
</picture>
Natürlich stellt ein Bild mit Proportionen, die je nach ausgewähltem <source>-Element variieren können, ein Leistungsproblem dar:
<img> unterstützt nur ein einziges width- und ein height-Attribut, aber das Weglassen dieser Attribute kann die Nutzererfahrung deutlich verschlechtern.
Um dies zu berücksichtigen, ermöglicht eine relativ aktuelle, aber gut unterstützte Ergänzung der HTML-Spezifikation die Verwendung der Attribute height und width für <source>-Elemente. Dadurch werden Layoutverschiebungen ebenso reduziert wie bei <img>. Dabei wird im Layout der entsprechende Platz für das ausgewählte <source>-Element reserviert.
<picture>
<source
media="(min-width: 800px)"
srcset="high-bp-1600.jpg 1600w, high-bp-1000.jpg 1000w"
width="1600"
height="800">
<img src="fallback.jpg"
srcset="lower-bp-1200.jpg 1200w, lower-bp-800.jpg 800w"
sizes="calc(100vw - 2em)"
width="1200"
height="750"
alt="…">
</picture>
Art Direction kann nicht nur für Entscheidungen, die auf der Größe des Darstellungsbereichs basieren, verwendet werden, sondern auch, da die meisten dieser Fälle mit srcset/sizes effizienter bearbeitet werden können. So lässt sich z. B. eine Bildquelle auswählen, die besser für das Farbschema des jeweiligen Nutzers geeignet ist:
<picture>
<source media="(prefers-color-scheme: dark)" srcset="hero-dark.jpg">
<img srcset="hero-light.jpg">
</picture>
Das Attribut type
Mit dem Attribut type können Sie die Einzelanfrage-Entscheidungs-Engine des <picture>-Elements verwenden, um Bildformate nur an Browser bereitzustellen, die sie unterstützen.
Wie Sie unter Bildformate und Komprimierung gelernt haben, ist eine Codierung, die der Browser nicht parsen kann, nicht einmal als Bilddaten erkennbar.
Vor der Einführung des <picture>-Elements musste der Browser bei den praktikablen Frontend-Lösungen zur Bereitstellung neuer Bildformate eine Bilddatei anfordern und parsen, bevor entschieden wurde, ob sie verworfen und ein Fallback geladen werden sollte. Ein gängiges Beispiel ist ein Skript mit folgenden Eigenschaften:
<img src="image.webp"
data-fallback="image.jpg"
onerror="this.src=this.getAttribute('data-fallback'); this.onerror=null;"
alt="...">
Mit diesem Muster würde trotzdem eine Anfrage für image.webp in jedem Browser gestellt, was für Browser ohne WebP-Unterstützung eine verschwendete Übertragung bedeutet. Browser, die die WebP-Codierung dann nicht parsen konnten, lösen ein onerror-Ereignis aus und tauschen den data-fallback-Wert in src aus. Diese Lösung war Verschwendung, aber auch hier waren Ansätze wie dieser die einzige im Frontend verfügbare Option. Denken Sie daran, dass der Browser beginnt, Anfragen für Bilder zu senden, bevor benutzerdefinierte Skripts ausgeführt oder sogar geparst werden können, sodass wir diesen Prozess nicht vorzeitig beenden konnten.
Das <picture>-Element wurde explizit dafür entwickelt, solche redundanten Anfragen zu vermeiden. Ein Browser kann ein nicht unterstütztes Format zwar immer noch nicht erkennen, ohne es anzufordern, aber das Attribut type warnt den Browser im Voraus vor den Quellcodierungen, damit er entscheiden kann, ob eine Anfrage gestellt werden soll.
Im Attribut type geben Sie den Medientyp (früher MIME-Typ) der Image-Quelle an, die im Attribut srcset der einzelnen <source> angegeben wird. Dadurch erhält der Browser alle Informationen, die er benötigt, um sofort zu bestimmen, ob der von diesem source bereitgestellte Bildkandidat ohne externe Anfragen decodiert werden kann. Wenn der Medientyp nicht erkannt wird, werden <source> und alle zugehörigen Kandidaten ignoriert und der Browser fährt fort.
<picture>
<source type="image/webp" srcset="pic.webp">
<img src="pic.jpg" alt="...">
</picture>
Hier erkennt jeder Browser, der die WebP-Codierung unterstützt, den image/webp-Medientyp, der im Attribut type des <source>-Elements angegeben ist, wählen diesen <source> aus und weisen das innere <img>-Element an, pic.webp anzufordern, zu übertragen und zu rendern, da wir nur einen einzelnen Kandidaten in srcset bereitgestellt haben. Alle Browser ohne WebP-Unterstützung ignorieren source. Wenn keine gegenteilige Anleitung vorliegt, rendert <img> den Inhalt von src wie seit 1992.
Natürlich müssen Sie hier kein zweites <source>-Element mit type="image/jpeg" angeben. Sie können von der universellen Unterstützung von JPEG ausgehen.
Unabhängig vom Browserkontext des Nutzers wird dies mit einer einzigen Dateiübertragung erreicht. Es wird keine Bandbreite für Bildquellen verschwendet, die nicht gerendert werden können. Das ist zukunftsorientiert: Neuere und effizientere Dateiformate erhalten eigene Medientypen, die wir dank picture nutzen können – ohne JavaScript, serverseitige Abhängigkeiten und die Geschwindigkeit von <img>.
Die Zukunft von responsiven Bildern
Alle hier besprochenen Markup-Muster waren im Hinblick auf die Standardisierung ein großer Aufwand: Die Änderung der Funktionalität von etwas, das so etabliert und von zentraler Bedeutung für das Web wie <img> war, war keine leichte Aufgabe und die Reihe der Probleme, die durch diese Änderungen gelöst werden sollten, waren, gelinde gesagt, umfangreich. Wenn Sie denken, dass es bei diesen Markup-Mustern viel Verbesserungspotenzial gibt, haben Sie völlig recht. Von Anfang an waren diese Standards als Grundlage für zukünftige Technologien gedacht.
Für all diese Lösungen war unbedingt Markup erforderlich, damit sie in die anfängliche Nutzlast vom Server eingebunden werden konnten, sodass der Browser rechtzeitig Bildquellen anforderte – eine Einschränkung, die zum zugegebenermaßen unhandlichen sizes-Attribut führte.
Als diese Funktionen jedoch auf der Webplattform eingeführt wurden, wurde auch eine native Methode zum Zurückstellen von Bildanfragen eingeführt.
<img>-Elemente mit dem loading="lazy"-Attribut werden erst angefordert, wenn das Layout der Seite bekannt ist. So können Anfragen für Bilder, die außerhalb des ursprünglichen Darstellungsbereichs des Nutzers liegen, erst später beim Rendern der Seite zurückgestellt werden. So lassen sich unter Umständen unnötige Anfragen vermeiden. Da der Browser das Seitenlayout zum Zeitpunkt der Anfrage vollständig versteht, wurde ein sizes="auto"-Attribut als Ergänzung zur HTML-Spezifikation vorgeschlagen, um in diesen Fällen die lästige lästige lästige mühsame sizes-Attribute zu vermeiden.
Außerdem gibt es am Horizont Ergänzungen für das <picture>-Element, mit dem sich außergewöhnliche Änderungen an der Gestaltung von Seitenlayouts anpassen lassen. Informationen zum Darstellungsbereich sind zwar eine solide Grundlage für Layoutentscheidungen auf hoher Ebene, sie verhindern jedoch, dass wir bei der Entwicklung einen Ansatz auf Komponentenebene verfolgen, d. h. eine Komponente, die in jeden Teil eines Seitenlayouts verschoben werden kann, mit Stilen, die auf den Raum reagieren, den die Komponente selbst einnimmt. Aus diesem Grund wurden Containerabfragen erstellt: eine Methode, bei der Elemente basierend auf der Größe des übergeordneten Containers und nicht anhand des Darstellungsbereichs gestaltet werden.
Während sich die Syntax der Containerabfrage nur gerade stabilisiert hat und die Browserunterstützung zum Zeitpunkt der Erstellung dieses Dokuments sehr eingeschränkt ist, bietet das Hinzufügen der Browsertechnologien, die sie ermöglichen, dem <picture>-Element die gleichen Möglichkeiten: ein potenzielles container-Attribut, das <source>-Auswahlkriterien basierend auf dem Platz zulässt, den <img> des <picture>-Elements einnimmt, anstatt auf der Größe des Darstellungsbereichs.
Wenn das etwas vage klingt, gibt es einen guten Grund: Diese Diskussionen über Webstandards sind noch nicht abgeschlossen, aber noch lange nicht beigelegt. Sie können sie derzeit noch nicht nutzen.
Während Markup für responsive Bilder verspricht, im Laufe der Zeit immer einfacher zu arbeiten, wie jede Webtechnologie, gibt es eine Reihe von Diensten, Technologien und Frameworks, die die Handschrift dieses Markups erleichtern. Im nächsten Modul erfahren Sie, wie Sie alles, was wir über Bildformate, Komprimierung und responsive Bilder gelernt haben, in einen modernen Entwicklungsworkflow einbinden können.