Analisi approfondita di CSS Lint

Il termine LINT è ora applicato generalmente a tool che mettono in evidenza utilizzi non corretti di un qualsiasi tipo di linguaggio attraverso l'analisi e il parsing dei codici sorgenti per portare alla luce potenziali errori che potrebbero compromettere la manutenibilità, la compatibilità e le performance.
Analisi approfondita di CSS Lint

Cos’è Lint

Il termine è ora applicato generalmente a tool che mettono in evidenza utilizzi non corretti di un qualsiasi tipo di linguaggio attraverso l’analisi e il parsing dei codici sorgenti per portare alla luce potenziali errori che potrebbero compromettere la manutenibilità, la compatibilità e le performance.

Sublime Text e CSS Lint

Tempo fa ho pubblicato un articolo su WebHouse che parlava di Sublime. Tra i tanti plugin che ho trattato, c’era anche SublimeLint, un plugin che valida in tempo reale il codice scritto. Tra i tanti linguaggi supportati c’è anche il CSS validato tramite il servizio CSS Lint. Non è un articolo sul plugin in se ma piuttosto rappresenta un’analisi su come Lint applica le regole che generano i warning e gli errori mostrati a video tramite il plugin.

Ferire i sentimenti

A prescindere dal plugin di Sublime, conoscevo il servizio già da molto tempo ma non lo avevo mai utilizzato all’interno dell’ambiente di lavoro. Non ti nascondo che da quando ho attivato il plugin, i css si sono riempiti di warning. Questa situazione un pò mi da fastidio. Dentro di te sai che alcune delle dichiarazioni che scrivi non rispettano sempre le regole d’oro che dovresti seguire. Spesso lasci correre perché non c’è tempo, perché in base al contesto non puoi fare altrimenti o perché in realtà per te è giusto che sia così. Loro preventivamente scrivono in home page:

Will hurt your feelings*
(And help you code better)

Ok avete ferito i miei sentimenti, adesso ogni volta che apro Sublime mi trovo davanti tutti quei warning e a volte anche errori che mi perseguitano anche di notte. No scherzo però se uno te lo fa notare, forse è il caso che rivedi il tuo modo di approcciarti al linguaggio. Sono il primo ad ammetterlo e un pò fa male. Prima però di ammettere totalmente la sconfitta, scendiamo più in profondità nella logica che gestisce tutto.

Il cuore di Lint

Per capirci meglio, ho aperto i settaggi del plugin da Preference > Package Settings > SublimeLinter > Settings – Default e tra le tante impostazioni ho trovato anche quelle che generano i warning e gli errori e se hai voglia vorrei analizzarle con te:

Adjoining Classes: “warning”

Cominciamo subito con le classi concatenate. Se per esempio devi definire a monte una certa classe che è la base comune per tutti gli elementi a cui la assocerai, viene comodo creare delle varianti o delle aggiunte concatenandone un’altra, ti faccio un esempio velocissimo:

.button{
    display:inline-block;
    padding:3px 6px;
    font-size:12px;
    text-transform:uppercase;
}
.button.red{
    background:red;
    color:white;
}

Questo meccanismo ti consente di non dover ripetere le prime 4 regole anche per il bottone rosso, arancio verde o giallo. Rendenderai il codice più manutentibile, snello e riusabile. CSS Lint inserisce un warning in quanto Internet Explorer 6 non le gestisce del tutto. Se ancora sviluppi tenendo in considerazione IE6, per motivi che esulano da questo articolo, allora tieni attivo l’alert.

Box-model: “true”

Bordi e padding aggiungono altro spazio oltre a quello di contenuto. Impostare larghezza o altezza con bordi e padding di solito è un errore perché non si otterrà il risultato visivo che stavi cercando. Spessissimo mi capita di dover inserire larghezze o altezze definendo anche bordi e padding, ma essendo il box-modeling alla base degli studi di qualsiasi webdesigner, credo sia superfluo (almeno per me) che Lint ogni volta me lo segnali come errore. Se sei alle primissime armi e non hai ancora affrontato questo tipo di tematiche, allora forse conviene che mantieni attiva questa opzione.

