Il modo in cui scriviamo CSS per i temi WordPress è nel mezzo di cambiamenti radicali. Di recente ho condiviso una tecnica per aggiungendo il supporto del tipo fluido in WordPress passando per theme.json, un nuovo file che WordPress ha spinto al massimo diventare una fonte centrale di verità per definire gli stili nei temi di WordPress che supportano le funzionalità di editing completo del sito (FSE).

Aspetta, no style.css file? Ce l'abbiamo ancora. Infatti, style.css is ancora un file obbligatorio nei temi a blocchi, sebbene il suo ruolo sia notevolmente ridotto alle metainformazioni utilizzate per la registrazione del tema. Detto questo, il fatto è che theme.json è ancora in fase di sviluppo attivo, il che significa che siamo in un periodo di transizione in cui potresti trovare stili definiti lì, in styles.css o anche a livello di blocco.

Quindi, che aspetto ha lo stile in questi giorni di WordPress FSE? Questo è ciò che voglio trattare in questo articolo. C'è una mancanza di documentazione per lo stile dei temi dei blocchi nel file Manuale per sviluppatori di temi WordPress, quindi tutto ciò che stiamo trattando qui è ciò che ho raccolto su dove sono attualmente le cose e sulle discussioni sul futuro dei temi di WordPress.

L'evoluzione degli stili di WordPress

Le nuove funzionalità di sviluppo incluse in WordPress 6.1 avvicinarci a un sistema di stili completamente definito theme.json, ma c'è ancora molto lavoro da fare prima di poterci appoggiare completamente. Un modo per avere un'idea di cosa accadrà nelle versioni future è usare il Plugin Gutenberg. È qui che le caratteristiche sperimentali vengono spesso esaminate a secco.

Un altro modo in cui possiamo avere un'idea di dove siamo è guardare l'evoluzione di temi WordPress predefiniti. Ad oggi, ci sono tre temi predefiniti che supportano la modifica dell'intero sito:

Ma non iniziare a fare trading con il CSS style.css per le coppie proprietà-valore JSON in theme.json ancora. Ci sono ancora regole di stile CSS che devono essere supportate theme.json prima di pensare di farlo. Le restanti questioni significative sono attualmente in discussione con l'obiettivo di spostare completamente tutte le regole di stile CSS theme.json e consolidare diverse fonti di theme.json in Interfaccia utente per l'impostazione di stili globali direttamente nel file Editor di siti WordPress.

Questo ci lascia in una posizione relativamente difficile. Non solo c'è nessun percorso chiaro per sovrascrivere gli stili dei temi, ma non è chiaro da dove provenga l'origine di quegli stili — è da diversi livelli di theme.json File, style.css, il plugin Gutenberg o da qualche altra parte?

Perché theme.json invece di style.css?

Ti starai chiedendo perché WordPress si sta muovendo verso una definizione di stili basata su JSON invece di un tradizionale file CSS. Ben Dwyer del team di sviluppo di Gutenberg spiega eloquentemente perché il theme.json approccio è un vantaggio per gli sviluppatori di temi.

Vale la pena leggere il post di Ben, ma la carne è in questa citazione:

L'override dei CSS, siano essi layout, preset o stili di blocco, rappresenta un ostacolo all'integrazione e all'interoperabilità: la parità visiva tra il frontend e l'editor diventa più difficile da mantenere, gli aggiornamenti ai blocchi interni possono entrare in conflitto con le sostituzioni. Il CSS personalizzato è, inoltre, meno portabile su altri temi a blocchi.

Incoraggiando gli autori del tema a utilizzare theme.json API ove possibile, la gerarchia degli stili definiti “base > tema > utente” può essere risolta correttamente.

Uno dei principali vantaggi dello spostamento di CSS in JSON è che JSON è un formato leggibile dalla macchina, il che significa che può essere esposto nell'interfaccia utente di WordPress Site Editor recuperando un'API, consentendo così agli utenti di modificare i valori predefiniti e personalizzare l'aspetto di un sito senza scrivendo qualsiasi CSS. Fornisce inoltre un modo per applicare uno stile ai blocchi in modo coerente, fornendo al contempo una struttura che crea livelli di specificità in modo tale che le impostazioni dell'utente abbiano la massima priorità su quelle definite in theme.json. Quell'interazione tra gli stili a livello di tema in theme.json e gli stili definiti dall'utente nell'interfaccia utente di Global Styles sono ciò che rende l'approccio JSON così attraente.

Gli sviluppatori mantengono la coerenza in JSON e gli utenti ottengono flessibilità con personalizzazioni senza codice. Questa è una vittoria per tutti.

