Skip to content

WordCamp Verona 2019

Dopo la parentesi, decisamente non programmata per quanto mi riguarda, ma diabolicamente pianificata da Maria Laura al WordCamp Bari 2019 che mi ha visto in qualche modo protagonista improvvisato insieme al mio socio Andrea per la presentazione al Fuori WordCamp della nostra ultima fatica, Grids, ho pensato che potesse essere la volta buona per vincere timidezza e senso di inadeguatezza cronico e candidarmi come speaker per il WordCamp di Verona.

Ad essere sinceri se Carola non mi avesse mandato un messaggio chiedendomi se avevo qualche argomento da presentare probabilmente avrei finito per far cadere tutto nel dimenticatoio come mio solito.

Raccolte un pò di idee e grazie a qualche dritta dal mio socio, ormai speaker navigato, mi son fatto coraggio e ho mandato la mia prima application!

Qualche settimana dopo il bellissimo WordCamp Europe, dove abbiamo avuto i nostri 30 secondi di gloria durante la presentazione di Matt Mullenweg, è arrivata la mail che la mia candidatura era stata scelta tra le 73 presentate.

Voglio ringraziare gli amici della community WordPress di Verona per avermi dato fiducia e la forza per rimettermi in gioco oltre ad avermi fatto ritrovare la motivazione giusta per riattivare il mio sito, ridotto da anni ad una pagina html con due link.

Di cosa parlerò? Questo è l’abstract del mio talk:

Hai veramente bisogno di un framework CSS?

Diciamo addio ai framework CSS ed esploriamo insieme le nuove tecniche che ci aiuteranno a realizzare e gestire ogni tipo di layout, in meno tempo.In questo talk analizzeremo i pro e i contro dei framework CSS più famosi, scopriremo perché oggi non è più necessario utilizzarli e come crearci un metodo di sviluppo front-end efficace, districandoci tra OOCSS, Atomic CSS, BEM e SMACSS.

Ci vediamo al WordCamp di Verona l’11 e il 12 ottobre!

Resettare o normalizzare il foglio stile?

Non poteva iniziare con un argomento migliore il primo post del nuovo blog, con un bel reset, come quello dato alla mia pagina statica rimasta in piedi per molti, forse troppi anni.

Il reset o la normalizzazione è il primo set di regole che devono essere dichiarate in un foglio di stile e il suo compito è quello di preparare il terreno per lo stile del nostro progetto, appianando o correggendo i comportamenti di default dei vari browser.

User agent stylesheet

Una piccola premessa prima di addentrarci nel discorso, ogni browser ha un proprio modo di definire lo stile degli elementi HTML presenti in pagina, come possiamo vedere nell’esempio qui sotto relativo allo stile dichiarato da Chrome per i <p>:

p {
    display: block;
    margin-block-start: 1em;
    margin-block-end: 1em;
    margin-inline-start: 0px;
    margin-inline-end: 0px;
}

A questo indirizzo è possibile consultare tutti i vari fogli di stile di default dei vari browsers.

Questo ci porta naturalmente alla domanda successiva, ovvero, come facciamo a risolvere questi problemi di consistenza tra i vari browser?

Ci sono sono vari approcci possibili al problema chiaramente, come reset o normalize, ma andiamo a scoprire di cosa si tratta.

Reset CSS

Partiamo con l’approccio più conosciuto e allo stesso tempo il più aggressivo, ovvero il reset di tutte le proprietà in modo da poter partire da una condizione che definirei “piatta” a livello stilistico. Il reset più famoso (e quello che ho usato per più tempo in tanti progetti) è sicuramente quello di Eric Meyer, che nonostante tutto si trova ancora applicato ancora oggi su larga parte dei siti web in circolazione.

Vediamo insieme la prima parte di questo set di regole:

html, body, div, span, applet, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, big, cite, code,
del, dfn, em, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
b, u, i, center,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td,
article, aside, canvas, details, embed, 
figure, figcaption, footer, header, hgroup, 
menu, nav, output, ruby, section, summary,
time, mark, audio, video {
    margin: 0;
    padding: 0;
    border: 0;
    font-size: 100%;
    font: inherit;
    vertical-align: baseline;
}

Il problema principale di questo approccio è che va a creare una serie di override non necessari e rende il debug veramente difficile per colpa dell’incredibile numero di selettori concatenati, un esempio? il tag html non necessità di un reset per quanto concerne margini, padding, border o vertical-align. 

Normalize CSS

Un approccio che ho iniziato ad utilizzare da qualche anno a questa parte è il normalizzare tutta una serie di comportamenti in modo da appianare le differenze di rendering tra i vari browser.

Ci sono diversi approcci al concetto di normalizzazione, un bel progetto open source è Normalize.css di Nicolas Gallagher, oppure il Reboot di Bootstrap.

Un esempio pratico? Tutti i browser bene o male specificano un margine per il body, dai 15px 10px dei vecchi ie agli 8px di tutti gli altri browser, bene, in normalize abbiamo:

body {
    margin: 0;
}

e non una serie infinita di tag ai quali non è veramente associato un valore di margine.

Questo chiaramente è l’esempio più semplice di tutti, in Normalize.css potete trovare tutte le regole commentate in modo da farvi un’idea più precisa di quello che viene fatto e perché.

Considerazioni

Per tanti anni ho usato l’approccio reset per avere un punto di partenza quanto più piatto possibile dove andare a creare il mio stile. Con il tempo mi sono reso conto che probabilmente questo era anche l’approccio probabilmente più pigro, perché non mi portava a capire meglio il funzionamento dei vari browser e trovare una strada più personale al problema.

Se applichiamo il concetto di normalizzazione allo sviluppo di un progetto c’è da dire che in realtà non tutte le regole sono necessarie e probabilmente la cosa migliore è svilupparsi un proprio normalize per ottimizzare al meglio il proprio stile, per esempio, nel normalize.css troviamo la seguente regola:

h1 {
    font-size: 2em;
    margin: 0.67em 0;
}

È vero che questa regola serve per appianare le differenze di dimensione degli h1 all’interno di section o article, ma siamo proprio sicuri che nel nostro progetto non andremo a definire a nostra volta una dimensione e una spaziatura per gli h1?

Nel mio workflow, lavorando con SASS ho scelto l’approccio a mixin, per la normalizzazione, facendo un mix tra il reboot di Bootstrap e Normalize.css e tenendo solo quello che mi sembrava veramente necessario e scomponendo il tutto in aree e integrandolo anche con altri mixins per l’ambiente di sviluppo in WordPress.

Questo è un esempio dell’impostazione di reset tipica che utilizzo su un tema WordPress:

// Normalization of HTML elements
@include evolvethemes_reset();
// Add the support for the screen-reader-text WP class
@include evolvethemes_wp_reset();
// Normalization of all the accessibility elements
@include evolvethemes_accessibility_reset();
// Normalization of all the typographic elements
@include evolvethemes_typography_reset();
// Normalization of all the forms elements
@include evolvethemes_form_reset();
// Normalization of all the Embedded content
@include evolvethemes_media_reset();

Chiaramente non è il sistema perfetto ma semplicemente un approccio possibile e come tutte le cose è soggetto a continue revisioni.

Voi che approccio preferite utilizzare?