Skip to content

Contare gli elementi in pagina con CSS

In uno degli ultimi progetti di Evolve mi è capitato di utilizzare una proprietà CSS che si chiama counter-increment, che uso raramente, così ho pensato che potesse essere una buona idea fare una breve panoramica per chi ancora non la conosce.

Counter-increment è una proprietà che si occupa di aumentare o diminuire un valore, è molto semplice da utilizzare ed è molto utile in quei casi in cui magari non vogliamo o non possiamo creare un contatore via PHP.

Come funziona?

Nella sua implementazione base ci basterà aggiungere counter-increment: contatore; alla classe o elemento che vogliamo contare, per esempio:

h2 {
    counter-increment: contatore;
}

A questo punto il valore di contatore sarà disponibile e potremo riutilizzarlo per esempio per prependerlo a tutti gli h2 utilizzando la funzione counter():

h2:before {
    content: counter(contatore);
}

La funzione counter() è incaricata di ritornare il valore di un contatore e può essere utilizzata come counter(contatore) oppure counter(contatore,stile) e supporta gli stessi stili delle liste, ovvero: disc | circle | square | decimal | decimal-leading-zero | lower-roman | upper-roman | lower-greek | lower-latin | upper-latin | armenian | georgian | lower-alpha | upper-alpha | none | inherit.

Un aspetto molto interessante dei contatori è che possono essere circoscritti a diverse aree o contesti utilizzando la proprietà counter-reset che permette di resettare il valore di uno o più contatori a zero o ad un valore predefinito.

Counter-increment può essere influenzato dalla struttura del markup, quindi è importante capire quando è necessario utilizzare counter-reset:

<ul>
    <li>List item</li>
    <li>List item</li>
    <li>List item</li>
</ul>

In questo caso se volessimo contare i li ci basterebbe scrivere:

li {
    counter-increment: contatore-li;
}

Aggiungendo un altro ul il conteggio dei li ripartirà automaticamente da 0.

Facciamo un altro esempio per capire quando utilizzare la proprietà di counter-reset:

<article>Articolo</article>
<article>Articolo</article>
<article>Articolo</article>
    
<aside>
    <article>Articolo</article>
    <article>Articolo</article>
    <article>Articolo</article>
</aside>
article {
    counter-increment: conta-articoli;
}

article:before {
    content: counter(conta-articoli);
}

In questo caso il valore del contatore sull’ultimo articolo sarà 6.

Per far si che il conteggio degli article all’interno del nostro elemento aside riparta da 0 dovremo aggiungere la seguente regola:

aside {
    counter-reset: conta-articoli;
}

Cosa non può fare

Onde evitare fraintendimenti, counter-increment non è disponibile globalmente una volta valorizzato ma è sempre associato all’elemento dove è stato specificato.

Il valore anche se è un intero possiamo considerarlo come una stringa perché non è possibile usarlo all’interno di calc() per delle operazioni.

Variabili CSS, come e quando usarle

Le variabili CSS, da non confondere con le variabili dei pre processor come SASS o LESS, sono in giro da parecchio ma solo negli ultimi anni si è iniziato a vedere qualche utilizzo nel mondo reale grazie anche al migliorato supporto da parte dei vari browser, tranne come al solito Internet Explorer. 

CSS Variables (Custom Properties)

Permits the declaration and usage of cascading variables in stylesheets.

W3C Candidate Recommendation

Supported from the following versions:

Desktop

  • 49
  • 31
  • No
  • 36
  • 9.1

Mobile / Tablet

  • 9.3
  • 67
  • No
  • 75
  • 67

* denotes prefix required.

  • Supported:
  • Yes
  • No
  • Partially
  • Polyfill

Stats from caniuse.com

Cosa sono esattamente le variabili CSS?

Le variabili CSS ci permettono di specificare un valore e ripeterlo più volte all’interno del nostro foglio di stile, un esempio?

:root {
  --colore-principale: #333;
  --colore-titoli: #000;
}

body {
  color: var(--colore-principale);
}

h1 {
  color: var(--colore-titoli);
}

h2 {
  color: var(--colore-titoli);
}

Questo è un semplice esempio con i colori, ma potete tranquillamente applicare lo stesso approccio anche per le spaziature, creando di fatto una specie di indice che vi risparmierà tanto tempo di ricerca e sostituzione qualora aveste la necessità di cambiare un valore in applicato in più punti.