Ci sono altri vantaggi, di sicuro, e Mike McAlister di WP Engine ne elenca diversi in questo thread di Twitter. Puoi trovare ancora più vantaggi in questo discussione approfondita sul blog Make WordPress Core. E dopo averlo letto, confronta i vantaggi dell'approccio JSON con i modi disponibili per definire e sovrascrivere gli stili nei temi classici.

Definizione di stili con elementi JSON

Abbiamo già visto molti progressi per quanto riguarda le parti di un tema theme.json è capace di acconciare. Prima di WordPress 6.1, tutto ciò che potevamo davvero fare era definire intestazioni e collegamenti. Ora, con WordPress 6.1, possiamo aggiungere pulsanti, didascalie, citazioni e titoli al mix.

E lo facciamo definendo elementi JSON. Pensa agli elementi come a singoli componenti che risiedono in un blocco di WordPress. Supponiamo di avere un blocco che contiene un'intestazione, un paragrafo e un pulsante. Quei singoli pezzi sono elementi, e c'è un elements oggetto in theme.json dove definiamo i loro stili:

{
  "version": 2,
  "settings": {},
  // etc.
  "styles": {
    // etc.
    "elements": {
        "button": { ... },
        "h1": { ... },
        "heading": { ... },
    },
  },
  "templateParts": {}
}

Un modo migliore per descrivere gli elementi JSON è come componenti di basso livello per temi e blocchi che non richiedono la complessità dei blocchi. Sono rappresentazioni di primitive HTML che non sono definiti in un blocco ma possono essere utilizzati tra i blocchi. Il modo in cui sono supportati in WordPress (e nel plugin Gutenberg) è descritto in Manuale dell'editor di blocchi e questo Tutorial completo di modifica del sito di Carolina Nymark.

Ad esempio, i collegamenti hanno uno stile in elements oggetto ma non sono un blocco a sé stante. Ma un collegamento può essere utilizzato in un blocco ed erediterà gli stili definiti nel file elements.link oggetto in theme.json. Tuttavia, ciò non incapsula completamente la definizione di un elemento, poiché alcuni elementi sono anche registrati come blocchi, come i blocchi Intestazione e Pulsante, ma tali blocchi possono ancora essere utilizzati all'interno di altri blocchi.

Ecco una tabella degli elementi attualmente disponibili per lo stile theme.json, per gentile concessione di Carolina:

Come puoi vedere, sono ancora i primi giorni e molte cose devono ancora passare dal plug-in Gutenberg a WordPress Core. Ma puoi vedere quanto sarebbe veloce fare qualcosa come lo stile di tutti i titoli in un tema a livello globale senza cercare selettori nei file CSS o DevTools.

Inoltre, puoi anche iniziare a vedere come la struttura di theme.json sorta di forme strati di specificità, che vanno da elementi globali (es headings) a singoli elementi (es h1) e stili a livello di blocco (es h1 contenuto in un blocco).

Ulteriori informazioni sugli elementi JSON sono disponibili in questa proposta Make WordPress ed questo biglietto aperto nel repository GitHub del plugin Gutenberg.

Specificità JSON e CSS

Continuiamo a parlare di specificità CSS. Ho accennato in precedenza che l'approccio JSON allo stile stabilisce una gerarchia. Ed è vero. Stili definiti su elementi JSON in theme.json sono considerati stili tema predefiniti. E tutto ciò che è impostato dall'utente nell'interfaccia utente di Stili globali sovrascriverà le impostazioni predefinite.

In altre parole: gli stili utente hanno più specificità rispetto agli stili di tema predefiniti. Diamo un'occhiata al blocco Button per avere un'idea di come funziona.

sto usando Tema vuoto, un tema WordPress vuoto senza stile CSS. Aggiungerò un blocco Button su una nuova pagina.

OK, sappiamo che WordPress Core viene fornito con uno stile leggero. Ora passerò al tema TT3 predefinito da WordPress 6.1 e lo attiverò. Se aggiorno la mia pagina con il pulsante, il pulsante cambia stile.

Puoi vedere esattamente da dove vengono questi nuovi stili nei TT3 theme.json file. Questo ci dice che gli stili degli elementi JSON hanno la precedenza sugli stili di WordPress Core.

Ora modificherò TT3 sovrascrivendolo con a theme.json file in un tema figlio, in cui il colore di sfondo predefinito del blocco Button è impostato su rosso.

