Über Responsive Bilder

Es gibt einen echten Bedarf, Medien zu liefern, die für das Gerät und die Umstände geeignet sind, da wir so wenig wissen über eine bestimmte Webanfrage. Ich habe kürzlich einen Blogbeitrag mit so vielen Bildern darauf veröffentlicht, dass die Seite 2,29 MB wog. Ich hätte eine Warnung posten sollen, als ich ihn getwittert habe: „Klicken Sie hier nicht, wenn Sie in einem 3G-Netzwerk sind, es wird wahrscheinlich ewig dauern, schauen Sie es sich einfach an, wenn Sie nach Hause kommen.“

Idealerweise hätten all diese Bilder, die ich serviert habe, eine Version mit niedrigerer Auflösung haben können, die in Browsern mit kleineren Fenstergrößen und/oder langsameren Verbindungsgeschwindigkeiten angezeigt wird. Selbst in Spitzenbrowsern gibt es noch keine native Möglichkeit, dies zu tun. Es ist also eine gute Zeit, darüber zu sprechen, wie wir uns das als Web-Entwickler vorstellen. Vielleicht können wir beeinflussen, wie sich die Spezifikation gestaltet.

Beschränken wir diese Konversation auf Inline-Rasterbilder. Also, die Dinge, die heute als <img> serviert werden. Soweit ich sehe, gibt es drei Wege, die wir gehen können.

1. Erstellen Sie ein neues Element, das nur dazu dient, dieses Problem zu lösen.
2. Erstellen Sie ein neues Bildformat, das entwickelt wurde, um dieses Problem zu lösen.
3. Tun Sie nichts, lösen Sie unsere Probleme mit anderen Technologien.

Jeder von ihnen hat Vor- und Nachteile. Schauen wir uns jeden einzelnen an.

Neues Element erstellen

Der wahrscheinlichste Kandidat ist <picture>, wie hier in der W3C-Community diskutiert. Scott Jehl hat ein JavaScript-Polyfill, das seine Funktionalität nachahmt. Die Syntax wäre

<picture alt="description of image">

  <!-- low-res, default -->
  <source src="small.jpg">

  <!-- med-res -->
  <source src="medium.jpg" media="(min-width: 400px)">

  <!-- high-res -->
  <source src="large.jpg" media="(min-width: 800px)">

  <!-- Fallback content -->
  <img src="small.jpg" alt="description of image">

</picture>

Vorteile

• Nachahmt andere Medien-Syntaxen wie <video> und <audio>, was Sinn ergibt.
• Der Fallback macht es rückwärtskompatibel mit Browsern, die es nicht unterstützen, was äußerst wichtig ist. Wir können keine Bilder haben, die in älteren Browsern einfach nicht funktionieren.
• Gibt uns Webautoren die Kontrolle, genau das anzuzeigen, was wir wollen, unter den von uns festgelegten Bedingungen.

Nachteile

• Es ist wesentlich komplizierter als <img>. Schwerer zu lehren, schwerer zu lernen, mehr Code zu schreiben. Leicht zu vermasseln.
• Trübt das Wasser von CSS und HTML ein wenig, indem die Media-Query-Syntax in HTML gebracht wird.
• Ähnliche Probleme wie bei Inline-Styles. Erschwert zukünftige Updates. Keine wiederverwendbare Abstraktion.

Neues Bildformat

Der Anstoß für diesen Blogbeitrag kam von Gesprächen, die ich mit Christopher Schmitt und einem von ihm geschriebenen Blogbeitrag hatte. Christopher ist der Meinung, dass ein neues Bildformat die ideale Lösung ist.

Dieses neue Bildformat hätte im Wesentlichen mehrere Versionen davon.

Welches Bild von einem Programm wie einem Webbrowser geliefert wird, ist eine Entscheidung, die durch einen virtuellen Händedruck zwischen dem Browser und dem Webserver getroffen werden kann.

Vielleicht kostet die Datei insgesamt 800 K, aber darin befinden sich vier verschiedene Versionen: 500 K, 200 K, 50 K, 10 K. Durch eine standardisierte Regelung würde eines dieser vier Bilder übermittelt und vom Browser angezeigt werden.

Klingt wie Fantasie? Es gibt bereits ein solches Bildformat namens FlashPix, das noch drastischere Versionierungen ermöglicht. Denken Sie, neue Bildformate sind unmöglich zu implementieren? WebP gewinnt mit anständiger Geschwindigkeit an Unterstützung.

Letztendlich bleibt die Syntax so, wie sie jetzt ist

<img src="unicorn.rpng" alt="fancy unicorn">

Ich habe diese Dateiendung erfunden, aber „responsive PNG“ wäre mir recht.

Christopher mag diesen Ansatz, weil

