Damit diese Webseite korrekt und mit vollem Funktionsumfang angezeigt wird, benötigen Sie JavaScript. Wie Sie JavaScript in Ihrem Browser einschalten

Responsive Webdesign: Problemfall img

Responsive Webdesign ist derzeit wahrscheinlich die Layout-Technik im Webdesign (und kommt im Übrigen auch hier im Blog zum Einsatz). Vereinfacht gesagt wird es damit möglich, ein Basis-Layout mittels CSS abhängig von der Bildschirmauflösung anzupassen – von den 320 Pixeln Breite eines Smartphones bis hin zu den 1600 und mehr Pixeln moderner Monitore. Ein Problem responsiver Designs sind Grafiken, oder besser: Elemente mit fester Breite, welche nicht über CSS zugewiesen wird.

Eine Grafik wird über das img-Element in Webseiten eingebunden, wobei ihr ihre tatsächlichen Ausmaße als Attribute zugewiesen werden. (Ausgenommen sind hier Hintergrundgrafiken – die kann man für jede Auflösung passend zuweisen.) Bindet man nun z.B. ein 640 Pixel breites Foto ein, sprengt dieses etwa die typischen 320 Pixel Bildschirmbreite eines Smartphones.

Lösungsansätze

  • Fluid images: Ethan Marcotte, Autor des usprünglichen Artikels, schlägt vor, Grafiken statt Dimensions-Attributen via CSS max-width: 100% zuzuweisen
  • Responsive Images: Scott Jehl präsentiert eine Technik, welche eine eingebundene kleine Grafik serverseitig durch eine größere ersetzt
  • Mit Javascript möchte Peter Gasston ein leeres div-Element bei hinreichender Auflösung dynamisch ersetzen

Den letztgenannten Ansatz halte ich für bedenklich, da er (ohne Fallback) nur mit Javascript-Unterstützung funktioniert, somit also Benutzern ohne Javascript ggf. wesentliche Informationen vorenthält. Zudem bleibt der schale Beigeschmack sinnfreien Markups im Code.

Der ursprüngliche Vorschlag von Ethan Marcotte ist relativ robust, hat aber den großen Nachteil, dass die eingebundene Grafik evtl. zu groß für volumenbasierte Datentarife ist. Zudem dürfte sie mangels Dimensionsangaben ab einer gewissen Anzahl Grafiken gerade auf Smartphones spürbar die Performance beeinflussen.

Der Ansatz von Scott Jehl ist letzlich kein „eigener“, sondern eine Erweiterung des ursprünglichen Vorschlags. Er bindet zunächst eine „mobile Grafik“ (übrigens auch ohne Dimensionen, insofern bleibt das potenzielle Performance-Problem) ein, welche für höhere Auflösungen mittels einer Kombination aus Javascript und URL-Rewriting durch die größere Version ersetzt wird. Leider ist diese Technik aus meiner Sicht nicht eben trivial umzusetzen, sie dürfte gerade für das Einbinden von Grafiken aus einer Mediendatenbank in einer CMS- oder Blog-Umgebung nur mit Mühe zu adaptieren sein.

Was nimmt man also?

Auf Seiten mit hohem img-Durchsatz und/oder relativ großen Bild-Dateien sollte man sich durch die Einbindung der Jehl-Methode wühlen – allerdings ist die tatsächliche Nutzung solcher Seiten mit kleinen Smartphone-Bildschirmen ohnehin höchst fragwürdig. Wer schaut sich schon Fotos auf flickr auf einem kleinen Bildschirm an? Fotolastige Seiten wie etwa Bildergalerien nutzen zudem heutzutage fast immer Lightbox-Skripte, welche auf kleinen Touchscreens schwierig zu bedienen, vor allem aber aufgrund der kleinen Dimensionen des Bildschirms sinnfrei sind.

Benötigt man hingegen nur wenige fluide Grafiken, welche noch dazu vertretbare Ausmaße (also im Rahmen der heute gängigen Display-Formate von Smartphones) und Dateigrößen haben, dürfte die Marcotte-Methode vollkommen ausreichen und akzeptabel performant sein. Sie besticht zudem durch ihre einfache Umsetzung.

Ideal ist das allerdings streng genommen alles nicht. Eine wirklich solide Lösung würde stets von einer Grafik mit geringeren Ausmaßen ausgehen, auch die Attribute width und height korrekt nutzen, im Zweifelsfall ohne Javascript mindestens sauber degradieren (noch besser: rein über HTML und CSS funktionieren) – und sich (natürlich ohne optische Irritationen) flüssig und sauber der jeweiligen Auflösung anpassen. Man wird ja noch träumen dürfen …

2 Trackbacks

Trackback-URL für diesen Eintrag

24 Kommentare