Ma nota il pulsante di ricerca in quell'ultimo screenshot. Dovrebbe essere anche rosso, giusto? Ciò deve significare che ha uno stile a un altro livello se la modifica che ho apportato è a livello globale. Se vogliamo cambiare entrambi pulsanti, potremmo farlo a livello di utente utilizzando l'interfaccia utente degli stili globali nell'editor del sito.

Abbiamo cambiato il colore di sfondo di entrambi i pulsanti in blu e modificato anche il testo utilizzando l'interfaccia utente degli stili globali. Nota che il blu da lì ha la precedenza sugli stili del tema!

Il motore di stile

Questa è un'idea molto rapida, ma buona, di come viene gestita la specificità CSS nei temi dei blocchi di WordPress. Ma non è il quadro completo perché non è ancora chiaro where quegli stili sono generati. WordPress ha i suoi stili predefiniti che provengono da qualche parte, consumano i dati theme.json per ulteriori regole di stile e sovrascrive quelle con qualsiasi cosa impostata in Stili globali.

Questi stili sono in linea? Sono in un foglio di stile separato? Forse sono iniettati nella pagina in a ?

Ecco cosa c'è di nuovo Stile motore si spera che risolva. Lo Style Engine è una nuova API in WordPress 6.1 che ha lo scopo di portare coerenza nel modo in cui gli stili vengono generati e dove vengono applicati gli stili. In altre parole, prende tutte le possibili fonti di stile ed è singolarmente responsabile della corretta generazione degli stili a blocchi. Lo so, lo so. Ancora un'altra astrazione in cima ad altre astrazioni solo per creare alcuni stili. Ma avere un'API centralizzata per gli stili è probabilmente la soluzione più elegante dato che gli stili possono provenire da diversi posti.

Diamo solo una prima occhiata allo Style Engine. In effetti, ecco cosa è stato completato finora, secondo il biglietto:

• Controlla e consolida dove il codice genera CSS di supporto per i blocchi nel back-end in modo che vengano consegnati dallo stesso posto (anziché da più posti). Questo copre le regole CSS come margine, riempimento, tipografia, colori e bordi.
• Rimuovere gli stili ripetitivi specifici del layout e generare nomi di classi semantiche.
• Riduci il numero di tag di stile in linea che stampiamo sulla pagina per il supporto di blocchi, layout ed elementi.

Fondamentalmente, questa è la base per stabilire un'unica API che contenga tutte le regole di stile CSS per un tema, ovunque provengano. Pulisce il modo in cui WordPress inietterebbe gli stili inline precedenti alla 6.1 e stabilisce un sistema per i nomi delle classi semantiche.

Ulteriori dettagli sugli obiettivi a lungo ea breve termine di Style Engine possono essere trovati in questo Fai una discussione principale di WordPress. Puoi anche seguire il problema di tracciamento ed consiglio di progetto per ulteriori aggiornamenti.

Lavorare con elementi JSON

Abbiamo parlato un po' degli elementi JSON nel file theme.json file e come sono fondamentalmente primitive HTML per definire stili predefiniti per cose come intestazioni, pulsanti e collegamenti, tra gli altri. Ora, diamo un'occhiata in realtà utilizzando un elemento JSON e come si comporta in vari contesti di stile.

Gli elementi JSON generalmente hanno due contesti: il livello mondiale e la livello di blocco. Gli stili a livello globale sono definiti con una specificità inferiore rispetto a quella a livello di blocco per garantire che gli stili specifici del blocco abbiano la precedenza per coerenza ovunque vengano utilizzati i blocchi.

Stili globali per elementi JSON

Diamo un'occhiata al nuovo tema TT3 predefinito ed esaminiamo lo stile dei suoi pulsanti. Quello che segue è un copia-incolla abbreviato del TT3 theme.json file (ecco il codice completo) che mostra la sezione degli stili globali, ma puoi trovare il codice originale qui.

{
  "version": 2,
  "settings": {},
    // ...
  "styles": {
    // ...
    "elements": {
      "button": {
        "border": {
          "radius": "0"
        },
        "color": {
          "background": "var(--wp--preset--color--primary)",
          "text": "var(--wp--preset--color--contrast)"
        },
        ":hover": {
          "color": {
            "background": "var(--wp--preset--color--contrast)",
            "text": "var(--wp--preset--color--base)"
          }
        },
        ":focus": {
          "color": {
            "background": "var(--wp--preset--color--contrast)",
            "text": "var(--wp--preset--color--base)"
          }
        },
        ":active": {
          "color": {
            "background": "var(--wp--preset--color--secondary)",
            "text": "var(--wp--preset--color--base)"
          }
        }
      },
      "h1": {
        "typography": { }
      },
      // ...
      "heading": {
        "typography": {
          "fontWeight": "400",
          "lineHeight": "1.4"
      }
      },
      "link": {
        "color": {
          "text": "var(--wp--preset--color--contrast)"
        },
        ":hover": {
          "typography": {
            "textDecoration": "none"
          }
        },
        ":focus": {
          "typography": {
            "textDecoration": "underline dashed"
          }
        },
        ":active": {
          "color": {
            "text": "var(--wp--preset--color--secondary)"
          },
          "typography": {
            "textDecoration": "none"
          }
        },
        "typography": {
          "textDecoration": "underline"
        }
      }
     },
    // ...
  },
  "templateParts": {}
}

