Fin da quando Ethan Marcotte ha cominciato a parlare di responsive web design nel 2010, gli sviluppatori e i designer si sono dati da fare per trovare dei modi per gestire la questione delle immagini responsive. È un problema spinoso perché stiamo inviando lo stesso sito web, con le stesse sorgenti di immagini, a una gran varietà di device con larghezze diverse. Volete un’immagine sfuocata e pixellata su un grande display? Oppure volete caricare un’immagine enorme (oh ma è così bella!) sul vostro telefono cellulare? Siamo in un vicolo cieco.
Moltissima gente intelligente, ossia il Responsive Issues Community Group (RICG) si è messa a lavorare assieme per risolvere lo stallo di questa situazione. Grazie a loro, l’elemento picture
e gli attributi srcset
e sizes
stanno per essere inseriti nella draft della specifica HTML 5.1. Dal momento che non possiamo prevedere dove e in che modo gli utenti visualizzeranno i nostri siti web, dobbiamo fare in modo che siano i browser stessi a scegliere l’immagine migliore per la situazione. La nuova specifica gestirà le seguenti questioni:
- selezione basata sul device-pixel-ratio
- selezione basata sulla viewport
- selezione basata sull’art direction
- selezione basata sul formato dell’immagine
La specifica introduce anche due nuovi attributi – srcset
e sizes
– per l’elemento img
. srcset
ci permette di dichiarare un insieme di file sorgenti per l’immagine, che i browser invieranno secondo alcune condizioni che noi specificheremo usando i descrittori. I descrittori x
indicano la densità in pixel dell’immagine, mentre i descrittori w
indicano la larghezza delle immagini: i browser useranno queste informazioni per scegliere l’immagine appropriata tra quelle elencate. L’attributo sizes
fornisce al browser un contesto sulle dimensioni dell’elemento immagine che dovrà essere visualizzato e dovrà essere incluso quando si usa srcset
con i descrittori w
. Questo è particolarmente importante per le immagini a larghezza variabile, di cui parlerò più dettagliatamente in seguito.
La cosa importante è che adesso abbiamo l’opzione di inviare immagini di qualità diversa oppure possiamo gestire l’aspetto dell’art direction delle immagini basandoci sulla viewport dell’utente, senza dover fare un setup complicato lato server. Le immagini responsive diventeranno parte integrante della specifica di HTML e, alla fine, tutti i browser supporteranno questa soluzione.
Ora, facciamo un tour dei tipi di selezione e del modo in cui potete utilizzarli.
Immagini a larghezza fissa: selezione basata sul device-pixel-ratio#section1
Con l’introduzione degli schermi Retina, è diventato necessario prendere in considerazione non solo la risoluzione di schermo, ma anche la densità di pixel. Gli schermi retina, i display 4K, gli UltraHD hanno tutti molti più pixel di un display a risoluzione standard della stessa dimensione. Più pixel = qualità dell’immagine più nitida.
Se, per un qualsiasi motivo, avete un’immagine che verrà sempre visualizzata ad una certa larghezza indipendentemente dalla dimensione dello schermo, supponiamo per esempio il logo del sito o un’immagine profilo, allora la strada che dovrete percorrere è quella della selezione basata sul device-pixel-ratio. Il browser sceglierà quale immagine caricare basandosi sul suo rapporto device-pixel.
In pratica, l’attributo srcset
elenca l’insieme di immagini sorgente a cui il browser può attingere per scegliere quale caricare. È un elenco separato da virgole. Il descrittore x
indica il rapporto device-pixel dell’immagine. A seconda dell’ambiente in cui opera, il browser utilizzerà questa informazione per selezionare l’immagine appropriata. Un qualsiasi browser che non comprenda srcset
caricherà semplicemente l’immagine dichiarata nell’attributo src
.
<img srcset="crest-383.jpg 1.5x, crest-510.jpg 2x" src="crest-255.jpg" alt="USWNT crest" />

Un esempio di un’immagine a larghezza fissa potrebbe essere il logo del sito, che rimane della stessa dimensione indipendentemente dalla larghezza della viewport. Tuttavia, le immagini relative al contenuto, sono solitamente responsive: le loro dimensioni tendono a cambiare a seconda della viewport. Per questo tipo di immagini, c’è un metodo migliore.
Immagini a larghezza fluida: selezione basata sulla viewport#section2
Per le immagini a larghezza fluida, usiamo srcset
con il descrittore w
e sizes
. Il descrittore w
dice al browser la larghezza di ciascuna immagine dell’elenco. L’attributo sizes
è anch’esso un elenco separato da virgole contenente due valori. Nell’ultima specifica, se srcset
ha una qualsiasi immagine che utilizza il descrittore w
, allora può essere presente anche l’attributo sizes
.
Ci sono due valori nell’attributo sizes
. Il primo è una media condition. Il secondo è il source-size-value, che determina la larghezza dell’immagine data una particolare media condition. Una cosa importante da notare è che non potete usare le percentuali come source-size-value: l’unica lunghezza CSS relativa che potete usare è vw
.
<img srcset="uswnt-480.jpg 480w,
uswnt-640.jpg 640w,
uswnt-960.jpg 960w,
uswnt-1280.jpg 1280w"
sizes="(max-width: 400px) 100vw,
(max-width: 960px) 75vw,
640px"
src="uswnt-640.jpg" alt="USWNT World Cup victory">