Kommentar-Feed für diesen Eintrag
Jens Grochtdreis

Jens Grochtdreis am :

Es gibt noch eine vierte Möglichkeit, die vor allem den Grafikern die Tränen in die Augen treiben wird: das Ausblenden von Bildern. Man könnte für Handys die Bilder mit display: none behandeln und einen extra Link stattdessen einblenden, der zu einer neuen Seite mit dem Bild führt. Das wird dann sicherlich auch als größeres Bild von modernen Browsern runterskaliert.

Der Ansatz geht nicht immer, aber er geht. Das Gleiche kann man mit Seitenbestandteilen machen, die nicht zwingend wichtig sind.

Im Prinzip machen das doch alle, die eine extra iPhone-App anbieten. Sowas aufgeräumtes, wie diese Apps findest Du im Web nicht. Und warum? Weil Werbebanner und Teaser und sonstige Bilder fehlen und sich auf das Wesentliche konzentriert wird.

Hach, wär das schön, wenn das auch für normale Webseiten gelten würde :-)

Matthias Mees

Matthias Mees am :

Mir treibt das auch die Tränen in die Augen -- denn die referenzierte Grafik wird ja nach wie vor geladen, wenn sie lediglich via CSS ausgeblendet wird. (Ich gestehe, mich interessiert derzeit an der ganzen Sache die Performance viel mehr als die Usability.)

Mit den Apps hast Du grundsätzlich Recht, durchaus nicht nur auf dem iPhone -- auch die analogen Android-Apps sind durchaus gut bedienbar (Kunststück, sie nutzen native oder zumindest sehr gut angepasste UI-Elemente). Aber: Sie sind weiss Gott nicht immer frei von Werbung.

Zudem dürfte App-Entwicklung selbst auf Sicht großen und kommerziellen Projekten vorbehalten sein. Für den Rest muss man meines Erachtens eine gangbare Alternative finden -- und mit @media-Queries ist der erste Baustein bereits da.

Kai

Kai am :

Moin!

Entschuldige, mir erschliesst sich die Problematik nicht. In dem einen Fall, jemand verkleinert sein Browserfenster, sind Grafiken und Bilder eh bereits geladen.

Im Falle des Aufrufs durch ein mobiles Endgerät kann ich doch von vorneherein schon anderes Markup ausliefern?!

Lg Kai

Matthias Mees

Matthias Mees am :

Zunächst mal ist ja eben das der Witz an Responsive Webdesign -- dass ich eben exakt dasselbe Markup rein über CSS an verschiedene Geräte anpassen kann.

Anderes Markup für mobile Geräte auszuliefern geht nicht via CSS oder JS (zumindest nicht verlässlich), es bleibt also nur Browsersniffing -- eine (meiner bescheidenen Meinung nach) rückwärts gewandte, wenig zukunftsträchtige Technik. Obendrauf kommt der erhöhte Aufwand, 2 Seiten zu pflegen.

Schepp

Schepp am :

Leider ist es nicht ganz trivial, sowas einem CMS beizubringen, aber wie wäre folgender Ansatz:

Das CMS parsed den ausgebenden Quelltext nach img-Elementen und ersetzt diese durch beliebige als inline-block definierte Elemente mit einem eindeutigen Klassennamen (etwa ein MD5-Hash vom Dateinamen).

Innen rein kann entweder ein transparentes Bild mit 100%-Ausdehnung um weiterhin ein alt-Attribut befüllen zu können, oder das Inline-Block-Element bekommt wahlweise ein title-Attribut (spart DOM-Elemente).

Gleichzeitig setzt es ein media-gequerytes Stylesheet zusammen, in das je nach Auflösung verschiedene Hintergrundbilder und Elementdimensionen für dieses Inline-Block-Element gesetzt werden.

Für JavaScript-Entmannte packst Du das Stylesheet in ein hinein, alle anderen bekommen es lazy-geloaded nachträglich in den Kopf gehängt.

Umsetzen könnte man sowas zum Beispiel, indem man einen Output-Buffer aufmacht und dessen Inhalt dann am Ende entsprechend aufbereitet und ausgibt.

PS: Die Textile-Verlinkung im Kommentarformular ist kapott :)

Schepp

Schepp am :

Die JavaScript-Entmannten bekommen es in ein noscript-Element, wollte ich schreiben. Doofer HTML-Filter :)

Matthias Mees

Matthias Mees am :

Ich bin, glaube ich, noch nicht wach genug, um Deinen Plan nachvollziehen zu können -- letzten Endes wäre es auf eine gewisse Art und Weise aber auch eine „Notlösung“, mit der man einen Mangel in den eigentlichen Basis-Techniken umginge. (Deswegen ist es nicht schlecht, nur relativ umständlich.)

