Negli ultimi anni si è affermato l'utilizzo dei CMS per il mantenimento e l'aggiornamento dei siti web. Tra i CMS più utilizzati in ambito open source abbiamo assistito all'affermarsi di Joomla, Drupal e WordPress (quest'ultimo ormai sdoganato dall'utilizzo “solo blog”).
Si tratta di CMS ben maturi e stabili, con grande supporto di community e una continuità stabile nei moduli: tutti vengono utilizzati anche per progetti di alto livello.
L'utilizzo dei CMS rende sempre più fondamentale l'organizzazione di CSS ben strutturati e riutilizzabili. Se prendiamo come esempio un CMS quale Drupal troveremo diverse classi generate dal suo core e che dovremo andare a personalizzare in base al nostro progetto e agli stili richiesti del nostro layout. Riscrivere ogni volta le classi personalizzate è molto dispendioso a livello di tempo e costi; ragionando a livello produttivo è un costo che inciderà sui nostri progetti e che possiamo andare a tagliare semplicemente, vediamo come.
Le classi generate dai CMS
I CMS generano una quantità di classi per il loro output e ognuno utilizza dei propri standard di naming. Ad esempio, Drupal utilizza la classe .node per i nodi di contenuto, Joomla utilizza la classe .contentpane per le parti di contenuto.
Ogni singola classe che viene generata dovrà essere personalizzata per i nostri progetti; per farci un'idea della quantità di classi generate che dovremo personalizzare possiamo inizialmente andare a leggere i CSS utilizzati nei template di base forniti con i nostri CMS. Ad una prima occhiata già si vedrà la quantità di classi, non completa, che viene generata. Inoltre, le classi generate sono molto approfondite e questo per poter personalizzare in estremo dettaglio ogni aspetto grafico e di layout per i nostri progetti.
Spesso poi ci troveremo di fronte a classi che non abbiamo personalizzato e che vengono visualizzate solo quando attivate un determinato modulo o componente del CMS. Ad esempio, quando in un progetto aggiungeremo in un secondo tempo una funzione che inizialmente non abbiamo previsto (una ricerca tra i contenuti, per citare un solo caso) dovremo personalizzare anche questa parte che precedentemente non avevamo definito nel foglio di stile.
Il primo e fondamentale consiglio di questo articolo è quello di creare un foglio di stile personalizzato con l'elenco di tutte le classi generate dai CMS, per velocizzare i tempi di sviluppo e per avere un metodo comune sui nostri diversi progetti su base unica di piattaforma.
Per semplificarvi la ricerca vi forniamo una lista di link utili per iniziare:
Riutilizziamo il nostro CSS
Il riutilizzo dei CSS è l'altro aspetto che andiamo ad affrontare. Se decidiamo di avvalerci del supporto continuativo di un CMS dovremo conoscere approfonditamente il prodotto per abbattere i tempi e i costi, e anche per una personalizzazione efficace delle classi e degli id presenti nel CMS.
Quando iniziamo lo sviluppo di un nuovo progetto basato sul CMS scelto, poi, dovremmo utilizzare qualche convenzione standard e un metodo comune, non possiamo di volta in volta nominare le cartelle o i fogli di stile che gestiscono i temi con nomi sempre diversi.
La teoria del “non reinventare l'acqua calda”, senza estremizzarla, è bene tenerla sempre presente quando iniziamo un progetto. Se dovessimo riscrivere sempre i nostri CSS per l'area di backend e per le classi generate perderemmo sempre molto tempo, il che si traduce in costi. Preparandoci invece a affrontare i nostri progetto con un metodo comune su una piattaforma di base avremo già pronto il nostro CSS con le classi elencate, ma non ancora personalizzate: dovremo poi solo concentrarci sulla personalizzazione senza perdere tempo a analizzare il codice generato dal CMS.
Seguiamo gli standard dei CMS, seguiamo sempre i nomi convenzionali utilizzati dal CMS per la gestione dei temi. Drupal, ad esempio, utilizza come nome standard per il foglio di stile del tema “style.css”: evitiamo quindi di nominare il CSS di volta in volta in modi diversi, si creerà solo confusione.
Prepariamo poi una cartella con all'interno tutti gli elementi che andremo ad utilizzare per il nostro tema: immagini, script, filmati Flash, etc. Una volta che avremo definito uno standard di sviluppo del tema utilizziamolo per i futuri progetti.
Ricordiamoci sempre di seguire costantemente l'evoluzione del CMS che abbiamo scelto: ad ogni sviluppo di major release, infatti, vengono spesso applicate delle modifiche alle classi e id generate dal core.
È importante anche essere ordinati nella scrittura del nostro CSS. Utilizzate spesso i commenti: è il modo più semplice e veloce per ritrovare velocemente la classe che cercavamo. Possiamo spezzare il CSS in più parti per semplicità:
/* Classi delle tabelle elenco contenuti */ … /* Classi form login user */ …
Per entrare nel dettaglio potremmo preferire l'utilizzo di più fogli di stile per ogni personalizzazione e creare un CSS “padre” in cui andremo ad importare più CSS “figli”:
admin.css @import userlogin.css @import tabellecontenuti.css
L'unico “difetto” da considerare nello spezzare in più fogli di stile l'eventuale personalizzazione è la sola gestione di più file: maggiore è il dettaglio che vogliamo applicare e maggiore sarà il numero dei file da gestire.
Quando avremo definito un buon grado di dettaglio e il nostro foglio di stile sarà ben formato e completo delle classi necessarie avremo una solida base su cui costruire i futuri progetti con il CMS scelto: quando dovremo iniziare un nuovo progetto potremo da subito copiare nella cartella dei CSS il foglio di stile personale, in questo modo avremo già eliminato tempi di sviluppo e costi aggiuntivi.
Una volta che il nostro foglio di stile sarà completato potrà essere affinato con ulteriori modifiche in ulteriori fasi di sviluppo e progetti che affronteremo. Difficilmente si arriverà ad un CSS completo e che non invecchierà mai. Consideriamo anche l'evoluzione dei browser e i loro annosi bug. Un ulteriore consiglio è quindi quello di creare un secondo foglio di stile per i nostri CMS che contenga solo le classi di personalizzazione che dovremo adattare per eventuali bug relativi ai browser. In questo caso è bene utilizzare il nome stesso del browser: fixie6.css, ad esempio, per il foglio di stile relativo a Internet Explorer 6.
