![](\"http:\/\/alistapart.com\/it\/wp-content\/uploads\/sites\/2\/2015\/06\/n102a.jpg\")
Ad un recente CSS meetup, ho chiesto \u201cChi di voi usa Sass nel proprio workflow quotidiano?\u201d La risposta \u00e8 stata quasi all’unanimit\u00e0 positiva: Sass non \u00e8 pi\u00f9 solo relegato ai piccoli progetti ed esperimenti personali, ma sta velocemente diventando il modo standard per scrivere CSS.<\/p>\n
Questa \u00e8 un’ottima notizia! Sass ci d\u00e0 molto pi\u00f9 potere sui fogli di stile complessi e in continua crescita, incluse nuove feature come le variabili, le direttive di controllo e i mixin che mancano (intenzionalmente) nella specifica CSS originale. Sass \u00e8 un linguaggio per i fogli di stile robusto ma comunque sufficientemente flessibile da tenere il nostro passo.<\/p>\n
Tuttavia, accanto all’adozione su larga scala di Sass (a cui faccio plauso), ho osservato un costante declino nella qualit\u00e0 del CSS in uscita (che deploro), il che ha un senso: Sass introduce un livello di astrazione tra l’autore e i fogli di stile, ma serve un modo per portare gli standard web, per cui abbiamo combattuto strenuamente, dentro questo nuovo ambiente. Il problema \u00e8 che la specifica Sass si sta espandendo cos\u00ec tanto che qualunque insieme di standard richiederebbe una revisione costante. Al contrario, quello di cui abbiamo bisogno \u00e8 un atto costitutivo, che stia al di fuori di Sass ma che caratterizzi il modo in cui scriviamo codice.<\/p>\n
Per poter avanzare, dobbiamo prima esaminare i punti problematici.<\/p>\n
Uno degli abusi dell’insieme di feature di Sass meglio documentati \u00e8 la tendenza all'”heavy nesting” dei selettori CSS<\/a>. Non fraintendetemi, l’annidamento ha i suoi benefici: raggruppa del codice per rendere pi\u00f9 semplice la gestione degli stili. Tuttavia, l’annidamento profondo pu\u00f2 essere problematico.<\/p>\n Da una parte, crea lunghe stringhe di selettori, che sono un problema per la performance:<\/p>\n Pu\u00f2 incasinare la specificit\u00e0, forzandovi a creare selettori successivi con specificit\u00e0 maggiore per sovrascrivere gli stili pi\u00f9 in alto nel cascade o, dio non voglia, costringervi ad usare \u00a0<\/p>\n Confronto di specificit\u00e0 tra due selettori.<\/p>\n \u00a0<\/p>\n Infine, il nesting pu\u00f2 ridurre la portabilit\u00e0 e la manutenzione degli stili, dal momento che i selettori sono legati alla struttura HTML. Se volessimo ripetere lo stile di Il nesting complicato \u00e8 probabilmente la prima causa di un CSS disastroso. Altre cause includono la duplicazione del codice e il tight coupling<\/a> e, di nuovo, questi sono i risultati di un Sass poco formato. Quindi, come possiamo imparare ad usare Sass con pi\u00f9 giudizio?<\/p>\n<\/div>\n Un’opzione consiste nel creare regole<\/strong> che fungano da limiti e governino parte di quel potere. Per esempio, Mario Ricalde<\/a> usa una linea guida per il nesting ispirata a Inception<\/cite>: \u201cNon scendere pi\u00f9 di quattro livelli.\u201d<\/p>\n Regole come queste possono essere specialmente utili per i nuovi arrivati perch\u00e9 forniscono dei chiari limiti entro cui lavorare. Ma esistono poche regole universali: la specifica Sass si estende a macchia d’olio ed \u00e8 in continua crescita (mentre scrivo questo articolo, Sass \u00e8 alla versione 3.4.5). Vengono introdotte nuove feature ad ogni nuova release e con loro anche pi\u00f9 corda con cui impiccarci<\/a>. Un insieme di regole da solo sarebbe inefficace.<\/p>\n Ci serve un atteggiamento pi\u00f9 proattivo e ad alto livello per sviluppare delle best practice piuttosto che un’enfasi sull’accumulo di regole individuali. Questo potrebbe assumere la forma di un:<\/p>\n Ciascun approccio ha vantaggi diversi:<\/p>\n Ciascuno di questi ha anche le sue difficolt\u00e0:<\/p>\n Sfortunatamente, sebbene questi metodi gestiscano il lato tecnico di Sass, non arrivano al nostro vero problema. Le nostre difficolt\u00e0 con Sass non nascono dalla specifica stessa ma dal modo in cui scegliamo di usarla. Sass \u00e8, dopotutto, un CSS preprocessor<\/em>: il nostro problema Sass \u00e8, pertanto, un problema di processo<\/em>.<\/p>\n Allora, cosa ci rimane?<\/p>\n Ogni lavoro ha i suoi artefatti, ma i problemi sorgono se si elevano questi effetti collaterali a un livello superiore rispetto al lavoro finale. Dobbiamo ricordarci che Sass ci aiuta a costruire il nostro CSS, ma non \u00e8 il gioco finale. In effetti, se l’introduzione delle variabili CSS<\/a> verr\u00e0 fatta, le specifiche CSS e Sass cominceranno a convergere, il che significa che un giorno potremmo fare del tutto a meno di Sass.<\/p>\n Abbiamo bisogno poi di una soluzione diretta non al codice di per s\u00e9 ma a noi come professionisti, qualcosa che ci dia delle linee guida tecniche mentre scriviamo il nostro Sass, ma contemporaneamente ci faccia anche guardare al futuro. Abbiamo bisogno di una dichiarazione di intenti ed obiettivi pubblica, o, in altre parole, di un manifesto.<\/p>\n<\/div>\n Quando ho scoperto Sass per la prima volta, ho sviluppato le mie linee guida personali. Col tempo, sono state formalizzate in un manifesto che potevo poi usare per valutare nuove feature e tecniche per capire se avessero avuto senso nel mio workflow. Questo \u00e8 diventato particolarmente importante al crescere di Sass ed \u00e8 stato usato ancora di pi\u00f9 nel mio team.<\/p>\n Il mio manifesto Sass \u00e8 composto da sei principi, o articoli, delineati qui sotto:<\/p>\n \u00c8 bene notare che mentre la particolare applicazione di ciascun articolo pu\u00f2 evolvere all’avanzare della specifica, gli articoli stessi dovrebbero rimanere invariati. Copriamoli uno per uno in maggior dettaglio.<\/p>\n La qualit\u00e0 e l’integrit\u00e0 del CSS generato ha molta pi\u00f9 importanza del codice precompilato.<\/em><\/p>\n Questo \u00e8 il principio da cui discendono tutti gli altri. Ricordatevi che Sass \u00e8 un passo nel processo verso il nostro obiettivo: mandare files CSS al browser. Questo non significa che il CSS debba essere meravigliosamente formattato o leggibile (non sar\u00e0 mai cos\u00ec se seguite le best practice e minimizzate i CSS), ma dovete tenere ben presente la performance.<\/p>\n Quando adottate delle nuove feature nella specifica Sass, dovreste chiedere a voi stessi \u201cQual \u00e8 l’output del CSS\u201d Se avete dei dubbi, investigate meglio: aprite il CSS processato. Sviluppare una comprensione pi\u00f9 approfondita della relazione tra Sass e CSS vi aiuter\u00e0 ad identificare le possibili problematiche di performance e a strutturare il vostro Sass di conseguenza.<\/p>\n Per esempio, l’uso di viene compilato come<\/p>\n Come potete vedere, non solo I progetti dovrebbero essere portabili senza fare estremamente affidamento su dipendenze esterne.<\/em><\/p>\n Ogni volta che usate Sass, state introducendo una dipendenza: la pi\u00f9 semplice installazione di Sass dipende da Ruby e dalla Sass gem per compilare. Tenete per\u00f2 a mente che pi\u00f9 dipendenze introducete pi\u00f9 rischiate di compromettere uno dei benefici maggiori di Sass: il modo in cui permette a un grande team di lavorare sullo stesso progetto senza pestarsi i piedi a vicenda.<\/p>\n Per esempio, insieme alla Sass gem potete installare una serie di packages extra<\/a> per fare pi\u00f9 o meno tutti i task possibili e immaginabili. La libreria pi\u00f9 comune \u00e8 Compass<\/a> (mantenuta da Chris Epstein, uno dei contributor originali di Sass), ma potete anche installare delle gem per i grid system e per framework come Bootstrap, gi\u00f9 gi\u00f9 fino a gem che aiutano nei task molto pi\u00f9 piccoli come la creazione di una palette di colori e l’aggiunta di ombre.<\/p>\n Queste gem creano un insieme di mixin pre-built a cui potete attingere nei vostri files Sass. A differenza dei mixin che scrivete all’interno dei vostri files di progetto, una gem \u00e8 scritta nella directory di installazione del vostro computer. Le gem vengono usate cos\u00ec come sono, come le funzioni core di Sass e l’unico riferimento ad esse \u00e8 con il metodo Qui \u00e8 dove le gem diventano problematiche. Torniamo allo scenario in cui un team sta lavorando allo stesso progetto: un membro del team, che chiamer\u00f2 John, decide di installare una gem per facilitare la gestione delle griglie. Installa la gem, la include nel progetto e la usa nei suoi files. Nel frattempo, un altro membro del team, diciamo Mary, fa il pull dell’ultima versione del repository per cambiare i font del sito web. Scarica i files, fa partire il compilatore ma all’improvviso riceve un errore. Da quando Mary ha lavorato per l’ultima volta sul progetto, John ha introdotto delle dipendenze esterne. Prima che Mary possa fare il suo lavoro, deve debuggare l’errore e scaricare la gem corretta.<\/p>\n Capite ora come questo problema pu\u00f2 essere moltiplicato all’interno di un team pi\u00f9 grande. Aggiungete la complessit\u00e0 del versioning e delle dipendenze tra gem e le cose diventano subito nebulose. Ci sono delle best practice per avere degli ambienti consistenti per i progetti Ruby consistenti nel tracciare ed installare le gem e le versioni strettamente necessarie<\/a>, ma l’approccio pi\u00f9 semplice consiste nell’evitare di usare del tutto altre gem.<\/p>\n Disclaimer: al momento, io utilizzo la libreria Compass e trovo che i suoi benefici battano gli svantaggi. Tuttavia, all’avanzare della specifica core Sass, sto considerando il momento in cui dir\u00f2 addio a Compass<\/a>.<\/em><\/p>\n Scrivete codice Sass che sia chiaramente strutturato. Prendete sempre in considerazione lo sviluppatore che verr\u00e0 dopo di voi.<\/em><\/p>\n Sass \u00e8 in grado di produrre CSS super-compresso, cos\u00ec non dovete andarci gi\u00f9 pesante con l’ottimizzazione del codice precompilato. Inoltre, a differenza dei commenti CSS regolari, i commenti inline in Sass non vengono inseriti nel file CSS finale.<\/p>\n Questo \u00e8 particolarmente utile quando si documentano i mixins, in cui l’output non \u00e8 sempre trasparente:<\/p>\nbody #main .content .left-col .box .heading <\/span>{<\/span> font-size<\/span>:<\/span> 2em;<\/span> }<\/span><\/code><\/pre>\n!important<\/code>:<\/p>\nbody #main .content .left-col .box .heading [0,1,4,1]\n\t.box .heading [0,0,2,0]<\/code><\/pre>\nheading<\/code> per un box<\/code> che non fosse nella leftcol<\/code>, avremmo bisogno di scrivere una regola separata per ottenere quell’effetto.<\/p>\n\nLavorare per una cura<\/h2>\n
\n
\n
\n
Riesaminiamo il paziente<\/h3>\n
\nIl manifesto Sass<\/h2>\n
\n
1. Output piuttosto che input<\/h3>\n
@extend<\/code> prende di mira tutte<\/em> le istanze del selettore. Il seguente Sass<\/p>\n.box <\/span>{<\/span>\n\tbackground: #eee;\n\tborder: 1px solid #ccc;\n\n\t.heading <\/span>{<\/span>\n\t font-size<\/span>:<\/span> 2em;<\/span>\n\t}<\/span>\n}<\/span>\n\n.box2 <\/span>{<\/span>\n\t@extend .box<\/span>;<\/span>\n\tpadding<\/span>:<\/span> 10px;<\/span>\n}<\/span><\/code><\/pre>\n.box, .box2 <\/span>{<\/span>\n background<\/span>:<\/span> #eee;<\/span>\n border<\/span>:<\/span> 1px solid #ccc;<\/span>\n}<\/span>\n.box .heading, .box2 .heading <\/span>{<\/span>\n font-size<\/span>:<\/span> 2em;<\/span>\n}<\/span>\n\n.box2 <\/span>{<\/span>\n padding<\/span>:<\/span> 10px;<\/span>\n}<\/span><\/code><\/pre>\n.box2<\/code> ha ereditato da .box<\/code>, ma .box2<\/code> ha anche ereditato da istanze in cui .box<\/code> \u00e8 utilizzato in un selettore antenato. \u00c8 un piccolo esempio, ma mostra come potete arrivare a dei risultati inattesi se non capite l’output del vostro Sass.<\/p>\n2. Prossimit\u00e0 piuttosto che astrazione<\/h3>\n
@include<\/code>.<\/p>\n3. Comprensione piuttosto che brevit\u00e0<\/h3>\n
\/\/ Force overly long spans of text to truncate, e.g.:<\/span>\n\/\/ @include truncate(100%)<\/span>;<\/span>\n\/\/ Where $truncation-boundary is a united measurement.\n\n@mixin truncate($truncation-boundary)<\/span>{<\/span>\n max-width<\/span>:<\/span>$truncation-boundary;<\/span>\n white-space<\/span>:<\/span>nowrap;<\/span>\n overflow<\/span>:<\/span>hidden;<\/span>\n text-overflow<\/span>:<\/span>ellipsis;<\/span>\n}<\/span><\/code><\/pre>\n