Responsive Images sind zur Zeit in aller Munde und verursachen viel Streit. Was steckt dahinter und wert streitet mit wem? Zeit für einen Überblick von jemandem, der mitten drin steckt und selbst an der Entwicklung von Entwürfen zum Thema beteiligt war. Ein Gastbeitrag von Anselm Hannemann.
Im Juli letzten Jahres kam die Diskussion um responsive images in Webseiten auf. Wir können zwar mittlerweile die tollsten Layouts für verschiedene Endgeräte optimieren, aber die inhaltlichen Bilder (<img>
-Elemente) bleiben dabei immer die gleichen. Und damit hat man natürlich einen großen Nachteil: Große Bilder für Desktopauflösungen werden auch bei Mobilgeräten in voller Dateigröße geladen. Andersherum kann für ein mobile optimiertes Bild kein qualitativ passendes Bild auf ein iPad3 mit HighRes-Display ausgegeben werden. Deshalb waren mehrere Leute der Meinung, dass Bilder ebenfalls responsiv werden müssen.
Historie und Initiativen
Die eine Fraktion der Interessierten wollte direkt ein streamendes Bildformat, was durchaus eine sehr gute und anstrebenswerte Lösung wäre. Allerdings werden damit Randbereiche wie andere Bildausschnitte nicht abgedeckt. Außerdem würde das neue Format wohl erst in frühestens zehn Jahren überall einsetzbar sein. Die andere Fraktion hingegen beschränkte sich auch deshalb auf HTML und CSS als Möglichkeiten. Zu dieser Fraktion gehörte auch ich und deshalb veröffentlichte ich in der Diskussion über das Problem und mögliche Lösungen auf der WHATWG-Mailingliste Ende Juli 2011 folgenden Vorschlag:
<img
src="http://cdn.url.com/img/myimage_xs.jpg"
media-xs="(min-device-width:320px and max-device-width:640px)"
media-xs-src="http://cdn.url.com/img/myimage_xs.jpg"
media-m="(min-device-width:640px and max-device-width:1024px)"
media-m-src="http://cdn.url.com/img/myimage_m.jpg"
media-xl="(min-device-width:1024px)"
media-xl-src="http://cdn.url.com/img/myimage_xsl.jpg"
/>
Dieser wäre prinzipiell mit alten Browsern kompatibel gewesen, da er auf dem bereits existenten img
-Element basiert und gleichzeitig eine einfache Syntax für alternative Ressourcen enthält – diese würden über über ganz normale CSS3 @media-queries angesteuert.
Der große Nachteil bei dieser Lösung ist, dass das bisher bekannte src
-Attribut nach aktueller Logik der Browser immer geladen werden würde. Im Zweifelsfall lädt der Browser also zunächst das in src
referenzierte Bild (das immer das kleinste Format sein sollte) und zusätzlich das passende höher auflösende Bild. Es würden also zusätzliche HTTP-Requests und mehr Datenmengen anfallen, als eigentlich erforderlich. Dies könnte jedoch für moderne Browser aufgehoben werden, wenn die Browserhersteller bei der Implementierung berücksichtigen. Hier war zumindest von Browserseite schnell eine ablehndende Haltung vorhanden, da angeblich größerer Aufwand nötig sei.
Nach ein paar Antworten schlief die Diskussion in der WHATWG Mailing Liste jedoch schnell ein. Das schlimme daran war jedoch, dass viele damals der Meinung waren, dass solch eine Lösung nicht gebraucht werde, da ja offenbar kein Bedarf für responsive images da sei. In diesem Zuge schrieb Ian Hickson selbst im Januar noch
What’s the use case for doing it for images in <img> elements? Typically <img> elements are for content images, where you don’t usually want to adapt anything.
Im Nachhinein ist diese Entwicklung insofern fatal, als dass einige dieser Leute nun im Mai 2012 einen First Draft für die WHATWG veröffentlicht haben. Als ich aber unterwarteterweise im Oktober 2011 wieder auf das Thema angesprochen wurde und auch mehrere Leute wieder anfingen über das Thema in Blogbeiträgen zu diskutieren, wendete sich zunächst das Blatt. Erneut kam das Thema auf die WHATWG-Mailingliste, wiederum jedoch nicht wirklich mit großer Resonanz.
Gründung der W3C Community Group "Responsive images" und das <picture>-Element
Plötzlich wurde im Februar 2012 dann vom W3C eine Community Group "Responsive images" eingerichtet. Eine Community Group ist eine Plattform, auf der jeder, der mitmachen möchte, über spezifische Probleme mit HTML/CSS diskutieren kann. Damit war endlich ein Ort geschaffen, an dem sinnvoll über Vor- und Nachteile der diversen Code-Vorschläge und der zu eruierenden Funktionalitäten und Eigenschaften diskutiert werden konnte. Schnell wuchs die Gruppe auf über 70 Teilnehmer heran, rege Diskussionen wurden geführt, Lösungen vorgeschlagen und verworfen. Letztlich blieb nur noch ein Vorschlag übrig: das <picture>
-Element. Dabei handelt es sich um ein komplett neues Element, das kein Standard-Browserverhalten mitbringt, wie es das bisherige img-Tag macht, das aber eben mehrere Ressourcen beinhalten kann. Die dazugehörige Syntax sollte wie folgt aussehen:
<picture alt="Alt tag describing the image represented">
<source src="photo.jpg" />
<source src="photo@2x.jpg" media="min-device-pixel-ratio:2" />
<img src="photo.jpg" />
</picture>
Es handelt sich also um eine Liste an Bildern in <source>
-Elementen, angereichtert und abgefragt nach Media Queries, plus ein mögliches Fallback-img-Tag am Ende für ältere Browser. Der Vorteil dieser Technik ist, dass Bilder nicht automatisch geladen werden und nur das angefordert wird, was wirklich nötig ist. Das funktioniert sogar bereits, denn Scott Jehl hat hierzu auf GitHub den sogenannten picturefill entwickelt, einen Polyfill für das <picture>
-Element. Sogar eine eine Methode zum bereits heute standardkonformen Einsatz gibt es. Diesen Vorteilen stehen aber auch einige ungelöste Probleme gegenüber.
Da wäre zum Beispiel die Frage der Ladezeit bei Geräten mit hoher Auflösung. Bloß weil ein iPad3 mit hochauflösendem Display ein Bild anfordert, ist ja noch lange nicht gesagt, dass dieses auch schnell geladen wird. Ist man beispielsweise per GPRS unterwegs, was zumindest in Deutschland dank knapp bemessener „Flatrates“ häufig der Fall ist, so möchte man vielleicht auch auf einem Highres-Bildschirm die kleine Variante des Bildes haben. Da stößt man nun mit den bisher zur Verfügung stehenden Media Query-Abfragen auf Probleme, denn eine Bandbreitenabfrage ist für einen Browser extrem schwierig durchzuführen. Auch die Syntax ist nicht unproblematisch; schließlich ist der ganze Spaß mit einigem Mehraufwand verbunden, wenn ich für jedes Bild mehrere Ressourcen angeben muss und für jede Ressource noch Media Queries festlegen muss.
Matthew Willcox beschäftigte sich deshalb intensiv in den letzten Wochen mit Möglichkeiten, die Media Query-Vergabe zu automatisieren. Am 13. Mai 2012 brachte er einen umfassenden Lösungsansatz heraus, der vorsieht, dass in <meta>
-Tags eine Art Template festgelegt wird und mit (noch zu spezifizierenden) HTML-Variablen diese Template-Variablen in den Ressourcenlisten eingesetzt werden können. Auch wenn ich persönlich dem konkreten Vorschlag nicht ganz zustimme: ein Templateverhalten in <meta>
-Tags festzulegen wäre eine Möglichkeit mit Variablen schnell und einfach HTML zu schreiben. Das wäre nicht nur für das <picture>
-Element sehr praktisch sondern auch für viele andere Anwendungen. Willcox‘ Ansatz sieht im HTML folgendermaßen aus:
<head>
<meta name="case" data="breakpoint1" media="min-width:350px" />
<meta name="case" data="breakpoint2" media="min-width:1000px" />
</head>
<body>
<img src="/content/images/{case}/photo.jpg" alt="" />
</body>
Im CSS ist dazu noch folgendes Format vorgesehen: Statt
@media only screen and (min-width: 700px) { ... }
soll nun
@media (case: breakpoint1) { ... }
geschrieben werden können.
WHATWG Vorschlag: responsive images via srclist-Attribut
Zum Streitpunkt wurde das Thema responsive images, als die WHATWG am 15. Mai einen ganz eigenen Entwurf für responsive images online stellte. Das kam sehr überraschend für die meisten – auch für mich, zumal man selbst auf den WHATWG-Mailinglisten vorab nicht allzuviel darüber lesen konnte. Ich war ehrlich gesagt etwas vor den Kopf geschlagen, als ich von diesem Entwurf hörte; hauptsächlich, weil die Syntax, die der Vorschlag verwendet, extrem unübersichtlich und HTML-untypisch ist:
<img src="face-600-200@1.jpeg" alt=""
set="face-600-200@1.jpeg 600w 200h 1x,
face-600-200@2.jpeg 600w 200h 2x,
face-icon.png 200w 200h">
Als Kurzsyntax:
<img src="logo.png" alt="SampleCorp" set="logo-HD.png 2x">
Die Angabe 600w 200h
ist nicht, wie man vielleicht vermuten würde, eine Größenangabe des Bildes (so war es ja im <img>
-Tag immer gewesen), sondern die Angabe der Viewportgröße. Das heißt, hier wird eine Art Mini-Media-Query angegeben. Für mich birgt allein das schon ein extrem großes Fehlerpotential für den normalen Webentwickler.
Zudem gibt es eine auflösungbasierte Angabe @1x
oder @2x
, mit der die Auflösungen notiert werden. Bietet man @1x
also mit 96ppi an, muss man @2x
automatisch mit 192ppi bereitstellen. Auch hier entsteht eine weitere Fehlerquelle. Und es gilt am Ende immer noch das Prinzip: der Nutzer muss ausbaden, was der Entwickler falsch gemacht hat. Wird diese Syntax also genauso eingeführt muss man befürchten, dass Entwickler Fehler generieren, die dazu führen, dass ein User auf eine Smartphoneseite mit einem LowRes-Gerät geht und ein HighRes-Bild ausgeliefert bekommt oder ähnliche Szenarios. Das wäre fatal und sollte wenn irgendwie möglich vermieden werden.
Das Resultat dieser Aktion der WHATWG war vorhersehbar: die Web-Community stand innerhalb von wenigen Stunden Kopf, wobei das vielleicht größte Problem an dieser Geschichte die Kommunikationsweise der WHATWG war. Ich versuche nun mein Bestes, die hunderten von E-Mails, Blogposts und dazugehörigen Kommentare zu sortieren und einzuordnen.
Das Kommunikationsproblem, was passierte und wie es dazu kam
Mehrfach hatte ich mit einigen Community-Membern den Versuch unternommen Browser-Hersteller mit in die Community-Group einzubinden. Der Erfolg war mäßig, denn außer einem Opera-Mitarbeiter meldete sich überhaupt niemand zu Wort, weder von Apple (Safari) noch von Google (Chrome), Mozilla (Firefox) oder Microsoft (Internet Explorer). Und nun, nachdem die Community Group mehrere Monate verschiedene Lösungswege durchdacht und sogar praktisch getestet hatte, wird kommentarlos ein komplett eigener Entwurf angenommen! Dieser kam übrigens von Apple – Apple hatte bereits zur iPad3-Einführung eine etwas eigenwillige CSS4 Responsive Images-Lösung eingeführt.
Leider scheint man in der WHATWG nicht einmal von der Existenz der Community Group etwas mitbekommen zu haben. Das jedoch kann ich mir schwerlich vorstellen, hatten wir nicht nur WHATWG-Mitglieder direkt angesprochen, sondern auch diverse Fachblogs und -portale, die darüber berichteten. Nebenher tauchte der Link zur Gruppe auch in den WHATWG-Mailinglisten auf. Dennoch wurde der Spezifikationsentwurf veröffentlicht und zunächst einmal gar nicht auf andere Vorschläge eingegangen. Das führte unweigerlich auch zu verbalen Auseinandersetzungen, die sicher vermeidbar gewesen wären.
Am 16. Mai hat sich zumindest Tab Atkins (Google) zu Wort gemeldet und versuchte die Wogen zu glätten. Seltsamerweise hat jedoch kaum jemand auf die Argumente, die gegen diese Sourcelist-Version der WHATWG sprechen, geantwortet. Ich denke, hier wird das letzte Wort auch nicht gesprochen sein, es wird viele lange Diskussionen geben, wie es sie bereits vor knapp einem Monat zur Vendor-Prefix-Debatte gegeben hat. Nicht zuletzt hat das W3C angekündigt, die Problematik bei ihrem nächsten Treffen (wöchentlich) anszusprechen und sich ihrer anzunehmen.
Mein Zwischenfazit
Ich persönlich hoffe, dass es in Zukunft eine sinnvoll strukturierte, für jeden Entwickler anwendbare Syntax für responsive Bilder geben wird und nicht einmal mehr sich die Browserhersteller mit einer schnell umzusetzenden Lösung auf Kosten der Entwickler durchsetzen. Das bedeutet aber auch, dass die Lösung noch ein wenig mehr Zeit einnehmen wird, bevor sie richtig eingesetzt werden kann. Doch gut Ding will bekanntlich Weile haben.
Über den Autor
Anselm Hannemann ist selbständiger Webentwickler, Digital Publishing-Experte und Vorkämpfer in Sachen Webstandards für Responsive Images.
Kommentare (10)
Sven Wolfermann ¶
22. Mai 2012, 15:27 Uhr
Schöne Zusammenfassung! Was mir aber zum allgemeinen Verständnis geholfen hatte war der Blogbeitrag von Jason Grigsby http://blog.cloudfour.com/the-real-conflict-behind-picture-and-srcset/ – ich hoffe, dass es bald eine vertretbare und und möglichst einfache Lösung geben wird, die dann auch irgendwann in vielen (wenigstens mobilen) Browsern genutzt werden kann.
florian tolk ¶
22. Mai 2012, 17:16 Uhr
Die Lösung der WHATWG ist faszinierend ... dumm ...
Ich habe Media Queries bisher immer als einen generischen Ansatz verstanden, der dazu in der Lage ist, alle möglichen wohldefinierten Umgebungsvariablen zu erkennen und zu verarbeiten.
Bisher iswt die einzige global wohldefinierte Eigenschaft die Bildschirmgröße. -- Aber das muss ja nicht so bleiben.
Die von der WHATWG vorgeschlagene Syntax ignoriert eigentlich die gesamte Media-Queries-Idee und baut eine spezielle Lösung.
Der Vorschlag des W3C ist auch bei langem drüber nachdenken unvergleichlich gefälliger ...
Und um mal konstruktiv auf das geschilderte Problem einzugehen: offenbar wird gerade daran gearbeitet, wie man mehrere konkurrierende wohldefinierte Umgebungsvariablen behandeln kann (bspw. hohe Auflösung aber niedrige Übertragungsrate) ... Freunde, das ist CSS - zur Erinnerung: das steht für Cascading Stylesheets ... ganz konkret: in der Syntax von CSS wird seit über einer Dekade sehr intensiv daran gearbeitet, (HTML-)Elemente konkurrierend zu formatieren ... weshalb ihr bei den vorgeschalteten Konkurrenzen etwas Neues erfinden möchtet ist mir ein Rätsel, in der Zwischenzeit würde ich empfehlen, einfach auch für Media Queries auf die Mechanismen(/Selektoren) zurückzugreifen, die auch heute in CSS funktionieren ... Vorteile: keine neue Syntax, keine Bauernfallen, stets auflösbar.
Holger Jakobs ¶
23. Mai 2012, 08:12 Uhr
@florian tolk: Genau, Media Queries könnten leicht "aufgebohrt" werden, um neben der Bildschirmgröße und -ausrichtung auch über die derzeit verfügbare Bandbreite Auskunft geben zu können, so dass dann das passende Bild geladen wird.
Insgesamt muss ich sagen, dass Anselm hier sehr gute Arbeit leistet. Ich finde es sehr schade, dass die WHATWG und auch die Browserhersteller so schlecht reagieren. Ebenfalls unschön ist das unabgestimmte Vorgehen von Apple.
Hoffen wir mal, dass man eine eingängige und leicht handhabbare Lösung findet. Nötig ist die auf jeden Fall in Ergänzung zum grundlegenden responsive Webdesign.
Anselm ¶
28. Mai 2012, 10:25 Uhr
@Sven, es gibt zumindest ein neues Framework, was versucht das Wirrwarr zu vereinfachen:
https://github.com/davidmarkclements/Respondu
@Florian: Das ist ja nicht ganz falsch, was du hier anbringst und ja, in vielen Fällen ist ein responsives Bild über CSS handlebar. Das geht auch heute schon, dafür gibt es genügend Möglichkeiten. Was fehlt, ist die Bandbreiten API, an der aber bereits gearbeitet wird:
http://www.w3.org/TR/2010/WD-system-info-api-20100202/
http://www.w3.org/TR/2011/WD-netinfo-api-20110607/
Dennoch gibt es durchaus einen Einsatzzweck für ein picture-Tag. Das kann zum Beispiel ein anderer Bildausschnitt oder ähnliches sein. Wenn wir für verschiedene Medien arbeiten, dann denke ich z.B. an speziell für eInk-Geräte aufbereitete Bilder, die ggf. sogar eine andere Bedeutung bekommen könnten. Auch möchte ich gerne die Möglichkeit haben, in HTML je nach Auflösung / Bildschirmtyp verschiedene Inhalte ausgeben zu können. Das bedeutet natürlich auch, dass der Entwickler darüber nachdenken muss, wie der Inhalt sich unterscheidet, ohne die Bedeutung zu verlieren (denn es muss ja den gleichen Sinn ergeben auf jedem Gerät).
Wichtig finde ich aber, dass man eben auf jeden Fall in CSS und in HTML responsive images definieren kann.
@Holger: Danke, ich kann nur hoffen, dass sich das noch bessert. Denn in großen Teilen hängt das Web auch von dieser Organisation ab und es ist unangebracht schnelle Lösungen rauszubringen, die tausende von Entwicklern später jahrelang mehr Arbeit abverlangen als initial etwas mehr Aufwand in eine gute Lösung zu stecken.
Sven ¶
19. Juni 2012, 14:01 Uhr
Ich habe jetzt einige Artikel zum dem Thema "Responsive Images" gelesen und frage mich, ob es wirklich DIE Lösung geben kann. Meiner Meinung nach nicht, denn die besuchte Webseite kann mein aktuelles Bedürfnis nicht ermitteln - also ob ich die Bilder in niedriger oder hoher Auflösung sehen möchte. Das kann auch von der jeweiligen Webseite abhängig sein, wo ich wert auf eine hohe Auflösung lege und wo nicht.
Daher kann auch anhand technischer Gegebenheiten (z. B. Verbindungsgeschwindigkeit) mein individuelles Bedürfnis nicht ermittelt werden. Denn dieses kann je nach Lust und Laune von der Verbindungsgeschwindigkeit komplett unabhängig sein. Eine Browsereinstellung will dafür mit Sicherheit auch keiner vornehmen, wobei das eigentlich der einzige Lösungsweg sein dürfte ...
non ¶
21. Juni 2012, 15:07 Uhr
Ich halte die hier vorgebrachten Lösungen für ziemlich großen Unsinn!
1. Verbraucht das Bereitstellen mehrerer Bilder unnötig Ressourcen, dazu wäre zum einen der Speicherplatz der sich je nach Größe und Anzahl der Stufen vervielfacht und zum anderen der Rechen- und Zeitaufwand diese Herzustellen, besonders wenn man hoch aufgelöste Bilder in vielen Stufen anbieten will!
2. Das bisher angesprochene Problem, dass es keine brauchbare Methode gibt festzustellen welche Version man an den Client schicken soll und jede Webseite hier völlig andere Kriterien (Bandbreite vs. Bildschirmauflösung vs. persönliche Präferenzen) festlegen würde und eben nicht der Nutzer selbst!
3. Eine egal in welcher Form völlig unnötig komplexe und vollkommen aufgeblähte Syntax!
4. Sind diese Varianten völlig an der Realität vorbei entwickelt! Denn wenn ich zum Beispiel mit meinem nicht so hoch auflösenden Smartphone online gehe, besteht die Realität eben aus zoomen, je nach dem ob ich den gesamten Überblick haben will oder aber Details anschauen will und ja ich verabscheue auf Smartphones optimierte Webseiten wo gerade mal 3 Wörter in eine Zeile passen und kein Zoomen (besonders bei Bildern) möglich ist. Was passiert nun aber wenn ich dank der niedrigen Auflösung ein niedrig aufgelöstes Bild bekomme und dann rein zoome? Etwa Zentimeter große Pixel, anstatt Details oder soll Alternativ je nach Zoomgrad das Bild immer und immer wieder in einer anderen Stufe neu geladen werden? In letztem Fall bevorzuge ich dann doch lieber gleich die maximal aufgelöste Variante runter zu laden, da dies sogar Bandbreite sparen würde und schneller ein brauchbares Ergebnis liefert! Wie verhält es sich mit Notebooks die eine mickrige Auflösung haben aber an einen Full HD (oder größer) Bildschirm angeschlossen werden? Was bekommen die und soll hier genauso dauernd eine neue Variante des Bildes geladen werden? Oder was passiert wenn der Browser nicht im Vollbild genutzt wird sondern in einem verkleinerten Fenster, auch dauerndes neu laden!?
Das Problem wurde zwar erkannt aber diese Lösungen gehen völlig an jeglicher Realität vorbei, in der Schule hieße das: "Thema verfehlt, setzen 6!" Und ich hoffe tatsächlich dass diese Lösungen niemals praktiziert werden oder zumindest dass es Software gibt, die diesen Unsinn ignoriert.
Die einzige wirklich vernünftige Möglichkeit für dieses Problem ist ein wie bereits erwähntes streambares Format, dass sich nach und nach aufbauen kann, ähnlich wie Formate die heute schon Interlacing unterstützen nur halt 2 Dimensional und nicht 1 Dimensional und eben mit etwas intelligenteren Clients. Das hätte diverse Vorteile:
1. Man muss nur ein einziges Bild anbieten, welches in einem Schritt direkt vom Grafikprogramm ausgespuckt werden könnte. So als würde man wie heute einfach nur ein JPG oder PNG erstellen. (Ressourcen-) Aufwand praktisch 0.
2. Man muss nicht mehr serverseitig feststellen welche Auflösung / Bandbreite / persönliche Präferenzen der Nutzer hat.
3. Die Syntax ist entsprechend einfach.
4. Der Client fängt einfach an das Bild zu laden und kann schon nach den ersten Bytes ein Bild darstellen, er kann mit dem laden solange fortfahren bis ein Bild in ausreichender Qualität dargestellt werden kann und anschließend mit dem Laden aufhören. Sollte man nun zum Beispiel rein zoomen, oder eine höhere Qualität benötigen, könnte man einfach dort mit dem Laden fortsetzen wo man aufgehört hat und solange weiter laden bis es komplett geladen wurde oder aber Alternativ bis man wieder den Punkt erreicht hat bei dem es ausreichend ist.
5. Der Nutzer selber könnte hier durch Browserseinstellungen festlegen was für ihn ausreichend ist (so, dass genug Pixel für die Auflösung vorhanden sind oder aber auch nur die halbe Anzahl der Pixel wenn man gerade Mobil online ist um Bandbreite zu sparen).
6. Dies würde sogar weitere Anwendungsgebiete ermöglichen / vereinfachen. Für Bildergalerien könnten so extra generierte Thumbnails entfallen, da man hier einfach direkt das streambare Format verwenden könnte bei dem das vollständig aufgelöste Bild erst beim Anklicken des jeweiligen Bildes angezeigt wird. Auch wären Zoom Effekte möglich bei dem das Bild erst beim zoomen nachgeladen wird.
Das größte Problem ist eben, dass es bestimmt wieder eine ganze Weile dauern würde bis es unterstützt wird, aber das ist kein Argument gegen ein streambares Format und für diesen Pfusch der hier beschrieben wurde und an der Realität vorbei entwickelt wurde, denn schließlich muss dieser Pfusch auch erst von den Browsern unterstützt werden um zu funktionieren und das kann auch durchaus lange dauern, außerdem gäbe es genügend (sogar mindestens genau so einfache) Möglichkeiten für Abwärtskompatibilität zu sorgen. Hier ein paar Varianten:
1. Man könnte ein vorhandenes Format wie PNG einfach erweitern, so dass alte Browser nur das bekannte (eine minimal auflösende Variante) anzeigen und die Information um ein höher Aufgelöstes Bild zu generieren erst in einem eigenen PNG-Chunk enthalten ist, ähnlich wie dies mit APNGs geschehen ist. Größtes Problem wäre hier wohl, dass einige Clients das gesamte Bild runter laden würden, auch wenn sie die Chunks gar nicht verstehen (gibt aber auch sicher intelligentere Clients, die solche Chunks einfach überspringen).
2. Man erlaubt es in dem img Tag so wie bei dieser Lösung 2 Bilder anzugeben, einmal die Variante für die Abwärtskompatibilität und einmal eines für das streambare Format. Das hat im Gegensatz zu der hier genannten Varianten den Vorteil, dass es NUR nötig ist solange das streambare Format keine breite Unterstützung erhält und kann somit problemlos und schmerzfrei in Zukunft entfallen.
3. Man könnte es anhand der Browserkennung, über einen speziellen HTTP Header oder durch anderweitig serverseitige Erkennung bestimmen, man könnte sogar ein Servermodul entwickeln, dass zum Beispiel normale PNGs automatisch in das streambare Format überführt, cached und es ausliefert, sofern der Client es unterstützt, vollständig ohne jeglichen Aufwand seitens des Entwicklers.
Das wäre alles aber auch nur solange nötig, solange sich das Format noch nicht breitflächig durchgesetzt hätte, danach würde man es so einfach wie jetzt ein PNG benutzten können.
Daniel Walprecht ¶
5. August 2012, 19:57 Uhr
Danke für den wirklich guten Beitrag,
ich habe jetzt mal das Script auf der Seite http://adaptive-images.com/ gefunden und wollte fragen ob das für dich sinnvoll erscheint.
Im Prinzip hört sich das ja wirklich nett an.
Ich wäre dankbar, wenn du darüber schreiben würdest.
Viele Grüße,
Daniel
Anselm ¶
6. August 2012, 12:16 Uhr
Hey Daniel,
das Script ist durchaus eine sehr gute interim-Lösung, basiert natürlich auf serverseitiger Technik und setzt ein paar Dinge voraus wie htaccess, etc..
Funktioniert aber gut und ist von Matt Wilcox geschrieben, der ja auch maßgeblich an der Entwicklung des Standards für Responsive images jetzt mitgewirkt hat.
Im übrigen ist der aktuelle Status, dass Mathew Marquis an einer offiziellen W3C Spezifikation schreibt, die dann in Kürze (16.8.) vorgelegt werden soll. Responsive Images werden dann in die HTML5-Spezifikation aufgenommen werden, also in relativer zeitlicher Nähe für jedermann verfügbar. Da Microsoft direkt mitwirken wird, denke ich, dass das auch wirklich zeitnah umgesetzt werden wird.
Fredi ¶
24. September 2013, 00:11 Uhr
Schöne Zusammenfassung und ein immer wichtigeres Thema, denn mehr und mehr Benutzer nutzen Mobilegeräte. HTML 5 Picture Element ist ebenfalls eine Lösung, die in Verbindung mit Apple Geräten als Standard durchsetzen könnte.
Raphael ¶
25. Februar 2014, 11:32 Uhr
Vielen Dank für diesen ausführlichen und hilfreichen Artikel zum Thema respsonive Image