A questo punto starete pensando, beh ma una sostituzione in batch con un editor di testo come Sublime Text o Visual Studio Code si fa in pochi secondi, dov’è il gran vantaggio delle variabili?

Pensate per un attimo di dove alterare dei parametri a seconda di una classe, come per esempio il cambio della skin o il cambio delle spaziature ad una determinata media query.

:root {
  --colore-principale: #333;
  --colore-sfondo: #fff;
  --gutter: 30px;
}

@media screen and (max-width:768px) {
  :root {
    --colore-principale: #fff;
    --colore-sfondo: #111;
    --gutter: 15px;
  }
}

body {
  color: var(--colore-principale);
  background-color: var(--colore-sfondo);
  padding: 0 var(--gutter);
}

Grids e le variabili

Quando abbiamo iniziato a sviluppare il concept del nostro plugin Grids ci siamo chiesti come fare per ottimizzare il più possibile il codice ed evitare che Javascript si facesse carico di stampare del CSS inline ad ogni cambio di proprietà dai controlli alla preview nel block editor aka Gutenberg. Abbiamo deciso quindi di sperimentare un approccio basato interamente sulle variabili.

Le variabili possono essere definite globalmente come abbiamo visto nell’esempio precedente o all’interno di un elemento, nel nostro caso il contenitore di markup della sezione:

.grids-areas-wrapper {    
    --section-columns: 1fr 1fr 1fr 1fr;
    --section-rows: auto;
    --section-gutter: 0px;
    --section-background-repeat: no-repeat;
    --section-background-size: auto;
    --section-background-attachment: scroll;
    --section-background-position-x: 50%;
    --section-background-position-y: 50%;
}

In questo modo siamo in grado cambiare una variabile e lasciare che sia il browser ad applicare tramite CSS il cambiamento al nostro elemento.

Compatibilità nel mondo reale e considerazioni

Bene, vi ho convinto a sperimentare con le variabili ma fermi tutti, dovete assolutamente supportare IE nel vostro progetto!

La buona notizia è che potete utilizzare il css-vars-ponyfill realizzato da John Hildenbiddle, utilizzato peraltro in Grids, ma la cattiva notizia è che non supporta le variabili nelle media queries, cosa purtroppo molto limitante dal punto di vista creativo.

E voi state già utilizzando le variabili CSS nei vostri progetti?

p.s.

Questo sito utilizza le variabili per cambiare la skin al cambio giorno/notte 😉

Quante volte vi sarà capitato di dover aggiornare il tema modificato per un cliente e all’improvviso temere di perdere tutto il lavoro fatto?

Vediamo insieme una serie di tecniche e regole d’oro per personalizzare un tema e adattarlo alle richieste del cliente senza perdere la compatibilità con gli aggiornamenti.

1 – Child theme

Ebbene si, la prima e imprescindibile regola è anche la più banale probabilmente per molti di voi, ovvero usare un child theme.

L’importanza cruciale nell’usare un child theme risiede nel fatto che ci permette di mantenere intatto e aggiornabile il tema parent, che sia stato acquistato su un marketplace o scaricato da WordPress.org non fa alcuna differenza.

Attivare il child theme ci permetterà di affrontare tutte le personalizzazioni con le tecniche che saranno illustrate nei punti seguenti garantendoci la possibilità di aggiornare il tema principale senza problemi.

E se il tema che abbiamo scaricato non ha un child theme incluso?

Niente paura, creare un child theme è molto semplice, può essere fatto a mano se si ha un minimo di dimestichezza con il codice oppure usare uno dei tanti plugin che si trovano sulla repository di WordPress.org che ci consentiranno di crearlo con un click.

2 – Sovrascrittura di template

Questa regola vale per temi e plugin, la sovrascrittura di un template, qualora dobbiate modificare larghe porzioni di codice e non sia presente un action o un filtro, è una pratica molto comune.

Sfruttando la gerarchia dei template di WordPress saremo in grado di sovrascrivere un template semplicemente copiando il file, se necessario con il suo percorso, all’interno del nostro child theme, un esempio?

Se volessimo modificare il template della pagina 404 ci basterà copiare il file 404.php dal tema parent nel tema child.

