{"id":234,"date":"2012-02-14T14:02:33","date_gmt":"2012-02-14T13:02:33","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/immagini-responsive-quasi-funzionato-cosa-ci-serve\/"},"modified":"2012-02-14T14:02:33","modified_gmt":"2012-02-14T13:02:33","slug":"immagini-responsive-quasi-funzionato-cosa-ci-serve","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/immagini-responsive-quasi-funzionato-cosa-ci-serve\/","title":{"rendered":"Immagini responsive: perch\u00e9 hanno quasi funzionato e cosa ci serve"},"content":{"rendered":"

\u00c8 nostro compito, in qualit\u00e0 di designer e developer, scegliere anche il pi\u00f9 apparentemente semplice task e cercare dei modi per migliorarlo . Quando Ethan Marcotte ha coniato l’espressione \u201cresponsive web design,<\/a>\u201d, ha detto che un sito web responsive \u00e8 composto da tre elementi: una griglia flessibile (flexible grid), delle immagini e dei media flessibili e le media query. Facendo cos\u00ec, ha aperto un mondo di nuove ed eccitanti componenti con cui ossessionarci. Io ho scelto le immagini flessibili.<\/p>\n

\u00c8 piuttosto semplice dare uno stile alle immagini per far s\u00ec che si ridimensionino fino alla dimensione dell’elemento padre aggiungendo img {mag-width: 100%;}<\/code> al foglio di stile. Per usarlo in maniera efficace, tuttavia, l’immagine deve essere sufficientemente larga per ridimensionarsi a qualunque dimensione possiamo ragionevolmente aspettarci sul pi\u00f9 grande display possibile. Questo implica una gran quantit\u00e0 di overhead. Nel caso migliore \u00e8 semplicemente uno spreco. Nel caso peggiore, il mobile browser si mette le mani in tasca e si mette in un angolo, di cattivo umore, praticamente non rendendo la pagina. Un pugno di immagini stampate a vivo progettate per un display da 13″ potrebbe mettere in ginocchio un dispositivo mobile su una connessione Edge.<\/p>\n

Sfortunatamente, non possiamo testare la larghezza di banda in nessun modo affidabile, non adesso perlomeno. Fare dei test implicherebbe probabilmente l’introduzione di un significativo download da sottoporre a misurazione, che \u00e8 molto simile a dar fuoco a qualcosa per capire esattamente quanto sia infiammabile. Quello che possiamo<\/strong> determinare con un buon grado di affidabilit\u00e0 \u00e8 la dimensione dello schermo del device e sebbene non possiamo necessariamente usare la dimensione dello schermo per fare assunzioni riguardanti la larghezza di banda, si collega direttamente a quello che stiamo cercando di ottenere: sebbene la dimensione della finestra del browser possa cambiare, non avremo mai bisogno di immagini pi\u00f9 grandi dello schermo dell’utente.<\/p>\n

Mentre stavamo lavorando al nuovo sito del Boston Globe<\/a>, abbiamo inventato una tecnica per attenuare la dimensione delle richieste per gli utenti che hanno una larghezza di banda limitata. Prima di descriverla, devo avvisarvi: non ha funzionato. Ma era tutto programmato.<\/p>\n

\n

Come funzionavano le immagini responsive<\/h2>\n

Scott Jehl<\/a> ha creato in maniera brillante la tecnica delle \u201cimmagini responsive\u201d di Filament Group<\/a>. Siamo partiti dall’ipotesi che la tecnica dovrebbe garantire il risultato per i device mobili. Con un approccio mobile-first, se una qualunque delle parti del processo fallisce, l’utente dovrebbe essere ancora in grado di ricevere un’immagine rappresentativa, seppur pi\u00f9 piccola, ed evitare le richieste inutilmente grandi su un device che potrebbe avere una larghezza di banda limitata. Il progressive enhancement vince.<\/p>\n

Ci sono tre componenti chiave per lo script delle nostre immagini responsive: il markup, il JavaScript ed una regola di redirect server-side.<\/p>\n

Probabilmente non vi sorprender\u00e0 sapere che abbiamo cominciato con un tag immagine:<\/p>\n

<img src=\"mobile-size.gif\"><\/code><\/pre>\n
Con questo come base, stiamo garantendo che il default \u00e8 un’immagine della dimensione adatta al mobile. Mettiamo il percorso per l’immagine pi\u00f9 grande in un attributo data per accedervi facilmente con JS:<\/p>\n
<img src=\"images\/mobile-size.jpg\" data-fullsrc=\"images\/desktop-size.jpg\"><\/code><\/pre>\n
Adesso che entrambe le sorgenti delle immagini sono nel nostro markup, abbiamo bisogno di un modo per caricare in maniera condizionata la sorgente appropriata. Per farlo abbiamo bisogno di conoscere la dimensione dello schermo dell’utente. Fortunatamente, c’\u00e8 un modo relativamente semplice per determinare la dimensione dello schermo attraverso JavaScript usando una property<\/a> nell’oggetto window<\/code> nel browser: window.screen.width<\/code>, sebbene anche questa non sia totalmente affidabile<\/a>.<\/p>\n
Qui incappiamo in una grande sfida: dobbiamo comunicare questa dimensione al server in tempo per rinviare la richiesta per l’originale src<\/code> dell’immagine, se necessario. Il server ha bisogno di sapere la dimensione dello schermo del client prima che le nostre immagini vengano visualizzate.<\/p>\n
Alla fine abbiamo deciso di impostare la dimensione dello schermo in un cookie. Un cookie impostato nella head di un documento risulta pronto in tempo per il parsing del body del documento ed include le richieste delle immagini.<\/p>\n
Presumo che stiate rabbrividendo all’idea di una funzionalit\u00e0 dipendente da un cookie e lo capisco. Alcune delle nostre prime iterazioni includevano i tag <noscript<\/code> e document.write<\/code>. Ho ancora gli incubi sui tag base<\/code> inclusi dinamicamente. Quelli erano tempi duri e le avevamo provate tutte.<\/p>\n
Il nostro secondo task JavaScript era ben pi\u00f9 semplice: se lo schermo ha una dimensione superiore a quella specificata, scambiamo l’originale src<\/code> di img<\/code> con il percorso contenuto nell’attributo data-fullsrc<\/code> e visualizziamo l’immagine pi\u00f9 grande al posto di quella pi\u00f9 piccola.<\/p>\n
Dal momento che la dimensione dello schermo \u00e8 adesso disponibile sul server, giocherelliamo con una soluzione che ridimensiona automaticamente l’immagine originale per adattarla allo schermo. Abbiamo deciso di non adottare questa soluzione per svariati motivi:<\/p>\n