Variabili e modularità con i CSS
Giovedì 27 Settembre 2007 - 08:47
di Alessandro Fulciniti
Alex Russel ha da poco scritto CSS 3: A Giant Serving Of FAIL, un intervento in cui illustra quanto i CSS 3 siano poco flessibili e modulari. Sarebbe bello, dice, se si potesse scrivere qualcosa del genere:
@define hlColor red;
@define hlBgColor yellow;
@define oUpdateColor #3f5070;
.highlight {
color: {hlColor};
text-decoration: underline;
}
.updated {
@importRule ‘.highlight’;
background-color: {hlBgColor};
}
.updatedByOthers {
@importRule ‘.updated’;
color: {oUpdateColor}; /* a nice dark blue */
}
Il post di Russel mi offre lo spunto per segnalare che ci sono già alcuni strumenti e linguaggi di programmazione che potrebbero fare al caso. Il primo è il PHP: un buon punto da cui partire potrebbe essere PHP-generated CSS magic.
Configurabile con un CGI e basato sul linguaggio di programmazione LUA, un’alternativa potrebbe essere Moonfall.
Oppure, con una sintassi simil-Pyton, ecco CleverCSS, che consente di definire variabili, selettori discendenti e molto altro.
Personalmente non ho ancora provato approcci del genere, e anche se ritengo che possa essere vantaggioso, lo sarebbe molto di più
se fossero una caratteristica dei CSS. E voi, avete mai usato o sviluppato soluzioni simili? Che ne pensate?
Commenti
1
Se i css fossero così sarebbe la manna che cade dal celo…penso che tutto ciò che posso agevolare la logica di sviluppo del software sia sempre positivo…
# - postato da Davide Bisconti - 27 Settembre 2007 - 09:41
2
riferendomi alla soluzione PHP-generated: non mi sembra niente di così eccezionale od innovativo. Un semplice CSS generato da php.
Piuttosto sarebbe più utile integrare nei css ( attualmente mancante ) un sistema di gestione di eventi che permetta di ‘evitare’ l’uso di javascript . Non intendo solo hover,active,ecc. ma anche un qualcosa che permetta di modificare proprietà eventuali altri oggetti (Ad esempio: sull’hover dell’oggetto A, l’oggetto B lo voglio rosso…).
La cosa è al momento possibile solo con l’uso di javascript, ma spesso mi trovo a rinunciare, visto che non mi piace un uso eccessivo di javascript.
3
@Paolo:
Sono perfettamente d’accordo con te, il javascript anche per me rimane un’incognita enorme, data la mole di antispyware, antivirus e utenti sospettosi che li disabilitano.
Tutti gli sforzi fatti per implementare un bel js spesso si vanno a far friggere, senza contare poi il tema accessibilità.
Un sistema di gestione eventi via css sarebbe una vera gioia…# - postato da crea-tivo livorno - 27 Settembre 2007 - 10:06
4
Qualche tempo fa mi rammaricai (nei commenti ad un post sui CSS) del fatto che i CSS siano stati pensati troppo per il desktop (!) e troppo poco per il Web.
Mi fu detto che criticavo i CSS perché li conosco poco.
Il fatto è che credo di essere in grado di scrivere un paio di regole CSS che abbiano senso e credo sia lecito poterli in parte criticare. Ciò che io avrei voluto per i CSS è un maggiore orientamento agli oggetti, qualcosa come:
#div1 { height : #div2.height #div3.height; }
tanto per fare un esempio.
# - postato da gianluca - 27 Settembre 2007 - 10:25
5
se fosse possibile passare dei parametri alle regole, ad es.
.elemento-centrato(@w, @h) {
position : absolute;
width : @w;
height : @h;
left : 50%;
top : 50%;
margin : -(@h/2)px 0 0 -(@w/2)px
}si potrebbe centrare qualsiasi contenitore a prescindere dalle dimensioni definendo un’unica classe
oppure scrivendo qualcosa del tipo
.minheight(@h) {
height : auto !important;
height : (@h)px;
min-height : (@h)px;
}.fl(@w) {
float : left;
display : inline;
width : (@w)px;
}si potrebbero creare blocchi flottati di ogni larghezza e altezza minima definendo solo due classi… un risparmio di tempo notevole
6
Io i parametri comuni a tutte le classi/id li passo cosi nei miei css:
#class1,#class2
{
paramentro1:valore
paramentro2:valore
….
}cosi da averli modulari senza dover riscrivere tutto ogni volta :|
7
Le variabili nei CSS avrebbero una serie di applicazioni utili non da poco.
Trasformare CSS in una linguaggio di scripting da sostituire a javscript per prima cosa snaturerebbe il significato dei fogli di stile, in secondo luogo non si farebbe altro che spostare il problema senza risolverlo. Almeno, secondo me.
8
ciao a tutti,
sinceramente mi sembra si stia un po’ travisando il significato dei css.
Il css non è un linguaggio di programmazione ma una definizione di stili.
Un codice come quello desiderato da Alex Russel non aggiunge nulla a quanto è già fattibile con i css semplicemente raggruppando gli stili (come dice pao) in questo modo.highlight, .updated, .updatedByOthers {
text-decoration: underline;
}.highlight, .updated {
color: red;
}.updated, .updatedByOthers {
background-color: yellow;
}.updatedByOthers {
color: #3f5070;
}e in più una ipotetica @importRule introduce un elemento che rende difficile la lettura e la manutenzione delle regole.
Per sapere gli stili della classe .updatedByOthers si deve andare a ritroso cercando altre 2 classi. La cosa in questo caso non è drammatica ma in un progetto che va al di là del semplice esempio può diventare un problema, così come lo può diventare una modifica ad un attributo di una regola da cui ereditano molte altre.@Fabrizio
Non sono nemmeno d’accordo con quanto dice Fabrizio sul passaggio dei parametri al css perchè evidenzia un approccio non semantico alla creazione della pagina. Mi spiego meglio:
se usi una classe css di nome .elemento-centrato stai già definendo a livello HTML che quell’oggetto sarà centrato e se un domani tu volessi allinearlo a sinistra dovresti cambiare HTML. Questo non è lo scopo per cui sono nati i css!
Con un approccio semantico non utilizzeresti una classe .elemento-centrato ma qualcosa tipo #elemento e nel css definisci una regola adatta che centra quell’oggetto, se vuoi allinearlo a sinistra cambi solo la regola css e non tocchi l’HTML. Lo stesso discorso vale per le regole .fl e .minheight.
In quest’ottica i parametri secondo me non hanno più senso.Se ci sono dei valori variabili, magari impostati dall’utente, come un colore o una width, io li metterei in uno stile inline in fase di costruzione della pagina da php.
IMHO
# - postato da Marco Bacchetta - 27 Settembre 2007 - 14:55
9
Certamente sarebbe bello avere perlomeno la possibilità di utilizzare costanti ed espressioni matematiche direttamente nei CSS.
Non serve invece, secondo me, farli diventare un linguaggio di scripting: offriranno (CSS 3) già abbastanza.
Quello che però io mi aspetto di avere in un futuro non troppo remoto è questo:
div.msgBody > h1 .. {
}
Attendo il selettore ‘..’ che permetterebbe di applicare la regola qui sopra al div con classe ‘msgBody’ che ha come figlio un h1
Sperando di non fare una figura di * (selettore universale) penso di poter affermare che una cosa del genere non è possibile ora con i CSS2.1 e non sarà possibile nemmeno con i CSS3 (se restano così).
Non sarebbe utile?
–
Tornando al tema del post avevo dato uno sguardo a CleverCSS e mi sembra davvero stupendo!
Non mi aspetto (e non ritengo necessario) che i CSS diventino qualcosa di simile, ma un tool che trasforma ciò in un foglio di stile lo vedo perfetto!
Stavo infatti pensando seriamente di realizzare qualcosa di analogo in PHP in modo da generare al volo il CSS risultante.
10
non solo sarebbe magnifico (e ridurrebbe errori e anche, seppur in maniera trascurabile, il peso delle pagine) ma credo che le “variabili” definiti in questo contesto sarebbero poco più che degli alias riutilizzabili, quindi non dovrebbe essere particolarmente complicato da realizzare. Penso anche ad HTML5 e alla proposta di standardizzare il rendering dell’html, se c’è chi pensa a quello… :-)
# - postato da seralf - 27 Settembre 2007 - 15:51
11
@Marco Bacchetta:
Sono ben conscio dell’uso semantico dei nomi da attribuire a classi e id: in questo contesto ho utilizzato quei nomi specifici per rendere chiaro subito a tutti il senso e l’utilizzo di quelle regole e dell’esempio da me proposto. In realtà volevo porre l’accento su un aspetto particolare, ovvero evitare di scrivere più classi che sono simili a meno del valore di una singola (o di poche) proprietà.Se nella programmazione tradizionale le funzioni non accettassero argomenti sarei costretto a replicare diverse volte la stessa funzione che fa sempre la stessa cosa a meno, appunto, di una istruzione. Questa cosa sarebbe ovviamente inefficiente in modo spaventoso e non vedo perchè non poter applicare lo stesso concetto anche ai css
Allo stato attuale se io dovessi creare - diciamo 10 - blocchi che abbiano altezza automatica ma altezze minime differenti potrei definire alternativamente 10 classi con le regole specifiche oppure una classe con le regoli comuni (in questo caso solo height: auto !important) e inserire le altre due proprietà in altre 10 regole: da questa cosa non si scappa.
Non vedo allora perchè non potenziare il linguaggio con delle funzionalità aggiuntive il cui scopo è sempre quello di definire l’aspetto presentazionale però usando meno regole e meno proprietà ridondanti e che mi evitino di applicare tante (troppe) classi ad uno stesso elemento (con buona pace della manutenibilità e leggibilità del codice)
Io che per lavoro scrivo css almeno 5 ore al giorno (e oltre quando sono in fase di consegna… sic!) sento da tempo questa inefficienza che deriva dalla mancanza di variabili (e personalmente di regole parametriche) all’interno di questo linguaggio.
Ovviamente IMHO :)
12
@Fabrizio
è interessante quello che dici e mi offre ulteriori spunti di riflessione che ti sottopongo.Se nella programmazione tradizionale le funzioni non accettassero argomenti sarei costretto a replicare diverse volte la stessa funzione che fa sempre la stessa cosa a meno, appunto, di una istruzione. Questa cosa sarebbe ovviamente inefficiente in modo spaventoso e non vedo perchè non poter applicare lo stesso concetto anche ai css
Il motivo per non applicare lo stesso concetto ai css è che il linguaggio di programmazione nasce per svolgere determinati compiti, mentre il css ha altri scopi. Il css non deve “fare qualcosa” ma deve definire degli stili (e comunque il grouping degli stili è concettualmente simile ad una funzione del linguaggio).
Allo stato attuale se io dovessi creare - diciamo 10 - blocchi che abbiano altezza automatica ma altezze minime differenti potrei definire alternativamente 10 classi con le regole specifiche oppure una classe con le regoli comuni (in questo caso solo height: auto !important) e inserire le altre due proprietà in altre 10 regole: da questa cosa non si scappa.
Lo so, è noioso da fare, ma è l’unico modo per mantenere veramente separata la presentazione della pagina dalla sua struttura. Inoltre, utilizzando delle variabili, è vero che scriveresti una sola regola css, ma sposteresti il problema nel codice HTML agganciando ad ognuno dei 10 blocchi la classe con il parametro dell’altezza da usare. Ed è proprio qui che si mischia semantica e presentazione perchè nell’HTML stai specificando un attributo proprio della presentazione, cioè l’altezza. Se quando vai in stampa ti accorgi che quelle altezze non vanno bene? Se fossero definite nel css (per pur palloso che sia) ti basterebbe creare un css ad hoc per la stampa.
…e che mi evitino di applicare tante (troppe) classi ad uno stesso elemento (con buona pace della manutenibilità e leggibilità del codice)
nel tuo esempio, ognuno dei 10 blocchi avrebbe solo una classe css agganciata e, se agganci l’elemento con l’id, nemmeno una.
Io che per lavoro scrivo css almeno 5 ore al giorno…
Se scrivessi solo css non potresti usare le variabili perchè non avresti accesso (in modifica intendo) al codice della pagina (HTML o php che sia). Il fatto che tu debba mettere mano al codice della pagina è la dimostrazione lampante che stai mischiando semantica e presentazione, inoltre costringi una persona, che magari fa solo grafica, a imparare il linguaggio con cui sono scritte le pagine mentre a chi fa il template della pagina non deve interessare se è scritta in php o altro.
Non dimentichiamo che il doctype strict va proprio in questa direzione perchè vieta qualsiasi elemento presentazionale all’interno dell’HTML.
# - postato da Marco Bacchetta - 27 Settembre 2007 - 17:49
13
sullo zen-cart ad esempio una tecnica così, o quanto meno simile è già adottata, un pò meno per i file css esclusivi, molto invece css in linea.
14
Come avevo già commentato anche nel post “CSS 3: A Giant Serving Of FAIL”, i CSS sono una tecnologia semplice, chiara e di facile scrittura/lettura. Volerli portale al livello di un vero e proprio linguaggio di programmazione (magari addirittura orientato agli oggetti) non farebbe altro che ucciderli.
Per come la vedo io il web ha bisogno di tecnologie semplici, che possano essere implementate velocemente dai browser. Ve lo immaginate il tempo che ci metterebbe IE ad imparare un CSS Object Oriented? :S
Già allo stato attuale i CSS sono potenti. Ovviamente in progetti molto complessi la loro costruzione deve essere pianificata, ma questo vale per tutte le tecnologie utilizzate. Se un foglio di stile diventa troppo complicato o grande, allora sono convinto che ci sia stato qualche errore in fase di progettazione.
# - postato da Francesco Camarlinghi - 03 Ottobre 2007 - 12:02
15
L’introduzione di variabili nei CSS non farà dei CSS un linguaggio di programmazione. Forse avete i concetti un po’ confusi.
Sarebbe utile e sensato invece. Tante volte sono stato tentato di scrivere cose di questo genere:
#rosso{
height:50px;
}
#blu{
height:#rosso 10px;
}# - postato da BLah - 27 Giugno 2008 - 11:41
16
Non mi ha preso il simbolo PIU’ 10px.
# - postato da BLah - 27 Giugno 2008 - 11:42