Der folgende Text ist ein Gastbeitrag von Parker Bennett. Parker hat bereits früher für CSS-Tricks geschrieben, in seinem Artikel Crop Top, der sich mit der Positionierung von flüssigen Bildern befasste. Dies ist eine großartige Fortsetzung dazu und präsentiert eine weitere Option im endlosen Sagen-Zyklus von responsiven Bildern. Es ist auch ein interessanter Kontrast zum gestrigen Beitrag über responsive Bilder – so kann man sehen, wie sehr sich die Ansätze zu diesem Problem unterscheiden können.
Wir wollen schnelle Seitenladezeiten. Wir wollen Retina-Bilder. Können wir alles haben?
Wir wollen keine riesigen Bilder an Nutzer ausliefern, die sie nicht benötigen. Es gibt verschiedene Ansätze, dies zu vermeiden – darunter Scott Jehls picturefill, serverseitige Lösungen und Lazy-Loading-Techniken – aber die einfachste Methode ist vielleicht die Verwendung eines background-image und der Magie von CSS-Media-Queries. So erhalten Ihre glücklichen Retina-Nutzer die hochauflösenden @2x-Versionen, und der Rest von uns… nun, zumindest muss ich nicht auf den Download von Mammutdateien warten.
(Um dies unten zu veranschaulichen, habe ich mein Standardbild für "Mobile First" schwarzweiß, die mittelgroße Version sepia gehalten, und es gibt eine größere Farbversion, wenn Sie das Fenster breiter ziehen oder einen Bildschirm mit hoher DPI haben.)
/* base background-image class */
.bg-image {
width: 100%;
/* default background-position */
background-position: center center;
/* lt ie 8 */
-ms-background-position-x: center;
-ms-background-position-y: center;
/* scale proportionately */
background-size: cover;
/* IE8 workaround - http://louisremi.github.io/background-size-polyfill/ */
-ms-behavior: url(/backgroundsize.min.htc); }
/* mobile-first default (b&w) */
.bg-image-sedona {
background-image: url(img/photo-sedona_512x320.jpg);
background-position: center 21%; }
/* example media queries (IE8 needs this:
http://code.google.com/p/css3-mediaqueries-js) */
@media
/* "mama-bear" - plus any-retina */
only screen and min-width : 513px,
only screen and (-webkit-min-device-pixel-ratio: 1.5),
only screen and ( min-device-pixel-ratio: 1.5) {
/* mid-size (sepia) */
.bg-image-sedona {
background-image: url(img/photo-sedona_1024x640.jpg); }
}
@media
/* "papa-bear" - plus larger retina */
only screen and (min-width : 1025px),
only screen and (min-device-width : 768px) and (-webkit-min-device-pixel-ratio: 1.5),
only screen and (min-device-width : 768px) and ( min-device-pixel-ratio: 1.5) {
/* high-res (color) */
.bg-image-sedona {
background-image: url(img/[email protected]); }
}Das div, das das background-image anzeigt, benötigt eine Höhe, die manuell gesetzt werden kann, oder, wie ich es hier getan habe, indem man ein transparentes "Proxy"-img einwickelt, das responsiv skaliert wird (mehr dazu hier).
Nun, wie Sie vielleicht bemerkt haben, kann es beim ersten Rendern eines großen Bildes auf einer Seite zu einer spürbaren Verzögerung kommen, während es lädt. Selbst kleinere Bilder können, bevor sie gecached sind, ein lästiges Aufblitzen anzeigen, während sie geladen oder ausgetauscht werden. Aber das können wir beheben…
CSS3 Mehrfach-Hintergründe: Wie sie sich stapeln
Neuere Browser erlauben uns, Hintergrundbilder zu stapeln, indem wir mehrere durch Kommas getrennte Werte deklarieren. So können wir das ursprüngliche, gecachte Bild anzeigen, während das Ersatzbild flüssig darüber geladen wird (beachten Sie die Stapelreihenfolge im Code unten).
Um dies in Aktion zu sehen, verkleinern Sie das Browserfenster und leeren Sie den Cache (wählen Sie "Browserdaten löschen" im Chrome-Menü oder "Caches leeren" im Safari-Entwicklermenü). Laden Sie die Seite nun neu. Scrollen Sie wieder nach unten und vergrößern Sie das Fenster, bis die Farbbilder darüber geladen werden. (Oder versuchen Sie dieses Pop-up-Fenster.)
Leider verstehen ältere Browser wie IE8* keine Mehrfach-Hintergrunddeklarationen und werfen die Hände hoch – sie zeigen nichts an (autsch!). Wir müssen also modernizr.js verwenden, um Feature-Detecting zu betreiben und eine Fallback-Lösung zu schaffen (wenn wir möchten, dass diese Browser etwas Größeres als die Mobile-First-Standardversion angezeigt bekommen).
/* .bg-image and .bg-image-sedona same as above.
.multiplebgs class added by modernizer.js. */
@media
/* "mama-bear" - plus any-retina */
only screen and min-width : 513px,
only screen and (-webkit-min-device-pixel-ratio: 1.5),
only screen and ( min-device-pixel-ratio: 1.5) {
/* no-multiplebgs - mid-size fallback (sepia) */
.no-multiplebgs .bg-image-sedona,
/* upscale to mid-size if no javascript */
.no-js .bg-image-sedona {
background-image: url(img/photo-sedona_1024x640.jpg); }
.multiplebgs .bg-image-sedona {
background-image:
/* mid-size on top (sepia) */
url(img/photo-sedona_1024x640.jpg),
/* mobile-first default on bottom (b&w) */
url(img/photo-sedona_512x320.jpg);
}
}
@media
/* "papa-bear" - all three images */
only screen and (min-width : 1025px) {
/* no-multiplebgs fallback is above */
.multiplebgs .bg-image-sedona {
background-image:
/* high-res on top (color) */
url(img/[email protected]),
/* mid-size in middle (sepia) */
url(img/photo-sedona_1024x640.jpg),
/* mobile-first default on bottom (b&w) */
url(img/photo-sedona_512x320.jpg);
}
}
@media
/* larger retina device - triggered immediately,
so mid-size image not needed */
only screen and (min-device-width : 768px) and
(-webkit-min-device-pixel-ratio: 1.5),
only screen and (min-device-width : 768px) and
( min-device-pixel-ratio: 1.5) {
/* no-multiplebgs fallback is above */
.multiplebgs .bg-image-sedona {
background-image:
/* high-res on top (color) */
url(img/[email protected]),
/* mobile-first default on bottom (b&w) */
url(img/photo-sedona_512x640.jpg);
}
}Standard vs. Progressive JPEGs
Bei JPEGs hängt die Art und Weise, wie ein Bild über einem anderen Bild in einem Mehrfachhintergrund gerendert wird, davon ab, wie es gespeichert wurde. Ein Standard-JPEG "malt" das Bild sequenziell, während es heruntergeladen wird. Progressive JPEGs "erscheinen" vollständig heruntergeladen. (Der Standardweg erscheint mir flüssiger.) Beachten Sie, dass Bildkompressoren wie ImageOptim standardmäßig auf progressiv (Jpegrescan ist aktiviert) eingestellt sind, da dies etwas Speicherplatz spart.
Natürlich wollen wir nicht, dass Nutzer unnötigerweise Bilder herunterladen oder unseren Wartungsaufwand übermäßig komplizieren. Daher ist es wichtig, dass wir unsere Breakpoints zurückhaltend gestalten und logisch durchdenken. Aber da wir das Austauschen von Bildern weniger auffällig machen können, eröffnen sich einige Möglichkeiten…
"lowsrc" vortäuschen
Früher, als das Internet noch mit Dampf betrieben wurde, war der Einwahlzugang so langsam, dass ein spezielles Attribut geschaffen wurde, damit die Nutzer *etwas* sahen, während es anderthalb Minuten dauerte, ihre animierten GIFs herunterzuladen: es hieß "lowsrc" und sah so aus: IMG SRC="big.gif" LOWSRC="small.gif".
Browser stellten die Unterstützung dafür in den späten 50er Jahren ein.
Aber etwas Ähnliches könnte jetzt nützlich sein, damit Nutzer *etwas* sehen, während es zweieinhalb Sekunden dauert, ihre hochauflösenden Retina-Bilder herunterzuladen. (Und vergessen Sie nicht, 4K kommt.)
Moderne Browser sind ziemlich schlau darin, Bilder sofort anzuzeigen, sobald sie abgerufen wurden. Indem wir kleinere, stärker komprimierte "lowsrc"-Bilder als Standard angeben und diese dann unter den @2x Retina-Bildern in unseren CSS-Media-Queries stapeln, werden die Dinge wahrscheinlich reaktionsschneller wirken. Wir können noch einen Schritt weiter gehen und jQuery verwenden…
Die Idee ist, das Austauschen von Bildern hinauszuzögern, bis die Seite vollständig mit unseren Standard-"lowsrc"-Bildern gerendert ist. Dann verwenden wir jQuery, um der Hauptklasse "bg-image" eine "hd"-Klasse hinzuzufügen, was unsere Media-Queries zum Austauschen der Bilder auslöst. Wir könnten auch hinauszögern und die hochauflösenden Bilder "lazy loaden", während wir zu ihnen scrollen, mit etwas wie dem jQuery Waypoints Plug-in.
/* .bg-image and .bg-image-sedona same as above
.hd class added by jQuery after page loads
(or perhaps "lazy loaded" as user scrolls) */
@media
/* "mama-bear" - plus any-retina */
only screen and (min-width : 513px),
only screen and (-webkit-min-device-pixel-ratio: 1.5),
only screen and ( min-device-pixel-ratio: 1.5) {
/* no-multiplebgs - mid-size fallback */
.no-multiplebgs .bg-image-sedona.hd,
.no-js .bg-image-sedona {
/* mid-size (sepia) */
background-image: url(img/photo-sedona_1024x640.jpg); }
.multiplebgs .bg-image-sedona.hd {
background-image:
/* mid-size on top (sepia) */
url(img/photo-sedona_1024x640.jpg),
/* mobile-first "lowsrc" on bottom (b&w) */
url(img/photo-sedona_512x320.jpg); }
}
@media
/* "papa-bear" - size only */
only screen and (min-width : 1025px) {
/* no-multiplebgs fallback is above */
.multiplebgs .bg-image-sedona.hd {
background-image:
/* high-res on top (color) */
url(img/[email protected]),
/* mid-size in middle (sepia) */
url(img/photo-sedona_1024x640.jpg),
/* mobile-first "lowsrc" on bottom (b&w) */
url(img/photo-sedona_512x320.jpg); }
}
@media
/* larger retina device, triggered immediately,
so mid-size image is not needed */
only screen and (min-device-width : 768px) and
(-webkit-min-device-pixel-ratio: 1.5),
only screen and (min-device-width : 768px) and
( min-device-pixel-ratio: 1.5) {
/* no-multiplebgs fallback is above */
.multiplebgs .bg-image-sedona.hd {
background-image:
/* high-res on top (color) */
url(img/[email protected]),
/* mobile-first "lowsrc" on bottom (b&w) */
url(img/photo-sedona_512x320.jpg); }
}/* waits until everything is loaded, not just DOM is ready */
$(window).load(function() {
$('.bg-image').addClass('hd');
});Sehen Sie diese "Faking lowsrc"-Demo in Aktion
Siehe ein Beispiel mit "Lazy Loading" in Aktion.
/* "lazy loads" when .bg-image appears in viewport -
http://imakewebthings.com/jquery-waypoints/ */
$('.bg-image').waypoint(function(direction) {
if (direction === 'down') {
$(this).addClass('hd');
}
}, { offset: 'bottom-in-view', triggerOnce: true });
/* other offsets: '100%' (image top at viewport bottom),
'125%' (just beyond the viewport, about to scroll in) */Zusammenfassend
Idealerweise würde ich mir wünschen, dass dies auf eine automatisiertere Weise funktioniert, wie picturefill.js, aber basierend auf einem Mobile-First img statt einem data-src-Attribut. Was denken Sie? Sie können sich den Quellcode für weitere Informationen ansehen, alle Demos auf CodePen ansehen oder die Beispieldateien hier herunterladen. Wenn Sie Fragen, Kommentare oder Korrekturen haben, schreiben Sie mir: parker@parkerbennett.com.
* IE8 unterstützt keine Mehrfach-Hintergründe, aber wenn Sie eine Breite und Höhe für Ihr Bild deklarieren können, könnten Sie etwas Ähnliches mit diesem Pseudo-Element-Ansatz von Nicolas Gallagher umsetzen.
Bei einem aktuellen Projekt habe ich anstelle des transparenten "Proxy"-img ein kleines Bild für Mobiltelefone verwendet. Dann habe ich auf größeren Bildschirmen das Bild ausgeblendet und stattdessen ein größeres Hintergrundbild angezeigt. Obwohl dies unkompliziert ist, berücksichtigt es keine zusätzlichen Bilder für Dinge wie Retina-Displays.
Ich finde es unglaublich frustrierend, dass es keine "perfekte" Methode dafür gibt. Jede Methode hat ihre Nachteile, und ich schätze, es ist eine Frage der Wahl der Methode, die am wenigsten Nachteile hat.
Korrigieren Sie mich, wenn ich falsch liege, aber kann man keine Media Queries verwenden, um für niedrige Auflösung, hohe Auflösung und hohe DPI auszublenden und anzuzeigen?
Ich denke, es gibt eine Lösung, aber das Seltsame ist, dass sie auf Blackberry funktioniert, aber auf dem iPhone sie direkt herausspuckt! … Ich bin mir nicht sicher, welchen Browser Sie verwenden, obwohl ich Opera Mobile benutze, aber auf meinem iPhone benutze ich auch Opera Mobile, aber aus irgendeinem seltsamen Grund ruiniert es alles!
Gareth, wenn du auf einem iPhone bist, ist es das 4, 4S oder 5? Danke
Das ist eine interessante Technik, aber sie bedeutet, dass Sie mehrere Ressourcen laden. Das ist in Ordnung, wenn Sie über eine Breitbandverbindung auf Ihrem Retina MBP verbunden sind. Wenn Sie jedoch auf Ihrem Retina iPhone oder einem anderen hochauflösenden Mobilgerät sind, während Sie nicht zu Hause sind, erhöhen Sie die heruntergeladenen Datenmengen.
Das sollte wirklich vermieden werden. Wer möchte schon Daten verschwenden? Jemand irgendwo hat die perfekte Lösung, hält sie aber zurück.
Das ist das Verrückte an dieser ganzen Situation. Responsive Bilder sind ein Balanceakt zwischen
Das macht dies zu einem Flächenbrand.
Wenn ein min-width und max-width Wert festgelegt wäre, würde nur eine Datei geladen, richtig?
Entschuldigung, wenn ich mich nicht klar genug ausgedrückt habe, aber ich denke, es ist möglich, Media Queries zu verwenden, um unnötige Downloads zu reduzieren. Zum Beispiel können wir ein Retina-iPhone separat mit min-device-width und min-device-pixel-ratio ansprechen. So erhalten sie das mittelgroße Bild, aber nicht das riesige.
Es gibt keine perfekte Lösung, nur abgewogene Kompromisse. Hier ist meine übliche Aufschlüsselung
Vektoren, wann immer möglich: Icon-Schriftart oder SVG.
UI-Elemente werden als Sprites zusammengefasst: sowohl 1x als auch 2x Versionen (Media-Query für Retina).
Für kleinere Bilder, die bis zu 512px breit angezeigt werden, verwende ich ein einzelnes flüssiges img, bei dem die tatsächliche Dateibreite 1,5x beträgt – also nicht mehr als 768px (Höhe und Breite des src sind auf die angezeigte maximale Breite oder proportional größer deklariert). Dies ist ein Kompromiss, der auf Retina gut aussieht und einfach zu warten ist.
Bei größeren Bildern beginne ich, Hintergrundbilder und Media-Queries in Betracht zu ziehen: das große Hintergrundbild auf der Startseite, wo es komisch aussieht, den Text rendern zu sehen und dann darauf zu warten, dass das Bild darunter geladen wird. Die Website eines Fotografen oder Architekten, die sie auf einem Retina-iPad präsentieren möchten. Selbst dann neige ich dazu, Dinge bei 1,5x statt @2x zu belassen, kein Bild breiter als 2048px.
Bei diesen größeren Bildern halte ich es für besser, schnell *etwas* zu sehen, damit die Nutzer die Seite überfliegen können, anstatt "Laden"-Grafiken zu sehen, daher die "lowsrc"-Idee. Sobald ich mich dafür entschieden habe, dieses Mobile-First-Bild (ca. 25 KB) anzuzeigen, ist es kein *zusätzlicher* Bandbreitenaufwand, Mehrfach-Hintergründe zu verwenden, um den Übergang flüssiger zu gestalten – das bereits gecachte Bild weiter anzuzeigen, während wir das größere Bild abrufen und darüber laden. Es ist auch kein größerer Bandbreiten-Hit, dieses "lowsrc"-Bild als mein "Proxy" zur Erstellung der div-Höhe zu verwenden.
Wie Dave Rupert bemerkt, sind 92,8 % aller "mobilen" Bildschirme @1.5x oder höher. Solange wir die Bandbreite nicht einfach berücksichtigen können, müssen wir Entscheidungen treffen, was die beste Erfahrung bietet und wie viel Arbeit wir dafür aufwenden wollen. Ich habe es noch nicht ausprobiert, aber ich denke, ein SASS-Mixin könnte hier hilfreich sein.
danke
Die Verschwendung von Daten ist der eine Punkt, aber die Verschwendung von Zeit ist ein weiterer. Das Laden mehrerer Ressourcen dauert länger und verursacht eine langsamere Reaktion und ruiniert das Benutzererlebnis.
Ich stimme Alex McCabe zu, was die Erhöhung von Daten und Anfragen betrifft.
Während dies auf einem Desktop gut aussehen würde (und das tut es auf den Beispielen), wäre es auf einem Datentarif und einem Mobilgerät ziemlich schlecht.
Ein "Ladebild" zu verwenden, ist jedoch eine Option – der Nutzer erwartet dort etwas. Dieses Bild könnte als skaliertes Hintergrundbild jedes Containers gesetzt werden, der ein Bild lädt.
Ich würde die serverseitigen Optionen dafür wählen.
Trotzdem ein toller Artikel, danke.
Ich glaube nicht, dass LOWSRC in den 50er Jahren verfügbar war. Damals wurde das Internet noch nicht erfunden.
Sarkasmus/Ironie + Internet = Post-Fail
Ich finde das großartig – definitiv ein Schritt in eine interessante Richtung.
Mann, responsive Bilder sind so eine Herausforderung. Normalerweise folge ich einfach der 1,5x-Regel (wobei 1,5x die Größe viel kleiner ist als 2x Dateigröße, aber *viel* näher an 2x im Aussehen auf Retina ist (da Retina mehr Pixel hat, als das menschliche Auge in durchschnittlicher Betrachtungsentfernung unterscheiden kann)).
Offensichtlich keine Option für Fotos, aber ich verwende SVGs, wo immer ich kann (d.h. das Logo auf meiner neuen Firmenwebsite). Die Dateien waren bereits winzig und es war perfekt scharf, selbst bei voller Bildschirmgröße auf Retina. Aber dann erkannte ich, dass die SVG versteckte Ebenen von AI hatte und ich die Größe um ein Drittel reduzierte! Ich exportierte PNG-Fallbacks, und sie sind viermal so groß (und ich habe nicht einmal sehr große Versionen exportiert).
Ich bin überrascht von der SVG-Unterstützung. Grundsätzlich ist nur IE8 etwas, worauf man wirklich achten muss.
Und vergessen Sie nicht die Gzip-Komprimierung auf Ihrem Server. Noch kleinere Dateigrößen! Ich verwende auch überall SVGs, wo immer ich kann.
@ Chris: Man braucht *immer* Art Direction :)
Auf technischer Ebene bin ich von dieser Technik gespalten. Ich bin nicht damit einverstanden, die Anfragen zu verdoppeln, plus zusätzliche Datenübertragung für diese Methode. Und denken Sie daran, nicht einmal 3G ist überall verfügbar.. manchmal bin ich außerhalb von Madison.. ich werde #@^&&$*%%$%* $#@^&*$^&#!!!
Ich habe einmal über die Notwendigkeit von Low-Res-Thumbnails in einer Galerie nachgedacht und dachte, dass der Nutzer sowieso alle Bilder sehen würde, warum also die Thumbnails zum Gewicht der Seite hinzufügen… Die Sache ist, nicht jeder Nutzer (tatsächlich wenige) klickt sich in einer Sitzung durch eine ganze Galerie. Mit anderen Worten, Daumenkino diente der schnellen Navigation und möglicherweise der selektiven Ladung über Links/.js. Dies ist eine umgekehrte Situation, wenn wir über Hintergrundbilder und Figuren (textbezogene Bilder), Avatare usw. sprechen. Jeder Nutzer "sitzt durch" den Hintergrund einer Website, Figuren und Avatare. Obwohl es die "langsamen Verbindungseffekte" abdeckt, scheint es ein teurer Weg zu sein, dies für "nicht-optionale" Inhalte zu tun.
Ich muss zustimmen, dass dies eher wie ein Zeitfresser wirkt, als etwas, das ein signifikant besseres Erlebnis schafft. Ich glaube, ich bin etwas geduldiger als der durchschnittliche Nutzer, daher werde ich warten, bis ein Bild geladen ist, wenn ich auch nur ein geringes Interesse daran habe. Aber wenn es zu lange dauert, werde ich abspringen. Aber es ist etwas, mit dem man arbeiten kann, das ist sicher. Hier gibt es gemischte Kritiken. Danke für die Lektüre.
Ich sehe den Sinn darin, diese Schicht-Sache in einer responsiven Website zu machen. Sie können einfach die benötigte Größe mit Media Queries laden. Das Flackern erscheint nur, wenn Sie die Browsergröße ändern. Ein normaler Nutzer tut dies nicht, während er Ihre Inhalte durchsieht. Aber für Retina-Support ist es vielleicht eine Lösung, um ein Bild vorab zu laden. Ja, und der zusätzliche Datentransfer ist natürlich ein Nachteil...
Ich habe gerade an einer responsiven Website gearbeitet und Scott Jehls Polyfill mit einem Fallback zu den mobilen Fotos verwendet und es hat mir sehr gut gefallen. Mit WordPress, das sich um alle Bildgrößen kümmert, und nur einer schnellen Funktion, um die HTML-Ausgabe zu handhaben, war es super einfach zu bedienen.
Eine Sache, an die ich bis später nicht einmal gedacht habe und von der ich glaube, dass diese Lösung auch darunter leiden wird, ist die Bildersuche. Da im Markup nur der mobile Fallback erwähnt wird, bedeutet das nicht, dass dies das einzige Bild ist, das Google finden wird, wenn es die Seite crawlt? Wenn ich also eine Nachrichtenwebsite bin, die einen Artikel über etwas schreibt, und ein schönes hochauflösendes Bild habe, das nur als Hintergrund in den CSS-Dateien existiert, wird ein Nutzer, der bei Google nach hochauflösenden Bildern sucht, es jemals finden können?
Ein sehr kleiner Anwendungsfall, ich weiß, aber er kam nach dem Start meines letzten Projekts auf und ich habe noch keine Antwort gefunden.
Immer wenn ich an responsives Design denke, denke ich immer an IE8, das ist Zeitverschwendung, wenn man mit verschiedenen Datenquellen arbeitet. Ich arbeite immer mit der einfachsten und schnellsten Methode, damit ich diese Website später bei Bedarf aufrüsten kann.
Im Moment scheinen Bilder in responsiven Kontexten einfach ein extrem nerviges Problem zu sein. Bisher habe ich noch keine "Lösung" gesehen, die wirklich funktioniert oder langfristig nachhaltig ist.
Ich denke, im Moment bleibe ich bei einzelnen Bildern, die so akzeptabel wie möglich sind.
1.5x oder 2x Bilder sind großartig, aber wie viele Leute benutzen einen Retina-Bildschirm? Wahrscheinlich nur ein kleiner Teil der Gesamtheit.
Dies ist eine unterhaltsame Tour durch CSS-Techniken, aber wirklich eine schlechte Idee aus Sicht der Leistung. Nicht nur wegen doppelter Anfragen, sondern weil keine Bildanfrage ausgelöst wird, bis das Stylesheet vollständig geparst ist und ein Teil des Layouts stattgefunden hat. In modernen Browsern mit Lookahead-Präparsern werden Hintergrundbilder viel später geladen als Bilder im Markup. Versuchen Sie ein komplexes (30k+) Stylesheet auf einer komplexen (80k+) Seite mit einer langsamen Verbindung, und Sie werden den Schmerz spüren, wenn Sie zusehen, wie das Layout im View "animiert". Das sind nicht die Droiden, nach denen wir suchen. (Für Server, die PHP ausführen, ist Adaptive Images für mich immer noch so ziemlich das Beste.)
http://adaptive-images.com/
Von ihrer Website: "AI prüft den User Agent String: Wenn es 'mobile' findet, sendet es die niedrigste Auflösung, die in $resolutions definiert ist, andernfalls geht es davon aus, dass Sie ein großes Gerät verwenden, und liefert die höchste."
Das ist, worauf Dave Rupert hinauswollte: Wenn 93% der mobilen Geräte High DPI sind, korreliert die "mobile"-Bezeichnung dann noch mit 1x-Bildern? Können wir Adaptive Images anpassen, um mittelgroße, hochauflösende Bilder für Retina-Mobilgeräte zu liefern?
Toller Artikel und Technik, aber es scheint mir etwas überkonstruiert.
Meiner Meinung nach ist Unveil.js eine viel einfachere Lösung, um hochauflösende Bilder auf Geräten mit Retina-Displays per Lazy Load zu laden und bedingt auszuliefern.
<img src="loader.gif" data-src="img.jpg" data-src-retina="img-retina.jpg" />$(function() { $("img").unveil(); });Ich habe das Skript geschrieben, also mag es etwas prätentiös erscheinen, aber ich stelle den Link hier ein, da ich wirklich glaube, dass es eine sehr gute und einfache Lösung für dieses Problem ist.
luis-almeida.github.io/unveil
Das ist in vielen Fällen eine großartige Lösung, Luís – gute Arbeit! (Auf Ihrer GitHub-Seite habe ich bemerkt, dass Ihr noscript-Beispiel zweimal src deklariert:
img src="bg.png" src="img1.jpg. Wenn das nur funktionieren würde, hätte ich mich nicht durch so viele Hürden gekämpft, um "lowsrc" vorzutäuschen!)Ich habe einen CodePen mit unveil.js zusammengestellt, aber mit einem "lowsrc"-img anstelle eines "loading.gif" angezeigt. Es ist definitiv einfacher, wenn Sie nicht sowieso ein Hintergrundbild verwenden müssen (sagen wir, für flexible Zuschnitte oder für, wissen Sie, einen Hintergrund).
Eine meiner Bedenken ist jedoch die Auslösung ausschließlich basierend auf der Bildschirmdichte. Wenn screensiz.es Recht hat, haben 93 % aller mobilen Geräte eine Pixel-Dichte von 150 % oder höher, aber die meisten benötigen kein hochauflösendes Desktop-Bild für ihren kleineren Bildschirm – sie könnten mit 768-864px gute Ergebnisse erzielen. Mit unveil.js gibt es keine Mittelstellung.
Sie können jedes mobile Gerät mit bedingten Tags ansprechen
http://wpsites.net/web-design/conditional-tags-mobile-devices/
Danke an Brad für die Hervorhebung dieser Fähigkeit in WordPress. Gibt es einen Code-Snippet oder ein Beispiel, wie das funktionieren könnte? Für mich wäre das Ideal, ein mittelgroßes hochauflösendes img src für mobile Retina-Bildschirme und das höchste hochauflösende img src für andere Retina-Bildschirme auszuliefern.
Oder man könnte all diese Bildwechseltechniken wegwerfen und zu einem Bild gehen, das sie alle beherrscht
http://blog.netvlies.nl/design-interactie/retina-revolution/
Es funktioniert nicht für PNG und deckt keine Art Direction ab, aber ansonsten finde ich es funktioniert wunderbar. Ich gestalte gerade eine Foto-Community-Website (erraten Sie mal), bei der die neue Version diese Technik verwenden wird. Die Bilder sind kleiner in der Dateigröße, haben aber viermal so viele Pixel. Es funktioniert wirklich. Ich denke, es ist eine Technik, die zuerst in Betracht gezogen werden sollte, da sie viel Komplexität vermeidet. Darüber hinaus denke ich, dass jede Lösung, die mehrere Bilder erfordert, problematisch ist, da der größte Teil des Webs von einem CMS angetrieben wird, das es möglicherweise nicht unterstützt.
WordPress generiert bereits 4 verschiedene Bildgrößen gemäß Ihren Medienerinstellungen.
Es ist nicht schwierig, weitere benutzerdefinierte Größen hinzuzufügen und sie dann mit spezifischen mobilen bedingten Tags zu verwenden.
Scheint eine coole Idee zu sein, aber ich mag die Idee nicht, dass wir die Hälfte der Bilder im HTML und den Rest in CSS definieren...
Wirklich interessant. Muss daran arbeiten.
Hier eine alternative Lösung für adaptive Bilder: http://litesite.org/holygrail/stage2/