kulturbanause Blog

Responsive Design, WordPress, Konzeption, HTML, CSS, JS & UX/UI …

Responsive Images – <picture>, srcset, sizes & Co.

Flexible Bilder sind ein wichtiger Bestandteil von responsiven Websites. Doch leider stellte genau dieses Thema Web Designer in den vergangenen Jahren vor enorme Herausforderungen. Ohne Scripte war es bisher nicht möglich Bilder ohne Performance- oder Qualitätsverluste auf allen Displaygrößen darzustellen. Und selbst mit der Unterstützung von Scripten waren einige Änderungen – z. B. die Veränderung des Bildausschnitts – eine mehr als lästige Aufgabe. Mit <picture>, srcset & sizes sind neue HTML-Elemente und -Attribute in die Spezifikation gewandert, mit deren Hilfe sich viele Probleme bald lösen werden.

Workshops und Seminare von kulturbanause

Unsere Seminar-Termine für 2018 sind online!

Jetzt Tickets sichern!

img vs. background

In diesem Beitrag geht es um Bilder im HTML-Code, also um inhaltlich relevante Grafiken. Bilder die per CSS einem Element als background zugewiesen wurden, können auch heute schon über Media Queries ausgetauscht werden. Im HTML-Code hingegen existierten bisher keine Media Queries, daher war der Austausch dort nicht ohne weiteres möglich.

Die bisherigen Lösungen

Mitte 2014 arbeiten die meisten Websites noch mit einem Kompromiss. Es wird das gleiche Bild für alle Displaygrößen und Displaytechnologien ausgespielt. Mit folgender CSS-Angabe verhält sich das Bild flexibel:


img {
  max-width: 100%;
  height: auto;
}

Diese Vorgehensweise hat bekanntlich große Nachteile. Entweder werden auf kleinen Displays zu große Dateien geladen, was der Performance schadet, oder das Bild wird über seine tatsächliche Breite hinaus skaliert. Letzteres führt zu schlechter Bildqualität auf großen Displays. Hochauflösende Displays werden gar nicht berücksichtigt.

Um diese Probleme zu beheben, wurden verschiedene Tricks und Scripte verwendet. Der Vollständigkeit halber möchte ich auch einige diese Techniken kurz erwähnen.

Downsampling

Um sowohl auf normalen als auch auf hochauflösenden Displays eine gute Bildqualität zu erreichen, wird das Bild oft in doppelter Größe geladen. Über die Größenattribute von HTML skaliert man das Bild auf gewünschte Größe herunter. Ziel ist es, die Pixeldichte der Grafiken soweit zu erhöhen, dass sie der DPR von hochauflösenden Geräten entspricht. Diese Methode nennt sich Downsampling.

Downsampling auf der Website von Bootstrap 2.3
Downsampling auf der Website von Bootstrap 2.3

Optisch erreicht man so auf allen Displays ein perfektes Ergebnis, allerdings werden auf niedrigauflösenden Geräten ebenfalls hochauflösende Grafiken geladen. Durch starke Kompression musste das allerdings nicht zwangläufig zu schlechter Performance führen. Ich setze diese Technik teilweise auch hier im Blog ein.

Adaptive Images

Das Script Adaptive Images dürfte den meisten von euch ein Begriff sein. Wie der Name bereits andeutet, handelt es sich um eine adaptive Lösung. Mit Hilfe eines PHP-Scripts, sowie einer .htaccess-Datei werden Bilder auf dem Server automatisch in verschiedene Größen geschnitten. Anschließend prüft das Script wie groß die Bildschirmauflösung des Anwenders ist und spielt das passende Bild aus.
Das Script bietet sich als Lösung durchaus an, hat aber auch klare Schwachstellen. Es ist beispielsweise nicht möglich das Bildmotiv zu verändern. Ebenfalls nicht berücksichtigt werden mehrspaltige Layouts oder hochauflösenden Displays.

Focal Point

Ein typisches Problem mit Bildern im Responsive Design ist der Bildausschnitt. Ein Foto kann zwar technisch problemlos auf Smartphone-Größe herunterskaliert werden, oft gehen dadurch aber wichtige Bilddetails verloren. Es ist also notwendig den Bildausschnitt zu verändert.
Gelöst werden kann dieses Problem mit einer CSS-Technik namens Focal Point. Dabei wird bestimmt, welcher Punkt immer sichtbar sein soll. Mit Hilfe eines Container-Elements und negativer margin-Angaben, wird das Bild anschließend ab einem bestimmten Breakpoint gezoomt und verschoben.
Eine Beispieldatei zu diesem Thema findet ihr hier. Es existiert auch bereits ein Framework namens Focal Point, dass sich unkompliziert in die Website integrieren lässt.

Die Anwendungsfälle (Use Cases) für Responsive Images

Um die soeben beschriebenen Probleme in Zukunft mit reinem HTML lösen zu können, hat sich die Responsive Images Community Group gegründet. Die Gruppe hat mehrere Jahre lang Lösungsvorschläge erarbeitet und hitzig diskutiert.

Logo der Responsive Images Community Group
Logo der Responsive Images Community Group

Im Rahmen der Diskussion wurden u.a. die möglichen Anwendungsfälle für Responsive Images formuliert:

  1. Bilder sollen mit unterschiedlicher Auflösung für normale und hochauflösende Displays ausgegeben werden
  2. Bilder innerhalb eines flexiblen Web-Layouts (responsive Layout) sollen mit unterschiedlicher Abmessung für verschiedene Viewport-Größen ausgegeben werden
  3. Es sollen unterschiedliche Bildausschnitte, Seitenverhältnisse oder Motive für verschiedene Viewport-Größen verwendet werden (Art Direction)
  4. Es sollen unterschiedliche Dateiformate für unterschiedliche Browser verwendet werden
  5. Kombinationen der letzten vier Punkte

Um diese Anwendungsfälle zu lösen, gibt es nun ein weiteres HTML-Element namens <picture>, die neuen Attribute srcset und sizes und die Werte x, w und vw.
In Kombination kann mit diesem Repertoir an neuem Markup jeder der oben beschriebenen Anwendungsfälle gelöst werden.

