{"id":462,"date":"2014-06-24T08:48:43","date_gmt":"2014-06-24T06:48:43","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/dry-e-i-mixin\/"},"modified":"2014-06-24T08:48:43","modified_gmt":"2014-06-24T06:48:43","slug":"dry-e-i-mixin","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/dry-e-i-mixin\/","title":{"rendered":"DRY e i mixin"},"content":{"rendered":"

Una delle feature pi\u00f9 potenti del CSS preprocessor Sass sono i mixin: un’astrazione di un pattern comune in un pezzo (“chunk”, ndr<\/em>) semantico e riutilizzabile. Pensate di prendere gli stili per un pulsante e, invece di dover ricordare tutte le sue propriet\u00e0, poter avere un selettore che includa gli stili del pulsante quando servono. Tali stili si troverebbero in una singola posizione, rendendone semplice l’aggiornamento e facendo in modo che rimangano coerenti.<\/p>\n

Tuttavia, troppo spesso, i mixin sono scritti in una maniera che porta alla duplicazione delle propriet\u00e0, creando cos\u00ec pi\u00f9 punti di malfunzionamento nel CSS in output e facendo aumentare la dimensione del file. Ora, se usate Sass, siete gi\u00e0 sulla strada giusta per la creazione di CSS pi\u00f9 piccoli rispetto al programmatore medio. Ma se siete ossessionati dalla performance come lo sono io, non potete accettare alcun elemento in eccesso. In questo articolo, vi mostrer\u00f2 come portare i vostri mixin Sass al nuovo livello ultra-leggero del CSS in output.<\/p>\n

\n

Un po’ di background su Sass<\/h2>\n

Sass funge da livello intermedio tra il foglio di stile scritto a mano e il file .css generato che viene inviato al browser, ed aggiunge molte feature grandiose<\/a> che contribuiscono a rendere la scrittura e la manutenzione del CSS pi\u00f9 semplice. Una delle cose che Sass permette di fare agli autori di CSS \u00e8 utilizzare il paradigma DRY, rendendolo pi\u00f9 semplice da mantenere. DRY, o \u201cdon\u2019t repeat yourself\u201d, \u00e8 un principio di programmazione, coniato in The Pragmatic Programmer<\/a>, che stabilisce che:<\/p>\n

\n

Ogni pezzo di conoscenza deve avere una rappresentazione singola, non ambigua e autorevole all’interno di un sistema.<\/p>\n<\/blockquote>\n

CSS non \u00e8 molto bravo in fatto di DRY: per necessit\u00e0, si duplicano sempre degli insiemi di propriet\u00e0 comuni (pensiamo ai pulsanti) Se doveste creare degli stili per un pulsante che ha tre tipi, gli stili dovrebbero o essere ripetuti per ogni tipo di pulsante oppure le propriet\u00e0 che creano quel pulsante dovrebbero essere suddivise tra pi\u00f9 selettori. Gli autori vengono cos\u00ec a trovarsi tra l’incudine e il martello: riscrivere le propriet\u00e0 per ogni tipo significa fare molto “copia e incolla” di regole CSS (facendo cos\u00ec aumentare la dimensione del file), introdurre molteplici punti di malfunzionamento, verr\u00e0 a mancare una sorgente univoca di verit\u00e0 e alla fine si avr\u00e0 un componente molto fragile. D’altro canto, suddividere le propriet\u00e0 in pi\u00f9 selettori significa che non c’\u00e8 un’unica ed autorevole rappresentazione di ciascun tipo di pulsante nel sistema ma, al contrario, ognuno sar\u00e0 suddiviso tra due o pi\u00f9 selettori. Questo aggiunge fragilit\u00e0 ai componenti, dal momento che adesso sono definiti in maniera ambigua.<\/p>\n

Idealmente, quello che vorremmo \u00e8 un modo per definire gli stili principali in un unico posto (senza duplicazioni) e<\/em> un singolo selettore con il quale si possano applicare gli stili.<\/p>\n<\/div>\n

\n

Perch\u00e9 DRY?<\/h2>\n

Perch\u00e9 crearci anche questo problema? In breve, perch\u00e9 un CSS scritto secondo il principio DRY pu\u00f2 migliorare la performance del sito. Quando si progetta un sito, la performance \u00e8 importante, dai formati delle immagini che scegliamo al modo in cui scriviamo i nostri selettori CSS. Questo \u00e8 vero, in particolare, quando si parla di mobile, dove cose basilari per il web, come ad esempio una richiesta HTTP , possono porre dei problemi di performance<\/a>. L’assunzione, per molto tempo ritenuta vera, che la dimensione del file CSS non incidesse sulla performance web su larga scala non vale pi\u00f9 quando gli utenti mobile si trovano di fronte a meno di 100MB di shared website cache<\/a>. \u00c8 importante ogni piccolo bit che pu\u00f2 essere tolto dalla cache.<\/p>\n

L’obiettivo, quindi, \u00e8 quello di creare dei selettori che si possano mantenere nel nostro Sass e nel nostro HTML, la cui rappresentazione CSS sia la pi\u00f9 piccola possibile per ridurne la dimensione nella cache.<\/p>\n<\/div>\n

\n

Mixin ed extend: due mezze soluzioni<\/h2>\n

I mixin di Sass forniscono la risposta a uno di questi problemi: permettono agli autori di fogli di stile di avere un unico posto in cui definire e referenziare gli stili principali. I mixin possono anche avere degli argomenti, che permettono dei piccoli cambiamenti tra una chiamata al mixin e l’altra rendendo possibile la creazione di diversi tipi dello stesso pattern. C’\u00e8 comunque un problema se si utilizzano solo i mixin: se gliene si d\u00e0 l’occasione, i mixin scriveranno le loro propriet\u00e0 ogni volta che verranno chiamati, intasando il CSS finale. I mixin risolvono solo la parte della singola e autorevole rappresentazione del principio DRY applicato alle dichiarazioni Sass, ma spesso lasceranno delle propriet\u00e0 duplicate nel CSS in output.<\/p>\n

Sass introduce un altro concetto che ci aiuta ad applicare DRY al nostro CSS: gli extend. Usati tramite la direttiva @extend<\/code>, gli extend permetto all’autore di un foglio di stile di dire “Voglio che il selettore A abbia gli stessi stili del selettore B”. Sass quindi separa il selettore A dal selettore B mediante una virgola, permettendo ad essi di condividere le propriet\u00e0 del selettore B e di scrivere le rimanenti propriet\u00e0 come al solito. A differenza dei mixin, agli extend non si possono assegnare argomenti. \u00c8 una situazione del tipo “o tutto o niente”.<\/p>\n

Sass<\/h3>\n
.couch {\n\tpadding: 2em;\n\theight: 37in;\n\twidth: 88in;\n\tz-index: 40;  \n}\n  \n.couch-leather {\n\t@extend .couch;\n\tbackground: saddlebrown;\n}\n\n.couch-fabric {\n\t@extend .couch;\n\tbackground: linen;\n}<\/code><\/pre>\n
CSS<\/h3>\n
.couch, \n.couch-leather, \n.couch-fabric {\n\tpadding: 2em;\n\theight: 37in;\n\twidth: 88in;\n\tz-index: 40;\n}\n\n.couch-leather {\n\tbackground: saddlebrown;\n}\n\n.couch-fabric {\n\tbackground: linen;\n}<\/code><\/pre>\n
Gli extend risolvono il problema delle propriet\u00e0 duplicate e quello del singolo selettore nel CSS in uscita, ma gli autori dello stylesheet devono ancora mantenere due insiemi separati di stili nel proprio Sass e devono ricordarsi quali propriet\u00e0 devono essere aggiunte a ciascun tipo di componente, come se avessero scritto due selettori per cominciare.<\/p>\n
Sia i mixin sia gli extend risolvono ciascuno met\u00e0 del problema. Combinando i mixin e gli extend con un po’ di architettura creativa e alcune feature interessanti di Sass, si pu\u00f2 creare un vero mixin DRY che combina entrambe le met\u00e0 in una rappresentazione singola, non ambigua e autorevole. sia nel modo in cui viene usato e mantenuto un pattern in Sass, sia<\/em> nel modo in cui vengono applicati e rappresentati gli stili di un componente nel CSS finale.<\/p>\n<\/div>\n
\n
Gli elementi costitutivi di DRY<\/h2>\n
Ci sono quattro caratteristiche che costituiscono le fondamenta della creazione di mixin DRY: i selettori segnaposto (placeholder), tipi di dati map, la direttiva @at-root<\/code> e la funzione unique-id()<\/code>.<\/p>\n
Selettori segnaposto<\/h3>\n
I selettori segnaposto sono un tipo unico di selettore da utilizzare con la direttiva @extend<\/code> di Sass. Si scrivono come i selettori di class, ma cominciano con un %<\/code> invece che con un .<\/code>. Si comportano esattamente come un extend normale ma non verranno stampati nel foglio di stile a meno che non vengano estesi. Proprio come gli extend normali, il selettore viene messo nel foglio di stile nel punto in cui \u00e8 dichiarato il segnaposto.<\/p>\n
Sass<\/h4>\n
%foo {\n\tcolor: red;\n}\n\n.bar {\n\t@extend %foo;\n\tbackground: blue;\n}\n\n.baz {\n\t@extend %foo;\n\tbackground: yellow;\n}<\/code><\/pre>\n
CSS<\/h4>\n
.bar, \n.baz {\n\tcolor: red;\n}\n\n.bar {\n\tbackground: blue;\n}\n\n.baz {\n\tbackground: yellow;\n}<\/code><\/pre>\n
Maps<\/h3>\n
Le maps sono dei tipi di dati (come i numeri, le stringhe e le liste) di in Sass 3.3<\/a> che si comportano in maniera simile agli oggetti in JavaScript. Sono composti da coppie di chiave\/valore, in cui le chiavi e i valori possono essere un qualunque tipo di dato di Sass (incluse le mappe stesse). Le chiavi sono sempre univoche e possono essere richiamate per nome, rendendole ideali per la memorizzazione e il recupero univoci.<\/p>\n
Sass<\/h4>\n
$properties: (\n\tbackground: red,\n\tcolor: blue,\n\tfont-size: 1em,\n\tfont-family: (Helvetica, arial, sans-serif)\n);\n\n.foo {\n\tcolor: map-get($properties, color);\n}<\/code><\/pre>\n
At-root<\/h3>\n
La direttiva @at-root<\/code>, novit\u00e0 di Sass 3.3<\/a>, mette delle definizioni riservate alla radice del foglio di stile, indipendentemente dall’annidamento attuale.<\/p>\n
Unique ID<\/h3>\n
La funzione unique-ide()<\/code> in Sass 3.3 restituisce un identificatore CSS garantito come univoco<\/a> nel run attuale di Sass.<\/p>\n<\/div>\n
\n
Creare un mixin di base<\/h2>\n
Convertire un pattern in un mixin richiede l’osservazione degli stili che lo compongono e la determinazione di cosa viene condiviso e cosa proviene dall’input dell’utente. Per i nostri scopi, utilizziamo come esempio un pulsante molto semplice:<\/p>\n
Sass<\/h3>\n
.button {\n\tbackground-color: #b4d455;\n\tborder: 1px solid mix(black, #b4d455, 25%);\n\tborder-radius: 5px;\n\tpadding: .25em .5em;\n\t\n\t&:hover {\n\t\tcursor: pointer;\n\t\tbackground-color: mix(black, #b4d455, 15%);\n\t\tborder-color: mix(black, #b4d455, 40%);\n\t}\n}<\/code><\/pre>\n
Per farlo diventare un mixin, scegliamo quali propriet\u00e0 sono controllate dall’utente (dinamiche) e quali non lo sono (statiche). Le propriet\u00e0 dinamiche saranno controllate dagli argomenti passati al mixin, mentre le propriet\u00e0 statiche verranno semplicemente scritte. Vogliamo che solo il colore sia dinamico per il nostro pulsante. Poi possiamo chiamare il mixin con il nostro argomento e il CSS verr\u00e0 stampato come ci aspettiamo:<\/p>\n
Sass<\/h3>\n
@mixin button($color) {\n\tbackground-color: $color;\n\tborder: 1px solid mix(black, $color, 25%);\n\tborder-radius: 5px;\n\tpadding: .25em .5em;\n\t\n\t&:hover {\n\t\tcursor: pointer;\n\t\tbackground-color: mix(black, $color, 15%);\n\t\tborder-color: mix(black, $color, 40%);\n\t}\n}\n\n.button {\n\t@include button(#b4d455);\n}<\/code><\/pre>\n
Funziona bene, ma produce molte propriet\u00e0 duplicate. Supponiamo di voler creare una nuova variante di colore per il nostro pulsante. Il nostro Sass (senza includere dal definizione del mixin) e il CSS in output saranno cos\u00ec:<\/p>\n
Sass<\/h3>\n
.button-badass {\n\t@include button(#b4d455);\n}\n\n.button-coffee {\n\t@include button(#c0ffee);\n}<\/code><\/pre>\n
CSS<\/h3>\n
.button-badass {\n\tbackground-color: #b4d455;\n\tborder: 1px solid #879f3f;\n\tborder-radius: 5px;\n\tpadding: .25em .5em;\n}\n.button-badass:hover {\n\tcursor: pointer;\n\tbackground-color: #99b448;\n\tborder-color: #6c7f33;\n}\n\n.button-coffee {\n\tbackground-color: #c0ffee;\n\tborder: 1px solid #90bfb2;\n\tborder-radius: 5px;\n\tpadding: .25em .5em;\n}\n.button-coffee:hover {\n\tcursor: pointer;\n\tbackground-color: #a3d8ca;\n\tborder-color: #73998e;\n}<\/code><\/pre>\n
Qui troviamo molte propriet\u00e0 duplicate, che creano intasamento nel nostro CSS in output. Non vogliamo che succeda questo, per cui utilizziamo in maniera creativa i selettori segnaposto.<\/p>\n<\/div>\n
\n
Applicare DRY a un mixin<\/h2>\n
Applicare DRY a un mixin significa semplicemente suddividerlo in parti statiche e dinamiche. Il mixin dinamico \u00e8 quello che verr\u00e0 chiamato dall’utente, quello statico conterr\u00e0 solo i pezzi che altrimenti sarebbero duplicati.<\/p>\n
Sass<\/h3>\n
@mixin button($color) {\n\t\t@include button-static;\n\n\tbackground-color: $color;\n\tborder-color: mix(black, $color, 25%);\n  \n\t&:hover {\n\t\tbackground-color: mix(black, $color, 15%);\n\t\tborder-color: mix(black, $color, 40%);\n\t}\n}\n\n@mixin button-static {\n\tborder: 1px solid;\n\tborder-radius: 5px;\n\tpadding: .25em .5em;\n\t\n\t&:hover {\n\t\tcursor: pointer;\n\t}\n}<\/code><\/pre>\n
Adesso che il nostro mixin \u00e8 suddiviso in due parti, vogliamo estendere gli item in button-static<\/code> per impedirne la duplicazione. Potremmo farlo usando un selettore segnaposto invece di un mixin, ma questo significa che il selettore verrebbe spostato nel nostro foglio di stile. Al contrario, vogliamo creare l\u00ec un placeholder in maniera dinamica, cos\u00ec che venga creato la prima volta in cui serve il selettore e mantenga l’ordine sorgente come ci aspettiamo. Per fare questo, il nostro primo passo consiste nel creare una variabile globale che trattenga i nomi dei nostri selettori dinamici.<\/p>\n
Sass<\/h3>\n
$Placeholder-Selectors: ();<\/code><\/pre>\n
Poi, in button-static<\/code>, controlliamo per vedere se esiste una chiave per il nostro selettore. Chiameremo questa chiave “button” per ora. Usando la funzione map-get<\/code>, o otterremo indietro il valore della nostra chiave o riceveremo null<\/code> se la chiave non esiste. In quest’ultimo caso, la imposteremo al valore di uno unique ID usando map-merge<\/code>. Usiamo la flag !global<\/code> dal momento che vogliamo scrivere su una variabile globale.<\/p>\n
Sass<\/h3>\n
$Placeholder-Selectors: ();\n\/\/ ...\n@mixin button-static {\n\t$button-selector: map-get($Placeholder-Selectors, 'button');\n\t\n\t@if $button-selector == null {\n\t\t$button-selector: unique-id();\n\t\t$Placeholder-Selectors: map-merge($Placeholder-Selectors, \n          ('button': $button-selector)) !global;\n\t}\n\t\n\tborder: 1px solid;\n\tborder-radius: 5px;\n\tpadding: .25em .5em;\n\t\n\t&:hover {\n\t\tcursor: pointer;\n\t}\n}<\/code><\/pre>\n
Una volta che abbiamo determinato se esiste gi\u00e0 un ID per il nostro segnaposto, dobbiamo creare il nostro placeholder. Lo facciamo con la direttiva @at-root<\/code> e con l’interpolation #{}<\/code> per creare un selettore segnaposto alla root della nostra directory con il nome del nostro unique ID. Il contenuto di quel selettore segnaposto sar\u00e0 una chiamata al nostro mixin statico (mixin ricorsivo, o cielo!). Poi estendiamo quello stesso selettore segnaposto, attivandolo e scrivendo le propriet\u00e0 nel nostro CSS.<\/p>\n
Usando un selettore segnaposto qui invece di estendere un intero selettore come una class, questo contenuto sar\u00e0 incluso solo se il selettore verr\u00e0 esteso, riducendo pertanto il CSS in output. Usando un’estensione invece di scrivere le propriet\u00e0, evitiamo anche propriet\u00e0 duplicate. Questo, a sua volta, riduce la fragilit\u00e0 del nostro CSS in uscita: ogni volta che viene chiamato questo mixin, queste propriet\u00e0 condivise sono in realt\u00e0 condivise nel CSS in uscita invece di essere legate in maniera grossolana attraverso gli step di preprocessing del CSS.<\/p>\n
Sass<\/h3>\n
$Placeholder-Selectors: ();\n\/\/ ...\n@mixin button-static {\n\t$button-selector: map-get($Placeholder-Selectors, 'button');\n\t@if $button-selector == null {\n\t\t$button-selector: unique-id();\n\t\t$Placeholder-Selectors: map-merge($Placeholder-Selectors, ('button': $button-selector)) !global;\n\t  \n\t\t@at-root %#{$button-selector} {\n\t\t\t@include button-static;\n\t\t}\n\t}\n\t@extend %#{$button-selector};   \n\t\n\t\n\tborder: 1px solid;\n\tborder-radius: 5px;\n\tpadding: .25em .5em;\n\t\n\t&:hover {\n\t\tcursor: pointer;\n\t}\n}<\/code><\/pre>\n
Ancora un attimo di pazienza, perch\u00e9 non abbiamo del tutto finito. Se ci fermassimo qui, otterremmo ancora dell’output duplicato, che \u00e8 qualcosa che non vogliamo (e otterremo un selettore che estende s\u00e9 stesso, anche questa \u00e8 una cosa che non vogliamo). Per prevenire ci\u00f2, aggiungiamo un argomento a button-static<\/code> per determinare se passare attraverso il processo di estensione o meno. Aggiungeremo anche questo al nostro mixin dinamico e lo passeremo al nostro mixin statico. Alla fine, avremo i seguenti mixin:<\/p>\n
Sass<\/h3>\n
$Placeholder-Selectors: ();\n\n@mixin button($color, $extend: true) {\n\t@include button-static($extend);\n\t\n\tbackground-color: $color;\n\tborder-color: mix(black, $color, 25%);\n\t\n\t&:hover {\n\t\tbackground-color: mix(black, $color, 15%);\n\t\tborder-color: mix(black, $color, 40%);\n\t}\n}\n\n@mixin button-static($extend: true) {\n\t$button-selector: map-get($Placeholder-Selectors, 'button');\n\t\n\t@if $extend == true {\n\t\t@if $button-selector == null {\n\t\t\t$button-selector: unique-id();\n\t\t\t$Placeholder-Selectors: map-merge($Placeholder-Selectors, ('button': $button-selector)) !global;\n\t\t\t\n\t\t\t@at-root %#{$button-selector} {\n\t\t\t\t@include button-static(false);\n\t\t\t}\n\t\t}\n\t\t@extend %#{$button-selector};\n\t\t}\n\t\t@else {\n\t\tborder: 1px solid;\n\t\tborder-radius: 5px;\n\t\tpadding: .25em .5em;\n\t\t\n\t\t&:hover {\n\t\t\tcursor: pointer;\n\t\t}\n\t}\n}<\/code><\/pre>\n
Dopo tutti questi sforzi, abbiamo creato un modo per mantenere facilmente i nostri stili in Sass, fornire un singolo selettore in HTML e tenere al minimo la dimensione totale del CSS. Non importa quante volte includiamo il mixin button<\/code>, non duplicheremo mai le nostre propriet\u00e0 statiche.<\/p>\n
La prima volta che usiamo il nostro mixin, gli stili verranno creati nel CSS nel punto in cui \u00e8 stato chiamato il mixin, preservando il “cascading” come lo volevamo e riducendo la fragilit\u00e0. Inoltre, dal momento che permettiamo pi\u00f9 chiamate allo stesso mixin, possiamo facilmente creare e mantenere delle variazioni sia in Sass sia in HTML.<\/p>\n
Con queste aggiunte, le chiamate al mixin del nostro esempio originale adesso producono il seguente CSS:<\/p>\n
Sass<\/h3>\n
.button-badass {\n\t@include button(#b4d455);\n}\n\n.button-coffee {\n\t@include button(#c0ffee);\n}\n\n.button-decaff {\n\t@include button(#decaff);\n}\n<\/code><\/pre>\n
CSS<\/h3>\n
.button-badass {\n\tbackground-color: #b4d455;\n\tborder-color: #879f3f;\n}\n.button-badass, \n.button-coffee, \n.button-decaff {\n\tborder: 1px solid;\n\tborder-radius: 5px;\n\tpadding: .25em .5em;\n}\n.button-badass:hover, \n.button-coffee:hover, \n.button-decaff:hover {\n\tcursor: pointer;\n}\n.button-badass:hover {\n\tbackground-color: #99b448;\n\tborder-color: #6c7f33;\n}\n\n.button-coffee {\n\tbackground-color: #c0ffee;\n\tborder-color: #90bfb2;\n}\n.button-coffee:hover {\n\tbackground-color: #a3d8ca;\n\tborder-color: #73998e;\n}\n\n.button-decaff {\n\tbackground-color: #decaff;\n\tborder-color: #a697bf;\n}\n.button-decaff:hover {\n\tbackground-color: #bcabd8;\n\tborder-color: #857999;\n}<\/code><\/pre>\n
Le nostre propriet\u00e0 statiche vengono separate da virgole nei punti in cui sono state definite, rendendo pi\u00f9 semplice il debugging, preservando l’ordine della sorgente e riducendo la dimensione del file CSS in output. Inoltre, solo le propriet\u00e0 che cambiano avranno un nuovo selettore. Forte, un mixin DRY!<\/p>\n<\/div>\n
\n
Spingersi oltre<\/h2>\n
Ora, riscrivere pi\u00f9 e pi\u00f9 volte lo stesso pattern per ogni mixin non \u00e8 per nulla DRY, anzi \u00e8 piuttosto WET (“write everything twice” – i programmatori sono dei mattacchioni). Non vogliamo ovviamente fare cos\u00ec. Invece, pensiamo alla creazione di un mixin per la generazione di segnaposto, cos\u00ec si possono richiamare quelli. Oppure, se usate l’estensione Toolkit<\/a> di Sass (sia via Bower sia come estensione di Compass), il mixin dynamic-extend<\/code> pu\u00f2 essere usato per trovare, creare ed estendere un placeholder dinamico. Passategli semplicemente un nome come stringa da cercare, come “button”.<\/p>\n
Sass<\/h3>\n
@import \"toolkit\";\n\n@mixin button($color, $extend: true) {\n\t@include button-static($extend);\n\t\n\tbackground-color: $color;\n\tborder-color: mix(black, $color, 25%);\n\t\n\t&:hover {\n\t\tbackground-color: mix(black, $color, 15%);\n\t\tborder-color: mix(black, $color, 40%);\n\t}\n}\n\n@mixin button-static($extend: true) {\n\t$button-selector: map-get($Placeholder-Selectors, 'button');\n\t\n\t@if $extend == true {\n\t\t@include dynamic-extend('button') {\n\t\t\t@include button-static(false);\n\t\t}\n\t}\n\t@else {\n\t\tborder: 1px solid;\n\t\tborder-radius: 5px;\n\t\tpadding: .25em .5em;\n\n\t\t&:hover {\n\t\t\tcursor: pointer;\n\t\t}\n\t}\n}<\/code><\/pre>\n
Con questo, potete ridurre il vostro pattern mixin DRY, riducendo cos\u00ec i files Sass di input cos\u00ec come i files CSS in output e assicurandovi il titolo di meta-programmatore in gran forma.<\/p>\n
Illustrazioni: {carlok}<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
Potreste gi\u00e0 avere una certa familiarit\u00e0 con il principio DRY per scrivere codice: Don’t Repeat Yourself (Non ripeterti). Usare Sass \u00e8 un ottimo modo per raggiungere questo obiettivo, ma Sam Richard ci invita a fare un passo in pi\u00f9. Per la fine di questo articolo, starete gi\u00e0 adattando i vostri mixin Sass per utilizzare la quantit\u00e0 minima in assoluto di codice, cos\u00ec che le vostre pagine saranno super leggere e rapide nel caricamento su qualunque piattaforma. La magia di Sass vi aspetta, allacciate le cinture!<\/p>\n","protected":false},"author":818,"featured_media":7000732,"comment_status":"open","ping_status":"open","template":"","categories":[4,244,111],"tags":[],"coauthors":[419],"class_list":["post-462","article","type-article","status-publish","has-post-thumbnail","hentry","category-codice","category-css","category-numero-94-24-giugno-2014"],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article\/462","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=462"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media\/7000732"}],"wp:attachment":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media?parent=462"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/categories?post=462"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/tags?post=462"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/coauthors?post=462"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}