Una vision per il nostro Sass

I sintomi#section1

Uno degli abusi dell’insieme di feature di Sass meglio documentati è la tendenza all'”heavy nesting” dei selettori CSS. Non fraintendetemi, l’annidamento ha i suoi benefici: raggruppa del codice per rendere più semplice la gestione degli stili. Tuttavia, l’annidamento profondo può essere problematico.

Da una parte, crea lunghe stringhe di selettori, che sono un problema per la performance:

body #main .content .left-col .box .heading { font-size: 2em; }

Può incasinare la specificità, forzandovi a creare selettori successivi con specificità maggiore per sovrascrivere gli stili più in alto nel cascade o, dio non voglia, costringervi ad usare !important:

body #main .content .left-col .box .heading  [0,1,4,1]
	.box .heading  [0,0,2,0]

Confronto di specificità tra due selettori.

Infine, il nesting può ridurre la portabilità e la manutenzione degli stili, dal momento che i selettori sono legati alla struttura HTML. Se volessimo ripetere lo stile di heading per un box che non fosse nella leftcol, avremmo bisogno di scrivere una regola separata per ottenere quell’effetto.

Il nesting complicato è probabilmente la prima causa di un CSS disastroso. Altre cause includono la duplicazione del codice e il tight coupling e, di nuovo, questi sono i risultati di un Sass poco formato. Quindi, come possiamo imparare ad usare Sass con più giudizio?

Lavorare per una cura#section2

Un’opzione consiste nel creare regole che fungano da limiti e governino parte di quel potere. Per esempio, Mario Ricalde usa una linea guida per il nesting ispirata a Inception: “Non scendere più di quattro livelli.”

Regole come queste possono essere specialmente utili per i nuovi arrivati perché forniscono dei chiari limiti entro cui lavorare. Ma esistono poche regole universali: la specifica Sass si estende a macchia d’olio ed è in continua crescita (mentre scrivo questo articolo, Sass è alla versione 3.4.5). Vengono introdotte nuove feature ad ogni nuova release e con loro anche più corda con cui impiccarci. Un insieme di regole da solo sarebbe inefficace.

Ci serve un atteggiamento più 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:

• Code standard, o linee guida per linguaggi di programmazione specifici che raccomandino uno stile di programmazione, delle pratiche e dei metodi.
• Framework, o un sistema di files e cartelle di codice standardizzato che può essere usato come fondamento di un sito web.
• Style guide, o un documento di codice vivo, con dettagli di tutti i vari elementi e moduli di codice del vostro sito o applicazione.

Ciascun approccio ha vantaggi diversi:

• I code standard costituiscono un buon modo per unire un team e migliorare la manutenzione di grandi codebase (si vedano le Sass guidelines di Chris Coyier).
• I framework sono sia pratici sia flessibili, offrendo le barriere di ingresso più basse e rimuovendo il peso delle decisioni. Come sa ogni front-end developer con un po’ di esperienza, anche decidere il nome di una class CSS può diventare un’attività debilitante.
• Le style guide rendono esplicite le relazioni tra il codice e l’output illustrando ciascun componente all’interno del sistema.

Ciascuno di questi ha anche le sue difficoltà:

• I code standards sono scomodi. Devono essere tenuti aggiornati e diventano una barriera in ingresso per i nuovi utenti e per quelli inesperti.
• I frameworks tendono ad essere smisurati. La loro flessibilità ha un costo.
• Le style guides purtroppo sono specifiche per il loro contesto: sono uniche per il brand che rappresentano.

Sfortunatamente, sebbene questi metodi gestiscano il lato tecnico di Sass, non arrivano al nostro vero problema. Le nostre difficoltà con Sass non nascono dalla specifica stessa ma dal modo in cui scegliamo di usarla. Sass è, dopotutto, un CSS preprocessor: il nostro problema Sass è, pertanto, un problema di processo.

Allora, cosa ci rimane?

Riesaminiamo il paziente#section3

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 è il gioco finale. In effetti, se l’introduzione delle variabili CSS verrà fatta, le specifiche CSS e Sass cominceranno a convergere, il che significa che un giorno potremmo fare del tutto a meno di Sass.

Abbiamo bisogno poi di una soluzione diretta non al codice di per sé 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.

Il manifesto Sass#section4

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 è diventato particolarmente importante al crescere di Sass ed è stato usato ancora di più nel mio team.

Il mio manifesto Sass è composto da sei principi, o articoli, delineati qui sotto:

1. Output piuttosto che input
2. Prossimità piuttosto che astrazione
3. Comprensione piuttosto che brevità
4. Consolidamento piuttosto che ripetizione
5. Funzione piuttosto che presentazione
6. Consistenza piuttosto che novità

