{"id":422,"date":"2013-12-19T16:36:12","date_gmt":"2013-12-19T15:36:12","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/perche-sass\/"},"modified":"2013-12-19T16:36:12","modified_gmt":"2013-12-19T15:36:12","slug":"perche-sass","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/perche-sass\/","title":{"rendered":"Perch\u00e9 Sass?"},"content":{"rendered":"
\n

Nota dagli editori:<\/strong> Siamo lieti di presentarvi un estratto da Sass For Web Designers<\/a> di Dan Cederholm, disponibile ora su A Book Apart<\/a>.<\/p>\n<\/div>\n

\n


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\u00e0 al mio workflow. Vade retro!<\/p>\n

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

Per questo motivo ho voluto scrivere questo breve libro: per condividere come ho potuto usare Sass per essere pi\u00f9 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\u00f2 essere fragile, \u00e8 comprensibile che i suoi autori siano in qualche modo protettivi verso le proprie creazioni. Amen?<\/p>\n

Ahem.<\/p>\n

Cos\u00ec, eccomi qui a mostrarvi come Sass non sconvolger\u00e0 necessariamente il vostro processo e il vostro workflow e in che modo potr\u00e0 rendervi migliore la vita. Dimostrer\u00f2 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.<\/p>\n<\/div>\n

\n

L’elevator pitch di Sass<\/h2>\n

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\u00f9 volte per quel valore? Non avreste preferito poter fare quanto segue con CSS?<\/p>\n

\n$brand-color: #fc3;\na {\n\tcolor: $brand-color;\n}\nnav {\n  background-color: $brand-color;\n}\n<\/code><\/pre>\n
E se poteste cambiare quel valore in un posto e l’intero foglio di stile riflettesse quel cambiamento? Potete farlo con Sass.<\/p>\n
E i blocchi di stili che si ripetono pi\u00f9 volte nello stylesheet?<\/p>\n
\np {\n\tmargin-bottom: 20px; \n\tfont-size: 14px; \n\tline-height: 1.5;\n}\nfooter {\n  margin-bottom: 20px;\n  font-size: 14px;\n  line-height: 1.5;\n}\n<\/code><\/pre>\n
Non sarebbe bello poter mettere quelle regole comuni in un blocco riutilizzabile? Ancora una volta, potete definirle  una volta e le includete ovunque occorra.<\/p>\n
\n@mixin default-type {\n\tmargin-bottom: 20px;\n  font-size: 14px;\n  line-height: 1.5;\n}\np {\n\t@include default-type;\n}\nfooter {\n  @include default-type;\n}\n<\/code><\/pre>\n
Anche questo \u00e8 Sass! E questi due esempi estremamente semplici non sono che la punta dell’iceberg delle potenzialit\u00e0 di Sass. Sono solo un assaggio di come Sass possa rendere pi\u00f9 veloce, pi\u00f9 semplice e pi\u00f9 flessibile la creazione di fogli di stile. \u00c8 un aiuto pi\u00f9 che benvenuto nel mondo del web design, perch\u00e9 tutti quelli che hanno creato un sito web sanno che\u2026<\/p>\n<\/div>\n
\n
CSS \u00e8 difficile<\/h2>\n
Ammettiamolo: imparare CSS non \u00e8 semplice. Comprendere cosa fa ogni propriet\u00e0, come funziona il cascade, quali browser supportano cosa, i selettori, i comportamenti anomali e cos\u00ec via, non \u00e8 facile. Aggiungete a questo la complessit\u00e0 delle interfacce che si realizzano al giorno d’oggi e la manutenzione che ne consegue e, aspettate, perch\u00e9 facciamo ancora cos\u00ec?<\/p>\n
Parte del problema \u00e8 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\u00e0 float<\/code>, ad esempio, fu creata semplicemente per allineare un’immagine all’interno di un blocco di testo. Tutto qui. Eppure noi abbiamo utilizzato questa propriet\u00e0 per i layout di intere interfacce.<\/p>\n
I nostri fogli di stile sono anche infinitamente ripetitivi. Colori, font, raggruppamenti di propriet\u00e0 spesso usate, etc. Un tipico file CSS \u00e8 un documento estremamente lineare, cosa che fa s\u00ec 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).<\/p>\n
All’aumento di complessit\u00e0 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\u00f9 rapidamente, mettendoci a disposizione propriet\u00e0 e selettori pi\u00f9 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<\/code>, box-shadow<\/code>, selettori avanzati, transizioni, transform, animazioni e cos\u00ec via. \u00c8 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.<\/p>\n
Il principio DRY<\/h3>\n
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.<\/p>\n
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<\/em> (http:\/\/bkaprt.com\/sass\/1\/<\/a>), DRY dichiara:<\/p>\n
Ogni pezzo di conoscenza deve avere una singola, inequivocabile, autorevole rappresentazione all’interno di un sistema.<\/p><\/blockquote>\n
L’idea \u00e8 che duplicare il codice possa causare errori e confusione per gli sviluppatori (http:\/\/bkaprt.com\/sass\/2\/<\/a>). \u00c8 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. \u00c8 pi\u00f9 efficiente e molto pi\u00f9 semplice mantenere il codice in questo modo.<\/p>\n
CSS \u00e8 tutto fuorch\u00e9 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.<\/p>\n
Chiederebbe: \u201cCome !@#$ mantieni questa cosa?!\u201d<\/p>\n
Con un po’ di disgusto voi rispondereste: \u201cTi ho parlato dei bug di IE?\u201d<\/p>\n
Ma allora perch\u00e9 \u00e8 cos\u00ec difficile lavorare con CSS?<\/h3>\n
Possiamo intuire il perch\u00e9 delle limitazioni sintattiche di CSS nel corso degli anni da un saggio del co-inventore di CSS Bert Bos (http:\/\/bkaprt.com\/sass\/3\/<\/a>):<\/p>\n
\n
CSS evita perfino le feature pi\u00f9 potenti che i programmatori utilizzano con i loro linguaggi di programmazione: macro, variabili, costanti simboliche, condizionali, espressioni con le variabili, etc. E questo perch\u00e9 queste cose darebbero molta corda ai power-user, ma gli utenti con meno esperienza vi si impiccherebbero involontariamente o, pi\u00f9 probabilmente, ne sarebbero cos\u00ec spaventati da non toccare nemmeno CSS. Si tratta di trovare un equilibrio, che nel caso di CSS \u00e8 un equilibrio diverso da altri.<\/p>\n<\/blockquote>\n
Gli architetti originali di CSS erano preoccupati della sua adozione: giustamente, volevano che quante pi\u00f9 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\u00f9 complicato, con pi\u00f9 sfumature e che pone pi\u00f9 sfide per la sua manutenzione e per renderlo a prova di futuro.<\/p>\n
Fortunatamente, ci sono delle opzioni che vengono in nostro aiuto e una di queste \u00e8 Sass.<\/p>\n<\/div>\n
\n
Cos’\u00e8 Sass?<\/h2>\n
Sass \u00e8 un preprocessore CSS. un layer tra gli stylesheet che create e i files .css<\/code> 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\u00e0 pi\u00f9 veloce, pi\u00f9 efficente e pi\u00f9 semplice da mantenere.<\/p>\n
Il sito di Sass (http:\/\/bkaprt.com\/sass\/4\/<\/a>) lo descrive in maniera succinta:<\/p>\n
\n
Sass \u00e8 un meta-linguaggio sopra a CSS che viene usato per descrivere lo stile di un documento in maniera pulita e strutturale, con pi\u00f9 potenza rispetto a quello che permette il semplice CSS. Sass fornisce sia una sintassi pi\u00f9 semplice ed elegante per CSS sia implementa varie feature che sono utili per creare dei fogli di stile pi\u00f9 gestibili.<\/p>\n<\/blockquote>\n
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\u00e0” 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.<\/p>\n
Pi\u00f9 nello specifico, Sass \u00e8 un’estensione di CSS3 e la sua sintassi SCSS (“Sassy CSS”), di cui parleremo tra un attimo, \u00e8 un superset di CSS3. Questo significa che un qualunque documento CSS3 valido \u00e8 anche un documento SCSS valido. Questo \u00e8 parte integrante di Sass come qualcosa in cui potete “buttarvi”. Cominciare con la sintassi Sass \u00e8 indolore e potete usarne quanta vi pare. Il che implica anche che convertire uno stylesheet CSS esistente a SCSS pu\u00f2 essere fatto a step, man mano che imparerete e vedrete pi\u00f9 funzionalit\u00e0 di Sass.<\/p>\n
Poi, quando parlerete Sass correntemente (e non ci vorr\u00e0 molto), vi sembrer\u00e0 davvero un’estensione naturale di CSS, dal momento che colma le lacune che tutti vorremmo fossero riempite dalla specifica stessa di CSS. Questo \u00e8 il motivo per cui, una volta iniziato ad usare Sass, non ho mai pensato che fosse strano o laborioso, ma mi \u00e8 subito sembrato proprio come dovrebbe essere CSS. Una volta che lo proverete, lo userete per sempre.<\/p>\n
Inoltre, Sass vi aiuta a comprendere meglio CSS. Dando la priorit\u00e0 ad alcune feature che non sono attualmente possibili senza l’aiuto di un preprocessore, si d\u00e0 agli autori di CSS un’implementazione reale e la possibilit\u00e0 di sperimentare alcune feature. Quando e se avranno senso, alcune funzionalit\u00e0 Sass potrebbero davvero influenzare le specifiche future di CSS.<\/p>\n<\/div>\n
\n
Malintesi su Sass<\/h2>\n
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\u00e0 sar\u00e0 grosso e illeggibile?<\/p>\n
Grazie al cielo, la risposta a tutte queste domande \u00e8 “no”, ovviamente, ma le sento ogni volta che qualcuno cita Sass sui vari canali internet. Facciamo un po’ di chiarezza.<\/p>\n
Ho paura della riga di comando!<\/h3>\n
Non sono affatto un esperto della riga di comando, ma ne ho imparato un po’ qua e l\u00e0 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.<\/p>\n
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 \u00e8 tutto quel che vi serve. In pi\u00f9, ci sono delle app e dei web framework che vi eviteranno la necessit\u00e0 di usare la riga di comando. (Ve le illustrer\u00f2 nel prossimo capitolo).<\/p>\n
Quindi, se cercate di evitare la riga di comando, non permettetele di impedirvi di provare Sass!<\/p>\n
Non voglio cambiare il modo in cui scrivo CSS!<\/h3>\n
Questa era l’idea sbagliata di cui ero schiavo. Imposto ed organizzo i miei fogli di stile in maniera particolare. C’\u00e8 una certa quantit\u00e0 di perizia nel documento, ma ricordatevi, dal momento che la sintassi SCSS \u00e8 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<\/code>. Una volta che avrete capito questo, potrete tuffarvici senza paura.<\/p>\n
Non voglio che Sass cambi il modo in cui progetto!<\/h3>\n
Di contro, Sass non risolver\u00e0 tutti i vostri problemi n\u00e9 corregger\u00e0 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\u00f2 ingigantire le cattive abitutini e parler\u00f2 anche di questo tra un po’. Ma quando viene usato in maniera appropriata ed intelligente, Sass pu\u00f2 essere di grande aiuto nella creazione di siti web.<\/p>\n
Ok, ora che ci siamo occupati dei convenevoli, cominciamo a divertirci. Penso che rimarrete sorpresi da quello che pu\u00f2 fare Sass. Nel prossimo capitolo imposteremo il nostro workflow (il modo in cui Sass pu\u00f2 inserirsi nel vostro processo e quanto \u00e8 semplice usare la linea di comando o le app). “Let’s get Sassing!”, gente.<\/p>\n
Illustrazioni: {carlok}<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
Ero un riluttante sostenitore di Sass. Scrivo fogli di stile a mano! Non ho bisogno d’aiuto! E sicuramente non voglio aggiungere della complessit\u00e0 extra al mio workflow. Vade retro! Cos\u00ec dice il designer, mago di CSS e co-fondatore di Dribbble Dan Cederholm all’inizio del suo nuovo libro citeSass For Web Designers\/cite, pubblicato oggi da A Book Apart. Tuttavia, lo scettico convertito scopre presto che il popolare pre-processore CSS pu\u00f2 essere un potente alleato anche per il pi\u00f9 appassionato artigiano del front-end design\/development. Dan non ha mai imparato nulla di CSS senza condividerlo (ed \u00e8 davvero bravo come insegnante) e in questo esclusivo estratto dal Capitolo 1 di Sass For Web Designers, avrete un assaggio di come Dan ha imparato a smettere di preoccuparsi ed usare Sass per avere pi\u00f9 controllo sui suoi fogli di stile e siti.<\/p>\n","protected":false},"author":818,"featured_media":7000717,"comment_status":"open","ping_status":"open","template":"","categories":[244,270,271,102],"tags":[],"coauthors":[314],"class_list":["post-422","article","type-article","status-publish","has-post-thumbnail","hentry","category-css","category-il-server-side","category-javascript","category-numero-85-19-dicembre-2013"],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article\/422","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=422"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media\/7000717"}],"wp:attachment":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media?parent=422"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/categories?post=422"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/tags?post=422"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/coauthors?post=422"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}