De manier waarop we CSS voor WordPress-thema's schrijven, bevindt zich midden in ingrijpende veranderingen. Ik heb onlangs een techniek gedeeld voor: ondersteuning voor vloeiende typen toevoegen in WordPress bij wijze van theme.json, een nieuw bestand dat WordPress is hard aan het pushen om een ​​centrale bron van waarheid te worden voor het definiëren van stijlen in WordPress-thema's die functies voor het bewerken van de volledige site (FSE) ondersteunen.

Wacht nee style.css het dossier? Dat hebben we nog steeds. In werkelijkheid, style.css is nog steeds een verplicht bestand in blokthema's, hoewel de rol ervan sterk wordt beperkt tot meta-informatie die wordt gebruikt voor het registreren van het thema. Dat gezegd hebbende, het feit is dat theme.json is nog steeds in actieve ontwikkeling, wat betekent dat we ons in een overgangsperiode bevinden waarin je stijlen kunt vinden die daar zijn gedefinieerd, in styles.css of zelfs op blokniveau.

Dus, hoe ziet styling er eigenlijk uit in deze WordPress FSE-dagen? Dat is wat ik in dit artikel wil behandelen. Er is een gebrek aan documentatie voor stijlblokthema's in de WordPress Thema Ontwikkelaars Handboek, dus alles wat we hier behandelen, is wat ik heb verzameld over waar de dingen momenteel zijn, evenals discussies over de toekomst van WordPress-thema's.

De evolutie van WordPress-stijlen

De nieuwe ontwikkelingsfuncties die zijn opgenomen in WordPress 6.1 brengt ons dichter bij een systeem van stijlen die volledig zijn gedefinieerd in theme.json, maar er is nog genoeg werk te doen voordat we er volledig op kunnen leunen. Een manier waarop we een idee kunnen krijgen van wat er in toekomstige releases komt, is door de Gutenberg-plug-in. Dit is waar experimentele functies vaak worden getest.

Een andere manier waarop we een idee kunnen krijgen van waar we zijn, is door te kijken naar de evolutie van standaard WordPress-thema's. Tot op heden zijn er drie standaardthema's die bewerking op de volledige site ondersteunen:

Maar begin niet met het inruilen van de CSS style.css voor JSON-eigenschap-waardeparen in theme.json net. Er zijn nog steeds CSS-stijlregels die moeten worden ondersteund in theme.json voordat we erover nadenken om dat te doen. De resterende belangrijke problemen worden momenteel besproken met het doel om alle CSS-stijlregels volledig te verplaatsen naar theme.json en consolideer verschillende bronnen van theme.json een UI voor het instellen van globale stijlen direct in de WordPress-site-editor.

Dat laat ons in een relatief moeilijke positie. Niet alleen is er geen duidelijk pad voor het overschrijven van themastijlen, maar het is onduidelijk waar de bron van die stijlen vandaan komt — komt het uit verschillende lagen van theme.json bestanden, style.css, de Gutenberg-plug-in of ergens anders?

Waarom theme.json in plaats van style.css?

Je vraagt ​​je misschien af ​​waarom WordPress op weg is naar een JSON-gebaseerde definitie van stijlen in plaats van een traditioneel CSS-bestand. Ben Dwyer van het Gutenberg-ontwikkelingsteam verwoordt welsprekend waarom de theme.json aanpak is een voordeel voor thema-ontwikkelaars.

Het is de moeite waard om Bens post te lezen, maar het vlees zit in dit citaat:

Het overschrijven van CSS, of het nu gaat om lay-out-, preset- of blokstijlen, vormt een obstakel voor integratie en interoperabiliteit: visuele pariteit tussen de frontend en editor wordt moeilijker te onderhouden, upgrades om internals te blokkeren kunnen conflicteren met overrides. Aangepaste CSS is bovendien minder overdraagbaar over andere blokthema's.

Door thema-auteurs aan te moedigen om te gebruiken theme.json API waar mogelijk kan de hiërarchie van "basis > thema > gebruiker" gedefinieerde stijlen correct worden opgelost.