Box-sizing: “warning”

Questa proprietà annulla completamente il discorso fatto nel precedente paragrafo del box-model. Se si inserisce questa proprietà, non ha più senso l’errore sul box-model, in quanto il box-sizing consente di definire la width come valore che include anche bordi e padding. Utilizzandola però compare un warning che ti avverte che su IE6 e 7 non funziona. Per queste versioni comprometteresti seriamente l’intero layout. Solitamente la utilizzo solo in alcuni contesti e mai generalizzata ad intere porzioni di struttura. Se mi serve, la utilizzo in maniera mirata, cosi da tenere tutto sotto controllo anche per le versioni che non la supportano.

Compatible-vendor-prefixes: “warning”

Quando utilizzi i vendor prefix è d’obbligo inserire anche la versione standard di quella stessa proprietà. In caso contrario viene giustamente segnalato un warning. Senza entrare troppo nel dettaglio della cascata dei css, diciamo che l’ultima dichiarazione inserita ha priorità rispetto alla precedenti. Buona prassi è quella di inserire come ultima quella standard cosi che un domani sarà quella ad avere priorità rispetto alle altre col prefix.

Display-property-grouping: “true”

In base al tipo di valore associato alla proprietà display, alcune proprietà vengono ignorate dall’interprete. Se ad un elemento viene associato display inline è inutile settare anche l’altezza a quello stesso elemento. Lint ci segnala errore per tutte le proprietà assegnate a valori di display non coerenti.

Duplicate-background-images: “warning”

Le Url sono utilizzate spessissimo nei CSS per richiamare sorgenti di file esterni. Un caso tra tutti è l’utilizzo di immagini di background per i pulsanti. Se abbiamo più elementi html che utilizzano lo stesso background, è inutile richiamare quella risorsa N volte. Meglio definire una classe comune e applicare quella classe a tutti gli elementi.

Duplicate-properties: “true”

Le proprietà duplicate all’interno di una stesso blocco di dichiarazioni hanno senso se vengono utilizzate per attuare un workaround. Il classico esempio è quello del background in rgba. Lint consente proprietà duplicate a patto che vengano scritte una di seguito all’altra e nella giusta sequenza:

/*Codice corretto*/
.selettore{
    background: #fff;
    background: rgba(255, 255, 255, 0.5);
}

/*Errore di duplicazione*/
.selettore{
    background: #fff;
    color: #000;
    padding:10px;
    ...
    ...
    ...
    background: rgba(255, 255, 255, 0.5);
}

Tutto questo ha senso. Di solito per eseguire un workaround, le proprietà duplicate vengono messe una di seguito all’altra. Nel secondo caso è probabile che tu ti sia distratto e abbia inserito due volte il background per un copia e incolla errato o perchè lo hai scritto in due momenti differenti. Lint il secondo caso lo interpreta come errore.

Empty-rules: “true”

A volte può accadere che vengano lasciate regole vuote. Puo accadere ad esempio quando vengono fatti interventi successivi di manutenzione e prima della pubblicazione ci si dimentica di cancellare le occorrenze. Eliminarle semplifica il codice e riduce il numero di operazioni che il browser deve processare per renderizzare la pagina.

Errors: “true”

Gli errori ortografici e di sintassi sono sempre dietro l’angolo. Lint intercetta questa tipologia di anomalie del codice e giustamente ce lo segnala come errore. Si sa che quando una proprietà o un valore è scritto in maniera errata, il compilatore la ignora totalmente.

Fallback-colors: “warning”

Attenzione ai fallback mancanti. Lint ti avverte che una proprietà (es: rgba) non è funzionante ovunque e che forse sarebbe più corretto inserire un fallback per coprire anche i browser più obsoleti. Un codice cosi come segue non genererà errori:

.selettore {
    color: red;
    color: rgba(255, 0, 0, 0.5);
}

Floats: “warning”