È bene notare che mentre la particolare applicazione di ciascun articolo può evolvere all’avanzare della specifica, gli articoli stessi dovrebbero rimanere invariati. Copriamoli uno per uno in maggior dettaglio.

1. Output piuttosto che input#section5

La qualità e l’integrità del CSS generato ha molta più importanza del codice precompilato.

Questo è il principio da cui discendono tutti gli altri. Ricordatevi che Sass è 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à mai così se seguite le best practice e minimizzate i CSS), ma dovete tenere ben presente la performance.

Quando adottate delle nuove feature nella specifica Sass, dovreste chiedere a voi stessi “Qual è l’output del CSS” Se avete dei dubbi, investigate meglio: aprite il CSS processato. Sviluppare una comprensione più approfondita della relazione tra Sass e CSS vi aiuterà ad identificare le possibili problematiche di performance e a strutturare il vostro Sass di conseguenza.

Per esempio, l’uso di @extend prende di mira tutte le istanze del selettore. Il seguente Sass

.box {
	background: #eee;
	border: 1px solid #ccc;

	.heading {
	  font-size: 2em;
	}
}

.box2 {
	@extend .box;
	padding: 10px;
}

viene compilato come

.box, .box2 {
  background: #eee;
  border: 1px solid #ccc;
}
.box .heading, .box2 .heading {
  font-size: 2em;
}

.box2 {
  padding: 10px;
}

Come potete vedere, non solo .box2 ha ereditato da .box, ma .box2 ha anche ereditato da istanze in cui .box è utilizzato in un selettore antenato. È un piccolo esempio, ma mostra come potete arrivare a dei risultati inattesi se non capite l’output del vostro Sass.

2. Prossimità piuttosto che astrazione#section6

I progetti dovrebbero essere portabili senza fare estremamente affidamento su dipendenze esterne.

Ogni volta che usate Sass, state introducendo una dipendenza: la più semplice installazione di Sass dipende da Ruby e dalla Sass gem per compilare. Tenete però a mente che più dipendenze introducete più 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.

