Variabili e colori

Perché le variabili

Le custom properties CSS (--nome-valore) centralizzano colori, spaziature, raggi, font e durate animazione. Definisci i token una volta in :root e richiamali con var(--nome) nei componenti. Cambiare il brand o il tema scuro diventa questione di aggiornare pochi valori invece di cercare hex sparsi in migliaia di righe.

Definire i token

Scegli nomi semantici legati al ruolo, non al valore: --color-text-primary invece di --gray-800 se il grigio può cambiare tra temi. Raggruppa per famiglia (color, space, font, radius). Documenta in commento la scala spazi (es. --space-1 = 0.25rem).

:root {
  --color-text: #1a1a1a;
  --color-surface: #ffffff;
  --color-accent: #2563eb;
  --space-sm: 0.5rem;
  --space-md: 1rem;
  --font-body: "Source Sans 3", system-ui, sans-serif;
  --radius-md: 0.5rem;
}

.card {
  padding: var(--space-md);
  color: var(--color-text);
  background: var(--color-surface);
  border-radius: var(--radius-md);
}

Usare i token

Nei componenti usa sempre var(); riserva valori letterali a eccezioni documentate. Fornisci fallback: var(--font-body, sans-serif) se la variabile manca in un contesto legacy.

Temi e override

Per dark mode combina prefers-color-scheme con override in :root o attributo data-theme sul html. Evita duplicare interi fogli stile: cambia solo i token colore e ombre. Testa contrasto WCAG dopo ogni palette nuova.

Organizzazione nei file

Suddividi token in layer: primitivi (scale raw) e semantici (--color-text-primary che punta al primitivo). I componenti consumano solo semantici così un rebrand tocca poche righe. Con preprocessor puoi mappare Sass a custom properties per retrocompatibilità. Evita var(--x, var(--y, #000)) profonde: difficili da debuggare.

In code review rifiuta hex nuovi fuori dal file token. Strumenti stylelint possono vietare colori letterali nei partial component.

Per consolidare quanto hai letto, scegli due pagine reali del tuo sito e applica gli stessi criteri con il team: una modifica alla volta, verifica su mobile e annota nel registro interno data e responsabile. Così la lezione diventa pratica ricorrente e non un intervento una tantum prima di una campagna.

Verifica periodica

Programma ogni trimestre un controllo su pagine ad alto traffico: applica i criteri di Variabili e colori con la stessa procedura (browser, dispositivo, rete). Registra esito e responsabile in un foglio condiviso così il team non riparte da zero.

Se hai appena cambiato tema, plugin o builder, ripeti il controllo dopo 48 ore: cache CDN e minificazione possono mascherare errori finché non scade la vecchia versione. Coinvolgi chi scrive i contenuti, non solo chi sviluppa: molti problemi nascono da campi CMS lasciati vuoti.

Confronta i risultati con una pagina concorrente solo per capire gap di chiarezza, non per copiare testi. L’obiettivo è che un visitatore capisca in pochi secondi cosa offri e come contattarti.

Errori comuni

• Hex hardcoded nei componenti accanto ai token.
• Nomi token incoerenti (--primary vs --color-brand).
• Catene var() circolari che invalidano la proprietà.
• Token per ogni pixel invece di una scala ragionata.
• Dimenticare fallback su font stack critici.

In pratica, integra questo controllo nella routine di qualità del sito: una pagina campione al mese per categoria (home, servizio, articolo, checkout se presente), stesso profilo browser e rete. Annota nel registro interno data verifica e esito, così al prossimo redesign sai cosa è già stato validato. Quando il team cresce, una checklist condivisa evita che ognuno interpreti i criteri in modo diverso e riduce regressioni dopo deploy frettolosi.

Quando lavori con clienti o stakeholder non tecnici, traduci ogni raccomandazione in un esempio concreto sulla loro pagina: uno screenshot prima/dopo, una URL di prova, un tempo di caricamento misurato. Così le lezioni diventano azioni nel backlog invece di slide dimenticate. Riutilizza gli stessi criteri su ambienti preview prima della produzione e registra chi ha approvato il go-live, per tracciabilità in caso di regressione SEO o accessibilità.

Tieni un elenco di URL di riferimento nel tuo progetto e riapplicalo dopo ogni modifica al tema o al CMS, così non devi ricordare a memoria ogni regola.

In breve

• Token in :root, uso con var().
• Nomi semantici e scala documentata.
• Override locali per temi e sezioni.
• Niente magic numbers sparsi nel CSS.