LESS: estendere i CSS
Giovedì 18 Giugno 2009 - 08:27
di Cesare Lamanna
Nei mesi scorsi abbiamo più volte segnalato diversi tentativi e proposte per rendere i CSS più simili ai linguaggi di programmazione per emularne le funzionalità essenziali e non previste nelle specifiche. Per citare solo due casi rimando ai post Variabili e modularità con i CSS e Variabili CSS: perché aspettare?.
Negli ultimi giorni mi sono imbattuto in questo articolo di Sitepoint dedicato a Object Oriented CSS (OOCSS) e nella presentazione su Usability Post di LESS. È su questo che mi soffermo.
Si tratta nelle parole degli autori, Alexis Sellier e Dmitry Fadeyev, di un sistema in grado di estendere i CSS aggiungendo 4 nuove funzionalità: variabili, mixins, regole annidate e operazioni. Un file .less usa di fatto la stessa sintassi dei CSS, ma deve essere compilato come documento .css attraverso una Ruby gem che può essere scaricata e installata dal sito ufficiale.
Molto interessanti e intuitivi gli snippet di codice postati per far comprendere il valore delle 4 nuove funzionalità. Partiamo dalle variabili e dall’esempio classicamente associato ad esse, quello della palette dei colori da inserire all’inizio del foglio di stile. In un CSS si farebbe così:
/* CSS */
#header {
color: #4D926F;
}
h2 {
color: #4D926F;
}
Con LESS così:
/* LESS */
@brand_color: #4D926F;
#header {
color: @brand_color;
}
h2 {
color: @brand_color;
}
Interessante anche la parte relativa ai mixins. È un concetto simile a quello delle variabili, ma applicato alle classi:
/* CSS */
#header {
-moz-border-radius: 8px;
-webkit-border-radius: 8px;
border-radius: 8px;
}
#footer {
-moz-border-radius: 8px;
-webkit-border-radius: 8px;
border-radius: 8px;
}
Ed ecco come risulta in LESS:
/* LESS */
.rounded_corners {
-moz-border-radius: 8px;
-webkit-border-radius: 8px;
border-radius: 8px;
}
#header {
.rounded_corners;
}
#footer {
.rounded_corners;
}
Insomma, potrebbe essere o no un ottimo ausilio per la scrittura di codice CSS?
Commenti
1
L’idea è sicuramente buona, ma credo che l’ostacolo di dove “compilare” ogni volta bloccherà la maggior parte dei “programmatori css”.
2
Sono d’accordo, se il processo di compilazione (per quanto possa essere veloce) non viene automatizzato in qualche modo, la vedo dura…
3
LESS è scritto in Ruby e c’è già nell’aria la creazione di un template handler per Rails che permetta di scrivere template CSS direttamente in LESS.
Così come avviene già per ERB, Builder, RJS o parlandi di plugin Prawn, questo permetterebbe di delegare direttamente a Rails la compilazione e soprattutto il caching del file CSS in modo del tutto automatico e trasparente.
Per chi non utilizza Rails, è solo una questione di approccio. Ci vuole un attimo a creare un task (Pake, Rake, Make…) o una procedura automatica che esegua il processo. Tutto sta, a mio avviso, nel comprendere le potenzialità di una tecnologia e capire se il compromesso tra uso e non uso porta valore aggiunto.
Per quanto riguarda LESS, nel mio caso la risposta è sì. Lo stesso vale, ad esempio, per il tool minify che nello specifico caso è scritto in JAVA.# - postato da Simone Carletti - 18 Giugno 2009 - 09:17
4
Semplicemente perchè non siete abituati a lavorare in progetti enterprise dove la ricompilazione è normale… vedi per esempio quasi tutti i progetti java…
# - postato da Andrea Paiola - 18 Giugno 2009 - 09:30
5
Ok Andrea, ma ricompili il java, non il css..
Ogni volta che devi testare qualcosa, magari spostare di N pixel alla volta un box per vedere di posizionarlo nel posto giusto devi ricreare il css, questo non succede sicuramente nemmeno con java.
Non so come funziona ruby (mi riprometto di studiarmelo ma poi il tempo…), ma credo che anche in questo caso se modifichi solo il css non sia necessario ricompilare.
Poi sicuramente è questione di metodo e abitudine, l’unica cosa che mi chiedo è se il vantaggio ottenuto sia maggiore di quello perso nella ricompilazione del css.
6
Eh no caro, alle volte ricompili anche il CSS… ossia li comprimi per avere meno richieste e occupare meno banda, tra le altre cose ( minified e co. ).
Comunque l’aggiornamento dei CSS è parte del deploy: quando vai a rilasciare l’applicazione ( crei il pacchetto ) aggiorni anche il CSS.
CSS che è stato aggiornato prima nell’ambiente di sviluppo e poi nell’ambiente di integrazione ;-)
Certo se il riciclo prevede solo l’aggiornamento del CSS e js… insomma roba statica, si fa il rilascio solo di quello direttamente da sviluppo a produzione.
Tutto questo in ambiente Java.
Per Ruby c’è Capistrano ( un software che serve appunto a fare il deploy ), dacci un occhio.
# - postato da Andrea Paiola - 18 Giugno 2009 - 10:11
7
Idea sicuramente molto buona e, di fatto, quasi dovuta visto che i CSS sono potentissimi ma sono ancora un “anello” statico in un mondo dinamico (per cui per renderli piu’ flessibili si ricorre alla fine ad altri strumenti: JS lato client e altro lato server).
Il problema e’ ovvio: se questi aspetti dinamici fossero gestiti dai browser sarebbe un conto, cosi’ invece si creano complicazioni in fase di sviluppo che sono e saranno una bella barriera per molti, o per pigrizia o per mancanza di cultura prettamente informatica. Io per esempio: non ho la minima esperienza di mondo Java e compilatori e non ne sento la mancanza.
Se pero’ dei CSS dinamici potrebbero risolvermi problemi consistenti, sarei pronto a mettere in piedi un sistema che li compila ecc. Semplicemente per ora, nel mio caso, i costi sono in un certo senso maggiori dei benefici.
Ma l’idea mi piace assai.
# - postato da pbattino - 18 Giugno 2009 - 11:39
8
Ma perché il CSS non può essere direttamente codificato così, lasciando ai browser l’arduo (?) compito di decodificarlo?
Le idee sono buone, il tempo per realizzarle non manca.
Evviva i CSS dinamici, con le variabili e tutto il resto!
9
Mi avete dato un’ idea, stasera vedo se riesco a svilupparla ;)
# - postato da kentaromiura - 18 Giugno 2009 - 13:12
10
Kenta adesso lo fa in PHP :D
# - postato da Andrea Paiola - 18 Giugno 2009 - 14:02
11
Esiste già csskon, che è molto simile, in PHP.
12
Non proprio Paiolino… vedrai ;)
# - postato da kentaromiura - 18 Giugno 2009 - 14:21
13
allora javascript :madai:
# - postato da Andrea Paiola - 18 Giugno 2009 - 14:32
14
ciao,
per rails esiste già anche sass che fa questo coi css.# - postato da sasuke - 18 Giugno 2009 - 16:43
15
@paiolone:
No, in c sciarp! XDhttp://borntobegeek.com/less.m...../test1.css
per ora ho implementato solo 2 delle 4 regole del less, che poi sono quelle di cui ha parlato Cesare, adesso rilascerò i sorgenti sia del programmino stand-alone per chi vuole precompilare in fase di build,
sia i file del controller per asp.net mvc che permette di creare il file css in automatico da un less, quindi niente più ricompilazioni XD tutto in maniera trasparente!!!
ps. non so se implementare le altre due funzionalità, richiedono sicuramente più tempo…
…ma dai, per adesso va anche bene cosi’ XD XD XD :p
# - postato da kentaromiura - 18 Giugno 2009 - 19:20
16
Se può essere d’ interesse a tutti, e non solo a paiocoso ecco un breve post descrittivo:
http://blogs.ugidotnet.org/MVP.....t-mvc.aspx
Ps. Questo post funziona anche da Trackback, visto che ho reso a Cesare quello che è di Lamanna XD
# - postato da kentaromiura - 18 Giugno 2009 - 20:46
17
nuoooo la sciarpetta nuooooo che già fa troppo caldo!
# - postato da Andrea Paiola - 18 Giugno 2009 - 21:43
18
Credo che tool di questo tipo siano davvero molto utili per poter scrivere codice più ad alto livello, coerente e autoesplicativo.
Per PHP esiste qualcosa di simile: CSS Cacheer di Shaun Inman. (ne avevo parlato lo scorso anno qui su Edit)
Supporta tutto ciò che fa LESS tranne la possibilità di definire espressioni per i valori delle proprietà.
Mancanza facilmente superabile vista la modularità di Cacheer e la facilità di svilupparne plugin: ne avevo realizzato uno che appunto implementava anche le espressioni.
(se a qualcuno interessasse faccia un fischio, altrimenti prima o vedrò di pubblicarlo da qualche parte :)Uno dei padri dei CSS si è inoltre espresso su soluzioni di questo tipo: le vede ottime rispetto alle richieste di modifica dello standard CSS (che si porterebbero dietro i soliti problemi di implementazione da parte dei browser).
Non vedo proprio perchè non sfruttare tutto ciò :)
# - postato da Andrea Zilio - 18 Giugno 2009 - 22:15
19
Semmai mi viene in mente un ovvio problema di accresciuta complessita’ (logica) del CSS: file molto piu’ compatti e logici si’, ma magari un po’ piu’ difficili da interpretare a posteriori. Ad esempio l’utilissima funzione di FireBug per vedere quali attributi sono realmente applicati ad un particolare elemento del DOM e DOVE sono dichiarati nel CSS come funzionerebbe? Dovrebbe essere adattato, e nel caso di CSS compilati lato server, perderebbe parzialmente di utilita’, nel senso che non potrebbe dirti a che riga andare a vedere la dichiarazione interessata.
Per questo se la compilazione fosse fatta lato client per me sarebbe meglio, ma capisco che e’ improponibile a breve termine (sai che casini di compatibilita’ per accontentare tutti…).
Non e’ un problema nuovo, ovviamente, e’ successo qualcosa di simile quando si e’ passati dai siti statici a quelli dinamici. E le soluzioni arriveranno anche in questo caso (vedi Developer Themer module per Drupal ecc.) ma ci vorra’ del tempo.
# - postato da pbattino - 19 Giugno 2009 - 11:22
20
quale è la compatibilità tra i browser?
21
I file LESS vengono “trasformati” in codice CSS normale, quindi i problemi di compatibilità sono quelli dei normali CSS.
22
Io uso php dentro i css ed ho tutta la dinamicità che voglio.
23
Devo dire che da quando ho provato Compass (che si basa su SASS) la produttività è aumentata notevolmente (e sopratutto la manutentibilità). Ho scritto un paio di cosine, magari tornano utili anche ad altri (spero non lo si voglia considerare spam)