Per esempio, insieme alla Sass gem potete installare una serie di packages extra per fare più o meno tutti i task possibili e immaginabili. La libreria più comune è Compass (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ù giù fino a gem che aiutano nei task molto più piccoli come la creazione di una palette di colori e l’aggiunta di ombre.

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 è scritta nella directory di installazione del vostro computer. Le gem vengono usate così come sono, come le funzioni core di Sass e l’unico riferimento ad esse è con il metodo @include.

Qui è dove le gem diventano problematiche. Torniamo allo scenario in cui un team sta lavorando allo stesso progetto: un membro del team, che chiamerò 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.

Capite ora come questo problema può essere moltiplicato all’interno di un team più grande. Aggiungete la complessità 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, ma l’approccio più semplice consiste nell’evitare di usare del tutto altre gem.

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ò addio a Compass.

3. Comprensione piuttosto che brevità#section7

Scrivete codice Sass che sia chiaramente strutturato. Prendete sempre in considerazione lo sviluppatore che verrà dopo di voi.

Sass è in grado di produrre CSS super-compresso, così non dovete andarci giù 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.

Questo è particolarmente utile quando si documentano i mixins, in cui l’output non è sempre trasparente:

// Force overly long spans of text to truncate, e.g.:
// @include truncate(100%);
// Where $truncation-boundary is a united measurement.

@mixin truncate($truncation-boundary){
    max-width:$truncation-boundary;
    white-space:nowrap;
    overflow:hidden;
    text-overflow:ellipsis;
}

Comunque, prendete in considerazione quali parti del vostro Sass arriveranno nel CSS finale.

4. Consolidamento piuttosto che ripetizione#section8

Don’t Repeat Yourself. Riconoscete e codificate i pattern che si ripetono.

Prima di cominciare un qualunque progetto, è opportuno sedersi e cercare di identificare tutti i vari moduli in un design. Questo è il primo step per scrivere CSS object-oriented. Inevitabilmente alcuni pattern non verranno svelati finché non avrete scritto la stessa riga (o una simile) di CSS tre o quattro volte.

Non appena riconoscete questi pattern, codificateli nel vostro Sass.

Aggiungete le variabili per i valori ricorrenti:

$base-font-size: 16px;
$gutter: 1.5em;

Usate i placeholder per gli stili visuali che si ripetono:

%dotted-border { border: 1px dotted #eee; }

Scrivete mixin in cui il pattern prenda delle variabili:

//transparency for image features
@mixin transparent($color, $alpha) {
  $rgba: rgba($color, $alpha);
  $ie-hex-str: ie-hex-str($rgba);
  background-color: transparent;
  background-color: $rgba;
  filter:progid:DXImageTransform.Microsoft.gradient(startColorstr=#{$ie-hex-str},endColorstr=#{$ie-hex-str});
  zoom: 1;
}

Se adottate questo approccio, noterete che entrambe i vostri files Sass e il CSS risultante diventeranno più piccoli e più gestibili.

5. Funzione piuttosto che presentazione#section9

Scegliete delle convenzioni per i nomi che siano appropriati alla funzione del vostro HTML e non alla sua presentazione visuale.

Le variabili Sass rendono incredibilmente semplice creare un tema per un sito web. Tuttavia, vedo troppo spesso del codice con questo aspetto:

$red-color: #cc3939; //red
$green-color: #2f6b49; //green

Collegare le vostre variabili al loro aspetto può aver senso al momento, ma se il design cambia e il rosso viene sostituito da un altro colore, finite con un disaccoppiamento tra il nome della variabile e il suo valore.

$red-color: #b32293; //magenta
$green-color: #2f6b49; //green

Un approccio migliore consiste nel dare un nome a queste variabili colore basandosi sulla loro funzione nel sito:

$primary-color: #b32293; //magenta
$secondary-color: #2f6b49; //green

Class di presentazione con selettori placeholder#section10

Cosa succede quando non possiamo mappare uno stile visuale a un nome di class funzionale? Supponiamo di avere un sito web con due box call-out, “Contact” e “References”. Il designer ha assegnato a entrambe un bordo e un background blu. Vogliamo massimizzare la flessibilità di questi box ma minimizzare qualsiasi codice ridondante.

Potremmo scegliere di collegare le classi nel nostro HTML, ma questo può diventare piuttosto restrittivo:

<div class="contact-box blue-box">
<div class="references-box blue-box">

Ricordatevi, vogliamo concentrarci sulla funzione non sulla presentazione. Fortunatamente, usando il metodo Sass @extend con una class placeholder diventa un’inezia:

%blue-box {
	background: #bac3d6;
	border: 1px solid #3f2adf;
}

.contact-box {
	@extend %blue-box;
	...
}
.references-box {
@extend %blue-box;
	...
}

Questo genera il seguente CSS, senza alcun riferimento visibile a %blue-box da nessuna parte se non negli stili.

.contact-box,
.references-box {
	background: #bac3d6;
	border: 1px solid #3f2adf;
}

Questo approccio taglia i riferimenti nel nostro HTML ai nomi di presentazione delle classi, ma ce li lascia ancora usare nei nostri files Sass in maniera descrittiva. Cercare di concepire nomi funzionali per stili comuni può farci cercare termini come base-box, che è molto meno significativo qui.

6. Consistenza piuttosto che novità#section11

Evitate di introdurre cambiamenti non necessari al CSS processato.

Se non vedete l’ora di inserire Sass nel vostro workflow ma non avete alcun nuovo progetto, potreste chiedervi quale sia il modo migliore per usare Sass in una codebase legacy. Sass supporta completamente CSS, quindi inizialmente si può semplicemente cambiare l’estensione da .css a .scss.

Una volta che avrete fatto questa mossa, potrebbe tentarvi l’idea di buttarvi a capofitto nel refactoring di tutti i vostri files, separandoli in partials, annidando i selettori e introducendo variabili e mixin. Ma questo può causare dei problemi lungo la linea per chiunque prenda in mano il vostro CSS processato. Il refactoring potrebbe non aver influenzato il display di nulla nel vostro sito, ma ha generato un file CSS completamente diverso e ogni cambiamento può essere estremamente difficile da isolare.

Al contrario, il modo migliore per passare a un workflow Sass consiste nell’aggiornare man mano i files. Se avete bisogno di cambiare la navigazione, separate quella porzione nei suoi partial prima di lavorarci. Questo preserverà il cascade e renderà molto più semplice individuare un qualunque cambiamento più avanti.

La prognosi#section12

Mi piace pensare alle nostre attuali difficoltà con Sass come ai dolori della crescita: sono il sintomo degli aggiustamenti che dobbiamo fare per adattarci ad un nuovo modo di lavorare ed esiste una cura alla fine, con il nostro maturare nella nostra comprensione di Sass.

La mia vision è che questo manifesto ci aiuterà a orientarci mentre ci muoviamo lungo il percorso: usatelo, cambiatelo o scrivete il vostro, ma cominciate a concentrarvi su come scrivete il vostro codice, sono solo su cosa scrivete.

Illustrazioni: {carlok}