Een van de belangrijkste voordelen van het verplaatsen van CSS naar JSON is dat JSON een machineleesbaar formaat is, wat betekent dat het kan worden weergegeven in de gebruikersinterface van de WordPress Site Editor door een API op te halen, waardoor gebruikers standaardwaarden kunnen wijzigen en het uiterlijk van een site kunnen aanpassen zonder helemaal geen CSS schrijven. Het biedt ook een manier om blokken consistent te stylen, terwijl het een structuur biedt die specifieke lagen creëert, zodat de gebruikersinstellingen de hoogste prioriteit hebben boven die gedefinieerd in theme.json. Dat samenspel tussen stijlen op themaniveau in theme.json en de door de gebruiker gedefinieerde stijlen in de Global Styles UI maken de JSON-aanpak zo aantrekkelijk.

Ontwikkelaars behouden consistentie in JSON en gebruikers krijgen flexibiliteit met aanpassingen zonder code. Dat is een win-win.

Er zijn zeker andere voordelen, en Mike McAlister van WP Engine somt er een aantal op in deze Twitter-thread. Hierin vind je nog meer voordelen diepgaande discussie op de Make WordPress Core-blog. En als je dat eenmaal hebt gelezen, vergelijk dan de voordelen van de JSON-aanpak met: de beschikbare manieren om stijlen in klassieke thema's te definiëren en te negeren.

Stijlen definiëren met JSON-elementen

We hebben al veel vooruitgang gezien wat betreft de onderdelen van een thema theme.json kan stylen. Vóór WordPress 6.1 konden we alleen koppen en links opmaken. Nu, met WordPress 6.1, we kunnen knoppen, bijschriften, citaten en koppen toevoegen aan de mix.

En dat doen we door te definiëren JSON-elementen. Zie elementen als individuele componenten die in een WordPress-blok leven. Stel dat we een blok hebben dat een kop, een alinea en een knop bevat. Die individuele stukken zijn elementen, en er is een elements bezwaar in theme.json waar we hun stijlen definiëren:

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

Een betere manier om JSON-elementen te beschrijven is als componenten op laag niveau voor thema's en blokken die niet de complexiteit van blokken nodig hebben. Het zijn representaties van HTML-primitieven die niet in een blok zijn gedefinieerd, maar over blokken kunnen worden gebruikt. Hoe ze worden ondersteund in WordPress (en de Gutenberg-plug-in) wordt beschreven in de Handboek voor blokeditor en dit Volledige zelfstudie over het bewerken van sites door Carolina Nymark.

Links zijn bijvoorbeeld gestileerd in de elements object, maar zijn geen blok op zich. Maar een link kan in een blok worden gebruikt en het zal de stijlen erven die zijn gedefinieerd op de elements.link bezwaar in theme.json. Dit vat de definitie van een element echter niet volledig samen, aangezien sommige elementen ook als blokken worden geregistreerd, zoals de blokken Heading en Button, maar die blokken kunnen nog steeds binnen andere blokken worden gebruikt.

Hier is een tabel met de elementen die momenteel beschikbaar zijn om in te stylen theme.json, met dank aan Carolina:

Zoals je kunt zien, is het nog vroeg en moet er nog veel worden verplaatst van de Gutenberg-plug-in naar WordPress Core. Maar je kunt zien hoe snel het zou zijn om iets te doen als alle koppen in een thema globaal te stylen zonder op zoek te gaan naar selectors in CSS-bestanden of DevTools.

Verder kun je ook beginnen te zien hoe de structuur van theme.json soort vormt lagen van specificiteit, gaande van globale elementen (bijv headings) naar afzonderlijke elementen (bijv h1), en stijlen op blokniveau (bijv h1 in een blok).

Aanvullende informatie over JSON-elementen is beschikbaar in: dit Maak WordPress voorstel en dit open ticket in de GitHub-repo van de Gutenberg-plug-in.

JSON- en CSS-specificiteit

Laten we het blijven hebben over CSS-specificiteit. Ik heb eerder gezegd dat de JSON-benadering van styling een hiërarchie tot stand brengt. En het is waar. Stijlen die zijn gedefinieerd op JSON-elementen in theme.json worden beschouwd als standaard themastijlen. En alles wat door de gebruiker is ingesteld in de gebruikersinterface van Global Styles, heeft voorrang op de standaardinstellingen.

