{"id":598,"date":"2016-03-15T18:16:41","date_gmt":"2016-03-15T17:16:41","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/container-queries-uniamo-le-forze-un-altra-volta\/"},"modified":"2016-03-15T18:16:41","modified_gmt":"2016-03-15T17:16:41","slug":"container-queries-uniamo-le-forze-un-altra-volta","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/container-queries-uniamo-le-forze-un-altra-volta\/","title":{"rendered":"Container Queries: uniamo le forze un’altra volta!"},"content":{"rendered":"
\n

Noi del RICG<\/a> siamo gente perseverante. Le immagini responsive sembravano essere morte e sepolte in maniera molto drammatica per quante, due o tre volte? Per\u00f2 \u201cmorte e sepolte per sempre\u201d non \u00e8 durato a lungo, grazie a tutti voi. Ogni volta che le immagini responsive sono state messe al tappeto, si sono rialzate un po’ pi\u00f9 forti di prima.<\/p>\n

Non \u00e8 difficile capire perch\u00e9 il percorso \u00e8 stato duro: cambiare una feature cos\u00ec vecchia in termini di software, cos\u00ec stabile<\/em> come l’elemento img<\/code> non \u00e8 una richiesta da nulla. Ma i designer e gli sviluppatori hanno emesso il verdetto: volevamo una feature che potesse far risparmiare ai nostri utenti un’enorme quantit\u00e0 di banda<\/a> e per realizzare tale feature ci siamo ritagliati un posto allo stesso tavolo dei rappresentanti dei vari browser e degli enti che da lungo tempo si occupano degli standard. \u00c8 stato un processo lungo e costellato di fallimenti, ma ci ha portato alle soluzioni che abbiamo oggi: non solo un nuovo elemento<\/a>, ma anche un’intera nuova suite di miglioramenti all’elemento img<\/code><\/a>. Adesso abbiamo a nostra disposizione opzioni per inviare gli asset in maniera intelligente, basandoci su una combinazione di dimensione della viewport, pixel density e supporto dei formati di file.<\/p>\n

Dopo tutto questo progresso guadagnato cos\u00ec duramente, non aveva senso mollare la nostra organizzazione su GitHub<\/a> e tornarcene a casa. Perci\u00f2, abbiamo cambiato la \u201cI\u201d in \u201cRICG\u201d da \u201cImages\u201d a \u201cIssues\u201d e abbiamo cambiato obiettivo: adesso puntiamo a cambiare il modo in cui tutti noi scriviamo CSS.<\/p>\n<\/div>\n

\n

Il problema delle media queries<\/h2>\n

Assegnare stili a un modulo che andr\u00e0 ad occupare pi\u00f9 container con una media query basata sulla viewport significa assegnare gli stili di pertinenza di quel modulo a tutti i container che potrebbe occupare. Non \u00e8 la frase cosa pi\u00f9 semplice al mondo da capire, ma \u00e8 qualcosa con cui scommetto che avete tutti familiarit\u00e0 nella pratica.<\/p>\n

Il sito responsive ideale \u00e8 un sistema di componenti flessibili, modulari, che possono essere riassegnati a seconda del contesto. Utilizzando le librerie di pattern e strumenti come Pattern Lab<\/a> di Brad Frost e Dave Olsen, dovremmo essere in grado di assegnare stili alle parti fondamentali di un sito web in maniera indipendente dal resto, assemblarli in moduli logici indipendenti dalla pagina e poi includerli nel layout della pagina in qualsiasi contesto dovrebbero occupare. Ma la realt\u00e0 non \u00e8 cos\u00ec precisa come potrebbe sembrare.<\/p>\n

Ai fini di questa discussione, supponiamo che ci sia stato assegnato il compito di costruire una landing page per un negozio che vende degli attrezzi basati su Whitworth<\/a>, un sistema di misura noto solo alle persone sufficientemente coraggiose – o sufficientemente pazze – da possedere un veicolo molto<\/em> vecchio prodotto dai britannici. Io mi metto in quest’ultimo gruppo.<\/p>\n

\"Wireframe<\/div>\n

Si tratta di un design piuttosto semplice. L’intera pagina \u00e8 composta da moduli prodotto che occupano un container centrale grande e un identico modulo \u201cfeatured item\u201d che occupa un container secondario. Il layout complessivo della pagina cambia solo in un singolo breakpoint, in cui il container \u201cfeatured item\u201d si sposta nella sidebar. Ecco una demo molto scarsa<\/a> che illustra quel cambiamento nel layout. Il suo CSS \u00e8 facilmente comprensibile:<\/p>\n

.col-a,\n.col-b <\/span>{<\/span>\n\tclear<\/span>:<\/span> both;<\/span>\n\tfloat<\/span>:<\/span> left;<\/span>\n}<\/span>\n@media( min-width: 960px ) <\/span>{<\/span>\n  .col-a,\n\t  .col-b <\/span>{<\/span>\n\t\tclear<\/span>:<\/span> none;<\/span>\n\t}<\/span>\n\t.col-a <\/span>{<\/span>\n\t\twidth<\/span>:<\/span> 70%;<\/span>\n\t}<\/span>\n\t.col-b <\/span>{<\/span>\n\t\twidth<\/span>:<\/span> 27%;<\/span>\n\t\tfloat<\/span>:<\/span> right;<\/span>\n\t}<\/span>\n}<\/span><\/code><\/pre>\n
Abbiamo a che fare davvero solo con i moduli in due contesti differenti e solo nel nostro breakpoint pi\u00f9 grande: il container primario e i \u201cfeatured container\u201d sono della stessa larghezza finch\u00e9 il \u201cfeatured container\u201d non diventa una sidebar. Aggiungiamo una class .featured<\/code> a quel container cos\u00ec da poter mettere in seguito nel suo \u201cscope\u201d i nostri stili.<\/p>\n
Ora che abbiamo sistemato il layout di pagina, possiamo concentrarci sul layout dei singoli moduli, che passano da un layout verticale a uno orizzontale, a seconda di quale vada meglio per lo spazio disponibile:<\/p>\n
\"Il<\/div>\n
Per il layout verticale non servono molte finezze in CSS. Il flusso naturale del nostro markup fa la maggior parte del lavoro per noi: aggiungiamo giusto qualche leggera modifica per vincolare la dimensione delle immagini del nostro prodotto e per centrarle al di l\u00e0 della loro dimensione:<\/p>\n
.mod img <\/span>{<\/span>\n\tdisplay<\/span>:<\/span> block;<\/span>\n\tmargin<\/span>:<\/span> 0 auto;<\/span>\n\twidth<\/span>:<\/span> 100%;<\/span>\n\tmax-width<\/span>:<\/span> 250px;<\/span>\n}<\/span><\/code><\/pre>\n
Gli stili per il layout orizzontale non sono molto pi\u00f9 difficili. Per ora, ci concentreremo sul container primario, quindi non mettiamo questi stili nello scope della nostra class .featured<\/code>. Dal momento che vogliamo che i moduli ritornino al layout verticale sopra agli 800px per il layout a tre colonne, dobbiamo solo applicare gli stili di layout orizzontale tra i 400px e i 799px:<\/p>\n
@media( min-width: 400px ) and ( max-width: 799px ) <\/span>{<\/span>\n\t.mod img <\/span>{<\/span>\n\t\tfloat<\/span>:<\/span> left;<\/span>\n\t\twidth<\/span>:<\/span> 30%;<\/span>\n\t\tmax-width<\/span>:<\/span> 999px;<\/span>\n\t}<\/span>\n\t.mod .mod-header,\n\t  .mod .mod-desc <\/span>{<\/span>\n\t\tfloat<\/span>:<\/span> right;<\/span>\n\t\twidth<\/span>:<\/span> 68%;<\/span>\n\t\tpadding-left<\/span>:<\/span> 2%;<\/span>\n\t}<\/span>\n}<\/span><\/code><\/pre>\n
\"Screenshot<\/div>\n
Non \u00e8 l’ideale ma si pu\u00f2 sistemare: basta semplicemente scrivere una nuova media query che va a sovrascrivere a quella creata per i moduli nel container primario e poi mettere tutti i nostri stili nello scope della class .featured<\/code>, che assegniamo all’elemento del container secondario:<\/p>\n
@media( min-width: 40em ) and ( max-width: 60em ) <\/span>{<\/span>\n\t.featured .mod img <\/span>{<\/span>\n\t\tfloat<\/span>:<\/span> left;<\/span>\n\t\twidth<\/span>:<\/span> 30%;<\/span>\n\t}<\/span>\n\t.featured .mod .mod-header,\n\t  .featured .mod .mod-desc <\/span>{<\/span>\n\t\tfloat<\/span>:<\/span> right;<\/span>\n\t\twidth<\/span>:<\/span> 68%;<\/span>\n\t}<\/span>\n}<\/span><\/code><\/pre>\n
Possiamo ancora tollerare questa cosa quando lavoriamo con design cos\u00ec semplici, ma pu\u00f2 peggiorare molto quando si cominciano a raffinare i dettagli. Per esempio, il layout verticale vuole che il pulsante \u201cadd to cart\u201d appaia sul lato destro del modulo, ma non c’\u00e8 abbastanza spazio quando passiamo al layout a tre colonne nei breakpoint medi:<\/p>\n
\"Screenshot<\/div>\n
Se miglioriamo i nostri stili cos\u00ec che i moduli \u201cadd to cart\u201d e \u201cquantity remaining\u201d vadano deliberatamente<\/em> sotto ai prezzi dei prodotti a queste dimensioni – allineati a sinistra invece di andare a posizionarsi nello spazio sulla destra – il nostro foglio di stile si aggroviglia un po’ di pi\u00f9.<\/p>\n
Scambiare l’allineamento da sinistra a destra per questi elementi \u00e8 semplice in termini degli stili stessi: stiamo semplicemente  gestendo solo le propriet\u00e0 text-align<\/code> e float<\/code> su \u201cquantity remaining\u201d e sul pulsante \u201cadd to cart\u201d. Per le media queries che controllano questi semplici stili, tuttavia, abbiamo una nuova lista di considerazioni su cui lavorare. Dobbiamo aggiungere due breakpoint a entrambe i breakpoint esistenti che gestiscono l’allineamento verticale. Questi stili impatteranno anche sul nostro modulo \u201cfeatured\u201d, quindi dovremo sovrascrivere questi nuovi stili usando la nostra class di scoping, a cui abbinare le media queries. Dal momento che il module \u201cfeatured\u201d ha un po’<\/em> pi\u00f9 di spazio per lavorarci rispetto ai moduli allineati three-across, il pulsante \u201cadd to cart\u201d pu\u00f2 ritornare prima a destra in quel contesto, nel breakpoint pi\u00f9 alto – un altro breakpoint. Ma un attimo, c’\u00e8 di pi\u00f9: questi stili non sono a prova di futuro. Se mai volessimo aggiungere un modulo a un nuovo contesto, dovremmo di nuovo fare copia-incolla di tutti i nostri stili, con una nuova class di scoping e una manciata di nuove media queries. Se la dimensione del layout della pagina cambia in qualunque modo (pi\u00f9 o meno padding, margini, un qualsiasi cambiamento degli stili degli elementi di layout basato sulla dimensione), dovremmo aggiustare tutte<\/em> quante quelle media queries. Adesso dobbiamo trovare una nuova dimensione della viewport<\/em> in cui i nostri breakpoint abbiano senso. Le nostre decisioni sono disconnesse dal nostro layout.<\/p>\n
Questa pagina non si avvicina nemmeno al livello di complessit\u00e0 che potremmo incontrare in un progetto reale, ma abbiamo gi\u00e0 uno stylesheet complesso da mantenere.<\/p>\n<\/div>\n
\n
Facciano il loro ingresso le element queries<\/h2>\n
Tutte queste complicazioni derivano dalla nostra dipendenza dalla viewport per prendere decisioni riguardanti gli stili. Le media queries funzionano bene per i nostri layout di pagina ad alto livello ma non si avvicinano nemmeno ad essere utili per i componenti modulari<\/a>. Quello di cui abbiamo davvero bisogno \u00e8 la capacit\u00e0 di assegnare stili ai componenti della pagina basandoci sullo spazio che occupano piuttosto che sulla dimensione della viewport.<\/p>\n
Le \u201celement queries\u201d assumono una sintassi che fa esattamente questo: siamo abituati a scrivere una media query per gli stili che si applicano solo quando la viewport \u00e8 pi\u00f9 grande di 40em, cos\u00ec:<\/p>\n
@media( min-width: 40em ) <\/span>{<\/span>\n}<\/span><\/code><\/pre>\n
Al contrario, immaginiamo una sintassi in cui la query stessa sia nello scope di un elemento e popolata con stili che si applicano solo quando quell’elemento \u00e8 pi\u00f9 grande di 40em:<\/p>\n
.mod:media( min-width: 40em ) <\/span>{<\/span>\n}<\/span><\/code><\/pre>\n
Bene, questo cambierebbe quasi tutto quello che abbiamo scritto finora per la nostra pagina Whitworth. Potremmo ancora usare le media queries per il cambio di layout maggiore della nostra pagina, quello in cui passiamo da un layout lineare all’avere un elemento primario pi\u00f9 grande e una sidebar: ha senso basarlo sulla dimensione della viewport. Tuttavia, una volta che avremo iniziato a costruire i moduli stessi, questa nuova sintassi ci permetterebbe di scrivere una sola volta tutti gli stili di cui potrebbero mai aver bisogno:<\/p>\n
.mod img <\/span>{<\/span>\n\tdisplay<\/span>:<\/span> block;<\/span>\n\tmargin<\/span>:<\/span> 0 auto;<\/span>\n\twidth<\/span>:<\/span> 100%;<\/span>\n\tmax-width<\/span>:<\/span> 250px;<\/span>\n}<\/span>\n\n.mod:media( min-width: 425px ) img <\/span>{<\/span>\n\tfloat<\/span>:<\/span> left;<\/span>\n\twidth<\/span>:<\/span> 30%;<\/span>\n\tmax-width<\/span>:<\/span> 9999px;<\/span>\n}<\/span>\n.mod:media( min-width: 425px ) .mod-header,\n.mod:media( min-width: 425px ) .mod-desc <\/span>{<\/span>\n\tfloat<\/span>:<\/span> right;<\/span>\n\twidth<\/span>:<\/span> 68%;<\/span>\n\tpadding-left<\/span>:<\/span> 2%;<\/span>\n}<\/span><\/code><\/pre>\n
Per dettagli di precisione come la posizione del pulsante \u201cadd to cart\u201d e delle \u201cquantity remaining\u201d, le cose non si complicano troppo. Dal momento che non dobbiamo gestire lo scope o raffinare i breakpoint del modulo per farli andare bene con i breakpoint del layout basati sulla viewport, abbiamo solo un problema: \u201cIl modulo \u00e8 troppo piccolo per avere il prezzo e il pulsante ‘aggiungi al carrello’ uno accanto all’altro?\u201d Un po’ di esperimenti ci dicono che non c’\u00e8 abbastanza spazio per entrambe gli elementi finch\u00e9 il modulo non sar\u00e0 pi\u00f9 grande di 320px e qui \u00e8 dove metteremo il nostro breakpoint basato sul modulo:<\/p>\n
.mod:media( min-width: 320px ) .mod-cost <\/span>{<\/span>\n\tfloat<\/span>:<\/span> left;<\/span>\n}<\/span>\n.mod:media( min-width: 320px ) .mod-buy <\/span>{<\/span>\n\tfloat<\/span>:<\/span> right;<\/span>\n}<\/span>\n.mod:media( min-width: 320px ) .buy-remaining <\/span>{<\/span>\n\ttext-align<\/span>:<\/span> right;<\/span>\n}<\/span><\/code><\/pre>\n
Se questa sintassi esistesse, finiremmo il nostro progetto Whitworth in un paio di righe di CSS.<\/p>\n
Ma le element queries non possono esistere, o perlomeno, non nel modo in cui le abbiamo immaginate. Proprio come per la prima versione della specifica di picture<\/code>, le element queries sono morte e sepolte per sempre, ma come la ricerca per le immagini responsive, non lasceremo che finiscano cos\u00ec, non finch\u00e9 avremo da risolvere un problema cos\u00ec evidente.<\/p>\n<\/div>\n
\n
Escano le element queries<\/h2>\n
Questo concetto non \u00e8 difficile da comprendere, non per noi developer comunque, ma non lo erano nemmeno le immagini responsive. Una volta che ci siamo imbattuti nei dettagli realistici dell’implementazione, tuttavia, le cose sono cambiate.<\/p>\n
Il primo passo per il RICG \u00e8 stato di sviluppare un documento di Use Cases and Requirements<\/a> per le element queries, che descrivesse e illustrasse il problema, non che proponesse una soluzione<\/em> ma solo la descrizione di un problema chiaro, che va risolto. Finora, \u00e8 un documento molto pi\u00f9 centrato del documento di Use Cases and Requirements per le immagini responsive<\/a> perch\u00e9 il suo unico obiettivo \u00e8 di risolvere una questione generale.<\/p>\n
Man mano che si \u00e8 sparsa la voce di questo documento, si \u00e8 cominciato a pensare un po’ di pi\u00f9 al problema, proprio come speravamo. Questo ha portato molti di noi alla stessa conclusione, prima che cominciassimo perfino a trafficare con una specifica proposta: le element queries non possono funzionare.<\/p>\n
Questo \u00e8 stato documentato altrove con maggiori dettagli<\/a>, ma l’idea \u00e8 questa: stiamo usando CSS per controllare CSS e questo significa che possiamo causare infiniti loop di cambiamenti di stile. Se possiamo dire a un elemento di assumere nuovi stili usando una element query, cosa succede se usiamo quella element query per cambiare la larghezza dell’elemento a una in cui non si applica pi\u00f9 la element query?<\/p>\n
.our-element:media(min-width: 500px) <\/span>{<\/span>\n\twidth<\/span>:<\/span> 499px;<\/span>\n}<\/span><\/code><\/pre>\n
Ora, dal momento che le query non si abbinano pi\u00f9, la nuova larghezza non viene pi\u00f9 applicata. Dal momento che la nuova larghezza non viene mai applicata, la element query andrebbe bene di nuovo, quindi verrebbe applicata la nuova larghezza, quindi la query non andrebbe pi\u00f9 bene, quindi la nuova larghezza non verrebbe applicata… E cos\u00ec via all’infinito. Il browser, posto di fronte a queste situazioni dovrebbe buttare via completamente gli stili della element query? Buttare via solo la nuova larghezza? Cancellarsi dalla macchina dell’utente? Avviare un fuoco di dimensioni piccole o medie? Nulla di tutto questo suona particolarmente attraente, men che meno dal punto di vista dei produttori di browser. Non permetterebbero mai che qualcosa con questo tipo di potenziale di errore veda la luce del giorno. Game over.<\/p>\n
Notizia eccitante, vero? Abbiamo capito che le element queries erano impossibili in una frazione<\/em> del tempo che ci \u00e8 voluto per capire che le immagini responsive erano impossibili. La prima volta, intendo.<\/p>\n
Ok, ascoltatemi. Le \u201celement queries\u201d sono fuori dai giochi, ovvio, ma il problema non \u00e8 cambiato: il documento Use Cases and Requirements non se ne va da nessuna parte. Dobbiamo ancora risolvere questo problema e adesso sappiamo come non<\/em> risolverlo: gli elementi non possono assumere nuovi stili basandosi sulle loro<\/em> propriet\u00e0.<\/p>\n<\/div>\n
\n
Facciano il loro ingresso le container queries<\/h2>\n
Per risolvere il problema delineato nel documento Use Cases and Requirements, abbiamo bisogno di reinquadrare il modo in cui parliamo di una potenziale soluzione. Dal momento che una soluzione non pu\u00f2 permettere a un elemento di riassegnare degli stili a s\u00e9 stesso<\/em>, possiamo costruire quei vincoli nella specifica: le queries attaccate a un elemento possono influenzare solo lo styling degli elementi figlio<\/em> di quell’elemento.<\/p>\n
Armati della nostra nuova conoscenza dell’impossibile, la ricerca per le element queries \u00e8 stata reinquadrata come container<\/em> queries.<\/p>\n
Come cambierebbe il progetto Whitworth questa cosa? Beh, niente: stavamo solo assegnando stili agli elementi figlio di .mod<\/code> comunque, non a .mod<\/code> stesso. Potrebbe semplicemente comportare pochi cambiamenti di comportamento in termini del modo in cui il browser tratta questi elementi. Il browser potrebbe finire con un implicito stile overflow<\/code> a livello del browser su qualsiasi elemento con una query attaccata, per prevenire il comportamento da loop infinito-molto pi\u00f9 prevedibile del browser che sceglie pezzi di stylesheet per evitare di fondersi.<\/p>\n
Quindi, come facciamo a far s\u00ec che le cose continuino a muoversi partendo da questo punto? Trovando la prossima questione impossibile da risolvere. Finora, le \u201ccontainer queries\u201d hanno tenuto testa a pi\u00f9 esami accurati delle \u201celement queries\u201d, ma parlare \u00e8 facile. Questa questione della ricorsione \u00e8 grande, ma gratta appena la superficie delle questioni potenziali in cui potremmo imbatterci mentre una soluzione comincia a prendere forma.<\/p>\n
Faremo molti pi\u00f9 progressi sperimentando con questo pattern, che non \u00e8 la cosa pi\u00f9 facile da fare quando si ha a che fare con sintassi che non esistono ancora. \u00c8 il modo in cui \u00e8 finita con la primissima versione di Picturefill di Scott Jehl<\/a> cos\u00ec tanti anni fa. Senza armeggiare, senza in realt\u00e0 usare<\/em> qualcosa che assomigli al markup pattern di picture<\/code>, non riuscivamo a dare molto senso alla specifica che stavamo per scrivere. Quindi, nello stesso spirito, il RICG ha avviato un repository di demo per le container query<\/a>, usando lo stesso shim<\/a> delle nostre demo di Whitworth. Come potete provare questa sintassi per conto vostro e contribuire a trovare i problemi in cui ci imbatteremo quando useremo questo tipo di CSS pattern sul serio – quel genere di problemi che si possono trovare solo realizzando<\/em> qualcosa? Clonate  il repo<\/a>, copiate la directory demo-template<\/code> in \/demos<\/code>, date un nome alla vostra demo e create qualcosa usando le container queries. Assicuratevi di farci sapere come va<\/a>, sia che vada bene sia che vada male.<\/p>\n<\/div>\n
\n
Escano di scena le container queries..?<\/h2>\n
La prima versione della specifica delle container queries<\/a> sta prendendo forma, ma potrebbe benissimo avere anche i giorni contati. Il documento Use Cases and Requirements non sta andando da nessuna parte per\u00f2: il problema che dobbiamo risolvere \u00e8 l\u00e0 fuori, incombente, e chiede in qualche modo<\/em> di essere risolto.<\/p>\n
Per quel che ne sappiamo, la risposta potrebbe essere questa primissima proposta. Oppure potrebbe essere qualcosa di completamente differente, qualcosa che non abbiamo nemmeno cominciato a prendere in considerazione. Ma il RICG non \u00e8 un decision-maker nel mondo degli standard web e non \u00e8 nostra intenzione diventarlo. Vogliamo essere un punto di raccolta per fornire alcune strade ai designer e ai developers che magari non hanno alcuna voglia di avventurarsi sugli arcani listservs e sui canali IRC per essere coinvolti negli standard che influenzano il loro lavoro quotidiano.<\/p>\n
Ci sar\u00e0 moltissimo altro lavoro da fare dopo questo e avremo bisogno di tutti voi per portarlo a termine. Con il vostro aiuto, con migliaia di voci di designer e developer che contribuiscono alla ricerca, \u00e8 solo questione di tempo per trovare insieme una risposta. L’abbiamo gi\u00e0 fatto in passato e lo faremo ancora.<\/p>\n
Fatevi forza, bandite la frase \u201celement queries\u201d dal vostro vocabolario per sempre. Andiamo a lavorare sulle container queries, indipendentemente da quale nome o forma prenderanno in futuro.<\/p>\n
Illustrazioni: {carlok}<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
Le media queries sono state lo strumento da usare per creare siti responsive, permettendoci di ridimensionare e ricombinare i moduli per adattarli ai vari contesti, layout e viewport. Ma fare affidamento sulle dimensioni fisse della viewport pu\u00f2 rapidamente far diventare i fogli di stile dei nodi gordiani. Abbiamo ancora bisogno di un modo future-friendly per gestire i CSS responsive. Mat Marquis esplora il problema e si muove verso la soluzione e ci chiama a raccolta.<\/p>\n","protected":false},"author":818,"featured_media":7000786,"comment_status":"open","ping_status":"open","template":"","categories":[244,273,141,257],"tags":[],"coauthors":[352],"class_list":["post-598","article","type-article","status-publish","has-post-thumbnail","hentry","category-css","category-mobile-multidevice","category-numero-123-15-marzo-2016","category-stato-del-web"],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article\/598","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=598"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media\/7000786"}],"wp:attachment":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media?parent=598"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/categories?post=598"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/tags?post=598"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/coauthors?post=598"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
Siamo passati da dozzine di righe di CSS ridondante, di media queries e di overrides a nove righe contenenti gli stili di cui abbiamo bisogno. Ha ancora pi\u00f9 importanza il fatto che non si romperebbe nulla se altri stili sulla pagina cambiassero. Potete provarlo voi stessi giocando un po’ con gli stili nei dev tool del browser in questa demo<\/a>, che utilizza uno script che simula il comportamento della element query. Non \u00e8 qualcosa che dovreste usare sui siti in produzione, ma \u00e8 un ottimo modo per capire questo concetto.<\/p>\n
Ecco fatto: questi sono tutti gli stili di cui avranno bisogno i layout del nostro modulo – guardate voi stessi questa demo<\/a>, che usa uno shim JavaScript per far funzionare nella pratica questa sintassi ancora teorica. Quando il modulo \u00e8 pi\u00f9 largo di 425px, il browser utilizza il layout orizzontale. Se il modulo \u00e8 pi\u00f9 piccolo di 425px, il browser usa il layout verticale. Gli stili ora dipendono al 100% dal container che il modulo occupa: se ha spazio a sufficienza per il layout orizzontale, questi sono gli stili che verranno usati. Se cambiamo il layout da tre colonne a due colonne, con ciascun modulo occupante la met\u00e0 del container, o se introducessimo un contesto completamente nuovo e imprevedibile per uno di questi moduli, non avremmo bisogno di cambiare nulla dei suoi stili. Immaginatevi quanto sarebbe pi\u00f9 utile una pattern library se rimuovessimo la dipendenza contestuale da questi tipi di moduli indipendenti: sareste in grado di prendere ciascun componente dalla pagina e spostarlo in un qualunque container nella pagina, senza dover rimettere mano a centinaia di righe di CSS, anzi, senza dover mettere mano ad alcun<\/em> CSS.<\/p>\n
Bene, ok. Questo funziona bene, come vedete qui<\/a>, ma, in termini di codice, \u00e8 un po’ disgustoso. Di sicuro, non \u00e8 un approccio DRY<\/a> alla scrittura del CSS.<\/p>\n
Ecco come funzionano questi stili in una pagina reale<\/a>. Funzionano bene, fino a un determinato punto: nel nostro container \u201cfeatured item\u201d, in cui ci sar\u00e0 sempre solo un modulo alla volta, nei breakpoint medi gli stili non sono proprio perfetti:<\/p>\n