Notwendige Informationen für die perfekte Bildgröße

Damit ihr versteht wie das neue Markup eingesetzt wird, solltet ihr euch kurz folgende Tabelle anschauen. Um für jeden Anwendungsfall das perfekte Bild laden zu können, müssen dem Browser die folgenden vier Informationen vorliegen.

Kennt der Browser Kennt der Entwickler
Größe des Viewports X
Bildschirmauflösung X
Abmessungen der Bilddatei X
Größe in der das Bild gerendert werden soll X

Der Browser kennt leider nicht alle notwendigen Informationen. Aus diesem Grund ist es notwendig, dass der Entwickler manuelle Hinweise vergibt. Dazu später mehr.

Bilder für unterschiedliche Display-Qualitäten ausgeben

Beginnen wir mit einem einfachen Anwendungsfall. Wir möchten eine Grafik in normaler Auflösung für Standard-Displays, und in hoher Auflösung für hochauflösende Displays ausgeben. Schaut euch dazu folgenden Code an:


<img src="bild.jpg" srcset="bild.jpg 1x, bild@2x.jpg 2x" alt="">

Zunächst wird ein ganz gewöhnlicher <img>-Tag verwendet. Über das src-Attribut wird die Bildquelle definiert. Soweit nichts Neues.

srcset

Mit srcset definiert ihr ein Set von Bildquellen und überschreibt damit das src-Attribut. Die einzelnen Quellen innerhalb von srcsetwerden mit Komma getrennt.

x-Wert

Neben den Dateinamen der Bilder seht ihr noch den sog. x-Wert. Dieser Wert bestimmt bei welchem DPR das Bild geladen werden soll. 1x entspricht einem normalen Display mit einfacher Pixeldichte, 2x steht für hochauflösende Displays mit einer Pixeldichte von 2 (z. B. das Retina-Display von Apple), 3x und mehr steht für noch höher auflösende Displays wie das des HTC One etc.

Der oben gezeigte Code lädt folglich das bild.jpg auf normalen Displays und bild@2x.jpg auf hochauflösenden Displays. Wenn ein Browser das neue srcset-Attribut nicht kennt, springt src als Fallback-Lösung ein.

Beispiel anzeigen

Bilder entsprechend der Viewport-Breite austauschen

Kommen wir nun zu einem weiteren Anwendungsfall. Der Browser soll immer das passende Bild für die aktuelle Viewport-Breite verwenden: Auf großen Displays sollen also große Bilder und auf kleinen Displays kleine Bilder geladen werden. Schaut euch dazu diesen Code an:


<img src="small.jpg" srcset="small.jpg 320w, medium.jpg 600w, large.jpg 900w" alt="">

Wie im letzten Beispiel wird zunächst ein normaler <img>-Tag mit src-Attribut verwendet. Das srcset-Attribut überschreibt in kompatiblen Browser das src-Attribut und stellt eine Liste mit verschiedenen Bildquellen bereit. Dieses Mal hat der Browser die Wahl zwischen drei Grafiken: small.jpg, medium.jpg und large.jpg.

Unterschiedliche Bildgrößen in unterschiedlichen Viewports
Funktionsweise des Beispiels in einem kompatiblen Browser

w-Wert

Neu in diesem Beispiel ist der w-Wert. Er beschreibt die physikalische Breite des Bildes in Pixeln – also die Breite die ihr beispielweise in Photoshop innerhalb des »Für Web speichern«-Dialogs sehen könnt. Der w-Wert muss manuell angegeben werden, da der Browser die Breite des Bildes nicht kennt.

Anzeige der physikalischen Bildgröße in Photoshop
Anzeige der physikalischen Bildgröße in Photoshop

Der oben gezeigte Code führt also dazu, dass der Browser bei Viewports unter 320 Pixel Breite die Grafik small.jpg lädt. Sobald der Viewport größer als 320 Pixel ist, wird medium.jpg geladen. Diese Grafik ist laut unserer Angabe 600 Pixel breit. Ab 600 Pixel wird daher large.jpg geladen.

Beispiel anzeigen

Bilder in flexiblen, mehrspaltigen Layouts

Kommen wir nun zu einem komplexeren Beispiel. Das Layout der Seite verändert die Anzahl der Spalten von einspaltig in der Smartphone-Version über zweispaltig in der Tablet-Version hin zu dreispaltig in der Desktop-Version. In einem solchen Fall kann es vorkommen, dass die Bilder in größeren Viewports, kleiner dargestellt werden.

Responsive Images in mehrspaltigen Layouts
Funktionsweise des Beispiels in einem kompatiblen Browser

Bisher haben wir die Bilder anhand der Viewport-Breite ausgetauscht. Bei mehrspaltigen Layouts macht diese Vorgehensweise keinen Sinn mehr. Damit der Browser das perfekte Bild laden kann, muss er alle vier Informationen der weiter oben gezeigten Tabelle kennen. Da er allerdings weder die Abmessungen der Bilder kennt, noch weiß wie breit das Bild dargestellt werden soll, müssen wir ihm nun zwei manuelle Hinweise mitteilen. Schaut euch dazu den folgenden Code an:


img {
  width:100%;
  height:auto;
}

@media screen and (min-width:28em) {
  img {
    width:50%;
  }
}

@media screen and (min-width:50em) {
  img {
    width:33%;
  }
}

<img 	

srcset=" large.jpg 900w,
      	 medium.jpg 600w,
      	 small.jpg 320w"

sizes="	 (min-width: 50em) 33vw,
         (min-width: 28em) 50vw,
         100vw"

src="small.jpg"

alt="" 

/>

srcset & sizes

