Personal tools
css: riconoscere i problemi prima che sia troppo tardi

Smells like CSS spirit!

Dec 20, 2012

css: riconoscere i problemi prima che sia troppo tardi

Consigli su come individuare i limiti del proprio modo di scrivere css e riprogettarne l'approccio

Continua la rassegna di consigli per la lettura, questa volta non con un libro ma con un interessantissimo articolo nel quale mi sono imbattuto e che voglio condividere con voi.

Citiamo subito la fonte: Code smells in CSS.

L'articolo ha suscitato subito il mio interesse perché mi sono trovato nelle stesse condizioni dell'autore: lavorare per mesi in modo continuativo allo sviluppo frontend di progetti web di dimensioni rilevanti.

Nel lavoro di ogni giorno come sviluppatori css, ci si trova spesso di fronte a situazioni che non quadrano nel loro impianto progettuale: in questo articolo vengono mostrati alcuni esempi concreti di css che fanno percepire queste situazioni. Imparando a riconoscerle, possiamo riuscire a evitarle prima di arrivare a un punto di non ritorno.

Andiamo quindi a vedere nello specifico alcuni di questi passaggi di codice che possono essere la cartina di tornasole della qualità del css e della sua mantenibilità futura.

  • Disfare stili già impostati in precedenza
    Ogni volta che siamo costretti a rimuovere uno stile già dato in precedenza abbiamo un un piccolo sentore di bruciato nell'aria. Resettare uno stile, al di là dei css di inizializzazione come i reset css, ci fa pensare al fatto che, forse,  quello stile lo si era impostato troppo a monte nella cascata di ereditarietà connaturata al linguaggio css.

    Un bell'esempio pratico:

    h2{

    font-size:2em;

    margin-bottom:0.5em;

    padding-bottom:0.5em;

    border-bottom:1px solid #ccc;

    }

    .no-border{

    padding-bottom:0;

    border-bottom:none;

    }

    In questo caso, prima si definisce uno stile molto generico per gli h2, poi con una classe dal nome terribile si resettano alcune proprietà, utilizzando sostanzialmente un approccio sottrattivo.

    Il caso ideale sarebbe, invece:

    h2{

    font-size:2em;

    margin-bottom:0.5em;

    }
    .headline{

    padding-bottom:0.5em;

    border-bottom:1px solid #ccc;

    }

    Dimezzando il numero di righe di css si dà lo stile ai titoli di secondo livello; con una classe significativa si riprogetta l'approccio css in senso additivo, anziché dover rimuovere stili già dati precedentemente.

    Questa piccola osservazione sembrerebbe cosa di poco conto, ma se la trasliamo ad un vasto progetto web che coinvolge migliaia di righe di codice css, riusciamo a comprenderne tutto il potenziale. Questo approccio ci consentirebbe di ribaltare la prospettiva dello scrivere moltissimo css per raggiungere meno stile.

     

Gli altri segnali di fumo che ci indica Harry Roberts, autore dell'articolo, sono i seguenti (li accennerò brevemente senza entrare nel dettaglio, in modo che possiate approfondirli direttamente alla fonte):

  • Numeri magici
    sono i valori numerici utilizzati dentro al css solamente perché funzionano nella singola circostanza e risolvono momentaneamente il problema. Chi di noi non ha mai usato un numero magico, scagli la prima pietra! Spesso la fretta ci impone di trovare una soluzione veloce e che funzioni subito, ma se non estrapoliamo la specificità del numero magico dal contesto andremo incontro a problemi soprattutto quando dovremo spiegare ad altri sviluppatori il suo uso, o quando passerà del tempo e non riusciremo più a risalire al motivo del loro utlizzo. I numeri magici non sono affidabili, statene alla larga!, suggerisce l'autore
  • Selettori css eccessivamente qualificati
    Sono quei selettori che specificano anche l'elemento html al quale si riferiscono:

    ul.nav{}

    a.button{}

    div.header{}

    è molto evidente come tali selettori inibiscano il loro utilizzo su elementi html diversi da quelli specificati; aumentano la specificità, innalzando quindi anche i tempi di lavoro del browser nel gestire tale comando css composito. E' sempre necessario ridurre la specificità dei selettori per migliorarne la portabilità, per migliorare le performance e ridurre la quantità di codice
  • Valori assoluti hard coded
    Valori assoluti inseriti nel codice vanno sempre trattati con cautela e sospetto. Ci si deve sempre chiedere il perché del loro utilizzo e se non fosse stato meglio adottare una soluzione più flessibile verso il futuro
  • Forza bruta dei valori e dei selettori
    In fondo, è sempre lo stesso discorso: a volte si fa prima a forzare con valori precisi o aumentando la forza della specificità, ma ciò nasconde sempre una mancanza di comprensione più generale del singolo contesto e un approccio alla sua portabilità. La conoscenza solida tiene sempre alla larga dalla forza bruta
  • Selettori pericolosi
    Sono i selettori ad amplissimo spettro, che colpiscono tutti gli elementi di riferimento in tutti i contesti, cosa che implica il dover tenere sotto controllo gli elementi in ogni possibile contesto: es. div{ } "fai questo, div!" (perché? volete forse dirmi che voi non parlate con i vostri div??). Da qui l'assunto che selettori troppo generici possono provocare danni in contesti che attualmente non sono sotto un'attenzione vigile e costante
  • Direttiva !important reattiva
    Si sa che la direttiva !important deve essere usata solo in certe circostanze, ma soprattutto deve essere usata in modo proattivo e non in maniera reattiva, ovvero per vincere altri selettori troppo specifici e far funzionare le cose. Un esempio classico dell'uso proattivo sono le classi di errore con colorazione rossa, si sa sempre in anticipo che esse dovranno"vincere" sulle colorazioni neutre. L'uso reattivo è un sentore di puzza di bruciato, è l'aggiramento temporaneo di un problema forse relativo a un intero impianto progettuale css che presenta criticità.
  • Uso degli ID nei selettori css
    L'autore arriva ad affermare che gli id nel css non andrebbero mai usati. Mai. Andrebbero usati solamente come hook javascript o identificatori degli elementi html. Sappiamo bene che gli id sono univoci, utilizzabili solamente una volta nella pagina, identificano un elemento specifico invece di rivolgersi all'astrazione di una situazione più generica. Inoltre aumentano esponenzialmente la specificità dei selettori, per ogni id servirebbero 257 classi...
  • Nomi delle classi troppo vaghi o generici
    Nomi troppo vaghi o generici ci espongono invece a rischi di fraintendimento, non dichiarano immediatamente a quale precisa situazione si riferiscono con il rischio di accavallamenti di senso con situazioni simili ma diverse. L'autore cita ad esempio .card.

Concludendo: è vitale, quando si hanno per mesi sotto gli occhi migliaia di righe di codice css, tentare di estraniarsi dai contesti specifici e cercare di avere anche una visione al di sopra di tutto, che abbia cura dell'intero impianto progettuale.

E dato che parliamo di un linguaggio, personalmente ritengo che non basti soffermarsi solamente su due versi poetici azzeccati o su un fraseggio, ma occorre considerare sempre l'atto poetico nel suo insieme.

Filed under: ,
comments powered by Disqus