In questo caso, sto dicendo al browser che l’immagine deve occupare il 100% della larghezza della viewport per larghezze della viewport fino a 400 pixel. Per larghezze della viewport fino a 960 pixel, l’immagine deve occupare il 75% della larghezza della viewport. E per tutto il resto oltre i 960 pixel, l’immagine deve essere di 640 pixel. Se non avete familiarità con vw
, date un’occhiata al grande articolo di Tim Severien che spiega le viewport units.
Il browser utilizza l’informazione da srcset
e sizes
per inviare l’immagine che meglio si addice alle condizioni specificate. Se la viewport del mio browser è 600 pixel, molto probabilmente mostrerà l’immagine a 75vw
. Il browser cercherà di caricare la prima immagine più larga di 450 pixel, che è uswnt-480.jpg
. Se sono su un display Retina con un rapporto device-pixel di 2, allora il browser cercherà di caricare la prima immagine più larga di 900 pixel, che dovrebbe essere uswnt-960.jpg
. Non possiamo essere sicuri esattamente di quale immagine verrà inviata perché ogni browser ha una certa libertà di azione sul modo in cui il suo algoritmo sceglie un’immagine appropriata basandosi sull’informazione che noi gli forniamo. Questo è il significato di “selezione basata sulla viewport”.
Poiché i primi due esempi mostrano la stessa immagine con diversi livelli di qualità, è sufficiente il solo attributo srcset
. Di nuovo, se siete preoccupati per i browser legacy, è per questo motivo che c’è src
: quei browser la tratteranno semplicemente come un’immagine regolare e la caricheranno da src
. Se desiderate mostrare immagini leggermente diverse a larghezze diverse, per esempio, vorrete mostrare solo le parti critiche di un’immagine a larghezze più piccole, perciò dovrete usare l’elemento picture
.
picture
: selezione basata sull’art direction#section3
L’elemento picture
è come un wrapper per l’immagine e i suoi file sorgenti. I browser hanno ancora bisogno di img
per sapere che devono inviare un’immagine: senza img
non visualizzano nulla. source
fornisce al browser delle versioni alternative dell’immagine da mostrare. La selezione basata sull’art direction è utilizzata nelle situazioni in cui vogliamo mostrare una specifica immagine ad uno specifico breakpoint. Non c’è alcuna ambiguità in termini di selezione dell’immagine quando si usa l’elemento picture
.
<picture>
<source media="(min-width: 960px)" srcset="ticker-tape-large.jpg">
<source media="(min-width: 575px)" srcset="ticker-tape-medium.jpg">
<img src="ticker-tape-small.jpg" alt="USWNT ticker-tape parade">
</picture>
In questo esempio, quando la viewport è più larga di 960 pixel, viene caricata una versione landscape-oriented dell’immagine (ticker-tape-large.jpg
). Per larghezze maggiori di 575 pixel, il browser carica invece un’immagine portrait-oriented di cui è stato fatto un crop (ticker-tape-medium.jpg
). E per larghezze minori di 575 pixel, l’immagine (ticker-tape-small.jpg
) caricata è stata ritagliata così da essere focalizzata solo su una giocatrice.
L’elemento picture
è backwards compatible: i browser che non supportano l’elemento picture
mostreranno img
come al solito. Tutti gli attributi standard delle immagini, come alt
, dovrebbero essere applicati a img
, non a picture
.
source
: selezione basata sul formato dell’immagine#section4
Negli ultimi anni sono apparsi dei nuovi formati per le immagini, che offrono una qualità migliore con dimensioni di file minori. Sembra una buona cosa, no? Sì, lo è, finché non realizzate che nessuno di questi formati è universalmente supportato in tutti i browser. WebP di Google ha un’ottima performance, ma viene supportato nativamente solo da Chrome e Opera. JPEG-XR, originariamente noto come HD Photo, era un formato immagine proprietario rilasciato da Microstoft, supportato solo da Internet Explorer. Se volete saperne di più, Zoltan Hawryluk ha fatto un’analisi dettagliata di questi nuovi formati.
<picture>
<source type="image/vnd.ms-photo" src="wwc2015.jxr">
<source type="image/jp2" src="wwc2015.jp2">
<source type="image/webp" src="wwc2015.webp">
<img src="wwc2015.png" alt="WWC 2015">
</picture>
Dal momento che source
ha anche un attributo type
, specificando il MIME type di ciascuna immagine, i browser possono scegliere la prima sorgente che abbia l’attributo type
di un MIME type supportato. L’ordine delle sorgenti è importante, in questo caso, ma se il browser non riconosce alcun tipo di immagine, ritornerà semplicemente all’elemento img
originale.
Posso usare tutto questo già adesso?#section5
Al momento in cui scrivo, picture
è supportato dalle ultime release stabili di Firefox, Chrome e Opera. Safari e Internet Explorer non supportano per niente picture
nativamente. srcset
se la passa leggermente meglio, con supporto pieno nelle ultime release stabili di Firefox, Chrome e Opera e con supporto parziale in Safari 8 e Internet Explorer Edge, in cui è permesso l’uso dei descrittori x
per cambiare risoluzione, ma non dei descrittori w
.
C’è un certo numero di polyfill per la gestione di questo problema relativo al supporto. Quello più noto probabilmente è picturefill di Scott Jehl. Attualmente, io sto usando respimage di Alexander Farkas sul mio sito. Finalmente, abbiamo raggiunto un punto in cui siamo d’accordo su una soluzione su come gestire le immagini responsive e questa soluzione viene implementata in tutti i maggiori browser. Anche se la specifica è ancora in fase di raffinamento, siamo davvero vicini a una soluzione responsive nativa.
E se volete essere super-aggiornati, vi raccomando tantissimo di guardare il Responsive Issues Community Group. Potete anche registrarvi per la loro newsletter o seguirli su Twitter.
Illustrazioni: {carlok}
Nessun commento
Altro da ALA
Webwaste
Uno strumento essenziale per catturare i vostri progressi lavorativi
Andiamo al cuore dell’accessibilità digitale
JavaScript Responsabile, Parte II
JavaScript Responsabile: parte prima