Scrivere un buon CSS

Pubblicato: 2016-10-17

Cerco sempre di imparare cose nuove. Tuttavia, cerco anche di imparare modi per migliorare il modo in cui già faccio le cose. Sia durante il mio concerto a tempo pieno che per i progetti collaterali dei clienti, la cosa su cui ho sempre voluto migliorare era il mio CSS. Mi sono sempre sentito abbastanza bravo quando si tratta di CSS, ma l'ho sempre trovato disordinato da leggere e spesso difficile da mantenere.

Quello che ho cercato di fare è scoprire cosa rende CSS buono, leggibile e manutenibile. Penso di aver escogitato (e trovato) alcuni modi per rendere tutto questo possibile.

I problemi

Ci sono molte cose che mi infastidiscono sui CSS. I fastidi più comuni che ho sono:

  • ripetizione del codice comune
  • prefissi del browser
  • mancanza di commenti
  • su selezionatori qualificati
  • nomi di classi povere

Quando si tratta dei miei progetti personali, mi assumo la piena responsabilità del mio codice. Raramente commento il mio CSS e spesso lo tratto come un ripensamento. È semplicemente sbagliato.

Per molto tempo ho pensato che i nomi delle mie classi fossero "semantica" e sono solo io a fare le cose, quindi non c'è bisogno di spiegare il codice, o piccoli "hack" o altro.

Tornare al codice su un progetto di vecchia data dimostra rapidamente che questa teoria è molto sbagliata.

Quando si tratta di codice al lavoro, non posso prendermi tutta la colpa. In effetti, parte del problema è il numero di persone che hanno messo le mani lì dentro. Attualmente il nostro team ha sette di noi che a un certo punto hanno scritto CSS per i nostri siti, con altri 6-8 che sono andati e venuti nel anni. Ogni membro del team ha diversi livelli di conoscenza e abilità riguardo ai CSS.

Inoltre, come spesso accade con i progetti di vecchia data, parte del codice è vecchio . Molto è pre-CSS3, o pre-qualunque-la-tendenza-era-cool-5-anni-fa. In entrambi i casi, c'erano spesso modi diversi di fare le cose nel momento in cui è stato scritto e, in alcuni casi, una naturale mancanza di conoscenza.

Ho anche appreso che alcuni programmatori insisteranno sul fatto che il loro codice è "auto-documentante". Se non hai familiarità con quel termine, si traduce in "il mio codice non ha commenti".

Soluzioni

Anche se nulla è perfetto, credo che ci siano cose che possiamo fare per migliorare il nostro codice. Ho scoperto le linee guida CSS di Harry Roberts tempo fa. È fedele alla promessa di "Consigli e linee guida di alto livello per scrivere CSS sani, gestibili e scalabili".

Commenti

Sebbene le linee guida CSS forniscano specifiche sugli stili di commento, personalmente cerco solo di inserire qualcosa per dirmi in futuro cosa stavo pensando. Inizio ogni componente con un commento che rappresenta il titolo, i dettagli sull'intento del componente.

Quando si utilizza un preprocessore, definisco commenti specifici da includere nel CSS o ignorati dal preprocessore. Sto ancora lavorando su questa parte e sto cercando di prendere l'abitudine di mettere qualcosa , qualsiasi cosa .

Orientamento agli oggetti

L'orientamento agli oggetti è un paradigma di programmazione che suddivide le grandi cose in piccole cose. Da Wikipedia:

La programmazione orientata agli oggetti (OOP) è un paradigma di programmazione che rappresenta il concetto di "oggetti" […] che di solito sono istanze di classi, [e] sono usati per interagire tra loro per progettare applicazioni e programmi per computer.

Quando si tratta di CSS, chiamiamo questo CSS orientato agli oggetti, o OOCSS . Il concetto di base rompe la struttura dell'elemento, dalla pelle dell'elemento. Ciò significa che possiamo facilmente riutilizzare qualsiasi modello di progettazione ricorrente, senza necessariamente riutilizzare contemporaneamente i dettagli di implementazione specifici. OOCSS si concentra fortemente sul riutilizzo del codice, che ci rende più veloci e può ridurre le dimensioni della nostra base di codice.

Penso ad aspetti strutturali come gli scheletri; frame comuni che danno costrutti noti come object . Questi oggetti sono modelli di design semplici e privi di qualsiasi cosmetico. Astraiamo la struttura da un insieme di componenti per avere un oggetto generico.

Quindi, opzionalmente, aggiungiamo il livello "pelle" alla nostra struttura in modo da poter dare alle astrazioni un aspetto e una sensazione specifici. Ad esempio (tratto dalle linee guida CSS):

 /**
 * Un oggetto pulsante semplice e senza design. Estendi questo oggetto con una skin `.btn--*`
 * classe.
 */
.btn {
    display: blocco in linea;
    imbottitura: 1em 2em;
    vertical-align: medio;
}

/**
 * Pelle dei pulsanti positivi. Estende `.btn`.
 */
.btn: positivo {
    colore di sfondo: verde;
    colore bianco;
}

/**
 * Pelle dei bottoni negativi. Estende `.btn`.
 */
.btn: negativo {
    colore di sfondo: rosso;
    colore bianco;
}

