Con la crescita dei progetti, il CSS semplice soffre di ambito globale — ogni selettore compete globalmente, scoppia una guerra di specificità, e nessuno osa eliminare una regola. Le metodologie impongono struttura e convenzioni di naming per mantenere il CSS manutenibile.
Una convenzione di naming che rende le relazioni esplicite e mantiene la specificità piatta (tutte classi singole):
{ }
{ }
{ }
{ }
<div class="card card--featured">
<h2 class="card__title">...</h2>
</div>
Il valore di BEM: i nomi delle classi sono auto-documentanti, scoped per convenzione, e uniformemente a bassa specificità (senza guerre di annidamento/id).
Componi stili da piccolissime classi single-purpose direttamente nel markup:
<div class="flex items-center gap-4 p-6 rounded-lg shadow">...</div>
Pro: nessun naming, nessun CSS inutilizzato (rimosso), token di design coerenti. Contro: HTML verboso. Estremamente popolare per velocità e coerenza.
L'approccio moderno nei framework component — scopa gli stili a un componente in modo che non possano fuoriuscire:
import styles from "./Card.module.css"; // class names are hashed/localized
<div className={styles.card}>...</div> // → .Card_card__a1b2 (unique)
Questo risolve il problema dell'ambito globale meccanicamente piuttosto che per convenzione.
OOCSS — separate structure from skin, reuse objects
SMACSS — categorize rules (base, layout, module, state, theme)
ITCSS — layer CSS by specificity (generic → explicit), low to high
Tutti combattono i medesimi nemici: creeping di specificità, collisioni di naming, codice morto, e cascate impredittibili. Che sia tramite naming (BEM), utility (Tailwind), o scoping (Modules), mantengono il CSS prevedibile e sicuro da modificare in scala.
I grandi codice CSS collassano sotto l'ambito globale e le guerre di specificità senza disciplina.
Scegliere e applicare coerentemente una metodologia (comunemente BEM, Tailwind, o CSS Modules scoped oggi) è ciò che mantiene gli stili modulari, eliminabili, e conflict-free man mano che il team e il codice crescono.