Questo vale per tutti i template di elencati nella pagina di gerarchia dei template, chiaramente se state utilizzando un tema custom che definisce una propria struttura di inclusione dei template questa regola non è applicabile.

3 – Usare i filtri

I filtri in WordPress fanno parte, insieme alle action, di quelli che sono chiamati “hooks”, ovvero degli agganci al codice che ci permettono di modificare dei comportamenti di un tema o plugin tramite una funzione.

I filtri, come dice il loro nome, filtrano del contenuto, quindi hanno bisogno a differenza delle azioni di ritornare sempre un valore.

Come possono tornarci utili nella personalizzazione di un tema?

Innanzitutto potremmo iniziare cercando tutti i filtri dichiarati nel nostro tema parent cercando apply_filters all’interno dei file php della cartella in modo da capire se il tema dichiara qualche filtro giusto per farci un’idea sul cosa possiamo modificare.

Se ad esempio facciamo questa ricerca all’interno del tema Twenty Nineteen troveremo diversi filtri definiti.

Prendiamone in esame uno molto semplice per capirne bene il funzionamento, il filtro dichiarato in image.php chiamato twentynineteen_attachment_size.

Il suo compito è quello di filtrare il valore dell’image size utilizzata per mostrare l’immagine nella pagina dedicata ad ogni singolo attachment.
In questo modo sarà possibile tramite child theme definire una nuova dimensione da utilizzare senza toccare il template originale.

Andiamo quindi nel nostro child theme, in functions.php e creiamo la seguente funzione:

function child_theme_attachment_size( $image_size ) {
    return $image_size;
}

Questa funzione per il momento non fa altro che accettare un valore in ingresso e ritornarlo senza modificarlo, nel pieno spirito dei filtri come abbiamo nella precedente spiegazione.
A questo punto ci inseriamo nel filtro con il nostro nuovo valore per la dimensione dell’immagine, diciamo che useremo ‘thumbnail’ come esempio:

function child_theme_attachment_size( $image_size ) {
    $image_size = 'thumbnail';
    return $image_size;
}

Ora non ci resta che associare questa nuova funzione al filtro che ci siamo segnati prima:

add_filter( 'twentynineteen_attachment_size', 'child_theme_attachment_size' );

4 – Usare le action

Le action a differenza dei filtri non necessitano di ritornare un valore e possono essere considerati dei veri e propri agganci per aggiungere contenuto come meglio crediamo, queste sono molto usate sopratutto nei plugin e un ottimo esempio a livello di organizzazione è sicuramente WooCommerce.

Come visto prima per i filtri, come facciamo a capire se un tema sta dichiarando qualche action da sfruttare a nostro vantaggio?

Ci basterà cercare nei file php nel tema do_action.

Un esempio di action possiamo trovarlo nel vecchio Twenty Sixteen che dichiara nel file footer.php chiamato twentysixteen_credits.

Come possiamo vedere dalla descrizione nel codice, questo action è lanciato subito dopo l’apertura del div con classe site-info e ci permette in questo modo di aggiungere del testo o del markup e personalizzare in questo modo il footer del tema senza necessariamente sovrascrivere il template footer.php.

Prepariamo quindi la nostra funzione per aggiungere un paragrafo con un testo:

function twentysixteen_custom_credits() {
    echo '

Testo che verrà inserito nel footer

'; }

e andiamo a collegarla all’action che ci siamo segnati:

add_action( 'twentysixteen_credits', 'twentysixteen_custom_credits' );

5 – Scrivere il CSS in un punto solo

Quest’ultima non è veramente una tecnica ma più buon senso direi.

Per colpa di WordPress che mette a disposizione due modi per modificare il CSS, uno nel customizer e uno attraverso l’editor di codice modificando direttamente il file style.css del child theme, oltre ai vari temi e plugin che aggiungono una loro textarea per aggiungere CSS o peggio ancora JavaScript custom, l’utente meno esperto si trova gioco forza a sparpagliare CSS un po’ ovunque, perdendo di vista tutto quello che è stato aggiunto al tema. 

Il consiglio che mi sento di dare è di utilizzare sempre il file style.css perché in questo modo sarà più semplice tenere sotto controllo tutte le modifiche.

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?