Un framework CSS a prova di test: Frontsize

framework css

Un framework CSS: Frontsize. Un anno e sette mesi fa, ho iniziato a collaborare con ideato, sapevo solo che si trattava di un’azienda che aveva sede a Cesena e Osimo, che il team era composto da sviluppatori molto competenti impegnati su lavori molto interessanti e che lavoravano con un metodo di lavoro chiamato sviluppo Agile. Non avendo mai lavorato su progetti di grandi dimensioni mi sono proposto come collaboratore, così ho avuto l’occasione di affrontare contesti costituiti da molte pagine, con molti elementi indipendenti tra loro, che potevano essere aggiornati di tanto in tanto e che potevano essere presenti in pagine differenti con diverse dimensioni, insomma un contesto che richiedeva un front-end con un CSS molto flessibile e capace di adattarsi a quante più situazioni possibili, sicuramente qualcosa che si basasse su un framework CSS.

Per poter lavorare su questo genere di progetti mi sono documentato su SMACSS, OOCSS, BEM, ITCSS e qualche altro approccio per prenderne gli aspetti che più si avvicinavano al mio modo di lavorare, ho analizzato Boostrap e Foundation per capire quali fossero gli aspetti più interessanti che avevano.

Durante questo periodo, mi sono messo al lavoro per sviluppare uno strumento che mi permettesse di creare da zero dei temi per questo genere di progetti, che potesse permettermi di creare widget riutilizzabili e scalabili, senza arrivare ad approcci strutturati e macchinosi da ricordare. Lo scopo era di utilizzare delle scorciatoie per scrivere stili composti e modulari, così da avere maggiormente il controllo sul front-end e non dovermi sempre ricordare di tutte le innumerevoli best-practice che serve sapere per avere un CSS solido e con stili ben organizzati.

Da lì è nato Frontsize, un framework scritto con il preprocessor LESS fatto per essere utilizzato via LESS per generare CSS. Non lo definisco front-end framework ma framework CSS perché dedicato esclusivamente alla generazione degli stili CSS.

Esiste un porting in SASS sempre aggiornato grazie all’aiuto di Alessandro Minoccheri che mi dà pieno supporto.

Lavorando all’interno del team ideato, gran parte del codice è stato scritto sulla base delle necessità che mi sono state sottoposte, insieme alle persone esterne a cui ho avuto la fortuna di sottoporlo. Da lì ho riscritto il core molte volte in base al loro feedback, fino ad arrivare ad una versione completa, stabile e testabile con CSSlint.

Documentazione
Al momento esiste una versione incompleta della documentazione, uno dei prossimi step del roadmap consiste proprio nel prepararne una versione completa per documentare a fondo tutte le funzionalità di Frontsize.

Come funziona?
Il progetto è suddiviso in due parti: core e tema. La logica è pensata per lasciare che lo sviluppatore lavori nella parte legata al tema, in quanto il core condivide tutti i mixin disponibili e una serie di variabili utili per mantenere stili, testi e spaziature consistenti.

Il file CSS viene generato da compile.less, che possiede già tutte le dipendenze di tutto il progetto.

Per testare il codice con CSSlint è necessario usare compile-test.less, che esclude normalize.css dai test perché non li passa.

Cosa mi permette di fare questo framework CSS?

Configurazione
Uno degli aspetti su cui ho lavorato di più è stato rendere configurabile tutto l’ambiente del framework tramite un file di progetto legato al tema che si sta utilizzando al suo interno, ogni variabile che viene riutilizzata all’interno di Frontsize si può gestire da app.less che si trova nella cartella del tema.

Dipendenze
Frontsize è pensato per dare allo sviluppatore la possibilità di lavorare su un tema dal quale partiranno tutti i moduli che scriverà e lasciare al core la parte di mixin e variabili disponibili. Così è possibile concentrarsi sul tema senza lavorare sul core. Tutte le dipendenze del tema sono gestite da import.less dove non sono presenti le dipendenze del core.

Struttura del progetto
Dal momento che non c’è ancora una documentazione completa, scriverò di seguito tutte le funzionalità disponibili facendole puntare direttamente sul progetto:

Cosa contiene il core?

  • Helper mixins – Sono in molti casi delle scorciatoie alle best-practice per il loro contesto specifico
  • Grid generators – Ci sono tre tipi di griglie disponibili, una in fase di sviluppo
  • State selectors generators – Mixin per generare selettori di stato, possono essere disattivati
  • Prefix helpers – Shortcut mixins per generare tutti i browser prefix, è possibile disattivare o attivare questa opzione da app.less
  • State selectors – Ci sono vari set disponibili, che possono essere attivati e disattivati individualmente da app.less
  • Regole media query dinamiche – Anche queste configurabili da app.less

 

Tool nel progetto

 

Il tema
Tutto il lavoro dello sviluppatore si svolgerà all’interno del tema in uso, di seguito descriverò come ho pensato di organizzare il codice basandomi sulle cartelle e i file che sono al suo interno.