Ich habe übrigens mal in die WHATWG-Mailingliste reingelesen -- die brüten scheinbar durchaus über Ähnliches, also einen Lösungsansatz, der Bestandteil der Spezifikation würde. (Oder ich habe sie komplett missverstanden, was auf der ML durchaus vorkommen kann.)

Und was die Textile-Verlinkung angeht: Da ist scheinbar der Webserver spazieren gegangen. Ich geh mal davon aus, dass das nur vorrübergehend so ist. :)

Schepp

Schepp am :

Das stimmt, es sind alles Notlösungen. Mal sehen, was sich seitens der WHATWG noch so tut.

Matthias Mees

Matthias Mees am :

Damit wir uns nicht missverstehen: Ich habe nichts gegen Notlösungen, wenn sie funktionieren. :)

Das eigentlich Unschöne ist, dass man über sowas nachdenken muss, weil die Technik, die es eigentlich „ab Werk“ leisten müsste, (noch) Mängel hat. Je mehr Leute darüber nachdenken, desto größer die Anzahl der Leute, die auf „Lösungen“ kommen, die von vernünftig meilenweit entfernt sind.

Torsten

Torsten am :

Theoretisch könnte doch da schon Das ModPageSpeed-Apache-Modul etwas reißen, oder? http://code.google.com/intl/de/speed/page-speed/docs/filter-image-optimize.html

Das wäre zumindest ein Anfang. Und dann könnte man auch mal schauen, ob man sowas wie http://tinysrc.net/ sinnvoll mit nutzen könnte.

Genaueres hab ich mir dazu auch noch nicht überlegt. Aber das sind so die zwei Lösungen neben den von Dir genannten, die ich da immer im Hinterkopf habe und mit denen ich mich mal näher auseinandersetzen will, wenn es mal wirklich von Nöten ist.

Matthias Mees

Matthias Mees am :

Auf die Gefahr hin, hier komplett skeptisch zu klingen, aber:

  1. mod_pagespeed ist vermutlich auf dem durchschnittlichen Webserver noch nicht verfügbar, insofern wenig massentauglich
  2. tinysrc ist ein kostenloser Dienst, bei dem die Verfügbarkeit auf Dauer durchaus in Frage gestellt werden darf -- zudem sind manche Leute bei fremdgehosteten Diensten generell skeptisch

Grundsätzlich muss man natürlich bei jeder Performance-Optimierung gucken, ob es sich rechnet – die mod_pagespeed-Doku erwähnt z.B. data:uri, was gerne mal bei viel Aufwand wenig bringt.

Kai

Kai am :

Ok, dann habe ich die Intention falsch verstanden, gebe Dir aber innerhalb dieses Gedankengangs natürlich recht.

Ich sehe das insgesamt anders: Wenn es das Ziel ist die mobile Version insgesamt performanter zu machen, vornehmlich in Hinblick auf Datenmenge und Ladezeiten, dann sind img-Tags ja nicht die einzigen Baustellen. Eventuell würde man in einer mobilen Version auch auf das eine oder andere Script verzichten wollen, wie Du ja selber anführst sind Lightbox-Scripte beispielsweise nahezu unbenutzbar, also raus damit (konsequenterweise).

Demzufolge müssten native Media-Queries, wenn man es denn dann auch richtig machen will, mehr leisten können als Bilder auszutauschen - und dafür sind sie nicht gedacht.

Letzlich bleibt es so oder so ein Kompromiss, wenn man nur eine Version der Seite machen will, bedingt sich natürlich auch durch den Zweck.

Schepp

Schepp am :

@Kai Wenn ich Seiten für mobile Geräte optimiere, dann benutze ich ein absolut webpositioniertes Dummyelement, dem ich per Mediaquery auf verschiedenen Geräten verschiedene CSS-Eigenschaften verpasse. Anschließend prüfe ich bei DOMready diese CSS-Eigenschaften und entscheide dann welche Scripte ich nachlade. Das geht ganz gut.

Kai

Kai am :

Klar. Mir war nur so, als ginge es hierbei um die Idealvorstellung, ohne zusätzliche Mittel den richtigen Inhalt auszuliefern. Wenn Hilfsmittel erlaubt sind, gibt es mehrere Wege nach Rom, aber darum ging es doch nicht, oder habe ich das einfach doch falsch verstanden?

Schepp

Schepp am :

Lightbox-Scripte sind ja sowieso JavaScript, also spricht auch nichts gegen JavaScript als Hilfsmittel.

Warum es Matthias geht, ist mehr eine Beeinflussung des HTMLs, respektive des HTML-Interpretierens ohne dabei von JavaScript und serverseitigen UA-Sniffern abhängig zu sein.

Bertram Simon

Bertram Simon am :