Qui vediamo come la classe .btn fornisce semplicemente una struttura a un elemento, ma non ha nulla riguardo ai cosmetici. Possiamo estendere .btn con una seconda classe, come .btn--positve per dare a quell'elemento uno stile più specifico:

 <button class="btn btn--positive">OK</button>

Preferisco di gran lunga usare più classi nel mio HTML, piuttosto che usare qualcosa come @extend in un preprocessore. Questo mi dà più visibilità nel mio HTML permettendomi di vedere rapidamente quali classi sono applicate al mio elemento. Significa anche che le mie classi non sono strettamente legate ad altri stili nel mio CSS. In un certo senso aiuta OOCSS a seguire i concetti di incapsulamento .

BEM

BEM ( Block, Element, Modifier ), è una metodologia front-end sviluppata da Yandex. BEM è in realtà una metodologia molto completa e onestamente non ho approfondito tutti i dettagli, ma quello che mi interessa è semplicemente la convenzione di denominazione.

Sto usando convenzioni di denominazione simili a BEM. Il concetto è lo stesso, ma la sintassi esatta potrebbe differire leggermente.

BEM suddivide le classi in tre gruppi:

  1. Blocco: la radice o la base di un componente
  2. Elemento: un componente all'interno di un Blocco
  3. Modificatore: una variazione o estensione del Blocco

Un'analogia molto semplice ( non un esempio):

 .cane {}
.dog__tail {}
.dog--piccolo {}

Gli elementi sono delimitati da due trattini bassi (__) e i modificatori sono delimitati da due trattini (–).

Nell'analogia sopra, vediamo che .dog è il Block, la radice dell'elemento. Quindi, .dog__tail è un elemento, è una parte più piccola di un blocco .dog . Infine, .dog--small è Modifier, una variazione specifica del Blocco .dog . Puoi anche applicare i modificatori agli elementi. ad esempio, potremmo avere .dog__tail--short per specificare nuovamente una variazione sull'elemento dog__tail .

In alcuni casi potrei volere più parole per blocchi, elementi o modificatori. In ogni caso, questi sono separati da un solo trattino (-) e le classi sono sempre scritte in minuscolo .

Preprocessori

Ho passato del tempo a inserire i preprocessori CSS nel mio flusso di lavoro e finora è stato incredibilmente prezioso. I preprocessori CSS prendono il codice scritto in un linguaggio preelaborato e lo convertono nel buon vecchio CSS. Non sono CSS, il che significa che non sono vincolati alle stesse regole e limitazioni dei CSS. Sebbene i CSS siano eccezionali, non sempre ci consentono di fare facilmente le cose che vorremmo fare.

Ad esempio, una cosa che sarebbe davvero interessante in CSS sono le variabili . Forse vuoi che qualcosa abbia il margine sinistro di un elemento uguale alla larghezza di un altro, e improvvisamente qualcuno decide che quei numeri devono cambiare. Poiché sono lo stesso numero e il tuo layout potrebbe fare affidamento su quel numero, devi cambiarlo in più di un posto. Ma con un varibale potresti cambiarlo in un solo posto e farlo riflettere nell'intero layout. Naturalmente, c'è molto di più nei preprocessori oltre alle semplici variabili, ma questo è un inizio!

Ovviamente non devi usare un preprocessore, ma penso che troverai la maggior parte delle persone che lo fanno, non torneranno indietro. So che non lo farò. Il guadagno in flessibilità e una maggiore leggibilità sono qualcosa a cui non posso rinunciare. Il semplice fatto di essere in grado di utilizzare variabili e mixin è sufficiente per tenermi agganciato.

Sono disponibili diversi preprocessori, ma gli unici due che ho davvero guardato e utilizzato sono LESS e SASS . Dai un'occhiata e considera di aggiungere uno di questi al tuo flusso di lavoro, non ti guarderai indietro.

Concludendo

Il mio vero punto qui, è che CSS può essere migliore. Tutto può essere migliore. Qualcuno mi ha detto di recente in un commento a un post su Reddit che "CSS non ha semantica". Non sono assolutamente d'accordo. CSS 100%, senza dubbio può essere semantico.

L'uso di OOCSS e BEM, infatti, conferisce al tuo CSS un significato molto semantico. Questo non significa che sia facile fin dall'inizio, ma vale la pena esplorarlo. Combinalo con i preprocessori CSS e hai il potenziale per CSS molto leggibili, manutenibili e scalabili .

Vorrei anche notare che questo non solo rende più leggibile il tuo CSS (preprocessato o meno), ma rende anche più leggibile il tuo HTML, applicando i nomi delle classi semantiche agli elementi.

TL; DR

Ok, forse era molto - per riassumere, scrivi CSS migliori in questo modo:

CSS orientato agli oggetti :

  • ogni classe fa una cosa: lo fa bene, lo fa bene

Nomi delle classi di stile Block, Element, Modifier (BEM) :

  • Blocco: .grid
  • Elemento: .grid__item (2 caratteri di sottolineatura)
  • Modificatore: .grid--wide (2 trattini)

I preprocessori sono fantastici :

  • dai un'occhiata: LESS – SASS
  • o trovarne altri: 8 preprocessori CSS per velocizzare i tempi di sviluppo