File nella root del tema

Configurazione del tema: app.less
La configurazione che si trova su app.less serve a definire tutte le variabili legate al core di Frontsize, NON quelle custom che l’utente si crea per il tema, come i colori, stili di bordi o altro.
Da qui è consigliato creare le regole delle griglie, definire le spaziature, i font i percorsi delle immagini e tutto quello che riguarda il comportamento globale del tema che viene utilizzato ripetutamente nel front-end.

Il file vars.less
Le variabili che non sono legate al core di Frontsize andrebbero utilizzate dentro a vars.less, le variabili core hanno nomi come @variable-name, mentre quelle custom sono consigliate @camelCase per tenere diversificati i due tipi di variabili e sapere cosa è legato al core e cosa non lo è.

Importazione all’interno del tema
Tutte le dipendenze del tema sono in import.less, da li si può vedere cosa viene caricato all’interno del tema ed è il posto da utilizzare nel caso si vogliano aggiungere file alla coda.

Cartelle del tema

Base
La cartella base contiene tutti gli element selectors, in pratica solo selettori legati ad elementi della pagina, così da dare uno stile predefinito dove serve a tutto il layout in qualsiasi punto sono.

Fonts e img
Queste cartelle contengono i file legati SOLO al tema e ai css, queste immagini finiranno poi su quella di produzione online.

Helpers
La cartella helpers contiene tutti i mixin che non sono compresi nel core possono essere posizionati qui, in modo che nel caso si debba aggiornare il core, il tema non si perde i mixin dedicati.

Vendor
Il core contiene già il vendor , tuttavia è possibile che ci sia la necessità di integrare altre librerie CSS esterne, in quel caso quelle dovrebbero andare nella carella vendor del tema.

Views
Questa è la cartella che meno si dovrebbe utilizzare nel tema, views dovrebbe contenere tutti gli stili legati ad una vista specifica che non verranno riutilizzati altrove. Potrebbe essere utile per ottimizzare il peso del css esportato quando una vista viene rimossa dando la possibilità di rimuovere anche il codice CSS strettamente legato ad essa. In futuro sarà eliminata e sostituita direttamente da widgets.

Widgets
La cartella widgets è il cuore del tema in quanto ad elementi che devono essere riutilizzati all’interno del tema, un tema scritto correttamente è un tema che si basa interamente su widget perché con l’approccio utilizzato questi possono essere ovunque nel front-end.

Per poter utilizzare correttamente un widget è importante capire come è pensata la sua struttura, che punta a essere il più semplice possibile.

Convenzioni
La prima cosa riguarda le convenzioni, un file widget-name.less deve contenere solo un selettore che conterrà tutti gli altri al suo interno:

Un file widget-name.less può avere un solo selettore che si chiama allo stesso modo, .widget-name.

Il nome deve essere composto, quindi NON widget o name, ma widget-name, per quanto riguarda i selettori figli invece, dovrebbero essere composti da nomi singoli e comunque senza spazi nel nome, quindi:

 

Perché questa convenzione?
La scelta di utilizzare questa convenzione assicura di non creare conflitti tra widget e selettori figli di altri widget, in pratica .title o .confirm non avrà nessuno stile fuori da .widget-name, quindi può esistere un altro .title dentro .another-widget senza che si porti dietro stili presi da altrove, evitando così reset di stili che rendono a dare sempre più specificità ai selettori del front-end.

 

Questa è una soluzione semplice e sufficiente ad evitare conflitti tra selettori, perché nella stessa cartella widgets, non possono esistere widget con lo stesso nome, e i selettori figli non possono avere nomi uguali ai nomi dei loro genitori widget.

Verso BEM
Questa convenzione può essere comoda con progetti di piccole dimensioni ma potrebbe  creare comunque conflitti soprattuto se un widget è contenuto dentro un altro widget, l’intenzione è quello di rendere i widget dei blocks, come accade su BEM, convenzione che sostituirà quella attuale.

Roadmap
I prossimi passi si sviluppo saranno incentrati su rendere quello che c’è ora accessibile e comprensibile senza essere costretti a leggere il codice all’interno del core.

  • Cambiamento da widget a block
  • Documentazione completa per la release 3.0.0
  • Integrazione comportamenti griglie con mixin su selettori
  • Integrazione con Bower
  • Griglie basate sul nuovo grid model
  • Template per testare tutti gli elementi HTML5
  • Set completo di blocks con le nuove convenzioni

 

Conclusione
Frontsize è nato per chi vuole sviluppare il design del proprio front-end partendo da zero pur avendo a disposizione una struttura di regole vasta, completamente configurabile e customizzabile in qualsiasi stato di sviluppo del tema. Questo permette di avere il controllo non solo su quello che si farà, ma anche di modificare quello che è già stato fatto dalle impostazioni, come ad esempio il percorso di tutte le immagini del tema, la possibilità di attivare o disattivare selettivamente i media query, attivare o disattivare fallback e prefissi del browser.