LESS CSS: ‘programmare’ gli stili

14 novembre 2011

Chi come noi scrive (anche) CSS per vivere desidera spesso un mondo migliore. Abbiamo sempre necessità di risparmiare tempo e linee di codice e spesso abbiamo la sensazione di poter evitare di ripetere le stesse direttive all’interno del medesimo progetto.

In alcuni casi abbiamo potuto giovarci di sistemi che rendono più consistenti, puliti e mantenibili i nostri fogli di stile, grazie ai Framework CSS (ormai determinanti nella creazione di progetti web), in altri casi abbiamo semplicemente dovuto chinare la testa e fondere i tasti corrispondenti alle shortcut del copincolla (chi scrive ha una mela un po’ più ammaccata).

In questo articolo vediamo come utilizzare LESS, una libreria che ci permette di utilizzare i concetti dei linguaggi di programmazione per scrivere CSS in modo semplice e più facilmente mantenibile.

Le aberrazioni del CSS

Il problema maggiore del CSS come da specifiche W3C è anche il suo maggiore vantaggio. Non essendo un linguaggio di programmazione permette una curva di apprendimento molto morbida e quindi una veloce metabolizzazione da parte di tutti.

L’assenza di una struttura formale forte però, permette anche una lunga serie di aberrazioni a cui noi tutti siamo abituati: tralasciando orrori di formattazione, scritture illegibili, mancati usi di shortcut nelle direttive, che faranno magari parte di una piccola galleria degli orrori a venire, quello su cui vorremmo soffermarci qui è la sostanziale ripetizione che affronta qualunque frontend developer per implementare il layout che il reparto grafico ha disegnato.

Come in tutti i prodotti grafici sensati, immaginiamo di avere una palette di colori di riferimento univoca e consistente. Detto in altri termini, abbiamo 4 massimo 5 colori (se sono di più siamo autorizzati ad inveire con il reparto grafico di cui sopra) che faranno capolino lungo tutte le migliaia di righe di CSS che scriveremo.

Assieme a questo avremo di fronte una serie di comportamenti visivi che si ripeteranno (al solito, sempre reparto creativo permettendo).

Il corretto stratagemma che tipicamente viene adottato è quello di stabilire una serie di classi CSS che assegnano alcuni comportamenti visuali e, fatto questo, assegnamo una o più di queste classi agli elementi, trasferendo loro i relativi comportamenti. Il CSS infatti ci permette di usare più classi come attributo di un tag, quindi usiamo questa feature per raggiungere il risultato voluto.

Vediamo un esempio:

.button {
  color:#fff;
  background: #dd0000;
  ...
}

.mainCTA {
  font-size:24px;
  font-family:"CustomFontFamily", Arial, Serif;
  line-height:40px;
}

.CTA  {
  height:50px;
  line-height:50px;
}

<input type="submit" class="button mainCTA CTA" />

Da un punto di vista formale questo è senz’altro corretto, ed il principio che c’è dietro in sostanza è quello di assegnare una classe diversa al tag per ogni variazione (“delta” in gergo), rispetto al comportamento più comune.

Soprattutto se dietro non c’è una strutturazione a monte, forte e progettata si farà molto presto ad arrivare ad un markup HTML di questo genere:

<input type="submit" class="button mainCTA CTA homepage user variant big" />

Ovviamente questo può essere bypassato usando le proprietà principali del CSS, ovvero cascading e ereditarietà delle direttive. Il problema che avremmo in questo caso però sarebbe ri-spostare la complessità all’interno del file CSS, per cui

.user-form .button {
  direttive
}

#homepage .user-form .button {
  altre direttive
}

#homepage .variant .user-form .button {
  ancora altre direttive
}

Chiaramente il markup torna ad essere abbastanza pulito, ma il CSS aumenta la sua complessità in maniera esponenziale. Per un lungo periodo queste ed altre considerazioni sono state all’ordine del giorno come mali necessari nell’uso di CSS come linguaggio per stilare le pagine web e rendere efficaci, accattivanti e gradevoli.

È evidente però che l’esplosione delle righe di CSS dovuta alla giusta necessità di far ricadere su un foglio di stile l’aspetto grafico di una pagina, assieme alla complessità del Cascading necessaria a gestire i delta di cui dicevamo, contribuiscono – fra le altre cose – a rendere poco leggibile e ancor meno mantenibile un progetto web e il suo relativo CSS.

Il CSS come linguaggio di programmazione

Negli ultimi anni, se non mesi, sono proliferate una serie di alternative che rendono un po’ più ibrido il linguaggio CSS, avvicinandolo un po’ ai linguaggi di programmazione propriamente detti.

Il loro punto in comune infatti è quelli di mettere a disposizione del frontend developer una sintassi molto simile, ma non identica al CSS che viene processata per ottenere come risultato finale un vero file CSS compilato.

Dal punto di vista concettuale non è diverso da quel che succedeva con un pezzo di codice compilato ad esempio nel linguaggio C.

È chiaro: stiamo introducendo un livello di astrazione che può sembrare improprio comparato con l’uso che è assegnato ai CSS. Utilizzare concetti di compilazione, preprocessing, può sembrare fuori luogo.

Analizziamo però quali vantaggi hanno genericamente i linguaggi di CSS preprocessed in comune tra loro:

  • Variabili (quindi definizioni di color, font-family, insiemi di direttive css)
  • Funzioni native
  • Funzioni custom
  • “Blocchi” di direttive
Già solo con queste quattro caratteristiche possiamo intuire alcune potenzialità. Di tutti i linguaggi preprocessed che esistono in questa sede analizziamo le caratteristiche di LESSCSS. In particolare, per rendere quest’articolo più completo possibile analizziamo la sintassi che compete il compilatore disponibile da lesscss.org: less.js.

Se vuoi aggiornamenti su LESS CSS: 'programmare' gli stili inserisci la tua e-mail nel box qui sotto:
 
X
Se vuoi aggiornamenti su LESS CSS: 'programmare' gli stili

inserisci la tua e-mail nel box qui sotto:

Ho letto e acconsento l'informativa sulla privacy

Acconsento al trattamento di cui al punto 3 dell'informativa sulla privacy