Met andere woorden: gebruikersstijlen hebben meer specificiteit dan standaard themastijlen. Laten we eens kijken naar het knoppenblok om een ​​idee te krijgen hoe dit werkt.

ik gebruik Leeg thema, een leeg WordPress-thema zonder CSS-styling. Ik ga een Button-blok toevoegen op een nieuwe pagina.

OK, we weten dat WordPress Core wordt geleverd met een lichte styling. Nu ga ik overschakelen naar het standaard TT3-thema van WordPress 6.1 en het activeren. Als ik mijn pagina ververs met de knop, verandert de knop van stijl.

Je kunt precies zien waar die nieuwe stijlen vandaan komen in TT3's theme.json het dossier. Dit vertelt ons dat de JSON-elementstijlen voorrang hebben op WordPress Core-stijlen.

Nu ga ik TT3 wijzigen door het te overschrijven met a theme.json bestand in een child-thema, waarbij de standaard achtergrondkleur van het Button-blok is ingesteld op rood.

Maar let op de zoekknop in die laatste schermafbeelding. Het moet toch ook rood zijn? Dat moet betekenen dat het op een ander niveau is gestileerd als de verandering die ik heb aangebracht op mondiaal niveau is. Als we willen veranderen zowel knoppen, we zouden dit op gebruikersniveau kunnen doen met behulp van de Global Styles UI in de site-editor.

We hebben de achtergrondkleur van beide knoppen gewijzigd in blauw en ook de tekst aangepast met behulp van de gebruikersinterface voor algemene stijlen. Merk op dat het blauw vanaf daar voorrang had op de themastijlen!

De stijlmotor

Dat is een heel snel, maar goed idee van hoe CSS-specificiteit wordt beheerd in WordPress-blokthema's. Maar het is niet het volledige plaatje omdat het nog onduidelijk is WAAR die stijlen worden gegenereerd. WordPress heeft zijn eigen standaardstijlen die ergens vandaan komen, de gegevens in beslag nemen theme.json voor meer stijlregels, en overschrijft die met alles wat is ingesteld in Globale stijlen.

Zijn die stijlen inline? Staan ze in een aparte stylesheet? Misschien worden ze op de pagina geïnjecteerd in a ?

Dat is wat de nieuwe Stijl Motor gaat hopelijk oplossen. De Style Engine is een nieuwe API in WordPress 6.1 die bedoeld is om consistentie te brengen in hoe stijlen worden gegenereerd en waar stijlen worden toegepast. Met andere woorden, het neemt alle mogelijke bronnen van styling in beslag en is als enige verantwoordelijk voor het correct genereren van blokstijlen. Ik weet het. Nog een andere abstractie bovenop andere abstracties om maar enkele stijlen te creëren. Maar het hebben van een gecentraliseerde API voor stijlen is waarschijnlijk de meest elegante oplossing, aangezien stijlen uit een aantal plaatsen kunnen komen.

We krijgen alleen een eerste blik op de Style Engine. In feite is dit wat er tot nu toe is voltooid, volgens het kaartje:

• Controleer en consolideer waar de code blokondersteuning-CSS genereert in de backend, zodat ze vanaf dezelfde plaats worden afgeleverd (in tegenstelling tot meerdere plaatsen). Dit omvat CSS-regels zoals marge, opvulling, typografie, kleuren en randen.
• Verwijder repetitieve lay-outspecifieke stijlen en genereer semantische klassenamen.
• Verminder het aantal inline stijltags dat we naar de pagina printen voor blok-, opmaak- en elementondersteuning.

Kortom, dit is de basis voor het opzetten van een enkele API die alle CSS-stijlregels voor een thema bevat, waar ze ook vandaan komen. Het ruimt de manier op waarop WordPress inline-stijlen vóór 6.1 zou injecteren en stelt een systeem in voor semantische klassenamen.