Utilizzare troppi float, soprattutto se non hai sicurezza nel gestirli, può creare problemi nei layout. Il float, cosi come il position interrompe il flusso del documento alterando la posizione degli elementi a cui viene applicata questa regola. A cascata vengono coinvolti anche altri elementi che sono soggetti a regole ben precise. Ignorare le regole base dei float potrebbe portarti a commettere errori. Lint conteggia se utilizzi più di 10 float all’interno del documento. Un warning ti mette in guardia sul loro utilizzo, ma d’altronde se ne hai bisogno vanno usati!

Font-faces: “warning”

Anche in questo caso bisogna stare attenti nell’usare i webfont. Appesantiscono il rendering della pagina, e se ne utilizzi più di 5 lint ti avverte con un warning. Sono daccordo che utilizzare troppi webfont fa calare le performace e porta il design a perdere di identità. I font devono essere 2 o al massimo 3. Google webfont è un ottimo modo per utilizzarli.

Font-sizes: “warning”

Lint controlla il numero di volte che hai definito il font-size. Sono più di 10? Bhe allora forse devi rivedere la struttura del tuo CSS e definire delle classi da poter riutilizzare al momento opportuno.

Gradients: “warning”

Attenzione ad usare i gradienti in CSS, non vi è alcun supporto per la regola standard e Lint vi segnalerà un warning se mancano i vendor. Attualmente però le cose sono cambiate, vi è un ampio supporto da parte dei browser e a meno che non vogliate garantire la retro-compatibilità per i gradienti potete anche disattivare questa opzione.

IDs: “warning”

L’attributo ID è molto particolare in quanto unico all’interno di un documento HTML. In quanto tale è strettamente connesso all’elemento a cui viene associato. La prassi vuole che sia consigliabile utilizzare come selettore le classi, riutilizzabili per loro natura, cosi da rendere il codice più riusabile. Ovviamente dipende anche da caso a caso, se sono sicuro che quell’ID verrà usato unicamente per quell’elemento allora possiamo in maniera abbastanza tranquilla, selezionarlo nel CSS tramite ID. Utilissimi lato javascript per identificare univocamente un elemento all’interno del DOM, a volte tornano utili anche nel CSS.

Import: “warning”

La regola @import serve per includere un css all’interno di un altro. Evitare assolutamente questa pratica. Meno risorse vengono scaricate più veloce sarà il render del proprio sito. Una delle soluzioni è quella di usare SASS che gestisce in maniera intelligente le chiamate con keyword @import prendendo i file che vuoi importare e combinandoli insieme in modo da poter servire un singolo file CSS al browser.

!important: “warning”

La notazione !important aggiunge specificità alla dichiarazione annullando le regole basi della cascata. Se ne utilizzi troppe senza avere il controllo totale della situazione potresti trovarti in difficoltà. Lint segnala un warning nel caso trova l’important, se però all’interno del file ne trova piu di 10, allora ti verrà segnalato un errore. Personalmente so a cosa vado incontro ogni volta che uso un !important ed è per me inutile un avvertimento del genere.

Known-properties: “true”

Il numero di proprietà CSS cresce giorno dopo giorno. Gli errori di ortografia sono dietro l’angolo. Lint si occupa di segnalare eventuali proprietà e corrispondenti valori non riconosciuti a patto che non siano precedute da un vendor-prefix.

Outline-none: “warning”

L’outline è fondamentale per coloro che navigano il web da tastiera. Eliminarlo è un errore e potrebbe rendere un sito non accessibile.

Overqualified-elements: “warning”

Ridurre il numero di selettori overqualified, rende il CSS più performante. Una dichiarazione del genere rende il css inutilmente ridondante riducendo le performance che un selettore più snello potrebbe avere.

body div.classe {
    color: red;   
}

Qualified-headings: “warning”

Gli stili dei titoli dovrebbero essere definiti in maniera generica all’inizio del CSS e dovrebbero avere uno stile coerente e uniforme all’interno di tutto il sito web. Definirli in relazioni a particolari aree del sito potrebbe mandare Lint in errore:

/* Non buono */
.box h3 {
    font-weight: normal;
}

/* Buono */
h3 {
    font-weight: normal;
}

Regex-selectors: “warning”

