Perché Sass?

Nota dagli editori: Siamo lieti di presentarvi un estratto da Sass For Web Designers di Dan Cederholm, disponibile ora su A Book Apart.

Ero un riluttante sostenitore di Sass. Io scrivo i fogli di stile a mano! Non mi serve aiuto! E sicuramente non voglio aggiungere ulteriore complessità al mio workflow. Vade retro!

Questo era quello che pensavo, ma la realtà è che Sass (come altri CSS preprocessor) può essere un alleato potente, uno strumento che ogni autore di fogli di stile può facilmente inserire nel proprio lavoro quotidiano. Mi ci è voluto un po’ di tempo per cambiare opinione, ma sono sicuramente felice di averlo fatto.

Per questo motivo ho voluto scrivere questo breve libro: per condividere come ho potuto usare Sass per essere più efficiente pur mantenendo il workflow in cui mi sentivo a mio agio per scrivere CSS, quello che ho usato negli ultimi dieci anni. Avevo molti pregiudizi su Sass che mi impedivano di dargli una chance. Inizialmente, ero preoccupato che avrei completamente alterato il modo in cui scrivo e gestisco i fogli di stile. Dal momento che a volte CSS può essere fragile, è comprensibile che i suoi autori siano in qualche modo protettivi verso le proprie creazioni. Amen?

Ahem.

Così, eccomi qui a mostrarvi come Sass non sconvolgerà necessariamente il vostro processo e il vostro workflow e in che modo potrà rendervi migliore la vita. Dimostrerò vari aspetti di Sass, come installarlo, come usarlo e come mi ha aiutato nei miei progetti. Con un po’ di fortuna potrei fare di voi dei sostenitori di Sass come me.

L’elevator pitch di Sass#section1

Non avete mai avuto bisogno di cambiare, ad esempio, un colore nel vostro foglio di stile e scoprire di dover fare “find and replace” più volte per quel valore? Non avreste preferito poter fare quanto segue con CSS?

$brand-color: #fc3;
a {
	color: $brand-color;
}
nav {
  background-color: $brand-color;
}

E se poteste cambiare quel valore in un posto e l’intero foglio di stile riflettesse quel cambiamento? Potete farlo con Sass.

E i blocchi di stili che si ripetono più volte nello stylesheet?

p {
	margin-bottom: 20px; 
	font-size: 14px; 
	line-height: 1.5;
}
footer {
  margin-bottom: 20px;
  font-size: 14px;
  line-height: 1.5;
}

Non sarebbe bello poter mettere quelle regole comuni in un blocco riutilizzabile? Ancora una volta, potete definirle una volta e le includete ovunque occorra.

@mixin default-type {
	margin-bottom: 20px;
  font-size: 14px;
  line-height: 1.5;
}
p {
	@include default-type;
}
footer {
  @include default-type;
}

Anche questo è Sass! E questi due esempi estremamente semplici non sono che la punta dell’iceberg delle potenzialità di Sass. Sono solo un assaggio di come Sass possa rendere più veloce, più semplice e più flessibile la creazione di fogli di stile. È un aiuto più che benvenuto nel mondo del web design, perché tutti quelli che hanno creato un sito web sanno che…

CSS è difficile#section2

Ammettiamolo: imparare CSS non è semplice. Comprendere cosa fa ogni proprietà, come funziona il cascade, quali browser supportano cosa, i selettori, i comportamenti anomali e così via, non è facile. Aggiungete a questo la complessità delle interfacce che si realizzano al giorno d’oggi e la manutenzione che ne consegue e, aspettate, perché facciamo ancora così?

Parte del problema è che CSS non era stato originariamente pensato per essere usato come facciamo oggi.. Certo, sta progredendo notevolmente grazie alla rapida innovazione del browser e all’implementazione di CSS3 e oltre, ma abbiamo ancora bisogno di fare affidamento su tecniche che sono, sotto tutti gli aspetti, degli hack. La proprietà float, ad esempio, fu creata semplicemente per allineare un’immagine all’interno di un blocco di testo. Tutto qui. Eppure noi abbiamo utilizzato questa proprietà per i layout di intere interfacce.

I nostri fogli di stile sono anche infinitamente ripetitivi. Colori, font, raggruppamenti di proprietà spesso usate, etc. Un tipico file CSS è un documento estremamente lineare, cosa che fa sì che un programmatore object-oriented si strappi tutti i capelli. (Non sono un programmatore a oggetti, ma mi sono rimasti pochi capelli. Interpretate questa informazione come volete).