Meer details over de langetermijn- en kortetermijndoelen van Style Engine vindt u in deze Maak een WordPress Core-discussie. Je kunt ook de . volgen volgprobleem en projectbord voor meer updates.

Werken met JSON-elementen

We hebben het een beetje gehad over JSON-elementen in de theme.json bestand en hoe ze in feite HTML-primitieven zijn voor het definiëren van standaardstijlen voor onder meer koppen, knoppen en koppelingen. Laten we nu eens kijken naar eigenlijk gebruik een JSON-element en hoe het zich gedraagt ​​in verschillende stijlcontexten.

JSON-elementen hebben over het algemeen twee contexten: de mondiaal niveau en blok niveau. De stijlen op globaal niveau zijn minder specifiek gedefinieerd dan op blokniveau om ervoor te zorgen dat blokspecifieke stijlen voorrang krijgen voor consistentie, waar blokken ook worden gebruikt.

Algemene stijlen voor JSON-elementen

Laten we eens kijken naar het nieuwe standaard TT3-thema en onderzoeken hoe de knoppen zijn gestyled. Het volgende is een verkorte copy-paste van de TT3 theme.json bestand (hier is de volledige code) met de sectie globale stijlen, maar je kunt de originele code hier vinden.

{
  "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": {}
}

Alle knoppen zijn gestileerd op globaal niveau (styles.elements.button).

We kunnen dit ook in DevTools bevestigen. Merk op dat een klasse genaamd .wp-element-button is de kiezer. Dezelfde klasse wordt ook gebruikt om de interactieve toestanden op te maken.

Nogmaals, deze styling gebeurt allemaal op mondiaal niveau, afkomstig van theme.json. Telkens wanneer we een knop gebruiken, heeft deze dezelfde achtergrond omdat ze dezelfde selector delen en er geen andere stijlregels zijn die deze overschrijven.

Even terzijde, WordPress 6.1 toegevoegd ondersteuning voor het opmaken van interactieve toestanden voor bepaalde elementen, zoals knoppen en links, met behulp van pseudo-klassen in theme.json - inclusief :hover, :focus en :active — of de gebruikersinterface voor algemene stijlen. Automatische ingenieur Dave Smith demonstreert deze functie in een YouTube-video.

We kunnen de achtergrondkleur van de knop overschrijven in theme.json (bij voorkeur in een child-thema omdat we een standaard WordPress-thema gebruiken) of in de Global Styles-instellingen in de site-editor (geen child-thema nodig omdat er geen codewijziging nodig is).

Maar dan veranderen de knoppen in één keer. Wat als we de achtergrondkleur willen overschrijven wanneer de knop deel uitmaakt van een bepaald blok? Dat is waar stijlen op blokniveau in het spel komen.

Stijlen op blokniveau voor elementen

Laten we, om te begrijpen hoe we stijlen op blokniveau kunnen gebruiken en aanpassen, de achtergrondkleur van de knop in het zoekblok wijzigen. Onthoud dat er een Button-blok is, maar wat we doen is de achtergrondkleur overschrijven op blokniveau van het Search-blok. Op die manier passen we de nieuwe kleur alleen daar toe in plaats van deze globaal op alle knoppen toe te passen.

Om dat te doen, definiëren we de stijlen op de styles.blocks bezwaar in theme.json. Dat klopt, als we de globale stijlen definiëren voor alle knoppen op styles.elements, we kunnen de blokspecifieke stijlen voor knopelementen definiëren op styles.block, die een vergelijkbare structuur volgt:

{
  "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)"
            }
          }
        },
        // ...
      }
    }
  }
}

Zie dat? ik zet de background en text eigenschappen op styles.blocks.core/search.elements.button met twee CSS-variabelen die vooraf zijn ingesteld in WordPress.

Het resultaat? De zoekknop is nu rood (--wp--preset--color--quaternary), en het standaard Button-blok behoudt zijn heldergroene achtergrond.

We kunnen de verandering ook in DevTools zien.

Hetzelfde geldt als we knoppen willen stylen die in andere blokken zijn opgenomen. En knoppen zijn slechts één voorbeeld, dus laten we eens kijken naar een ander voorbeeld.

