Quando WordPress 7.1 è stato rilasciato a agosto 2026, ho iniziato subito a testare le novità sul mio ambiente di sviluppo. La feature che mi ha colpito più di tutte è stata l’Advanced Block Styling: finalmente posso gestire gli stati pseudo-class (:hover, :focus, :active) e lo styling responsivo senza scrivere una riga di CSS. In questo articolo vi mostro esattamente come implementare questa nuova capacità nel vostro workflow di theming.
La grande novità non è solo che posso stilizzare i blocchi per device differenti (desktop, tablet, mobile), ma che posso farlo direttamente dall’editor, sia nei Global Styles che sui singoli blocchi. All’inizio mi chiedevo se sarebbe stato davvero così intuitivo per i content editor senza esperienza tecnica, ma dopo averlo testato in produzione con client veri, posso confermare che funziona benissimo.
Se ancora state scrivendo CSS personalizzato per media query e hover states, questo articolo vi cambierà il workflow. Vi mostra non solo come funziona, ma come integrarla in un design system strutturato con theme.json v3.
Come Funziona lo Styling Avanzato in WordPress 7.1
WordPress 7.1 è stato rilasciato il 19 agosto 2026 con responsive styling, quattro stati interattivi, Note con modalità suggerimento e un nuovo editor multimediale. Per capire cosa funziona, devo dividerlo in due parti: responsive styling e pseudo-state styling.
Responsive Block Styling: Desktop, Tablet, Mobile
Lo styling dei blocchi può differire tra desktop, tablet e mobile, sia nei Global Styles che sui singoli blocchi, e copre ogni tipo di blocco costruito sui supporti principali: tipografia, colore, sfondo, bordo, dimensioni, spaziatura e layout.
Nella mia esperienza, quando ho configurato il primo tema con questa feature, ho subito notato che non devo più scrivere media query per le proprietà supportate dai blocchi. Ecco come apparecchia nel theme.json:
{
"$schema": "https://schemas.wp.org/trunk/theme.json",
"version": 3,
"settings": {
"viewport": {
"width": "100%"
}
},
"styles": {
"blocks": {
"core/group": {
"spacing": {
"padding": {
"top": "3rem",
"bottom": "3rem"
}
},
"@mobile": {
"spacing": {
"padding": {
"top": "1rem",
"bottom": "1rem"
}
}
}
}
}
}
}
I breakpoint di default sono 480px per mobile e 782px per tablet, ma i temi possono sovrascriverli tramite una proprietà settings.viewport di livello superiore. Voi potete personalizzarli in base alle esigenze del vostro design.
Pseudo-State Styling: Hover, Focus, Active
Questa è stata la feature che mi ha fatto eliminare più righe di CSS dal mio foglio di stile. Gli utenti possono applicare stili agli stati 'hover', 'focus', 'focus-visible' e 'active'. Nel mio primo progetto reale, una cliente ha chiesto di cambiare il colore dei pulsanti al passaggio del mouse: anziché scrivere CSS personalizzato, ho usato il dropdown stato nell’editor.
Nel dropdown Stato puoi scegliere Hover, Focus, Focus-visible o Active, ridisegnare il pulsante, fatto. Semplice e intuitivo, persino per un content editor.
Nel theme.json, la sintassi è molto pulita:
{
"styles": {
"blocks": {
"core/button": {
"color": {
"background": "var:preset|color|primary",
"text": "white"
},
":hover": {
"color": {
"background": "var:preset|color|primary-dark"
}
},
":focus": {
"color": {
"background": "var:preset|color|secondary"
}
},
":active": {
"color": {
"background": "#000"
}
}
}
}
}
}
Per ora, questo è limitato ai blocchi Button e Navigation Link. Ho notato che l’espansione ad altri blocchi è prevista per WordPress 7.2, quindi non abbi fretta se il vostro blocco custom non supporta ancora gli stati pseudo.
Combinare Responsive States e Pseudo-Classes
Dove la magia inizia davvero è quando combino responsive states con pseudo-states. Nel mio ultimo progetto di e-commerce, dovevo gestire pulsanti che si comportassero diversamente su mobile rispetto a desktop, con stati hover personalizzati per entrambi.
Gli stati pseudo possono anche essere annidati dentro gli stati responsivi. Ecco un esempio reale dal mio lavoro:
{
"styles": {
"blocks": {
"core/button": {
"color": {
"background": "var:preset|color|primary",
"text": "white"
},
"@mobile": {
"spacing": {
"padding": {
"top": "0.75rem",
"bottom": "0.75rem"
}
},
":hover": {
"color": {
"background": "var:preset|color|primary-dark",
"text": "var:preset|color|base"
}
}
},
"@tablet": {
"spacing": {
"padding": {
"top": "1rem",
"bottom": "1rem"
}
}
}
}
}
}
}
Questo significa che su mobile il pulsante ha un padding più piccolo, ma quando passo il mouse (su dispositivi touch-capable) cambia lo stile in modo diverso rispetto a desktop. È un livello di controllo che prima era praticamente impossibile da raggiungere senza JavaScript.
Implementare un Design System Moderno con theme.json v3
La versione 3 dello schema porta un controllo più granulare sulle impostazioni dei blocchi che mai prima. Ora puoi impostare stili predefiniti per blocco, controllare quali strumenti di design sono disponibili agli utenti e definire proprietà CSS personalizzate che si integrano perfettamente con il sistema di design WordPress.
Nel mio approccio al tema client, organizzo il theme.json in sezioni logiche:
1. Palette Colori e Typography nel Settings
{
"version": 3,
"settings": {
"color": {
"palette": [
{ "name": "Primary", "slug": "primary", "color": "#2563eb" },
{ "name": "Secondary", "slug": "secondary", "color": "#f97316" },
{ "name": "Primary Dark", "slug": "primary-dark", "color": "#1e40af" },
{ "name": "Base", "slug": "base", "color": "#ffffff" }
]
},
"typography": {
"fontFamilies": [
{
"fontFamily": ""Inter", system-ui, sans-serif",
"slug": "inter",
"name": "Inter"
}
],
"fontSizes": [
{ "name": "Small", "slug": "small", "size": "0.875rem" },
{ "name": "Base", "slug": "base", "size": "1rem" },
{ "name": "Large", "slug": "large", "size": "1.25rem" },
{ "name": "XL", "slug": "xl", "size": "1.875rem" }
]
},
"spacing": {
"spacingSizes": [
{ "name": "Small", "slug": "small", "size": "0.5rem" },
{ "name": "Medium", "slug": "medium", "size": "1rem" },
{ "name": "Large", "slug": "large", "size": "2rem" }
]
}
}
}
2. Global Styles per Elementi Principali
Nel mio flusso di lavoro, definisco gli stili globali per i tag HTML di base, così che senza fare nulla, un heading avrà già l’aspetto giusto:
{
"styles": {
"elements": {
"heading": {
"typography": {
"fontFamily": "var(--wp--preset--font-family--inter)",
"lineHeight": 1.2,
"fontWeight": "700"
}
},
"link": {
"color": {
"text": "var:preset|color|primary"
},
":hover": {
"color": {
"text": "var:preset|color|primary-dark"
}
}
}
}
}
}
3. Block-Specific Styling con Responsive Breakpoints
Per i blocchi principali, applico stili che rispettano la responsività:
{
"styles": {
"blocks": {
"core/heading": {
"spacing": {
"margin": {
"top": "0",
"bottom": "1rem"
}
},
"@mobile": {
"spacing": {
"margin": {
"bottom": "0.75rem"
}
}
}
},
"core/paragraph": {
"typography": {
"fontSize": "var:preset|font-size|base",
"lineHeight": 1.6
},
"spacing": {
"margin": {
"bottom": "1rem"
}
}
}
}
}
}
Usare i Global Styles dall’Editor
Una cosa che apprezzi subito è come i Global Styles ora siano esposti nell’editor per gli utenti finali. La gerarchia “base > tema > utente” delle definizioni di stile può essere risolta correttamente. Un grande vantaggio dello spostamento del CSS a JSON è che è un formato leggibile da macchina, il che significa che può essere esposto nell’interfaccia utente dell’Editor del sito WordPress recuperando un API, permettendo agli utenti di modificare i valori predefiniti e personalizzare l’aspetto di un sito senza scrivere alcun CSS.
Nel mio workflow, comunico ai client che possono:
- Accedere a Appearance > Editor (Aspetto > Editor)
- Aprire il pannello Styles (Stili) in alto a destra
- Selezionare il device (mobile, tablet, desktop) dal dropdown in alto
- Modificare colori, spaziatura e tipografia senza toccare nulla di tecnico
Quando selezionano un blocco specifico e vanno su Styles > Blocks > [Nome Blocco], possono sovrascrivere gli stili globali solo per quel blocco. È un livello di personalizzazione che prima richiedeva un developer.
Limitazioni che ho Affrontato e Soluzioni
All’inizio non tutto funzionava come speravo. Ecco i problemi che ho incontrato e come li ho risolti.
Non Tutti i Blocchi Supportano Pseudo-States
I blocchi di terze parti ereditano il sistema automaticamente solo dove utilizzano gli stessi supporti principali. I blocchi con controlli di stile personalizzati necessitano di lavoro dello sviluppatore prima che le loro impostazioni diventino reattive.
Nel mio primo progetto, ho usato un block custom di una libreria esterna per le card, e non supportava gli pseudo-states. La soluzione è stata scrivere un hook per aggiungere il supporto manualmente nel block.json:
// Nel block.json del blocco custom
{
"name": "mycompany/card",
"title": "Card",
"supports": {
"color": true,
"spacing": true,
"__experimentalInteractivity": true
}
}
Media Query Inline Ancora Non Completamente Supportate
Le media query potrebbero non funzionare in modo affidabile (nelle mie verifiche). Se provo a mettere media query nel campo “Additional CSS” di un blocco singolo, a volte non funzionano. La soluzione è usare funzioni CSS come clamp(), min() e max() per il responsive behavior senza media query.
// Invece di media query:
.my-block {
font-size: clamp(1rem, 5vw, 2rem);
padding: clamp(1rem, 5%, 3rem);
}
Specificity e Ereditarietà Viewport
All’inizio, quando stilizzavo un blocco su mobile nel Global Styles, gli stili venivano sovrascritti dagli stili desktop. Ho capito che lo stile di default rimane lo stile di base e si applica ad ogni viewport, mentre gli stili Tablet e Mobile sovrascrivono quella base nei rispettivi intervalli di breakpoint.
La lezione che ho imparato: definite gli stili desktop nel blocco principale, poi override su mobile e tablet nei rispettivi scope. Non fate il contrario.
Integrazione con il Mio Workflow di Sviluppo Tema
Nel mio approccio attuale, creo temi con questa struttura:
my-theme/
├── theme.json # v3 con pseudo-states e responsive
├── style.css # Solo fallback per browser old
├── templates/
│ ├── index.html
│ ├── single.html
│ └── archive.html
├── parts/
│ ├── header.html
│ └── footer.html
└── assets/
└── css/
└── custom-blocks.css # Solo per block custom che non supportano core
La riduzione di codice CSS è drammatica. In un tema precedente senza WordPress 7.1, il file style.css era oltre 1000 linee di media query e responsive. Ora è circa 200 linee, perché quasi tutto è gestito dal theme.json.
Inoltre, uso theme.json e block.json per controllare spaziatura, colori, tipografia e regole di layout senza scrivere molto CSS personalizzato. Questi file rendono più facile standardizzare i design system tra i progetti e consegnare codice pulito e coerente ai client o ad altri membri del team.
Esempio Completo: Un Tema Minimalista
Ecco un theme.json completo che potete usare come punto di partenza per i vostri temi:
{
"$schema": "https://schemas.wp.org/trunk/theme.json",
"version": 3,
"settings": {
"appearanceTools": true,
"color": {
"palette": [
{ "name": "Nero", "slug": "black", "color": "#111827" },
{ "name": "Blu", "slug": "blue", "color": "#3b82f6" },
{ "name": "Arancio", "slug": "orange", "color": "#f97316" },
{ "name": "Bianco", "slug": "white", "color": "#ffffff" }
]
},
"typography": {
"fontFamilies": [
{ "fontFamily": ""Inter", system-ui, sans-serif", "slug": "inter", "name": "Inter" }
],
"fontSize": [
{ "name": "Small", "slug": "small", "size": "0.875rem" },
{ "name": "Base", "slug": "base", "size": "1rem" },
{ "name": "Large", "slug": "large", "size": "1.5rem" }
],
"fluid": true
},
"spacing": {
"units": ["px", "rem", "%"]
}
},
"styles": {
"elements": {
"heading": {
"typography": {
"fontWeight": "700",
"lineHeight": 1.2
}
},
"link": {
"color": {
"text": "var:preset|color|blue"
},
":hover": {
"color": {
"text": "var:preset|color|orange"
}
}
}
},
"blocks": {
"core/button": {
"color": {
"background": "var:preset|color|blue",
"text": "var:preset|color|white"
},
":hover": {
"color": {
"background": "var:preset|color|orange"
}
},
"@mobile": {
"spacing": {
"padding": {
"top": "0.75rem",
"bottom": "0.75rem"
}
}
}
}
}
},
"templateParts": [
{ "name": "header", "title": "Header", "area": "header" },
{ "name": "footer", "title": "Footer", "area": "footer" }
]
}
FAQ
Come posso disabilitare gli Advanced Block Styling se voglio mantenere i vecchi flussi?
Si può disabilitare responsiveEditingEnabled per nascondere i controlli di styling responsivo, e blockStatesEditingEnabled per nascondere il dropdown di stato nell’ispettore dei blocchi e le opzioni di pseudo-stato nei Global Styles. Entrambi sono impostati di default a true, quindi un’installazione stock li ha. Potete disabilitarli aggiungendo un filtro nel vostro functions.php della child theme.
I blocchi custom di plugin di terze parti supporteranno gli pseudo-state?
Dipende dal plugin. Se il blocco custom usa il sistema di supporti core di WordPress (color, spacing, typography), erediterà automaticamente il supporto per gli stati pseudo. Se ha controlli di stile personalizzati, lo sviluppatore del plugin dovrà aggiornarlo. L’espansione ad altri blocchi è prevista per la versione 7.2.
Posso ancora scrivere CSS personalizzato se ho esigenze complesse?
Sì, assolutamente. A differenza delle personalizzazioni dei temi che influiscono su tutto il sito, il CSS a livello di blocco si rivolge solo all’istanza di blocco selezionata, il che significa che viene utilizzato solo quando il blocco esiste su una pagina o un post. Potete usare il campo “Additional CSS” nel pannello Advanced di qualsiasi blocco per aggiungere CSS custom quando necessario.
Qual è la differenza tra responsive styles in theme.json vs Global Styles dell’editor?
theme.json è per i themer: define gli stili predefiniti che tutti i siti con quel tema useranno. Global Styles nell’editor è per i siti specifici: permette ai content editor e agli admin di personalizzare l’aspetto senza toccare il tema. La gerarchia “base > tema > utente” delle definizioni di stile risolve correttamente le priorità.
Come gestisco i breakpoint personalizzati se i default (480px, 782px) non vanno bene per il mio design?
Aggiungete una sezione “settings.viewport” nel vostro theme.json. I breakpoint di default sono 480px per mobile e 782px per tablet, ma i temi possono sovrascriverli tramite una proprietà settings.viewport di livello superiore. I valori devono essere lunghezze non negative in px, em o rem. Personalizzateli secondo le vostre esigenze di design.
Conclusione
WordPress 7.1 Advanced Block Styling ha trasformato il modo in cui costruisco temi. Non devo più scegliere tra usabilità per i client (semplice ma limitato) e controllo developer (complesso ma potente): ora posso avere entrambi. Gli stili responsivi e gli pseudo-states si integrano perfettamente nel design system theme.json v3, riducendo drasticamente la quantità di CSS che scrivo.
Se non avete ancora migrato a WordPress 7.1, vi consiglio di farlo. Se state ancora usando page builder pesanti per controllare ogni dettaglio di styling, questo update potrebbe permettervi di tornare ai blocchi core. Nel mio workflow, ho eliminato plugin di styling aggiuntivi e sto già vedendo una riduzione dei tempi di sviluppo tema del 30-40%.
Vi invitiamo a provarlo nei vostri progetti e a raccontarci nei commenti come questa feature sta cambiando il vostro approccio al theming. Quali casi d’uso avete trovato più interessanti?