Image mit srcset

Das Bild 1 benutzt (ganz klassisch) das img-Tag mit srcset und kommt aus einem Typo3 Default-Contentelement vom CType 'image', ist also vom Editor pflegbar. Das Bild sitzt in einer 50% breiten Spalte, auf kleineren Bildschirmen bricht es dann auf 100% Breite um.

Wenn man den Code unten anschaut, der das Bild generiert (oder die Debug-Ausgaben im Bild), dann wird klar, wo das Problem bei diesem Ansatz liegt: weil das Partial an allen Stellen verwendet wird, an denen Bilder von verschiedenen Contentelementen im Backend eingebunden werden, weiss der Entwickler nicht, wie breit das Bild dargestellt werden wird, wenn der Editor es frei in Spalten stecken kann. Also gebe ich dort für das sizes Attribut das immer sichere '100vw' an, das dem Browser sagt: "das Bild wird immer 100% breit dargestellt". Das stimmt für Displays < 768px, dort bricht die Spalte um und das Bild ist (annähernd, abzüglich Rand) 100% breit. Ab 768px wird das Layout aber zweispaltig, das Bild ist jetzt nur noch um die 50% breit. Die Lösung ist erstmal einfach: richtiges sizes-Attribut mitgeben und dem Browser genau das mitteilen, damit er für jede Bildschirmgrösse ein Bild in der passenden Größe auswählen kann: sizes="(max-width:767px:100vw),50vw". Nur: wollen wir das unsere Editoren, die erstmal einzigen sind, die wissen, wie gross das Bild auf verschiedenen Viewports dargestellt werden wird) so ins Backend schreiben lassen? Siehe Bild 2 für ein img/srcset mit korrektem sizes-Attribut bei dem wir auch noch die Margin links und rechts beachten.

Das Fluid dazu sieht so aus, es wird (ganz normal) der f:media viewhelper verwendet. Das srcset-Attribut wird vom ai:getSrcset Viewhelper generiert:

<f:media file="{file}"
         class="image-embed-item img-responsive"
         width="{dimensions.width}"
         alt="{file.alternative}"
         title="{file.title}"
         data="{
            'img-debug':'{jsdebug}'
         }"
         additionalAttributes="{
            'sizes': '{sizesAttr}',
            'srcset': '{ai:getSrcset(file:file, widths:\'360,580,720,1024,1440,1920\', debug:debug)}'
         }"
/>

Bei diesem Bild stimmt das sizes Attribut nun, Bei Berücksichtigung der Ränder links und rechts (15px bei kleiner 768px, sonst 30px) ist das Attribut nun:

 

(min-width:768px) calc(50vw - 30px),calc(100vw - 45px)

 

aka: "Lieber Browser. Wenn deine Breite mindestens 768px ist, dann wird das Bild 100vw minus 45px breit sein. Wenn kleiner, dann ist es 100vw minus 30px breit." Der Browser kann sich nun aus den Kandidaten, die wir ihm mit dem sources-Attribut mitteilen den am besten passenden Kandidaten aussuchen (und dabei z.B. auch die Pixel-Density berücksichtigen).

Easy, oder? Das Bild wird nun immer in der korrekten Grösse geladen. Nur:

Das sizes Attribut hab ich mir hier jetzt für diese Demo kurz im Backend eingebaut. Für ne Demo: ok. Für Editoren: nur sehr erfahrenen und leidensfähigen zumutbar. Zumal: verschiebt man ein Element in eine andere Spalte oder ändert das Seitenlayout, dann muss wahrscheinlich auch der Wert des sizes Attributs angepasst werden.

 

Plus

  • relativ einfache Syntax, wenn man sie einmal verstanden hat
  • w3c Standard
  • geht in allen modernen Browsern und ohne JavaScript

Minus

  • man muss das Layout bei verschiedenen Breakpoints kennen um dem Browser mitzuteilen, in welcher Größe das Bild auf welcher Bildschirmgröße dargestellt wird. Schwierig realisierbar bei dynamisch pflegbaren Inhalten
  • keine Art Direction möglich, also z.B. unterschiedliche Bildbeschnitte je nach Anzeigegerät

Wann verwenden?

  1. Wenn man die Größe eines Bildes über die Breakpoints hinweg sicher kennt, z.B. ein Header-Bild, das immer 100% breit sein wird, weil der Editor es im Idealfall nur so verwenden darf
  2. wenn keine Art-Direction benötigt wird