Voorbeeld: koppen op elk niveau opmaken

Laten we al deze informatie naar huis rijden met een voorbeeld. Deze keer zullen we:

• Stijl alle koppen globaal
• Stijl alle elementen van Heading 2
• Stijlkop 2 elementen in het Query Loop-blok

Laten we eerst beginnen met de basisstructuur voor: theme.json:

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

Dit bepaalt de omtrek voor onze globale stijlen en stijlen op blokniveau.

Stijl alle koppen globaal

Laten we het toevoegen headings maak bezwaar tegen onze globale stijlen en pas enkele stijlen toe:

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

Dat stelt de kleur voor alle koppen in op de vooraf ingestelde basiskleur in WordPress. Laten we de kleur en lettergrootte van Kop 2-elementen ook op globaal niveau wijzigen:

{
  "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": { }
  }
}

Nu zijn alle elementen van Kop 2 ingesteld als de primaire vooraf ingestelde kleur met a vloeiende lettergrootte. Maar misschien willen we een vaste fontSize voor het Heading 2-element wanneer het wordt gebruikt in het Query Look-blok:

{
  "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
            }
          }
        }
      }
    }
  }
}

Nu hebben we drie niveaus van stijlen voor Kop 2-elementen: alle koppen, alle Kop 2-elementen en Kop 2-elementen die worden gebruikt in het Query Loop-blok.

Voorbeelden van bestaande thema's

Hoewel we in dit artikel alleen naar de stijlvoorbeelden voor knoppen en koppen hebben gekeken, ondersteunt WordPress 6.1 het opmaken van aanvullende elementen. Er is een tabel waarin ze worden beschreven in de “Stijlen definiëren met JSON-elementen” pagina.

Je vraagt ​​je waarschijnlijk af welke JSON-elementen welke CSS-eigenschappen ondersteunen, om nog maar te zwijgen over hoe je die zou declareren. Terwijl we wachten op officiële documentatie, zijn de beste bronnen die we hebben de theme.json bestanden voor bestaande thema's. Ik ga links naar thema's geven op basis van de elementen die ze aanpassen, en wijs erop welke eigenschappen zijn aangepast.

Geef ze zeker allemaal theme.json bestand een goede look, want deze thema's bevatten uitstekende voorbeelden van stijl op blokniveau op de styles.blocks voorwerp.

Afsluiten

Regelmatige wijzigingen in de editor voor de volledige site worden een belangrijke bronnen van irritatie bij veel mensen, waaronder technisch onderlegde Gutenberg-gebruikers. Zelfs zeer eenvoudige CSS-regels, die goed werken met klassieke thema's, lijken niet te werken voor blokthema's vanwege de nieuwe lagen van specificiteit we hebben het eerder behandeld.

Over een GitHub-voorstel om de site-editor opnieuw te ontwerpen in een nieuwe browsermodus, Sara Gooding schrijft in een WP Tavern-post:

Het is gemakkelijk om te verdwalen terwijl u de Site Editor probeert te omzeilen, tenzij u dag en nacht in de tool werkt. De navigatie is springerig en verwarrend, vooral als je gaat van het bladeren door sjablonen naar het bewerken van sjablonen en het wijzigen van individuele blokken.

Zelfs als een enthousiaste vroege rijder in de wereld van Gutenberg-blokeditor en blokoogthema's, heb ik heel veel van mijn eigen frustraties. Ik ben echter optimistisch en verwacht dat de site-editor, eenmaal voltooid, een revolutionair hulpmiddel zal zijn voor zowel gebruikers als technisch onderlegde thema-ontwikkelaars. Deze hoopvolle tweet bevestigt dat al. In de tussentijd lijkt het erop dat we ons moeten voorbereiden op meer veranderingen en misschien zelfs een hobbelige rit.

Referenties

Ik som alle bronnen op die ik heb gebruikt tijdens het onderzoeken van informatie voor dit artikel.

JSON-elementen

globale stijlen

Stijl Motor

Bedankt voor het lezen! Ik zou graag uw eigen reflecties horen over het gebruik van de blokthema's en hoe u uw CSS beheert.