{"id":519,"date":"2015-02-09T16:41:53","date_gmt":"2015-02-09T15:41:53","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/immagini-responsive-in-pratica\/"},"modified":"2015-02-09T16:41:53","modified_gmt":"2015-02-09T15:41:53","slug":"immagini-responsive-in-pratica","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/immagini-responsive-in-pratica\/","title":{"rendered":"Immagini responsive in pratica"},"content":{"rendered":"<div class=\"paragrafo\">\n<blockquote>\n<p>Il diavolo ha messo una penalit\u00e0 sulle cose della vita che ci piacciono.<\/p>\n<p><cite><a href=\"http:\/\/en.wikiquote.org\/wiki\/Albert_Einstein#Attributed_from_memory_and_posthumous_publications\">Albert Einstein<\/a><\/cite><\/p><\/blockquote>\n<p><img decoding=\"async\" src=\"http:\/\/alistapart.com\/it\/wp-content\/uploads\/sites\/2\/2015\/02\/n107image.jpg\" border=\"0\" align=\"left\" \/>Il <a href=\"http:\/\/httparchive.org\/interesting.php#bytesperpage\">62% del peso del web \u00e8 costituito dalle immagini<\/a> e <a href=\"http:\/\/httparchive.org\/trends.php?s=All&amp;minlabel=Nov+15+2010&amp;maxlabel=Oct+15+2014#bytesImg&amp;reqImg\">pi\u00f9 passano i giorni pi\u00f9 inviamo byte di immagini<\/a>. Sarebbe fantastico se tutti questi byte fossero usati in maniera ottimale, ma su schermi piccoli o a bassa risoluzione <a href=\"http:\/\/timkadlec.com\/2013\/06\/why-we-need-responsive-images\/\">la maggior parte dei dati viene sprecata<\/a>.<\/p>\n<p>Perch\u00e9? Nonostante il web sia stato progettato per essere accessibile da <a href=\"https:\/\/twitter.com\/timberners_lee\/status\/228960085672599552\">tutti<\/a>, con <a href=\"http:\/\/www.w3.org\/Consortium\/mission#principles\">qualunque dispositivo<\/a>, \u00e8 solo recentemente che il panorama dei device si \u00e8 diversificato abbastanza da forzare un movimento grande quanto il settore verso il responsive design. Quando progettiamo in maniera responsive, il nostro contenuto fluisce elegantemente ed efficientemente in ogni device. Tutto il nostro contenuto, ad eccezione delle bitmap. Le immagini bitmap hanno una risoluzione fissa e il loro contenitore, il venerabile <code>img<\/code> con la sua purtroppo singola <code>src<\/code> non permette alcun adattamento.<\/p>\n<p>Posti di fronte ad una <a href=\"http:\/\/www.urbandictionary.com\/define.php?term=Sophie%27s+choice\">scelta di Sophie<\/a> &#8211; se rendere le pagine sfuocate per alcuni o lente per tutti &#8211; la maggior parte dei designer sceglie l&#8217;ultima, mandando a tutti le immagini che dovrebbero riempire gli schermi pi\u00f9 grandi e a maggior risoluzione. Quindi, spreco.<\/p>\n<p>Ebbene, dopo tre anni di dibattito, sono emersi alcuni markup per risolvere il problema delle immagini responsive:<\/p>\n<ul>\n<li><code>srcset<\/code><\/li>\n<li><code>sizes<\/code><\/li>\n<li><code>picture<\/code><\/li>\n<li>e la nostra vecchia amica <code>source<\/code> (presa in prestito da <code>audio<\/code> e <code>video<\/code>)<\/li>\n<\/ul>\n<p>Questi nuovi elementi ed attributi ci permettono di inserire nel markup pi\u00f9 sorgenti alternative e mandano ad ogni client la sorgente che meglio gli si adatta. Si sono fatte strada nelle specifiche ufficiali e la loro prima implementazione completa, in Chrome 38, \u00e8 uscita a Settembre. Con fallback eleganti e <a href=\"http:\/\/scottjehl.github.io\/picturefill\/\">un polyfill<\/a> per tamponare il problema, possiamo e dovremmo implementare le immagini responsive <em>fin d&#8217;ora<\/em>. Allora facciamolo!<\/p>\n<p>Prendiamo una pagina web esistente e rendiamo le sue immagini responsive. Lo faremo in tre passaggi, applicando ciascun pezzo del nuovo markup a turno:<\/p>\n<ol>\n<li>Ci assicureremo che le nostre immagini si ridimensionino efficientemente con <code>srcset<\/code> e <code>sizes<\/code>.<\/li>\n<li>Applicheremo l&#8217;art direction alle nostre immagini con <code>picture<\/code> e <code>source media<\/code>. <\/li>\n<li>Forniremo un formato di immagine alternativo usando <code>picture<\/code> e <code>source type<\/code>.<\/li>\n<\/ol>\n<p>In questo processo vedremo di persona gli incredibili guadagni in termini di performance permessi dalle nuove feature.<\/p>\n<\/div>\n<div class=\"paragrafo\">\n<h2>Lo status quo<\/h2>\n<blockquote>\n<p>Credo non mi interessi cos\u00ec tanto essere vecchio quanto mi interessi essere grasso e vecchio.<\/p>\n<p><cite><a href=\"http:\/\/thinkexist.com\/quotation\/i_guess_i_don-t_so_much_mind_being_old-as_i_mind\/200747.html\">Benjamin Franklin<\/a> (o era <a href=\"http:\/\/www.tejvan.co.uk\/funny\/funny_quotes_old_age\/view\/index.html\">Peter Gabriel<\/a>?) <\/cite><\/p><\/blockquote>\n<p>Prendiamo come tema <a href=\"https:\/\/alistapart.github.io\/code-samples\/407\/demo\/status-quo.html\">una piccola pagina sulle bizzarre coperte denominate quilt<\/a>. \u00c8 una semplice pagina responsive. Non c&#8217;\u00e8 molto che possa intralciare il suo contenuto primario: immagini giganti (di coperte!). Vogliamo mostrare sia il design generale di ogni coperta sia quanti pi\u00f9 intricati dettagli possibile. Cos\u00ec, per ciascuna, presentiamo due immagini:<\/p>\n<ol>\n<li>l&#8217;intera coperta, della larghezza del paragrafo<\/li>\n<li>un dettaglio della stessa, che riempia il 100% della larghezza della viewport.<\/li>\n<\/ol>\n<p>Come potremmo assegnare la dimensione e che markup dovremmo usare per le nostre immagini <em>senza<\/em> usare quello nuovo?<\/p>\n<p>Per prima cosa prendiamo in considerazione le coperte intere. Per essere sicuri che appaiano sempre ben definite, dobbiamo capire la dimensione pi\u00f9 grande possibile del layout. Ecco il CSS che ci interessa:<\/p>\n<pre><code>* {\n\tbox-sizing: border-box;\n}\nbody {\n\tfont-size: 1.25em;\n}\nfigure {\n\tpadding: 0 1em;\n\tmax-width: 33em;\n}\nimg { \n\tdisplay: block;\n\twidth: 100%;\n}<\/code><\/pre>\n<p>Possiamo anche calcolare la larghezza pi\u00f9 grande possibile per il display di <code>img<\/code> prendendo la <code>max-width<\/code> di <code>figure<\/code>, sottraendone il <code>padding<\/code> e convertendo gli em in pixel:<\/p>\n<pre><code>  100% &lt;img&gt; width\nx ( 33em &lt;figure&gt; max-width\n   - 2em &lt;figure&gt; padding )\nx 1.25em &lt;body&gt; font-size\nx 16px default font-size\n= 620px<\/code><\/pre>\n<p>Oppure possiamo imbrogliare rendendo davvero grande la finestra e dando un sbirciata ai dev tools:<\/p>\n<p><img decoding=\"async\" src=\"http:\/\/alistapart.com\/it\/wp-content\/uploads\/sites\/2\/2015\/02\/box-model.png\" border=\"0\" alt=\"Immagine del box mode nei dev tools di Chrome che mostra che l'elemento \u00e8 largo 620px.\" \/><\/p>\n<p>(io preferisco il secondo metodo).<\/p>\n<p>In entrambe i modi arriviamo alla massima larghezza del display che mostra l&#8217;<code>img<\/code> dell&#8217;intero quilt con larghezza di 620px. Renderemo le nostre immagini sorgente al doppio di questa per accomodare gli schermi con risoluzione 2x: 1240 pixel di larghezza.<\/p>\n<p>Ma cosa facciamo con le nostre immagini del dettaglio? Si espandono fino a riempire l&#8217;intera viewport, la cui dimensione non ha un limite superiore fissato. Cos\u00ec scegliamo <a href=\"http:\/\/en.wikipedia.org\/wiki\/1080p\">qualcosa di leggermente pi\u00f9 grande e dal sapore di standard<\/a> e le rendiamo, diciamo, al massimo a 1920 pixel di larghezza.<\/p>\n<p>Quando rendiamo le nostre immagini a queste dimensioni <a href=\"https:\/\/alistapart.github.io\/code-samples\/407\/demo\/status-quo.html\">la nostra pagina dello status quo<\/a> pesa un notevole 3.5MB. Tutto tranne 5.7kB di quel peso \u00e8 costituito da immagini. Possiamo intuire che molti dei byte di quelle immagini costituiscono un overhead invisibile quando vengono inviati a piccoli schermi a bassa risoluzione, ma quanti? Mettiamoci al lavoro.<\/p>\n<\/div>\n<div class=\"paragrafo\">\n<h2>Primo passaggio: ridimensionamento con <code>scrset<\/code> e <code>sizes<\/code><\/h2>\n<blockquote>\n<p>Teatherball with a tennis ball for his shoelaces<\/p>\n<p>Naturally adapt to have more than two faces<\/p>\n<\/blockquote>\n<p><cite><a href=\"http:\/\/rapgenius.com\/Kool-ad-dum-diary-lyrics#note-2535201\">Kool AD, <cite>Dum Diary<\/cite><\/a><\/cite><\/p>\n<p>Il primo problema che affronteremo \u00e8 far s\u00ec che le nostre immagini si ridimensionino in maniera efficiente tra le varie larghezze della viewport e le risoluzioni di schermo. Offriremo <em>pi\u00f9 risoluzioni<\/em> della nostra immagine, cos\u00ec che possiamo inviare file sorgenti giganti solo agli schermi giganti e\/o ad alta risoluzione e versioni pi\u00f9 piccole a tutti gli altri. In che modo? Con <code>srcset<\/code>.<\/p>\n<p>Ecco una delle nostre immagini dei dettagli larga quanto la viewport:<\/p>\n<pre><code class=\"language-markup\">&lt;img\n\tsrc=\"quilt_2-detail.jpg\"\n\talt=\"Detail of the above quilt, highlighting the embroidery \n       and exotic stitchwork.\" \/&gt;<\/code><\/pre>\n<p><code>quilt_2-detail.jpg<\/code> ha una larghezza di 1920 pixel. Rendiamo due versioni pi\u00f9 piccole che devono andare con questa e scriviamo il markup in questo modo:<\/p>\n<pre><code class=\"language-markup\">&lt;img\n\tsrcset=\"quilt_2\/detail\/large.jpg  1920w, \n\t        quilt_2\/detail\/medium.jpg  960w,\n\t        quilt_2\/detail\/small.jpg   480w\"\n\tsrc=\"quilt_2\/detail\/medium.jpg\"\n\talt=\"Detail of the above quilt, highlighting the embroidery\n      and exotic stitchwork.\"&gt;<\/code><\/pre>\n<p>La prima cosa da notare riguardo a questa <code>img<\/code> \u00e8 che ha ancora <code>src<\/code>, che verr\u00e0 caricata dai browser che non supportano la nuova sintassi.<\/p>\n<p>Per i client pi\u00f9 capaci, abbiamo aggiunto qualcosa di nuovo: un attributo <code>srcset<\/code>, che contiene una lista separata da virgole di URL per le risorse. Dopo ciascun URL includiamo un \u201cdescrittore di larghezza\u201d, che specifica la larghezza in pixel di ciascuna immagine. La vostra immagine \u00e8 1024 x 768? Mettete un <code>1024w<\/code> dopo il suo URL in <code>srcset<\/code>. I browser che riconoscono <code>srcset<\/code> usano queste larghezze in pixel e tutto il resto che sanno dell&#8217;attuale ambiente di browsing per scegliere una sorgente da caricare tra quelle specificate nell&#8217;insieme.\u009d<\/p>\n<p>In che modo fanno la loro scelta? Ecco quel che preferisco di <code>srcset<\/code>: non lo sappiamo! <em>Non possiamo<\/em> saperlo perch\u00e9 la logica che sta dietro alla scelta \u00e8 stata intenzionalmente lasciata non specificata.<\/p>\n<p>Le prime soluzioni proposte per il problema delle immagini responsive cercavano di dare <em>pi\u00f9 controllo<\/em> agli autori. Avremmo dovuto farcene carico <em>noi<\/em>, creando insiemi esaustivi di media query &#8211; piani di emergenza che elencano tutte le combinazioni di dimensioni di schermo e di risoluzioni, con una sorgente creata su misura per ciascuna.<\/p>\n<p><code>srcset<\/code> ci salva da noi stessi. Il controllo dei particolari \u00e8 ancora disponibile quando ci serve (di pi\u00f9 su questo a breve), ma la maggior parte delle volte \u00e8 meglio se lasciamo che sia il browser a decidere. I browser hanno un patrimonio di conoscenza dello schermo, della viewport, della connessione e delle preferenze di una persona. Cedendo il controllo, descrivendo le nostre immagini piuttosto che prescrivendo sorgenti specifiche per una miriade di destinazioni, permettiamo al browser di far valere la sua conoscenza. Otteniamo una funzionalit\u00e0 migliore (future-friendly!) da molto meno codice.<\/p>\n<p>Tuttavia c&#8217;\u00e8 un inghippo: scegliere una sorgente sensata richiede la conoscenza della dimensione del layout dell&#8217;immagine. Per\u00f2 non possiamo chiedere ai browser di ritardare la scelta finch\u00e9 tutto l&#8217;HTML, il CSS e il JavaScript siano stati tutti caricati e ne abbia fatto il parsing. Quindi dobbiamo dare ai browser una stima della larghezza del display dell&#8217;immagine usando un altro attributo nuovo: <code>sizes<\/code>.<\/p>\n<p>Come ho fatto a nascondervi questa scomoda verit\u00e0 fino ad ora? Le immagini dei dettagli nella nostra pagina di esempio sono un caso particolare. Occupano l&#8217;intera larghezza della viewport\u2014<code>100vw<\/code>\u2014che quindi diventa il valore di default delle <code>sizes<\/code>. Tuttavia, le nostre immagini delle coperte intere, hanno la stessa larghezza del paragrafo e spesso occupano significativamente meno spazio. \u00c8 necessario che noi si dica al browser esattamente quanto grandi debbano essere con <code>sizes<\/code>.<\/p>\n<p><code>sizes<\/code> accetta le <a href=\"http:\/\/www.w3.org\/TR\/css3-values\/#lengths\">lunghezze CSS<\/a>. Quindi:<\/p>\n<pre><code class=\"language-markup\">sizes=\"100px\"<\/code><\/pre>\n<p>&#8230;dice il browser: questa immagine verr\u00e0 mostrata alla larghezza fissa di <code>100px<\/code>. Semplice!<\/p>\n<p>Il nostro esempio \u00e8 pi\u00f9 complesso. Mentre le <code>img<\/code> della coperta hanno come stile una semplice regola <code>width: 100%<\/code>, le figure che le ospitano hanno una <code>max-width<\/code> di <code>33em<\/code>.<\/p>\n<p>Fortunamtamente, <code>sizes<\/code> ci permette di fare due cose:<\/p>\n<ol>\n<li>Ci permette di dare misure diverse elencandole separate da virgole.<\/li>\n<li>Ci permette di agganciare delle media condition alle misure.<\/li>\n<\/ol>\n<p>In questo modo:<\/p>\n<pre><code class=\"language-markup\">sizes=\"(min-width: 33em) 33em, 100vw\"<\/code><\/pre>\n<p>Dice: la viewport \u00e8 pi\u00f9 larga di <code>33em<\/code>? Questa immagine sar\u00e0 larga <code>33em<\/code>. Altrimenti, sar\u00e0 <code>100vw<\/code>.<\/p>\n<p>Questo si avvicina a quello che serve a noi, ma non va completamente bene. Il nostro esempio \u00e8 reso complicato dalla natura relativa degli em. Il corpo della nostra pagina ha un <code>font-size<\/code> di <code>1.25em<\/code>, quindi \u201c1em\u201d\u009d nel contesto del CSS delle nostre <code>figure<\/code> sar\u00e0 1.25 volte la dimensione di default del font del browser. Ma all&#8217;interno delle media condition (e quindi, all&#8217;interno di <code>sizes<\/code>), un eem \u00e8 sempre uguale al font size di default. Occorre fare delle moltiplicazioni per 1.25: 1.25 x 33 = 41.25.<\/p>\n<pre><code class=\"language-markup\">sizes=\"(min-width: 41.25em) 41.25em,\n       100vw\"<\/code><\/pre>\n<p>Questo cattura piuttosto bene la larghezza delle nostre coperte e, francamente, probabilmente \u00e8 sufficientemente buono. \u00c8 accettabile al 100% che <code>sizes<\/code> fornisca la browser una stima grezza della larghezza del layout delle <code>img<\/code>. Spesso, barattare una piccola quantit\u00e0 di precisione per degli enormi guadagni in termini di leggibilit\u00e0 e manutenibilit\u00e0 \u00e8 la scelta giusta. Ci\u00f2 detto, proseguiamo e rendiamo preciso il nostro esempio calcolando gli em di padding su entrambe i lati della figura: 2 lati x 1.25 em della media-condition ciascuno = 2.5em di padding da tenere presenti.<\/p>\n<pre><code class=\"language-markup\">&lt;img \n\tsrcset=\"quilt_3\/large.jpg  1240w, \n\t        quilt_3\/medium.jpg  620w,\n\t        quilt_3\/small.jpg   310w\"\n\tsizes=\"(min-width: 41.25em) 38.75em,\n\t       calc(100vw - 2.5em)\"\n\tsrc=\"quilt_3\/medium.jpg\"\n\talt=\"A crazy quilt whose irregular fabric scraps are fit \n       into a lattice of diamonds.\" \/&gt;<\/code><\/pre>\n<p>Rivediamo cosa abbiamo fatto in questo caso. Abbiamo dato al browser la versione grande, media e piccola della nostra immagine usando <code>srcset<\/code> e abbiamo dato loro delle larghezze in pixel usando i descrittori <code>w<\/code>, e abbiamo detto al browser quanto spazio del layout dovranno occupare mediante <code>sizes<\/code>.<\/p>\n<p>Se questo fosse un semplice esempio, avremmo potuto dare al browser una singola lunghezza nel CSS come <code>sizes=\"100px\"<\/code> o <code>sizes=\"50vw\"<\/code>. Ma non siamo stati cos\u00ec fortunati. Abbiamo dovuto dare al browser <em>due<\/em> lunghezze CSS e stabilire che la prima lunghezza si applica solo quando \u00e8 vera una certa media condition.<\/p>\n<p>Fortunatamente, tutto quel lavoro non \u00e8 stato fatto in vano. Utilizzando <code>srcset<\/code> e <code>sizes<\/code>, abbiamo dato al browser tutto quello di cui ha bisogno per scegliere una sorgente. Una volta che conosce le larghezze in pixel delle sorgenti e la larghezza del layout della <code>img<\/code>, il browser calcola la proporzione della larghezza sorgente-layout per ogni sorgente. Quindi, supponiamo che <code>sizes<\/code> ritorni 620px. Una sorgente di <code>620w<\/code> avrebbe 1x i pixel della <code>img<\/code>. Una sorgente di <code>1240w<\/code> ne avrebbe 2x. <code>310w<\/code>? 0.5x. Il browser individua queste proporzioni e poi sceglie qualsiasi sorgente voglia.<\/p>\n<p>Vale la pena notare che la specifica permette di fornire direttamente proporzioni e che alle sorgenti senza un descrittore verr\u00e0 assegnata la proporzione di default <code>1x<\/code>, permettendoci di scrivere markup come questo:<\/p>\n<pre><code class=\"language-markup\">&lt;img src=\"standard.jpg\" srcset=\"retina.jpg 2x, super-retina.jpg 3x\" \/&gt;<\/code><\/pre>\n<p>Questo \u00e8 un modo carino e compatto per dare immagini ad hi-DPI. Ma, funziona solo per immagini con larghezza fissa. Tutte le immagini della nostra pagine delle coperte folli sono fluide, quindi questa \u00e8 l&#8217;ultima volta in cui sentiremo parlare dei descrittori <code>x<\/code>.<\/p>\n<\/div>\n<div class=\"paragrafo\">\n<h2>Misurare<\/h2>\n<p>Ora che abbiamo <a href=\"https:\/\/alistapart.github.io\/code-samples\/407\/demo\/first-pass.html\">riscritto la nostra pagina delle coperte folli usando <code>srcset<\/code> e <code>sizes<\/code><\/a>, cosa abbiamo guadagnato in termini di performance?<\/p>\n<p>Il peso della nostra pagina \u00e8 ora (gloriosamente!) reattivo alle condizione del browsing. Varia, pertanto non possiamo rappresentarlo con un solo numero. Ho ricaricato la pagina molte volte in Chrome e ho messo su un grafico il suo peso in una variet\u00e0 di viewport di larghezza diversa:<\/p>\n<div class=\"illustration full left\"><img decoding=\"async\" src=\"http:\/\/alistapart.com\/it\/wp-content\/uploads\/sites\/2\/2015\/02\/first-pass.png\" border=\"0\" alt=\"Un grafico del peso della pagina per larghezza della finestra. C'\u00e8 una riga piatta in cima e dei gradini sotto.\" width=\"100%\" \/><\/div>\n<p>La prima linea grigia e piatta in alto rappresenta il peso dello status quo, 3.5MB. Le linee spesse (schermi 1x) e sottili (2x) di colore verde rappresentano il peso della nostra pagina per ogni larghezza di viewport tra 320px e 1280px aggiornata con <code>srcset<\/code> e <code>size<\/code>.<\/p>\n<p>Su schermi 2x di 320px di larghezza abbiamo tagliato il peso della nostra pagina di due terzi: prima la pagina era di 3.5MB, adesso inviamo solo 1.1MB. Su schermi 1x di 320px, la nostra pagina \u00e8 <em>meno di un decimo<\/em> il peso che era: 306kB.<\/p>\n<p>Da qui, le dimensioni in by crescono man mano che carichiamo sorgenti pi\u00f9 grandi per riempire viewport pi\u00f9 grandi. Sui device 2x facciamo un salto significativo alle larghezze della viewport di circa 350px e torniamo al peso dello status quo dopo 480px. Sugli schermi 1x, il risparmio \u00e8 notevole: abbiamo risparmiato tra il 70 e l&#8217;80% del peso originale della pagina finch\u00e9 non abbiamo passato i 960px. L\u00e0 raggiungiamo il massimo con una pagina che \u00e8 pi\u00f9 piccola del 40% circa rispetto a quella da cui siamo partiti.<\/p>\n<p>Questi tipi di riduzioni &#8211; 40%, 70%, 90% &#8211; dovrebbero farvi fermare di colpo. Abbiamo tolto quasi <em>due megabyte e mezzo<\/em> di carico per ogni iPhone Retina. Misuratelo in millisecondi o moltiplicatelo per migliaia di pageview e vedrete per che cosa \u00e8 tutta questa agitazione.<\/p>\n<\/div>\n<div class=\"paragrafo\">\n<h2>Secondo step: <code>picture<\/code> e art direction<\/h2>\n<blockquote><p><code>srcset<\/code> se sei pigro, <code>picture<\/code> se sei matto\u2122<\/p><\/blockquote>\n<p><a href=\"http:\/\/ircbot.responsiveimages.org\/bot\/log\/respimg\/2014-06-24#T78853\">Mat Marquis<\/a><\/p>\n<p>Allora, per le immagini che devono semplicemente ridimensionarsi, facciamo una lista delle sorgenti e delle loro larghezze in pixel in <code>srcset<\/code>, facciamo sapere al browser quale sar\u00e0 la larghezza dell&#8217;<code>img<\/code> visualizzata usando <code>sizes<\/code> e lasciamo perdere <a href=\"http:\/\/alistapart.com\/article\/dao#section2\">il nostro desiderio da pazzi di avere il controllo<\/a>. Per\u00f2, ci saranno momenti in cui vorremo che le nostre immagini si adattino in modi che vanno oltre il ridimensionamento. Quando lo facciamo, abbiamo bisogno di riappropriarci di una parte di quel controllo sulla scelta della sorgente. Faccia il suo ingresso <code>picture<\/code>.<\/p>\n<p>Le nostre immagini dei dettagli hanno un aspect ratio grande, 16:9. Su schermi grandi vanno benissimo ma sui telefoni appaiono piccole. Le cuciture e i ricami che dovrebbero essere mostrati nei dettagli sono troppo piccoli per risaltare.<\/p>\n<p>Sarebbe bello se potessimo fare un ingrandimento sugli schermi piccoli, presentando un crop pi\u00f9 alto e stretto.<\/p>\n<p><img decoding=\"async\" src=\"http:\/\/alistapart.com\/it\/wp-content\/uploads\/sites\/2\/2015\/02\/art-direction.gif\" border=\"0\" alt=\"Illustrazione animata che mostra quanto diventano piccole le immagini dei dettagli sugli schermi pi\u00f9 stretti e quanti pi\u00f9 dettagli otteniamo presentando un crop diverso.\" width=\"100%\" \/><\/p>\n<p>Questo tipo di ritaglio su misura del <em>contenuto<\/em> dell&#8217;immagine perch\u00e9 si adatti ad ambienti specifici \u00e8 detto \u201c<a href=\"http:\/\/usecases.responsiveimages.org\/#art-direction\">art direction<\/a>\u201d. Ogni volta che facciamo un crop o alteriamo un immagine perch\u00e9 sia adatta ad un breakpoint (piuttosto che fare un semplice ridimensionamento dell&#8217;intera immagine), stiamo facendo art direction.<\/p>\n<p>Se includessimo i crop ingranditi in un <code>srcset<\/code>, non si potrebbe dire quando verrebbero scelti e quando no. Utilizzando <code>picture<\/code> e <code>source media<\/code>, possiamo rendere espliciti i nostri desideri: carica solo i crop rettangolari larghi quando la viewport \u00e8 pi\u00f9 larga di 36em. Nelle viewport pi\u00f9 piccole, usa sempre quelle quadrate.<\/p>\n<pre><code class=\"language-markup\">&lt;picture&gt;\n\t&lt;!-- 16:9 crop --&gt;\n\t&lt;source\n\t\tmedia=\"(min-width: 36em)\"\n\t\tsrcset=\"quilt_2\/detail\/large.jpg  1920w,\n\t\t        quilt_2\/detail\/medium.jpg  960w,\n\t\t        quilt_2\/detail\/small.jpg   480w\" \/&gt;\n\t&lt;!-- square crop --&gt;\n\t&lt;source\n\t\tsrcset=\"quilt_2\/square\/large.jpg  822w,\n\t\t        quilt_2\/square\/medium.jpg 640w,\n\t\t        quilt_2\/square\/small.jpg  320w\" \/&gt;\n\t&lt;img\n\t\tsrc=\"quilt_2\/detail\/medium.jpg\"\n\t\talt=\"Detail of the above quilt, highlighting the \n             embroidery and exotic stitchwork.\" \/&gt;\n&lt;\/picture&gt;<\/code><\/pre>\n<p>Un elemento <code>picture<\/code> contiene un qualsiasi numero di elementi sorgente e un&#8217;<code>img<\/code>. Il browser esamina le <code>source<\/code> di <code>picture<\/code> finch\u00e9 trova quella il cui attributo <code>media<\/code> si abbina all&#8217;ambiente attuale. Invia il corrispondente <code>srcset<\/code> della <code>source<\/code> all&#8217;<code>img<\/code>, che \u00e8 ancora l&#8217;elemento che \u201cvediamo\u201d sulla pagina.<\/p>\n<p>Ecco un caso pi\u00f9 semplice:<\/p>\n<pre><code class=\"language-markup\">&lt;picture&gt;\n\t&lt;source media=\"(orientation: landscape)\" srcset=\"landscape.jpg\" \/&gt;\n\t&lt;img src=\"portrait.jpg\" alt=\"A rad wolf.\" \/&gt;\n&lt;\/picture&gt;<\/code><\/pre>\n<p>Nelle viewport in modalit\u00e0 landscape, <code>img<\/code> riceve <code>landscape.jpg<\/code>. Quando siamo in protrait (o se il browser non supporta <code>picture<\/code>) <code>img<\/code> rimane cos\u00ec com&#8217;\u00e8 e si carica <code>portrait.jpg<\/code>.<\/p>\n<p>Questo comportamento pu\u00f2 sorprendere in parte se si \u00e8 abituati ad <code><a href=\"http:\/\/www.w3.org\/html\/wg\/drafts\/html\/master\/embedded-content.html#the-audio-element\">audio<\/a><\/code> e <code><a href=\"http:\/\/www.w3.org\/html\/wg\/drafts\/html\/master\/embedded-content.html#the-video-element\">video<\/a><\/code>. A differenza di questi elementi, <code>picture<\/code> \u00e8 un wrapper invisibile: uno <code>span<\/code> magico che semplicemente invia un <code>srcset<\/code> alla sua <code>img<\/code>.<\/p>\n<p>Possiamo metterla anche in questi termini: <code>img<\/code> non \u00e8 un fallback. Stiamo applicando il <em>progressive enhancement<\/em> a <code>img<\/code> inserendola in un elemento <code>picture<\/code>.<\/p>\n<p>In pratica, questo significa che qualunque stile vogliamo applicare all&#8217;immagine che verr\u00e0 visualizzata dovr\u00e0 essere impostato su <code>img<\/code>, <em>non<\/em> su <code>picture<\/code>.  <code>picture { width: 100% }<\/code> non fa alcunch\u00e9. <code>picture &gt; img { width: 100% }<\/code> fa quello che volete.<\/p>\n<p><a href=\"https:\/\/alistapart.github.io\/code-samples\/407\/demo\/second-pass.html\">Ecco la nostra pagina di coperte pazze con applicato quel pattern<\/a>. Tenendo a mente che il nostro scopo per l&#8217;utilizzo di <code>picture<\/code> era di fornire agli utenti su piccolo schermo pi\u00f9 pixel (pi\u00f9 <em>significativi<\/em>), vediamo come cambia la performance:<\/p>\n<div class=\"illustration full left\"><img decoding=\"async\" src=\"http:\/\/alistapart.com\/it\/wp-content\/uploads\/sites\/2\/2015\/02\/second-pass.png\" border=\"0\" alt=\"Un altro grafico che mostra il peso della pagina rispetto alla larghezza della finestra.\" width=\"100%\" \/><\/div>\n<p>Niente male! Stiamo mandando pochi byte in pi\u00f9 agli schermi 1x piccoli, ma per qualche complicata ragione avendo a che fare con <a href=\"http:\/\/blog.cloudfour.com\/how-do-you-pick-responsive-images-breakpoints\/\">le dimensioni delle nostre immagini sorgente<\/a>, abbiamo in realt\u00e0 esteso il range di dimensioni di schermo che vedo un risparmio a 2x. Il risparmio sulla pagina al primo passaggio si era fermato a 480px sugli schermi 2x, ma dopo il nostro secondo passaggio, continua fino a 700px.<\/p>\n<p>La nostra pagina adesso si carica pi\u00f9 rapidamente <em>e<\/em> appare migliore sui device pi\u00f9 piccoli. E non abbiamo ancora finito!<\/p>\n<\/div>\n<div class=\"paragrafo\">\n<h2>Terzo step: formati multipli con <code>source type<\/code><\/h2>\n<p>I 25 anni di storia del web sono stati dominati da due formati bitmap: JPEG e GIF. C&#8217;\u00e8 voluta una decade <a href=\"http:\/\/alistapart.com\/article\/pngopacity\">dolorosa<\/a> per PNG prima di potersi unire al club esclusivo. Nuovi formati come <a href=\"http:\/\/en.wikipedia.org\/wiki\/WebP\">WebP<\/a> and <a href=\"http:\/\/en.wikipedia.org\/wiki\/JPEG_XR\">JPEG XR<\/a> stanno bussando alla porta, promettendo agli sviluppatori una miglior compressione e offrendo caratteristiche utili come gli alpha channels e modalit\u00e0 lossless. Ma a causa della tristemente singola <code>src<\/code> di <code>img<\/code>, la loro adozione \u00e8 stata lenta: gli sviluppatori hanno bisogno di un supporto quasi universale per un formato prima di poterlo utilizzare. Non pi\u00f9 ora. <code>picture<\/code> rende semplice offrire pi\u00f9 formati seguendo lo stesso pattern <code>source type<\/code> stabilito da <code>audio<\/code> e <code>video<\/code>:<\/p>\n<pre><code class=\"language-markup\">&lt;picture&gt;\n\t&lt;source type=\"image\/svg+xml\" srcset=\"logo.svg\" \/&gt;\n\t&lt;img src=\"logo.png\" alt=\"RadWolf, Inc.\" \/&gt;\n&lt;\/picture&gt;<\/code><\/pre>\n<p>Se il browser supporta un <code>type<\/code> di <code>source<\/code>, mander\u00e0 il <code>srcset<\/code> di quella <code>source<\/code> all&#8217;<code>img<\/code>.<\/p>\n<p>Questo \u00e8 un esempio chiaro, ma quando sovrapponiamo i cambiamenti di <code>source type<\/code> sulla nostra pagina esistente delle coperte pazze, ad esempio per aggiungere il supporto per WebP, le cose si fanno spinose (e ripetitive):<\/p>\n<pre><code class=\"language-markup\">&lt;picture&gt;\n\t&lt;!-- 16:9 crop --&gt;\n\t&lt;source\n\t\ttype=\"image\/webp\"\n\t\tmedia=\"(min-width: 36em)\"\n\t\tsrcset=\"quilt_2\/detail\/large.webp  1920w,\n\t\t        quilt_2\/detail\/medium.webp  960w,\n\t\t        quilt_2\/detail\/small.webp   480w\" \/&gt;\n\t&lt;source\n\t\tmedia=\"(min-width: 36em)\"\n\t\tsrcset=\"quilt_2\/detail\/large.jpg  1920w,\n\t\t        quilt_2\/detail\/medium.jpg  960w,\n\t\t        quilt_2\/detail\/small.jpg   480w\" \/&gt;\n\t&lt;!-- square crop --&gt;\n\t&lt;source\n\t\ttype=\"image\/webp\"\n\t\tsrcset=\"quilt_2\/square\/large.webp   822w,\n\t\t        quilt_2\/square\/medium.webp  640w,\n\t\t        quilt_2\/square\/small.webp   320w\" \/&gt;\n\t&lt;source\n\t\tsrcset=\"quilt_2\/square\/large.jpg   822w,\n\t\t        quilt_2\/square\/medium.jpg  640w,\n\t\t        quilt_2\/square\/small.jpg   320w\" \/&gt;\n\t&lt;img\n\t\tsrc=\"quilt_2\/detail\/medium.jpg\"\n\t\talt=\"Detail of the above quilt, highlighting the\n                     embroidery and exotic stitchwork.\" \/&gt;\n&lt;\/picture&gt;<\/code><\/pre>\n<p>\u00c8 davvero molto codice per un&#8217;unica immagine e stiamo inoltre gestendo un gran numero di files: 12! Tre risoluzioni, due formati e due crop <em>per immagine<\/em> sono davvero molti. Tutto quello che abbiamo guadagnato in performance e funzionalit\u00e0 ha avuto un costo pagato dalla complessit\u00e0 anticipata e dalla sostenibilit\u00e0 futura.<\/p>\n<p><a href=\"http:\/\/blog.cloudfour.com\/8-guidelines-and-1-rule-for-responsive-\">L&#8217;automazione \u00e8 vostra amica<\/a>: se la vostra pagina conterr\u00e0 enormi blocchi di codice che fanno riferimento a numerose versioni alternative di un&#8217;immagine, sar\u00e0 meglio che evitiate di scriverla a mano.<\/p>\n<p>Si deve anche sapere quando troppo \u00e8 troppo. Nel nostro esempio, ho usato tutti gli strumenti presenti nella specifica. Questa cosa non \u00e8 quasi <em>mai<\/em> prudente. Si possono avere guadagni incredibili usando una qualsiasi delle nuove feature da sola e dovreste studiarvi bene le complessit\u00e0 derivanti dalla somma di ciascuna prima di estrarre <a href=\"http:\/\/saveforwebclaws.tumblr.com\/\">le tenaglie<\/a> e buttarvi nella riparazione dello scarico del lavandino.<\/p>\n<p>Detto questo, <a href=\"https:\/\/alistapart.github.io\/code-samples\/407\/demo\/third-pass.html\">diamo un&#8217;occhiata a quello che pu\u00f2 fare WebP per le nostre coperte<\/a>.<\/p>\n<div class=\"illustration full left\"><img decoding=\"async\" src=\"http:\/\/alistapart.com\/it\/wp-content\/uploads\/sites\/2\/2015\/02\/third-pass.png\" border=\"0\" alt=\"Il nostro terzo e ultimo grafico di peso della pagina contro larghezza della finestra.\" width=\"100%\" \/><\/div>\n<p>Abbiamo un ulteriore 25-35% di risparmio in pi\u00f9 oltre a quello che abbiamo gi\u00e0 ottenuto, non solo nella parte bassa, ma su tutto il piano. Sicuramente non \u00e8 da sottovalutare! La mia metodologia in questo caso non \u00e8 per nulla rigorosa: la performance del vostro WebP potrebbe cambiare, ma il punto \u00e8: nuovi formati che possono dare benefici significativi rispetto allo status quo attuale costituito da JPEG\/GIF\/PNG e altri che continueranno ad arrivare. <code>picture<\/code> e <code>source type<\/code> abbassano la barriera in ingresso, spianando per sempre la strada per l&#8217;innovazione nei formati di immagine.<\/p>\n<\/div>\n<div class=\"paragrafo\">\n<h2><a href=\"http:\/\/meninblazers.wikispaces.com\/Size+The+Day\"><code>size<\/code> the day<\/a><\/h2>\n<blockquote>\n<p>Questo \u00e8 il segreto della perfezione:<\/p>\n<p>When raw wood is carved, it becomes a tool;<\/p>\n<p>[&#8230;]<\/p>\n<p>The perfect carpenter leaves no wood to be carved.<\/p>\n<\/blockquote>\n<p><cite><a href=\"http:\/\/www.chinapage.com\/gnl.html#27\">27. Perfection, Tao Te Ching<\/a><\/cite><\/p>\n<p>Per anni, abbiamo saputo cosa rallentava le nostre pagine responsive: le immagini, quelle grandi, create soprattutto per gli schermi molto grandi, che abbiamo inviato a <em>tutti<\/em>. \u00c8 da un po&#8217; che sappiamo come sistemare questo problema, inviando sorgenti diversi a client diversi. Il nuovo markup ci permette di fare proprio questo. <code>srcset<\/code> ci permette di offrire pi\u00f9 versioni di un&#8217;immagine ai browser, che con un po&#8217; di aiuto da <code>sizes<\/code>, sceglie la sorgente pi\u00f9 appropriata da caricare tra quelle offerte. <code>picture<\/code> e <code>source<\/code> ci permettono di intervenire e di esercitare un po&#8217; pi\u00f9 di controllo, assicurandoci che verranno scelte determinate sorgenti in base o alle media query o al supporto del tipo di file.<\/p>\n<p>Insieme, queste feature ci permetto di creare un markup adattabile, flessibile e <em>responsive<\/em> per le immagini. Ci permettono di mandare a ciascuno dei nostri utenti una sorgente su misura per il suo device, permettendo immensi guadagni in termini di performance. Armati di un <a href=\"http:\/\/scottjehl.github.io\/picturefill\/\">eccellente polyfill<\/a> e di un occhio verso il futuro, gli sviluppatori dovrebbero cominciare ad usare questo markup <em>ora<\/em>!<\/p>\n<p>Illustrazioni: {carlok}<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>Quando creiamo un design responsive, il nostro contenuto fluisce elegantemente ed efficacemente in ogni device. Tutto il nostro contenuto, eccezion fatta per le immagini. Ora non pi\u00f9. Eric Portis ci guida alla scoperta del nuovo elemento picture e di altri attributi che ci permettono di inserire nel markup pi\u00f9 sorgenti alternative. Scoprite adesso come usare le immagini responsive: mandate le migliori immagini per ogni contesto, tagliate il peso della pagina e velocizzate la performance.<\/p>\n","protected":false},"author":818,"featured_media":7000755,"comment_status":"open","ping_status":"open","template":"","categories":[4,247,124,274],"tags":[],"coauthors":[439],"class_list":["post-519","article","type-article","status-publish","has-post-thumbnail","hentry","category-codice","category-html","category-numero-107-10-febbraio-2015","category-responsive-design"],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article\/519","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article"}],"about":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/types\/article"}],"author":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/users\/818"}],"replies":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/comments?post=519"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media\/7000755"}],"wp:attachment":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media?parent=519"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/categories?post=519"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/tags?post=519"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/coauthors?post=519"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}