Beginnen wir mit den Bestandteilen die wir schon kennen. <img>, src und srcset sind bekannt: Wir laden ein Bild, legen mit src eine Standard-Grafik fest und definieren über srcset eine Liste an Bildquellen. Für jede Bildquelle legen wir fest wie breit die Grafik in Pixeln ist.
Bisher unbekannt ist das sizes-Attribut. Über sizes wird festgelegt, wie breit eine Grafik dargestellt werden soll. Hier teilen wir dem Browser also die zweite fehlende Information mit. Innerhalb von sizes können nun verschiedene Rahmenbedingungen beschrieben werden – in diesen Beispiel drei, da wir drei verschiedene Layout-Ansichten haben. Jede Rahmenbedingung besteht dabei aus einem optionalen Media Query der die Viewport-Breite beschreibt, und der Breite des Bildes, hier angeben in der Einheit vw (Viewport-Width = Viewportbreite).
Eine Angabe wie (min-width: 28em) 50vw bedeutet also: Ab 28em Viewport-Breite soll das Bild die Hälfte (50%) des Viewports einnehmen. Mit (min-width: 50em) 33vw legen wir die Regel für das dreispaltige Layout fest. Ab 50em soll ein Bild ein Drittel des Viewports einnehmen. Als letztes muss immer auch noch der Standard festgelegt werden. 100vw entspricht dabei der vollen Breite.
Neben der Einheit vw sind auch alle anderen CSS-Einheiten wie px, em und sogar die calc()-Funktion möglich.

Ein Rechenbeispiel

Der Browser wählt im zuletzt gezeigten Beispiel das passende Bild automatisch aus. Wenn der Viewport beispielsweise 700 Pixel breit ist sieht die Berechnung folgendermaßen aus:

700 Pixel ist mehr als 28em (448px) und weniger als 50em (800px). Das Bild soll demnach die Hälfte der Viewport-Breite einnehmen (entspricht 350px). Da 350 Pixel mehr ist, als die physikalische Breite von small.jpg (320w) wird medium.jpg (600w) geladen.
Wenn der Anwender ein hochauflösendes Display mit einer DPR von 2 verwendet, multipliziert der Browser den benötigten Wert mit 2. Das Bild müsste dann mindestens 700 Pixel breit sein. Auf einem Retina-Display verwendet der Browser daher large.png (900w).

Bitte beachtet auch, dass der Browser keine kleineren Version eines Bildes mehr nachlädt, wenn er bereits ein höher auflösendes bzw. größeres Bild geladen hat.

Beispiel anzeigen

Keine Kontrolle bei srcset & sizes

Beachtet bitte, dass ihr nicht exakt bestimmen könnt welches Bild der Browser lädt. Die geeignetste Grafik kann der Browser nämlich selbst bestimmen. In den meisten Fällen wird die obige Beispiel-Berechnung zutreffen, in Zukunft ist es aber denkbar, dass Kriterien wie die Bandbreite oder individuelle Benutzereinstellungen Einfluss auf die Auswahl des Browsers nehmen. Der Benutzer könnte beispielsweise festlegen, dass im WLAN immer das Bild mit der besten Qualität verwendet wird. Im 3G-Netz lädt der Browser das Bild mit der geringsten Dateigröße.
Da ihr nicht verlässlich sagen könnt welches Bild geladen wird, bieten sich srcset und sizes nur für unterschiedliche Größen und Qualitätsstufen des selben Motivs an.

Art Direction – Das Motiv verändern

Kommen wir nun zum sog. Art Direction Use Case. Hierbei soll das Bild sichtbar ausgetauscht werden. Es ist beispielsweise denkbar den Bildausschnitt oder das Seitenverhältnis zu verändern. Auch ein kompletter Austausch der Grafik ist vorstellbar: Eine Infografik mit starker horizontaler Ausrichtung lässt sich auf dem Smartphone beispielsweise ins Hochformat drehen um auch auf kleinen Bildschirmen erkennbar zu bleiben.

Das <picture>-Element

Erst wenn ihr etwas aus dem Bereich Art Direction umsetzten möchtet, ist das neue HTML-Element <picture> mit von der Partie. Es dient als Container-Element für verschiedene Bildquellen. Die Bildquellen werden dabei über das HTML-Element <source> definiert.


<picture>
  <source media="(min-width: 38em)" srcset="art-direction-horizontal.jpg">
  <source srcset="art-direction-vertical.jpg">
  <img src="art-direction-vertical.jpg" alt="">
</picture>

Mit dem hier abgebildeten Code wird die Grafik ausgetauscht, sobald der Viewport 38em überschreitet. Auf großen Bildschirmen wird art-direction-horizontal.jpg verwendet, auf kleinen Bildschirmen art-direction-vertical.jpg.

Art Direction mit dem picture-Element
Funktionsweise des Beispiels in einem kompatiblen Browser

<source>, sourceset & media

Innerhalb von <picture> gebt ihr verschiedene Bildquellen an. Die Quellen werden von oben nach unten gelesen und der erste Treffer wird geladen. Die Reihenfolge ist also entscheidend. Als letztes notiert ihr mit <img src=" "> eine Fallback-Lösung für inkompatible Browser.
Innerhalb von <source> wird über das media-Attribut der Media Query notiert der für diese Bildquelle gelten soll. Anschließend legt ihr über srcset die Bildquellen fest. Ihr könnt wie im Beispiel gezeigt auch nur eine Quelle angeben.

Beispiel anzeigen

Art Direction und hochauflösende Displays

Der Vollständigkeit halber möchte ich euch auch noch ein etwas komplexeres Beispiel mit verschiedenen Bildquellen innerhalb von srcset zeigen. Das Beispiel verwendet drei unterschiedliche Quellen in jeweils zwei Qualitätsstufen.


<picture>
  <source media="(min-width: 56.25em)" srcset="large.jpg 1x, large@2x.jpg 2x">
  <source media="(min-width: 37.5em)" srcset="medium.jpg 1x, medium@2x.jpg 2x">
  <source srcset="small.jpg 1x, small@2x.jpg 2x">
  <img src="fallback.jpg" alt="">
</picture>

Beispiel anzeigen

Verschiedene Dateiformate