All’aumento di complessità e robustezza di interfacce e applicazioni web, stiamo piegando il design originale di CSS a fare cose che non si sarebbe mai sognato di fare. Siamo davvero furbi. Fortunatamente, al giorno d’oggi, ii produttori di browser adottano nuove feature CSS molto più rapidamente, mettendoci a disposizione proprietà e selettori più efficienti e potenti che risolvono i problemi che pone l’odierno web. Sto parlando di feature come le nuove opzioni di layout in CSS3, border-radius, box-shadow, selettori avanzati, transizioni, transform, animazioni e così via. È un momento entusiasmante, ma manca ancora molto in CSS. Ci sono lacune che devono essere colmate per rendere molto piu semplice la vita di un autore di fogli di stile.

Il principio DRY#section3

Se sbirciamo nel mondo del software engineering (e preferisco di gran lunga sbirciare piuttosto che starci e sentirmici a mio agio), possiamo vedere subito come l’organizzazione, le variabili, le costanti, etc., siano radicati ed un modo cruciale di lavorare per le persone che creano sistemi complessi.

Potreste aver sentito parlare del principio “Don’t Repeat Yourself” (DRY). Coniato e definito da Andy Hunt e Dave Thomas nel loro libro, The Pragmatic Programmer (http://bkaprt.com/sass/1/), DRY dichiara:

Ogni pezzo di conoscenza deve avere una singola, inequivocabile, autorevole rappresentazione all’interno di un sistema.

L’idea è che duplicare il codice possa causare errori e confusione per gli sviluppatori (http://bkaprt.com/sass/2/). È anche una questione di buon senso: si scrivono una sola volta dei pattern che si ripetono spesso e si riutilizzano quei pezzi per tutta l’applicazione. È più efficiente e molto più semplice mantenere il codice in questo modo.

CSS è tutto fuorché DRY. A volte, gronda regole, dichiarazioni e valori ripetuti. Scriviamo costantemente gli stessi pezzetti di codice per i colori, i font e i pattern di stile che usiamo spesso nei nostri fogli di stile. Se un software developer che abbracci la filosofia DRY desse uno sguardo a un file CSS di dimensioni discrete, piangerebbe dapprima confuso e poi frustrato.

Chiederebbe: “Come !@#$ mantieni questa cosa?!”

Con un po’ di disgusto voi rispondereste: “Ti ho parlato dei bug di IE?”

Ma allora perché è così difficile lavorare con CSS?#section4

Possiamo intuire il perché delle limitazioni sintattiche di CSS nel corso degli anni da un saggio del co-inventore di CSS Bert Bos (http://bkaprt.com/sass/3/):

CSS evita perfino le feature più potenti che i programmatori utilizzano con i loro linguaggi di programmazione: macro, variabili, costanti simboliche, condizionali, espressioni con le variabili, etc. E questo perché queste cose darebbero molta corda ai power-user, ma gli utenti con meno esperienza vi si impiccherebbero involontariamente o, più probabilmente, ne sarebbero così spaventati da non toccare nemmeno CSS. Si tratta di trovare un equilibrio, che nel caso di CSS è un equilibrio diverso da altri.

Gli architetti originali di CSS erano preoccupati della sua adozione: giustamente, volevano che quante più persone possibile creassero siti web. Volevano che CSS fosse sufficientemente potente da dare stili alle pagine web e da permettere la separazione del contenuto dalla presentazione, pur rimanendo semplice da comprendere ed usare. Posso sicuramente rispettare questa decisione, ma allo stesso tempo, abbiamo del lavoro da fare, lavoro che sta diventando sempre più complicato, con più sfumature e che pone più sfide per la sua manutenzione e per renderlo a prova di futuro.

Fortunatamente, ci sono delle opzioni che vengono in nostro aiuto e una di queste è Sass.

Cos’è Sass?#section5

Sass è un preprocessore CSS. un layer tra gli stylesheet che create e i files .css che mandate al browser. Sass (abbreviazione di Syntactically Awesome Stylesheets) colma le lacune di CSS come linguaggio, permettendovi di scrivere del codice DRY che sarà più veloce, più efficente e più semplice da mantenere.

Il sito di Sass (http://bkaprt.com/sass/4/) lo descrive in maniera succinta:

Sass è un meta-linguaggio sopra a CSS che viene usato per descrivere lo stile di un documento in maniera pulita e strutturale, con più potenza rispetto a quello che permette il semplice CSS. Sass fornisce sia una sintassi più semplice ed elegante per CSS sia implementa varie feature che sono utili per creare dei fogli di stile più gestibili.

Quindi, mentre il CSS normale non permette cose come le variabili, i mixin (blocchi di stile riutilizzabili) ed altre cose, Sass fornisce una sintassi che fa tutto questo e molto altro, permettendovi delle “super funzionalità” in aggiunta al vostro normale CSS. Poi si traduce (o compila) quella sintassi nei cari vecchi files CSS mediante un programma a riga di comando o con dei web-framework plugin.

Più nello specifico, Sass è un’estensione di CSS3 e la sua sintassi SCSS (“Sassy CSS”), di cui parleremo tra un attimo, è un superset di CSS3. Questo significa che un qualunque documento CSS3 valido è anche un documento SCSS valido. Questo è parte integrante di Sass come qualcosa in cui potete “buttarvi”. Cominciare con la sintassi Sass è indolore e potete usarne quanta vi pare. Il che implica anche che convertire uno stylesheet CSS esistente a SCSS può essere fatto a step, man mano che imparerete e vedrete più funzionalità di Sass.

Poi, quando parlerete Sass correntemente (e non ci vorrà molto), vi sembrerà davvero un’estensione naturale di CSS, dal momento che colma le lacune che tutti vorremmo fossero riempite dalla specifica stessa di CSS. Questo è il motivo per cui, una volta iniziato ad usare Sass, non ho mai pensato che fosse strano o laborioso, ma mi è subito sembrato proprio come dovrebbe essere CSS. Una volta che lo proverete, lo userete per sempre.

Inoltre, Sass vi aiuta a comprendere meglio CSS. Dando la priorità ad alcune feature che non sono attualmente possibili senza l’aiuto di un preprocessore, si dà agli autori di CSS un’implementazione reale e la possibilità di sperimentare alcune feature. Quando e se avranno senso, alcune funzionalità Sass potrebbero davvero influenzare le specifiche future di CSS.

Malintesi su Sass#section6

Prima ho citato il fatto di esser stato refrattario a usare Sass. Questo in parte era dovuto a molti preconcetti che avevo prima di usarlo. Devo conoscere Ruby o le buffonate del command-line avanzato? Devo cambiare completamente il modo in cui ho sempre scritto i fogli di stile? Il CSS che ne uscirà sarà grosso e illeggibile?

Grazie al cielo, la risposta a tutte queste domande è “no”, ovviamente, ma le sento ogni volta che qualcuno cita Sass sui vari canali internet. Facciamo un po’ di chiarezza.

Ho paura della riga di comando!#section7

Non sono affatto un esperto della riga di comando, ma ne ho imparato un po’ qua e là nel corso degli anni: quanto basta per mettermi nei pasticci. Non ho paura di attraversare il file system con la riga di comando o usare i comandi Git, etc.

Detto questo, sono solidale con i designer e gli sviluppatori front-end che non vogliono usarla. Alcuni colleghi hanno la fobia della riga di comando. Per Sass, sono richieste davvero poche azioni da riga di comando. In effetti, un singolo comando è tutto quel che vi serve. In più, ci sono delle app e dei web framework che vi eviteranno la necessità di usare la riga di comando. (Ve le illustrerò nel prossimo capitolo).

Quindi, se cercate di evitare la riga di comando, non permettetele di impedirvi di provare Sass!

Non voglio cambiare il modo in cui scrivo CSS!#section8

Questa era l’idea sbagliata di cui ero schiavo. Imposto ed organizzo i miei fogli di stile in maniera particolare. C’è una certa quantità di perizia nel documento, ma ricordatevi, dal momento che la sintassi SCSS è un superset di CSS3, non dovrete cambiare nulla del modo in cui scrivete CSS. I commenti, l’indentazione, la non indentazione, tutte le preferenze di formattazione possono rimanere identiche quando lavorate nei files .scss. Una volta che avrete capito questo, potrete tuffarvici senza paura.

Non voglio che Sass cambi il modo in cui progetto!#section9

Di contro, Sass non risolverà tutti i vostri problemi né correggerà le vostre cattive abitudini. I fogli di stile inefficienti e grossi possono solo essere inefficienti e grossi anche quando userete Sass. Una buona organizzazione e una certa astuzia dovrebbero essere le vostre armi in questo caso. In effetti, ci sono istanze in cui Sass può ingigantire le cattive abitutini e parlerò anche di questo tra un po’. Ma quando viene usato in maniera appropriata ed intelligente, Sass può essere di grande aiuto nella creazione di siti web.

Ok, ora che ci siamo occupati dei convenevoli, cominciamo a divertirci. Penso che rimarrete sorpresi da quello che può fare Sass. Nel prossimo capitolo imposteremo il nostro workflow (il modo in cui Sass può inserirsi nel vostro processo e quanto è semplice usare la linea di comando o le app). “Let’s get Sassing!”, gente.

Illustrazioni: {carlok}