Tutti i pulsanti hanno uno stile a livello globale (styles.elements.button).

Possiamo confermarlo anche in DevTools. Si noti che una classe ha chiamato .wp-element-button è il selettore. La stessa classe viene utilizzata anche per lo stile degli stati interattivi.

Ancora una volta, questo stile sta accadendo a livello globale, proveniente da theme.json. Ogni volta che utilizziamo un pulsante, avrà lo stesso sfondo perché condividono lo stesso selettore e nessun'altra regola di stile lo sovrascrive.

Per inciso, WordPress 6.1 ha aggiunto supporto per lo stile degli stati interattivi per determinati elementi, come pulsanti e collegamenti, utilizzando pseudo-classi in theme.json - Compreso :hover, :focuse :active — o l'interfaccia utente di Stili globali. Ingegnere automatico Dave Smith dimostra questa caratteristica in un video di YouTube.

Potremmo sovrascrivere il colore di sfondo del pulsante sia in theme.json (preferibilmente in un tema figlio poiché stiamo utilizzando un tema WordPress predefinito) o nelle impostazioni Stili globali nell'editor del sito (non è necessario alcun tema figlio poiché non richiede una modifica del codice).

Ma poi i pulsanti cambieranno tutto in una volta. E se volessimo sovrascrivere il colore di sfondo quando il pulsante fa parte di un determinato blocco? È qui che entrano in gioco gli stili a livello di blocco.

Stili a livello di blocco per gli elementi

Per capire come possiamo utilizzare e personalizzare gli stili a livello di blocco, cambiamo il colore di sfondo del pulsante che è contenuto nel blocco Cerca. Ricorda, c'è un blocco Button, ma quello che stiamo facendo è sovrascrivere il colore di sfondo a livello di blocco del blocco di ricerca. In questo modo, stiamo solo applicando il nuovo colore lì invece di applicarlo globalmente a tutti i pulsanti.

Per fare ciò, definiamo gli stili su styles.blocks oggetto in theme.json. Esatto, se definiamo gli stili globali per tutti i pulsanti attivi styles.elements, possiamo definire gli stili specifici del blocco per gli elementi del pulsante styles.block, che segue una struttura simile:

{
  "version": 2,
  // ...
  "styles": {
    // Global-level syles
    "elements": { },
    // Block-level styles
    "blocks": {
      "core/search": {
        "elements": {
          "button": {
            "color": {
              "background": "var(--wp--preset--color--quaternary)",
              "text": "var(--wp--preset--color--base)"
            }
          }
        },
        // ...
      }
    }
  }
}

Guarda quello? Ho impostato il background ed text proprietà su styles.blocks.core/search.elements.button con due variabili CSS preimpostate in WordPress.

Il risultato? Il pulsante di ricerca ora è rosso (--wp--preset--color--quaternary), e il blocco Button predefinito mantiene il suo sfondo verde brillante.

Possiamo vedere il cambiamento anche in DevTools.

Lo stesso vale se vogliamo dare uno stile ai pulsanti che sono inclusi in altri blocchi. E i pulsanti sono solo un esempio, quindi diamo un'occhiata a un altro.

Esempio: stilizzare le intestazioni a ogni livello

Portiamo a casa tutte queste informazioni con un esempio. Questa volta, noi:

• Dai uno stile a tutte le intestazioni a livello globale
• Disegna tutti gli elementi dell'Intestazione 2
• Stile Intestazione 2 elementi nel blocco Query Loop

Innanzitutto, iniziamo con la struttura di base per theme.json:

{
  "version": 2,
  "styles": {
    // Global-level syles
    "elements": { },
    // Block-level styles
    "blocks": { }
  }
}

Questo stabilisce lo schema per i nostri stili globali e a livello di blocco.

Dai uno stile a tutte le intestazioni a livello globale

Aggiungiamo il headings obiettare ai nostri stili globali e applicare alcuni stili:

{
  "version": 2,
  "styles": {
    // Global-level syles
    "elements": {
      "heading": {
        "color": "var(--wp--preset--color--base)"
      },
    },
    // Block-level styles
    "blocks": { }
  }
}

Ciò imposta il colore per tutte le intestazioni sul colore di base preimpostato in WordPress. Cambiamo anche il colore e la dimensione del carattere degli elementi dell'intestazione 2 a livello globale:

{
  "version": 2,
  "styles": {
    // Global-level syles
    "elements": {
      "heading": {
        "color": "var(--wp--preset--color--base)"
      },
      "h2": {
        "color": "var(--wp--preset--color--primary)",
        "typography": {
          "fontSize": "clamp(2.625rem, calc(2.625rem + ((1vw - 0.48rem) * 8.4135)), 3.25rem)"
        }
      }
    },
    // Block-level styles
    "blocks": { }
  }
}

Ora, tutti gli elementi dell'Intestazione 2 sono impostati per essere il colore predefinito principale con a dimensione del carattere fluida. Ma forse vogliamo una fissa fontSize per l'elemento Heading 2 quando viene utilizzato nel blocco Query Look:

{
  "version": 2,
  "styles": {
    // Global-level syles
    "elements": {
      "heading": {
        "color": "var(--wp--preset--color--base)"
      },
      "h2": {
        "color": "var(--wp--preset--color--primary)",
        "typography": {
          "fontSize": "clamp(2.625rem, calc(2.625rem + ((1vw - 0.48rem) * 8.4135)), 3.25rem)"
        }
      }
    },
    // Block-level styles
    "blocks": {
      "core/query": {
        "elements": {
          "h2": {
            "typography": {
              "fontSize": 3.25rem
            }
          }
        }
      }
    }
  }
}

Ora abbiamo tre livelli di stili per gli elementi dell'Intestazione 2: tutte le intestazioni, tutti gli elementi dell'Intestazione 2 e gli elementi dell'Intestazione 2 che vengono utilizzati nel blocco Query Loop.

Esempi di temi esistenti

Sebbene in questo articolo abbiamo esaminato solo gli esempi di stile per pulsanti e intestazioni, WordPress 6.1 supporta lo stile di elementi aggiuntivi. C'è una tabella che li delinea nel "Definizione di stili con elementi JSON" .

Probabilmente ti starai chiedendo quali elementi JSON supportano quali proprietà CSS, per non parlare di come le dichiareresti. Mentre aspettiamo la documentazione ufficiale, le migliori risorse che abbiamo saranno le theme.json file per i temi esistenti. Fornirò collegamenti a temi in base agli elementi che personalizzano e indicherò quali proprietà sono personalizzate.

Assicurati di dare ciascuno theme.json archiviare una buona occhiata perché questi temi includono eccellenti esempi di stile a livello di blocco sul file styles.blocks oggetto.

Concludendo

Le frequenti modifiche all'editor completo del sito stanno diventando a principali fonti di irritazione per molte persone, Compreso utenti Gutenberg esperti di tecnologia. Anche le regole CSS molto semplici, che funzionano bene con i temi classici, non sembrano funzionare per i temi a blocchi a causa di nuovi livelli di specificità abbiamo coperto prima.

Per quanto riguarda a Proposta GitHub per riprogettare l'editor del sito in una nuova modalità browser, Sara Gooding scrive in un post di WP Tavern:

È facile perdersi mentre si cerca di aggirare l'Editor del sito a meno che non si lavori giorno e notte all'interno dello strumento. La navigazione è turbolenta e confusa, specialmente quando si passa dalla navigazione del modello alla modifica del modello alla modifica dei singoli blocchi.

Anche come appassionato primo pilota nel mondo dell'editor di blocchi Gutenberg e dei temi block-eye, ho tonnellate delle mie stesse frustrazioni. Sono ottimista, tuttavia, e prevedo che l'editor del sito, una volta completato, sarà uno strumento rivoluzionario sia per gli utenti che per gli sviluppatori di temi esperti di tecnologia. Questo tweet di speranza già lo conferma. Nel frattempo, sembra che dovremmo prepararci a ulteriori cambiamenti, e forse anche a una corsa accidentata.

Riferimenti

Sto elencando tutte le risorse che ho utilizzato durante la ricerca di informazioni per questo articolo.

elementi JSON

Stili globali

Stile motore

Grazie per aver letto! Mi piacerebbe sentire le tue riflessioni sull'utilizzo dei temi dei blocchi e su come gestisci i tuoi CSS.