Vielleicht ist es an der Zeit, sich von dem -Tag in der jetzigen Form zu verabschieden:)

Bertram Simon

Bertram Simon am :

Jetzt bin ich auch in die HTML-Filter-Falle gelaufen... Sollte img-tag heißen:)

Matthias Mees

Matthias Mees am :

Eigentlich geht es mir darum, dass HTML, ggf. unter Zuhilfenahme von CSS, eine Möglichkeit bieten müsste, die Skalierung von Grafiken zu lösen. Es sollte diese Möglichkeit geben, ansonsten sind media-queries teilweise arg limitiert. Oder meinetwegen ein SVG-Pendant, das für Fotos geeignet ist.

Dass es etwas Analoges für JS braucht, ist klar -- aber da gibt es eher jetzt schon sinnvolle Lösungen als für img.

Freizeitler

Freizeitler am :

Mit CSS3 könnte es klappen. Stichwort: background-size. Einen Container nehmen, Hintergrundbild rein, allem 100% geben, Textbeschreibung rein, mit text-indent rauskloppen und sich fröhlich skalieren lassen. Habe ich zwar noch nie so gemacht, aber warum nicht?

Jonathan

Jonathan am :

Hi, Wenn es rein um eine Skalierung geht könnte ich mir etwas in der Art vorstellen:

-webkit-transform: scale(0.5);

Würde sich natürlich mit der angestrebten Performance beißen. Besser ist natürlich, wie oben schon erwähnt anderen Inhalt auszuliefern, wie auch immer man das letztendlich macht.

Siegfried

Siegfried am :

Bilder, die als Inhalt eingebunden werden (also mit img), kann der Browser ganz gut skalieren. Die Methode von Ethan Marcotte ist also im Prinzip durchaus gut. Und dass die Qualität der Skalierung vielleicht nicht mit der von Gimp oder Photoshop mithalten kann, ist mir persönlich, ehrlich gesagt, schnurz.

Aber eine kleine Ergänzung hätte ich noch zu der Methode: Zusätzlich zu (von mir aus) 100% sollten noch max-width und min-width angegeben werden. Dabei sollte max-width der natürlichen Breite des Bildes entsprechen, und min-width entweder der Hälfte davon, oder, wenn man das riskieren will, mindestend einem Viertel der natürlichen Bildgröße. So lange ein Bild nur verkleinert wird, ist das Ergebnis akzeptabel. Ab einer gewissen "Kleinheit" hört der Spaß allerdings auf. Ein Bild vergrößern sieht immer Sch... aus.

Zusätzlich kann man natürlich auch noch Javascript Ersetzungen implementieren. Ohne Javascript fliegt einem dann wenigstens nicht gleich Alles um die Ohren.

Bleibt als moderne Form der Wahl zwischen Skylla und Charybdis: Kleines Bild bei guter Performance und schlechtem Aussehen oder großes Bild bei mieser Performance und gutem Aussehen. So wie Odysseus sollte man sich da irgendwo im Mittelfeld halten. Ist gesünder :)

Matthias Mees

Matthias Mees am :

Es geht mitnichten (allein) um die Performance bei der Skalierung -- es geht darum, dass der Benutzer eines kleinen Gerätes ggf. über eine schmale, nicht pauschal abgerechnete Verbindung ein Bild in 800x600 runterladen muss, obwohl sein Gerät nur 320x480 oder 480x320 anzeigen kann.

Dari4sho

Dari4sho am :

Was haltet ihr davon, weitgehend auf img-tags zu verzichten und diese durch Container mit Background-Image zu ersetzen? So hat man den Markup unberührt, Bilder komplett ins CSS ausgelagert und kann durch angepasste Stylesheets die neuen Bilder laden - welche man beim Erstellungsprozess direkt mit erstellt und auf dem Server bereitstellt. Das bedarf natürlich einer Vorplanphase, gerade bei größeren Projekten. Aus SEO-Technischer Sicht bezüglich der alt-Tags könnte man ja auch problemlos img als Container missbrauchen.

Matthias Mees

Matthias Mees am :

Nichts.

  1. img und background-image sind nicht dasselbe. img transportiert normalerweise wichtige Informationen (siehe 3.)
  2. Jedes background-image wäre ein zusätzlicher HTTP-Request, also Performance-Horror.
  3. Man bläst sich mit den verschiedenen Hintergrundbild-Zuweisungen unnötig das CSS auf.
  4. Das alt-Attribut hat mehr Bedeutung als nur SEO (siehe 1.) – Barrierefreihheit nicht zu vergessen.
  5. Elemente zu „missbrauchen“ entsprich nicht semantisch sinnvollem Markup.

Kommentar schreiben

Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
Markdown-Formatierung erlaubt