Bookmark and Share
You are here: Home Blog Maurizio Lupo Sviluppo front-end (parte 5): scrivere HTML

Sviluppo front-end (parte 5): scrivere HTML

Anche la scrittura dell'HTML ha subito un evoluzione. Parleremo di HTML5 e non solo.

by Maurizio Lupo - 2012-06-27

HTML5

Apriamo l'articolo con una doverosa premessa (nonchè un utile chiarimento) riguardante il termine HTML5.

Nonostante esistano delle specifiche, questo termine appartiene più al mondo del marketing che a quello dell'informatica ed indica generalmente l'utilizzo delle nuove tecnologie in ambito web.

In realtà le innovazioni di cui parlo sono spalmate in decine di specifiche (o meglio working draft ... bozze) diverse.
Non perdiamoci troppo con la terminologia !

Le specifiche HTML5 portano nei browser moltissime innovazioni. Una cosa che non tutti sanno e che sono quasi tutte compatibili verso il basso: si possono usare fin da subito e la pagina risulterà compatibile con i vecchi browser !
Ad esempio il tag video non funziona sui vecchi browser ma non rende la pagina errata e, tra l'altro, ha la possibilità di definire un fallback se non supportato.

In realtà c'è una piccola eccezione: i nuovi tag semantici (section, article ecc.) non vengono riconosciuti correttamente in Internet Explorer < 9. Fortunatamente c'è una semplice soluzione usando questa libreria Javascript: HTML5shim.

Per una panoramica di queste funzioni consiglio il lavoro di Mark Pilgrim "Dive into HTML5" disponibile anche on-line.

Markup semantico e design

Utilizzando HTML e CSS è una buona norma riconosciuta da anni quella di separare i compiti dei due linguaggi: HTML per la semantica e CSS per lo stile. Una separazione troppo netta tra i due mondi può portare però a grossi problemi: non si può applicare lo stile corretto se l'HTML non è marcato appositamente. 
Facebook si trovava esattamente con questo problema quando ha ingaggiato la consulente Nicole Sullivan: il risultato delle suo lavoro è stato talmente valido che è stato portato come esempio in numerose presentazioni.
Tra le regole più importanti è un utilizzo intensivo delle classi nei selettori (spesso assegnate in modo multiplo) come marcatore di stile.
Seguendo questa pratica è possibile riutilizzare meglio le regole css. L'utilizzo degli ID nei selettori, al contrario, viene fortemente sconsigliato.

Un semplice esempio:
se nel nostro stile il colore principale è il rosso è meglio usare una sola classe per lo scopo:

.maincolor{
    color: red;
}


Ed attaccare questa classe dove necessario, piuttosto che usare selettori multipli.
Questa pratica porta ad evitare di lavorare troppo sulla specificità delle regole, che per chi non lo sapesse si tratta di un modo per determinare quando una regola è prioritaria rispetto ad un'altra.

Riporto la regola qui:
"per ogni match si assegnano dei punti: 1 punto per ogni selettore di tipo (p, h1, a, ecc.), 10 punti per ogni classe (.miaclasse) e 100 punti per ogni id (#mioid), 1000 punti per "!important"."
La regola con il punteggio più alto vince.
La stessa Nicole Sullivan è anche coautrice di uno strumento per validare i css e controllare se sono state seguite le "buone pratiche".

Benefici

Questi buone pratiche permettono di generare del codice (si , anche il CSS e l'HTML si considerano codice) che sia performante e mantenibile.
Le due cose vanno a braccetto: un css molto ripetitivo e complicato non è nè mantenibile e n performante.
Una regola basata su un selettore semplice è molto più veloce che una regola basata su selettori multipli.
Bisogna anche tenere conto molto chiaramente che le regole sui selettori vengono sempre valutate da destra a sinistra e quindi la regola:

.sezione div{
    ...
}

cercherà prima tutti i div e poi li fitrerà in seguito !

Da qui la regola: quando è possibile è meglio mettere la condizione più restrittiva a destra sel selettore.
Oltre a marcare al meglio l'HTML è anche importante non esagerare nello specificare i selettori. Ad esempio con:

div.miaclasse {
    ...
}

Non ha senso specificare "div" se la mia classe è assegnata solo a elementi "div" (a maggior ragione se usiamo gli id che per loro natura dovrebbero essere univoci).

Altri utili strumenti

Oltre a queste semplici linee guida, per facilitare la scrittura di css modulari, vengono usati dei preprocessori CSS. Questi estendono la sintassi dei CSS aggiungendo molte utili funzionalità (variabili, blocchi innestati ecc.). Tutti questi strumenti hanno un compilatore che li trasforma in semplici CSS.
Questi sono i più noti:

Un'altro interessantissimo strumento che ci semplifica enormemente il lavoro è un foglio di stile di reset. Si tratta di un css preimpostato che cerca di eliminare le differenze che intercorrono tra gli stili di default dei vari browser.

Infine molte delle cose che ho trattato in questa serie di articoli si possono ritrovare nel progetto HTML5Boilerplate: un HTML vuoto pronto per l'uso!

Spero che questa breve serie abbia chiarito un po' di cosa si occupa la figura emergente di frontend developer. Happy hacking !