Mit Hilfe von <picture> ist es auch möglich verschiedene Dateiformate auszugeben. In diesem Fall kommt innerhalb von <source> das type-Attribut zum Einsatz. Über type definiert ihr den MIME-Type des Bildes. Das folgende Beispiel bietet die Grafiken sowohl als JPG als auch im Format WEB-P an. Mit WEB-P kompatible Browser wie Chrome laden das neue Format, alle anderen Browser erhalten die JPG-Grafik.


<picture>
  <source media="(min-width: 56.25em)" srcset="large.webp" type="image/webp">
  <source media="(min-width: 56.25em)" srcset="large.jpg">

  <source media="(min-width: 37.5em)" srcset="medium.webp" type="image/webp">
  <source media="(min-width: 37.5em)" srcset="medium.jpg">

  <source srcset="small.webp" type="image/webp">
  <source srcset="small.jpg">
  <img src="fallback.jpg" alt="">
</picture>

Beispiel anzeigen

Browser-Support

Zum Veröffentlichungszeitpunkt dieses Beitrags steht der native Browsersupport von Chrome und Firefox unmittelbar bevor. Die Details entnehmt ihr bitte der Website Can I Use:

Benutzt srcset, sizes und <picture> ab sofort!

Ihr könnt die in diesem Beitrag vorgestellten Techniken ab sofort einsetzen, denn es gibt native Fallback-Lösungen. Ein inkompatibler Browser zeigt die Grafik innerhalb von <img src=" "> an.

Darüber hinaus existiert das bekannte Polyfill picturefill.js mittlerweile in einer überarbeiteten Version. Ihr müsst das Script lediglich im <head> der Seite einbinden. Picturefill.js rüstet sowohl den Browsersupport für das <picture> Element als auch für sourceset und sizes nach. Bitte beachtet, dass picturefill.js mindestens in Version 2.3.1 eingebunden werden sollte! Details dazu entnehmt ihr bitte diesem Artikel.

Picturefill.js korrekt einbinden

Wenn ihr ohne das <picture>-Element arbeitet, bindet das Script wie folgt ein:


<script src="picturefill.js" async></script>

Wenn ihr das <picture>-Element einsetzt, und nicht bereits HTML5Shiv verwendet, ergänzt den Code wie hier gezeigt:


<script>
// Picture element HTML5 shiv
document.createElement( "picture" );
</script>
<script src="picturefill.js" async></script>

Beispiel mit picturefill.js anzeigen

Funktionen in Chrome Canary aktivieren

Wenn ihr die neuen Funktionen in der Entwickler-Version von Chrome (Chrome Canary) vorab aktivieren wollt, ladet Chrome Canary herunter und gebt folgenden Befehl in die Adresszeile ein:

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

Anschließend aktiviert ihr die experimentellen Browser-Funktionen und startet Chrome neu.

Kompatibilität von Validatoren

Die bekannten HTML-Validatoren validator.w3.org und validator.nu unterstützen die neue HTML-Spezifikation ab sofort.

Links / Quellen

Jetzt bist du gefragt!

Hast du Anregungen, Ergänzungen, einen Fehler gefunden oder ist dieser Beitrag nicht mehr aktuell? Dann freuen wir uns auf deinen Kommentar.

Du kannst diesen Beitrag natürlich auch weiterempfehlen. Wir sind dir für jede Unterstützung dankbar!

Unterstützung bei Responsive Design-Projekten

Unsere Agentur ist auf responsive Design spezialisiert. Wir realisieren u.a. maßgeschneiderte Websites und führen Schulungen durch. Wenn du Unterstützung bei der Planung, Gestaltung und Entwicklung einer Website im Responsive Design benötigst, helfen wir gerne weiter.
Responsive Webdesign-Leistungsangebot →

Das könnte dich auch interessieren

