# Cascade layers con un reset: l'ordine che toglie gli !important

@layer decide l'ordine di vittoria prima della specificità, così un reset non richiede più !important. L'ordine corretto e i tre casi in cui non basta.

> Pagina: https://ui.eneawork.it/blog/css-layer-reset
> Markdown: https://ui.eneawork.it/blog/css-layer-reset.md

*2026-11-01*

Risposta breve: @layer decide l'ordine di vittoria delle regole prima della specificità, quindi un reset in uno strato inferiore non richiede più !important. Quattro strati dichiarati in testa al foglio sostituiscono gran parte dei workaround.

Il catalogo EneUI misura 111.985 componenti, 1.556 blocchi e 12.808 icone da 1.472 librerie, valori letti da /api/stats il 1 novembre 2026. L'ordine degli strati è stato verificato nel pannello Styles di DevTools su Chrome, Firefox e Safari correnti: le regole compaiono raggruppate per strato. Il comando sotto si esegue in locale.

## L'ordine è la regola

Lo strato dichiarato per primo perde. Non conta dove scrivi la regola nel file, conta l'ordine della prima dichiarazione di ogni nome: una riga @layer reset, tokens, base, components, utilities; in testa al foglio fissa tutto il resto.

@layer reset, tokens, base, components, utilities; @layer reset { *, *::before, *::after { box-sizing: border-box; } body { margin: 0; } img { display: block; max-width: 100%; } :where(h1, h2, h3) { margin: 0; font-size: inherit; font-weight: inherit; } } @layer tokens { :root { --radius: 0.5rem; } } @layer base { body { font: 1rem/1.6 system-ui, sans-serif; } } @layer components { .btn { font-weight: 600; } }

Il reset dentro reset perde contro .btn dentro components anche quando il selettore del reset è più specifico. Questo è il guadagno: la specificità smette di essere il criterio con cui si litiga.

## Dove un reset a strati va in crisi

Il supporto copre Chrome 99, Firefox 97 e Safari 15.4. Non ha senso un polyfill: su un browser che non conosce @layer le regole restano valide, perdono solo l'ordine garantito.

## Il limite

Gli strati non risolvono i conflitti dentro lo stesso strato: lì torna la specificità. Un reset scritto con :where() ha specificità zero e resta sotto controllo; un reset con selettori lunghi riporta il problema dentro lo strato basso, dove è più difficile da vedere.

## Come verificarlo

## Dove continuare

Nel catalogo: componenti shadcn, componenti e blocchi. Le guide: cosa è Tailwind CSS e tematizzare shadcn; il confronto: Tailwind contro CSS Modules.

## FAQ

### Devo riscrivere tutto il CSS?

No. Basta dichiarare gli strati in testa e spostare un foglio alla volta: il codice fuori dagli strati continua a funzionare e vince, quindi il passaggio è graduale.

### Come convivono con Tailwind?

Tailwind vive in uno strato suo, di solito utilities. Il reset va in uno strato precedente: così una classe del componente vince sulla base senza !important.

### L'ordine cambia se importo un foglio dopo?

No, se gli strati sono già dichiarati. L'ordine vale dalla prima dichiarazione: un @import successivo entra nello strato che nomina, non in cima.

### Gli strati annullano :where()?

No, sono strumenti diversi. Lo strato decide fra blocchi di regole, :where() azzera la specificità dentro un blocco. Si usano insieme.

### Perché il mio reset non vince su un componente?

Quasi sempre perché il CSS del componente non è stratificato: le regole fuori dagli strati battono ogni strato. Importalo con layer() o spostalo.