er die fortgesetzte Nutzung des IMG-Elements ermöglicht, das in den Knochen, dem Mark des Webs, verankert ist.

Ich mag dieses Denken. Kein Grund, sich von einem Element abzuwenden, das so lange gut funktioniert hat. Aber natürlich würden wir das nicht tun. Es gibt keinen Grund, <img> zu ersetzen, nur darauf aufzubauen und Alternativen anzubieten.

Vorteile

• Hält die Syntax einfach. Funktioniert so, wie es immer war.
• Hält auch die Erstellung einfach. Eine Datei, nicht mehrere. Die Akzeptanz wäre wahrscheinlich schneller und mehr Leute würden es tatsächlich tun (weniger Leute würden 4 Versionen jedes Bildes erstellen und Abfragen zum Servieren handwerklich gestalten).

Nachteile

• Möglicher Kontrollverlust. Um die Dinge einfach zu halten, würde das Bildformat die Logik dessen übernehmen, was genau serviert wird. Wird es immer die richtige Entscheidung treffen? Was berücksichtigt es? Elterncontainerbreite? Netzwerkverbindungsgeschwindigkeit? Eine Kombination?
• Nicht rückwärtskompatibel. Was passiert in Browsern, die das neue Format nicht unterstützen?

Andere Technologien

Wir könnten uns sicher auf JavaScript verlassen, um uns hier zu helfen. Es könnte uns zum Beispiel mit dem neuen Bildformat helfen. Wir würden normale PNGs und JPGs in unserem <img> verwenden und die src eine Weile gegen das neue Format austauschen, bis das neue Format universell unterstützt wird. Vielleicht etwas übertrieben, aber machbar.

Und wenn es das kann, vielleicht sollten wir es einfach das ganze Problem lösen lassen. JavaScript kann all die „Tests“ durchführen, die wir wahrscheinlich brauchen (z. B. Fenstersizing-Tests, Netzwerkgeschwindigkeits-Tests), und es könnte für den Austausch unserer src mit passenderen verantwortlich sein. Die foresight.js von Adam Bradley Bibliothek macht das bereits. Vielleicht ist das, wofür JavaScript da ist, und wir müssen uns nicht einmischen.

Denken Sie, dass die Client-seitige Natur von JavaScript nicht ideal ist? Es gibt ein paar Lösungen, die Dinge serverseitig machen.

Adaptive Images von Matt Wilcox ist eine unglaublich clevere Lösung, die ein winziges bisschen JS verwendet, nur um die aktuelle Bildschirmgröße zu messen und einen Cookie zu setzen, und dann werden alle Anfragen für Bilder durch etwas PHP geleitet, das bestimmt, welche Version eines Bildes serviert wird, passend zur Bildschirmgröße.

Sencha.io Src ist eine weitere Lösung, die komplett JavaScript-frei ist. Sie führt UA-Sniffing durch, um das Gerät zu bestimmen und entscheidet, welche Bildgröße basierend darauf serviert wird. Sie fügen einfach die Sencha-Service-URL vor die src des Bildes

<img src='//src.sencha.io/http://mywebsite.com/images/unicorn-hires.jpg' alt="unicorn" />

Das ist die einfachste mögliche Nutzung, sie kann viel ausgefeilter sein. Es ist jedoch ein Beta-Dienst eines Drittanbieters, also seien Sie sich der inhärenten Bedenken bewusst (z. B. wenn sie ausfallen, werden Ihre Bilder nicht geladen). Ich stelle mir vor, dass es letztendlich ein kostenpflichtiger Dienst sein wird.

Vorteile

• Wir bringen die Standarde nicht durcheinander.
• Kein Warten darauf, dass Browser etwas Neues unterstützen.

Nachteile

• Ignorieren wir damit einfach das Problem? Sollen Standards nicht bei echten Problemen helfen?
• Der Code, der benötigt wird, um dies richtig zu machen, ist übertrieben.

Wo ich lande

Sich auf ältere Technologie und Hacks zu verlassen, reicht mir nicht, aber ich kann nicht entscheiden, ob ich ein neues Format oder eine neue Syntax bevorzuge. Vielleicht beides? Vielleicht eine Hybridlösung? Ich denke, die Syntax ist wahrscheinlicher, weil mehr darüber diskutiert wird. Ein Format ist eine viel größere Aufgabe, und ich habe kein Flüstern über aktive Entwicklung in dieser Richtung gehört.

Es wird ein lustiger Tag sein, an dem ich diesen Blogbeitrag mit „offiziellen“ Best Practices aktualisieren kann!

Verwandt

• Brad Frost: Optimierung von Web-Erlebnissen für hochauflösende Bildschirme
• W3C: Responsive Images Community Group
• Tim Kadlec: Tests zu Media Queries & Asset-Downloads