60 Kommentare

  1. Mirco

    Verfasst am 2. September 2014 um 14:58 Uhr.

    Danke der Beitrag ist sehr informative und hilfreich.
    Ich frage mich jedoch ob es besser ist die Grafiken in HTML mit Hilfe von dem tag oder in CSS als Background-Image einzufügen?
    Ist es richtig das in HTML eingefügte Grafiken dank dem alt=““ besser für den Inhalt der Seiten stehen oder gibt es auch in CSS derartige Möglichkeiten?
    Ich finde nämlich das CSS bessere Möglichkeiten der Einbindung etc. bietet.

    Ich hoffe mir kann geholfen werden. Vielen Dank!

    • Stefan

      Verfasst am 3. September 2014 um 9:53 Uhr.

      Diese Variante ist nur für Bilder die du in deinem Inhalt verwendest. Zum Beispiel ein Bild das dich im Urlaub zeigt danach noch weitere, du wirst jetzt ja nicht für jedes Bild einen div Container anlegen und es über css definieren.

      Dafür setzt du ab jetzt einfach diese Variante von img ein. Musst aber bei 10 Bildern a min 3 Größen 30Bilder-Dateien zurecht legen.

    • Jonas Hellwig

      Verfasst am 3. September 2014 um 12:42 Uhr.

      Hallo Mirco,

      inhaltlich relevante Grafiken gehören in den HTML-Code und werden dort auch von Screenreadern und Google ausgelesen. Dazu gehört dann ein vernünftiges alt-Attribut.

      Layout- und Schmuckgrafiken ohne echten inhaltlichen Wert gehören in den CSS-Code und sind für Google unsichtbar.

  2. Ingo

    Verfasst am 2. September 2014 um 16:35 Uhr.

    Wow, das ist wirklich mal ein umfassender Artikel zu einem Thema, wo man sich sonst in der Regel alles zusammensuchen muss. Vielen Dank für Deine Mühe! Und gut, dass sich da langsam Standards herausbilden.

  3. Stefan

    Verfasst am 3. September 2014 um 9:59 Uhr.

    Ich hoffe nur das WordPress das bald mit aufnimmt oder das es ein PlugIn kommt das diese Variante anständig umsetzt.

    Oder ich mach mir eine Aktion in Photoshop für die verschiedenen Größen.
    Der mehr Aufwand ist für einen guten Zweck aber immer noch ein Aufwand :-)

    Schöne Grüße
    Stefan

  4. Stefan B

    Verfasst am 3. September 2014 um 14:45 Uhr.

    Ein schöner Artikel. Wie ich sehe wird srcset ja sogar vom mobilen Chrome unterstützt. Dass die Desktop-Browser das noch nicht alle können, finde ich sogar gar nicht mal so schlimm. Aber wenn dann auf den Android Smartphones schon mal das kleinere Bild ausgeliefert werden kann, umso besser.

    Sehe ich das richtig: Sofern ich die Art Direction nicht in Anspruch nehmen möchte, ist srcset die korrekte Wahl?

    • Jonas Hellwig

      Verfasst am 3. September 2014 um 14:50 Uhr.

      Hallo Stefan, genau so ist es. srcset ist die erste Wahl, erst wenn du Art Direction einsetzen möchtest kommt das <picture>-Element ins Spiel.

  5. Sven

    Verfasst am 3. September 2014 um 15:18 Uhr.

    Super Zusammenfassung und klasse Vortrag gestern!

  6. Marco

    Verfasst am 3. September 2014 um 19:42 Uhr.

    Danke für diesen super umfangreichen Artikel.
    Ich habe das ganze mal in Firefox 32 ausprobiert. Laut caniuse.com soll Firefox das ab dieser Version unterstützen, wenn man den entsprechenden Wert in der about:config ändert.
    Leider scheint das, zumindest bei mir, noch nicht zu funktionieren. Schade!

  7. Ramona

    Verfasst am 4. September 2014 um 10:33 Uhr.

    Ein gelungener Beitrag, danke! Wir kommen um eine anständige Lösung nicht herum. Aber wie bastle ich die Attribute in knapp 400 Posts nachträglich ein? Es gab mal ein Plugin, das nicht weiterentwickelt wurde (trotz anderslautender Aussage der Entwickler): http://wordpress.org/support/view/plugin-reviews/new-nine-adaptive-images.

  8. Sandro

    Verfasst am 4. September 2014 um 13:45 Uhr.

    Vielen Dank für diesen hervorragenden Artikel!

  9. Kerstin

    Verfasst am 5. September 2014 um 13:09 Uhr.

    Danke!
    Du rockst!

  10. Peter Müller

    Verfasst am 8. September 2014 um 9:39 Uhr.

    Danke für diesen Artikel. Er wird vielen Leute helfen, die Sache besser zu begreifen. Nach dem ersten Lesen dachte ich „Geil. Alles klar.“, nach dem zweiten kamen dann doch wieder Fragen und Anmerkungen. Here we go:

    Adaptive Images
    prüft die Bildschirmauflösung des Gerätes, *nicht* den Viewport. Darum reicht es zum Testen auch nicht, die Größe des Browserfensters zu ändern.

    Picturefill.js
    benötigt den zusätzlichen JS-Schnippsel für picture nur, wenn kein aktueller HTML5Shiv eingebunden wird. Da ist document.createElement( „picture“ ) schon drin.

    Und jetzt die eigentliche Frage:
    Der Abschnitt „Bilder entsprechend der Viewport-Breite austauschen“ ist ja phantastisch einfach zu verstehen, mit einem „w“-Wert wie 320w als Media Query, aber das wird so nicht mehr lange funktionieren, oder?

    Eric Portis schreibt in seinem „Srcset and sizes“ vom März 2014:
    „The old srcset and the new srcset both use w descriptors in comma-separated lists of resource URLs, but the old and the new w mean completely different things! Old w was a shorthand form of media query: the width it described was the viewport width. New w describes the width of the file.“

    Das Beispiel im Artikel funktioniert also nur, weil Webkit und Blink momentan noch „the old w“ implementiert haben. Sobald die Browser „the new w“ drin haben, gibt 320w nur noch die Breite des Bildes an, die dann zusammen mit „sizes“ verwendet wird, und dann werden die Bilder nicht mehr getauscht.

    • Jonas Hellwig

      Verfasst am 8. September 2014 um 10:06 Uhr.

      Hallo Peter,

      vielen Dank für deinen Kommentar. Die Anmerkungen zu Adaptive Images und picturefill.js sind richtig und wichtig – ich ergänze den Beitrag entsprechend.

      Was deine Frage zum w-Wert angeht: Ich habe mich beim Inhalt dieses Artikels bereits am neuen Wert orientiert. w = physikalische Breite der Bilddatei. Ich gehe davon aus, dass beim Anwendungsfall »Bilder entsprechend der Viewport-Breite austauschen« der Browser den Viewport automatisch berücksichtigt. Sobald der Viewport größer ist als die Pixelbreite des Bildes (Retina-Displays mal nicht berücksichtigt), wird die größere Datei geladen. Das sizes-Attribut kommt erst ins Spiel, wenn das Bild nicht nur anhand der Viewport-Breite ausgewählt werden soll, sondern wenn auch andere Kriterien vom Browser berücksichtigt werden sollen. Beispielsweise ein mehrspaltiges Layout.
      Es ist allerdings in der Tat möglich, dass das sizes-Attribut in Zukunft zwingend notwendig wird, da der Browser eben nicht automatisch den Viewport berücksichtigt. Das wäre dann der von dir geschilderte Fall. Von der Syntax her fände ich das unnötig kompliziert.
      Kennst du eine Möglichkeit den »neuen w-Wert« jetzt schon zu testen? Ich weiß gerade nicht in welcher Dev-Version des Browsers welcher w-Wert implementiert ist.

      • Peter Müller

        Verfasst am 8. September 2014 um 10:27 Uhr.

        Nee, kenne ich so auf Anhieb auch nicht. Ich habe mich da die letzten Tage ein bisschen mit beschäftigt, und lese daher gerade alles dazu, was mir unter die Augen kommt. Und jedes Mal wenn ich glaube, jetzt habe ich es begriffen, dann passt wieder ein anderes Puzzlestück nicht ins Bild…

        Bei Chrome ist srcset seit V34 drin (aber die Webkit-Implementierung, also „old w“): http://www.chromestatus.com/feature/4644337115725824

        Ab V38 soll dann „picture“ drin sein, gemäß der neuen Spec:
        http://www.chromestatus.com/features/5910974510923776

        Ob sich dadurch auch srcset ändert, das ja Teil der Spec ist, und „the new w“ bekommt, wird da nicht so deutlich. Wie sagte Andy Clarke auf Twitter „Blimey it’s complicated“ ;-)

      • Peter Müller

        Verfasst am 8. September 2014 um 12:08 Uhr.

        Ich habe mir gerade noch mal die Spec zu Embedded Content noch einmal angeschaut: http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content.html#introduction-3

        Dort gibt es folgendes Beispiel zu „Viewport-based selection“:


        <img sizes="100vw"
        srcset="wolf-400.jpg 400w, wolf-800.jpg 800w, wolf-1600.jpg 1600w"
        src="wolf-400.jpg" alt="The rad wolf">

        Im Kommentar darunter steht der Satz „In this example, the sizes attribute could be omitted because the default value is 100vw.“

        Fazit: Dein Beispiel funktioniert, und der Browser geht davon aus, dass er für das Bild den Standardwert von 100vw benutzen soll.

      • Jonas Hellwig

        Verfasst am 8. September 2014 um 12:32 Uhr.

        Hey Peter, vielen Dank für deine Recherche. Deine Kommentare werten den Beitrag noch einmal spürbar auf! :)

  11. Thorvald

    Verfasst am 12. September 2014 um 9:59 Uhr.

    Sehr guter Artikel! Danke!

  12. Joern

    Verfasst am 30. September 2014 um 15:19 Uhr.

    Hmm, also bei mir funktionieren die Beispiele nicht (Google Chrome 39). Muss man da noch was extra einstellen?

    • Jonas Hellwig

      Verfasst am 30. September 2014 um 15:25 Uhr.

      Du musste es möglicherweise noch über eine Flag aktivieren. Die Vorgehensweise wird am Ende des Artikels beschrieben.

  13. Joern

    Verfasst am 1. Oktober 2014 um 14:33 Uhr.

    Okay, wer bis zum Ende liest ist klar im Vorteil… ;)
    Dauert aber dann ja noch wirklich ewig bis zum „Produktiveinsatz“, wenn ich selbst in der Chrome-Entwicklerversion die Sache noch extra anschalten muss.

    • Peter Müller

      Verfasst am 20. Oktober 2014 um 14:49 Uhr.

      In Chrome 38 ist es glaube ich drin, ohne Flag, out of the box.

  14. Sebastian

    Verfasst am 5. November 2014 um 19:46 Uhr.

    Wahnsinns Artikel..!

    Wunderbar erklärt – keine Verständnisprobleme!

    Vielen lieben Dank!

  15. Webdesign Magdeburg

    Verfasst am 10. Dezember 2014 um 6:39 Uhr.

    Danke für diese mühevolle Aufarbeitung dieses Themas.
    Das hat mir in den letzten Jahren doch einiges an Kopfschmerzen bereitet.
    Aber so leicht verständlich aufgearbeitet versteht jetzt jeder das, was ich mir in langer Arbeit selber aneignen musste.

    lg Christian

  16. James

    Verfasst am 26. Dezember 2014 um 12:38 Uhr.

    Schöne Anleitung. Lässt sich das auch irgenwie in WP mit ACF Images in Verbindung bringen, so dass das Ganze dann so aussieht:

    ??

  17. kartinka

    Verfasst am 29. Januar 2015 um 9:34 Uhr.

    Vielen Dank für die hilfreiche Anleitung und die vielen Fall-Beispiele!
    Hier wurde das Thema sehr gut und ausführlich beschrieben. Danke.

  18. Andy

    Verfasst am 2. April 2015 um 11:09 Uhr.

    Wichtiger, denn je ist heute ein Responsive Webdesign, um eine Homepage auf (nahezu)allen Geräten optimal lesbar darzustellen und Ladezeiten zu verkürzen. Die Anleitung ist sehr interessant und auch recht leicht nachvollziehbar. Ich werde mich in Zukunft auf alle Fälle mit diesem Thema befassen, da ich unsere Homepage vor Kurzem auf Reponsive Webdesign umgestellt habe und sie natürlich weiter optimieren möchte.

  19. Daniel

    Verfasst am 28. April 2015 um 9:13 Uhr.

    Hallo, ich habe mich auch im responsiven Design geübt. Sah zum Anfang auch ganz gut aus aber die Seite verschob sich immer mehr um so mehr Tabellen und Frames ich drin hatte. Habe wieder gewechselt in klassisch HTML und lass es auch dabei. Für die Mobile Lösung werde ich einfach eine Mobile Seite schreiben die auch nur über Mobile ansteuerbar ist :-)

    VG sagt Daniel

  20. toni

    Verfasst am 12. Mai 2015 um 11:37 Uhr.

    Ein fantastischer Artikel! Viel Dank dafür!

    wäre aber noch besser validem HTML5-Code

  21. Kim

    Verfasst am 25. Mai 2015 um 15:40 Uhr.

    Hi,

    ein wahnsinns Artikel, vielen Dank!

    Das CMS Contao bietet diese Funktionen seit Version 3.4 an, auch eine einfache Nutzung für Redakteure/Editoren. Wäre toll, wenn diese Info oben unterhalb von WordPress nachgetragen werden könnte :)

  22. sissi

    Verfasst am 6. Juni 2015 um 15:20 Uhr.

    toll aufbereiteter artikel, werde ich sicher öfters mal als gedankenstütze aufrufen -> *bookmarked* :)

  23. Paul Disson

    Verfasst am 20. Juli 2015 um 16:06 Uhr.

    Danke für den Beitrag .
    Ein sehr interessantes Thema und hilfreich noch dazu .

    Liebe grüße
    Paul Disson

  24. Yves

    Verfasst am 28. Juli 2015 um 17:20 Uhr.

    Vielen Dank für den sehr verständlichen Artikel. Nachdem ich mir das video zu „responsive Images“ auf css.tricks angeschaut habe, hat mir dieser Beitrag sehr geholfen.

  25. Stefan

    Verfasst am 10. September 2015 um 8:37 Uhr.

    Vielen Dank für den verständlichen Artikel. Und überhaupt diesen interessanten und hilfreichen Blog.
    Eine (vielleicht nicht nur für mich wichtige) Frage: Wie kann ich die srcset-Technik bei Hintergrundbildern einsetzen/formulieren (url:(…);)? Ich verwende diese Methode, um Text über Bilder laufen zu lassen. Danke vorab!

  26. Jürgen

    Verfasst am 24. September 2015 um 11:40 Uhr.

    Hallo Jonas,

    danke für das öffentliche dokumentieren, sowie die mündliche Weitergabe deines Wissens über diverse Vorträge.

    Ich setze das picture Element auch auf einer Webseite ein. Das funktioniert soweit auch ganz gut. Allerdings stört mich die erste halbe Sekunde während die Webseite lädt (z.B. im chrome). An der Stelle wo das picture Element ist, befindet sich nämlich ein leerer Raum (ohne Höhe und Breite). Dadurch wird der untere Seiteninhalt hochgezogen. Sobald das Bild ermittelt und geladen ist, wird das Bild angezeigt und der Seiteninhalt wieder runtergeschoben. Jetzt ist alles wieder in Ordnung. Gibt es hierfür eine einfache schöne Lösung?
    Wenn das Bild über ein picture Element geladen wird und ein Seitenverhältnis von z.B. 16:9 hat und sich responsive skaliert (Breite und Höhe passen sich dem Bildschirm an), dann sollte der Platz freigehalten werden und zwar in der Größe des nachzuladenden Bildes, so das der Inhalt nicht kurzfristig springt.

    Viele Grüße
    Jürgen

  27. Tatjana König

    Verfasst am 5. November 2015 um 9:16 Uhr.

    Super umfangreich! Vielen Dank dafür!

  28. Martin

    Verfasst am 10. Dezember 2015 um 13:56 Uhr.

    Super Artikel und verständlich erklärt – Daumen hoch! :)

  29. Ralf Behnke

    Verfasst am 30. Dezember 2015 um 20:12 Uhr.

    An solch einem ausführlich und verständlich dargestelltem Artikel können sich so einige Fachbücher ein Beispiel nehmen.
    Große Klasse!!!
    Bitte weiter so, auch im nächsten Jahr und vielen Dank.

  30. Andreas

    Verfasst am 7. März 2016 um 21:32 Uhr.

    Hallo Jonas,
    danke für deinen wie immer tollen Info-Artikel.
    Bei den neuesten Diskussionen zu Responsive Images vermisse ich jedoch immer wieder den Aspekt der Performance. Es geht irgendwie nur noch um Lösungen, die Bilder den immer höher auflösenden Displays anzupassen (Stichwort Retina). Aber was ist mit den Ladezeiten? Ich habe in der vergangenheit mit allen möglichen Plugins für WordPress und diversen Bildgrößen herumgetestet, um meine Homepage-Bilder möglichst optimal anzubieten. Doch selbst wenn ich Bilder wohlmeinend in mehreren Größen von 150 – 1000 px erstelle, wird so oder so das größte Bild geladen, aufgrund der irren Auflösungen der heutigen Displays.
    Wird also die Frage der Ladezeiten immer unwichtiger? Muss ich denn nicht nach wie vor berücksichtigen, dass Handy-User unterwegs im Mobilfunknetz und eben nicht mit schnellem WLAN surfen? Was nützen mir superscharfe und -große Bilddateien mit mehreren MB, die ewig laden?
    Ich bin ehrlich gesagt etwas ratlos, wie ich zukünftig vorgehe. Aus meiner Sicht ist es vernünftiger, die Bilddatei klein zu halten, auch wenn das Bild dann auf einem Retina-Display nicht mehr 100% sondern nur noch 98% toll aussieht.
    Konkret gefragt: brauche ich unter diesen Umständen überhaupt Plugins wie RICG oder Adaptive Images?
    Gruß, Andreas

    • Jonas Hellwig

      Verfasst am 8. März 2016 um 10:16 Uhr.

      Hallo Andreas, vielen Dank für deinen Kommentar. Die Performance ist ein zunehmend wichtiger Faktor, daher stellt die Retina-Optimierung in der Tat ein Problem dar. Mit Hilfe eines Tricks kann man allerdings Bilder in Retina-Auflösung von der Dateigröße her unter die Dateigröße von normalen Bildern bekommen. Das ist möglich, indem man die Retina-Variante als JPG speichert und extrem start komprimiert. Die entstehenden JPG-Artefakte werden durch das Downsampling (oben in diesem Beitrag erklärt) optisch reduziert.

      • Andreas

        Verfasst am 8. März 2016 um 11:04 Uhr.

        Hallo Jonas, danke für deine Antwort. Würdest du denn sagen, dass man bzgl. der Responsive-Lösungen zukünftig alle Bildgrößen unterhalb von 1000 px Breite getrost ignorieren kann? Oder andersherum, dass man nur noch 1000px und aufwärts implementieren sollte, da kleine Bilder nur noch von den allerwenigsten Handys geladen werden?

  31. Thomas

    Verfasst am 28. April 2016 um 17:34 Uhr.

    Ich danke Ihnen für diesen informativen Beitrag. Das responsive Design wird ja immer wichtiger und ist kaum noch aus dem modernen Webdesign wegzudenken. Bei Bildern gibt es viele Dinge die man falsch machen kann. Ihr Artikel gibt da sehr gute Hilfestellungen, die auch anschaulich erklärt sind.

  32. KIim

    Verfasst am 4. September 2016 um 18:50 Uhr.

    Hallo,

    Vielen Dank für die Tollen und ausführlichen Beitrag. Wir haben versucht bei unserem Onlineshop http://www.wasdazu.ch/ die Bilder Dynamisch für Mobile Geräte darzustellen. Leider erfolglos. Zur Zeit lösen wir das Problem so, das wir die Bilder nur in kleinen Format abspeichern… somit passt es für alle Displaygrösse :) .. Für Langfristig ist das keine Lösung. Wir versuchen die Lösung wie oben dargestellt nach zu bilden.. hoffe es klappt danach reibungslos : )

    Lieben Grüsse

    Kim

  33. Daniel

    Verfasst am 15. Dezember 2016 um 9:22 Uhr.

    Hallo Jonas,

    super Artikel, vielen Dank dafür. Ich habe folgendes Problem. Ich versuche in WordPress (Visual Composer) Deinen Code

    einzubinden. Dafür nutze ich die Funktion Ungefiltertes HTML. Auf dem Desktop funktioniert das auch. Den Browser kann ich zusammen- und auseinanderziehen und das Bild ändert die Größen.

    Allerdings wenn ich das auf meinen Samsung S7 in Chrome anschauen möchte, zeigt er mir an der Stelle kein Bild an. Woran kann das liegen?

    Ich habe 3 verschiedene Bildgrößen
    1. 1920×240
    2. 800×340
    3. 400×340

    Auf Deine Antwort freue ich mich.

    VG Daniel

    • Jonas Hellwig

      Verfasst am 15. Dezember 2016 um 9:54 Uhr.

      Hallo Daniel, es könnte daran liegen, dass der Browser deines Smartphones keine responsive Images unterstützt und du keine Fallback-Lösung eingebaut hast. Aber im Zusammenhang mit dem Visual Composer ist alles möglich, da kann ich keine Aussage zu treffen.

      • Daniel

        Verfasst am 15. Dezember 2016 um 18:16 Uhr.

        Hallo Jonas, danke für die Rückmeldung. Ich werde es weiter versuchen :-)

      • Daniel

        Verfasst am 15. Dezember 2016 um 20:03 Uhr.

        Also ich glaube ich komme der Sache näher. Ich habe Deinen Picture Code inkl. Fallback Lösung im ganz normalen WordPress Text eingefügt. Jetzt lädt mir sowohl Safari als auch Chrome auf dem iPad die Bilder nicht. Ich glaube es liegt daran, dass ich PICTUREFILL VERSION 3.0.2 nicht auf meiner WordPress Installation habe. Es wäre super, wenn Du/jemand mir sagen kann wo ich picturefill.js reinladen muss. Den Code von dir Jonas habe ich schon im Header drin.

        Danke im Voraus.

        Daniel

      • Daniel

        Verfasst am 15. Dezember 2016 um 22:19 Uhr.

        Hab es geschafft. Danke :-)

        Musste in dem Code


        // Picture element HTML5 shiv
        document.createElement( „picture“ );

        anstelle picturefill.js folgenden Link einfügen „https://cdn.rawgit.com/scottjehl/picturefill/3.0.2/dist/picturefill.js“

  34. Andre Kremer

    Verfasst am 27. Januar 2017 um 20:14 Uhr.

    Lieber Jonas,

    es ist zwar etwas länger her, aber ich habe einen Korrekturvorschlag:

    Bei #chapter7 (Art Direction – Das Motiv verändern) funktioniert es nur im Browser, nicht auf Mobilgeräten. Lösung:

    Evtl. in lowercase schreiben ;-)

    Grüße nach Berlin
    Andre

  35. Michael Lengenfelder

    Verfasst am 26. März 2017 um 21:35 Uhr.

    Hi,
    das Beispiel:
    https://media.kulturbanause.de/2014/09/responsive-images/srcset-sizes-3.html
    funktioniert bei mir am Chrome 57 nicht, das Bild medium.jpg wird bereits bei einem Viewport von 220px geladen. Lt. dem Code sollte es erst nach 320 geladen werden.

    Gruß

    • Bernhard

      Verfasst am 20. Juli 2017 um 11:03 Uhr.

      Inzwischen habe ich den Chrome 59 und es wird nur das Bild „Large“ geladen – egal bei welchem Viewport und auf welchem Gerät. Also kann man die Methode mittels w-Wert vergessen.

  36. Michael Lengenfelder

    Verfasst am 20. Juli 2017 um 12:34 Uhr.

    Ja, kann ich bestätigen.

  37. Jonas Hellwig

    Verfasst am 20. Juli 2017 um 12:37 Uhr.

    Bei mir funktioniert nach wie vor alles so wie es soll. Allerdings werden keine kleineren Versionen eines Bildes mehr nachgeladen, wenn der Browser schon eine größere Version im Cache hat. Wenn ihr den Cache deaktiviert, sollte es klappen.

    • Michael Lengenfelder

      Verfasst am 20. Juli 2017 um 12:43 Uhr.

      Leider nein, man sieht am Header, dass er das Bild neu vom Server holt. Immer das large.jpg

    • Michael Lengenfelder

      Verfasst am 20. Juli 2017 um 12:43 Uhr.

      Chrome:
      Version 59.0.3071.115 (Offizieller Build) (64-Bit)

      • Bernhard

        Verfasst am 21. Juli 2017 um 6:29 Uhr.

        Hallo, er macht es doch. Und es hat mit dem Cache zu tun. Wenn man mehrmals! Shift + F5 drückt merkt der Chrome es irgendwann das sich der Viewport Verändert hat und lädt die richtige Grafik.

      • Michael Lengenfelder

        Verfasst am 21. Juli 2017 um 8:03 Uhr.

        Hi, so, jetzt kommt medium.jpg.

        Man muss den Chrome oben in der Developer-Ansicht auch ‚Responsive‘ einstellen, dann spielt er auch mit. Standard bei mir war Galaxy S5, damit geht es nicht. … auch nicht nach 20mal Shift-F5. Passt..

Kommentar verfassen

Dieser Blog lebt vom Feedback der Besucher! Also los, mach mit!
Bitte habe Verständnis dafür, dass Kommentare die mit dem Inhalt dieses Beitrags nichts zu tun haben, gelöscht werden.