Spesso i selettori CSS assomigliano molto ad espressioni regolari. Lint ci avverte che utilizzare certi operatori può inficiare sulle performance. Sono stati scritti interi libri sulle performance dei CSS ma ci limitiamo a precisare di essere il più lineare possibile nello scrivere una regola. Regole del genere non sono sinonimo di performance:

.selettore[class~=xxx]{
    color: red;
}

.selettore[class^=xxx]{
    color: red;
}

.selettore[class|=xxx]{
    color: red;
}

.selettore[class$=xxx]{
    color: red;
}

.selettore[class*=xxx]{
    color: red;
}

Shorthand: “warning”

Attenzione alla notazione abbreviata. E’ sempre un bene utilizzarla. Una situazione del genere può essere facilmente ottimizzata:

.selettore{
    margin-top:5px;
    margin-right:10px;
    margin-bottom:7px;
    margin-right:10px;    
}

.selettore{
    margin:5px 10px 7px;
}

Star-property-hack & Underscore-property-hack: “warning”

Sono entrambi hack molto famosi e diffusi tra noi frontender. Li ho usati anche io in molte occasioni. Per chi non li conoscesse, consentono di scrivere una proprietà e renderla valida solo per alcune versioni di IE. Il CSS è il seguente:

/* Don't try this at home */
.selettore{
    width:200px;
    border:1px solid red;
    
    *width:210px; /* solo per IE7 e precedenti */
    _border:1px solid green; /* solo per IE6 e precedenti */
}

Lint (e non solo lui) è contrario a questo tipo di pratiche. Si preferisce sempre creare un CSS ad-hoc ed includerlo tramite commenti condizionali, pratica ben più consolidata e affidabile.

Negative text-indent: “warning”

Il text-indent negativo, largamente utilizzato per le tecniche di image replacement, è segnalato come warning. Spesso e volentieri vengono settati valori negativi in px molto elevati per nascondere il testo al di fuori dell’area visibile dall’utente. Fatti una ripassata delle tecniche. Una scrollbar orizzontale molto lunga potrebbe comparire per pagine la cui lettura va da destra verso sinitra. Si può fixare il tutto aggiungendo direction: ltr alla regola che presenta questa tecnica.

Unique-headings: “warning”

Il contesto in cui viene posto un elemento titolo spesso definisce la formattazione dello stesso. I titoli, come detto in precedenza, dovrebbero essere definiti in un unico punto e garantire la loro caratteristica intrinseca di essere elementi atomi all’interno dell’ecosistema sito web.

Universal-selector: “warning”

Il selettore universale, intercetta tutti gli elementi. Sebbene spesso conveniente per la selezione di un gruppo di elementi, il selettore universale provoca problemi di prestazioni quando viene usato come parte fondamentale (estrema destra) di un selettore.

.selettore * {
    ...
}

Vendor-prefix: true

Se vuoi ottenere lo stesso risultato indifferentemente dal browser utilizzato dall’utente, conviene che i vendor-prefix vengano utilizzati. Usarli significa rendere il CSS più verboso ma lo rendono sicuramente a prova di browser. Una situazione del genere potrebbe andare in errore:

.selettore {
    -moz-border-radius: 5px;
}

Zero-units: “warning”

E’ molto semplice. Quando inserisci un valore pari a 0, non inserire mai unità di misura. Se un valore è 0 lo sarà a prescindere dall’unità. Non è quindi necessario inserirle.

.selettore {
    border-width: 5px;
    width: 0;
}

Conclusioni

CSS Lint è un ottimo strumento. L’esperienza mi ha confermato molti dei dubbi che avevo e alcuni del molti warning potrebbero tranquillamente essere disattivati perché poco utili al fine ultimo di rendere il CSS il più snello e performante possibile. Spesso risulterà difficile seguire alla lettera tutte le indicazioni e chiudere gli occhi su alcune cose non ti renderà un frontend peggiore. Cerca solo di analizzare le singole situazioni e valutare i pro e i contro, con una buona base teorica e molta pratica riuscirai a districarti agevolmente nella giungla del CSS. Ecco la Repo ufficile su GitHub

Search
Tags
Seleziona rubrica
Seleziona rubrica
Codice Github