Een van de hoofddoelen van de WordPress Site Editor (en ja, dat is nu de “Officiele naam) is om de basisstijl van blokken te verplaatsen CSS naar gestructureerde JSON. JSON-bestanden zijn machinaal leesbaar, waardoor ze kunnen worden gebruikt door de op JavaScript gebaseerde Site Editor voor het rechtstreeks in WordPress configureren van de globale stijlen van een thema.
Het is nog niet helemaal zover! Als we kijken naar het Twenty Twenty-Two (TT2) standaardthema, waren er twee belangrijke onopgeloste problemen: styling interacties (Leuk vinden :hover, :active, :focus), en de marges en opvulling van lay-outcontainers. Je kunt zien hoe die tijdelijk werden opgelost in de TT2 style.css bestand in plaats van het in de theme.json het dossier.
WordPress 6.1 loste die problemen op en wat ik wil doen is specifiek naar de laatste kijken. Nu we JSON-gebaseerde stijlen hebben voor de marges en opvulling van lay-outcontainers, opent dat ons voor flexibelere en robuustere manieren om afstand in onze themalay-outs te definiëren.
Over wat voor afstand hebben we het?
Ten eerste hebben we dat al opvulling op rootniveau wat een mooie manier is om opvulling op de te beschrijven <body> element. Dat is fijn, want het zorgt voor een consistente spatiëring op een element dat op alle pagina’s en berichten wordt gedeeld.
Maar er is meer aan de hand, want nu hebben we een manier voor blokken om die opvulling te omzeilen en zichzelf over de volledige breedte uit te lijnen. Dat is dankzij padding-bewuste uitlijningen wat een nieuwe opt-in-functie is theme.jon. Dus zelfs als je opvulling op rootniveau hebt, kun je nog steeds toestaan dat bijvoorbeeld een afbeelding (of een ander blok) uitbreekt en over de volledige breedte gaat.
Dat brengt ons bij een ander ding dat we krijgen: beperkte lay-outs. Het idee hier is dat alle blokken die in de lay-out zijn genest, de inhoudsbreedte van de lay-out respecteren – wat een algemene instelling is – en er niet buiten vloeien. We kunnen dat gedrag blok voor blok onderdrukken met uitlijningen, maar daar komen we op terug.
Laten we beginnen met…
Opvulling op rootniveau
Nogmaals, dit is niet nieuw. We hebben de mogelijkheid gehad om opvulling in te stellen op de <body> element erin theme.json sinds het experiment Gutenberg-plug-in introduceerde het in versie 11.7. We zetten het op de styles.spacing object, waar we hebben margin en padding objecten om de afstand boven, rechts, onder en links op het lichaam te definiëren:
{
"version": 2,
"styles": {
"spacing":
"margin": {
"top": "60px",
"right": "30px",
"bottom": "60px",
"left": "30px"
},
"padding": {
"top": "30px",
"right": "30px",
"bottom": "30px",
"left": "30px"
}
}
}
}Dit is een globale instelling. Dus als we DevTools zouden openen en de <body> element, zouden we deze CSS-stijlen zien:
body {
margin-top: 60px;
margin-right: 30px;
margin-bottom: 60px;
margin-left: 30px;
padding-top: 30px;
padding-right: 30px;
padding-bottom: 30px;
padding-left: 30px;
}Koel. Maar hierin ligt de vraag hoe we in vredesnaam kunnen toestaan dat sommige blokken uit die ruimte breken om het volledige scherm van rand tot rand te vullen. Dat is waarom de afstand er is, toch? Het helpt voorkomen dat dit gebeurt!
Maar er zijn inderdaad genoeg gevallen waarin u die afstand op een eenmalige instantie wilt doorbreken wanneer u in de Block Editor werkt. Stel dat we een afbeeldingsblok op een pagina plaatsen en we willen dat het over de volledige breedte gaat terwijl de rest van de inhoud de opvulling op rootniveau respecteert?
Binnenkomen…
Padding-bewuste uitlijningen
Tijdens een poging om het eerste standaard WordPress-thema te maken dat alle stijlen in de theme.json file illustreert hoofdontwerper Kjell Reigstad hierin de uitdagende aspecten van het doorbreken van opvulling op rootniveau GitHub-probleem.
Er zijn nieuwe functies in WordPress 6.1 gemaakt om dit probleem aan te pakken. Laten we die hierna bekijken.
useRootPaddingAwareAlignments
Een nieuwe useRootPaddingAwareAlignments eigenschap is gemaakt om het probleem aan te pakken. Het werd eigenlijk voor het eerst geïntroduceerd in de Gutenberg-plug-in v13.8. De originele pull-aanvraag is een mooie inleiding over hoe het werkt.
{
"version": 2,
"settings": {
"appearanceTools": true,
"useRootPaddingAwareAlignments": true,
// etc.
},Merk meteen op dat dit een functie is waarvoor we ons moeten aanmelden. De eigenschap is ingesteld op false standaard en we moeten het expliciet instellen op true om het in te schakelen. Merk ook op dat we hebben appearanceTools ingesteld op true ook. Dat kiest ons voor UI-besturingselementen in de Site-editor voor het opmaken van randen, linkkleuren, typografie en, ja, spatiëring, inclusief marge en opvulling.
Instelling appearanceTools ingesteld op true kiest automatisch blokken voor marge en opvulling zonder ook maar iets in te stellen settings.spacing.padding of setting.spacing.margin tot true.
Wanneer we inschakelen useRootPaddingAwareAlignmentskrijgen we aangepaste eigenschappen met rootpadding-waarden die zijn ingesteld op de <body> element aan de voorzijde. Interessant is dat het ook de opvulling toepast op de .editor-styles-wrapper class zodat de afstand wordt weergegeven wanneer u werkt in de back-end Block Editor. Best wel gaaf!
Ik kon die aangepaste CSS-eigenschappen in DevTools bevestigen terwijl ik aan het rondsnuffelen was.
inschakelen useRootPaddingAwareAlignments past ook linker- en rechteropvulling toe op elk blok dat de waarden “inhoud” en “brede” breedte ondersteunt in de afbeelding Global Styles hierboven. We kunnen die waarden ook definiëren in theme.json:
{
"version": 2,
"settings": {
"layout": {
"contentSize": "640px",
"wideSize": "1000px"
}
}
}Als de Global Styles-instellingen anders zijn dan gedefinieerd in theme.json, dan hebben de Global Styles voorrang. Je kunt alles leren over het beheren van blokthemastijlen in mijn laatste artikel.
contentSizeis de standaardbreedte voor blokken.wideSizebiedt een “brede” lay-outoptie en creëert een bredere kolom voor blokken om uit te rekken.
Dus dat laatste codevoorbeeld geeft ons de volgende CSS:
/* The default content container */
.wp-container-[id] > * {
max-width: 640px;
margin-left: auto !important;
margin-right: auto !important;
}
/* The wider content container */
.wp-container-[id] > .alignwide {
max-width: 1000px;
}[id] geeft een uniek nummer aan dat automatisch wordt gegenereerd door WordPress.
Maar raad eens wat we nog meer krijgen? Ook volledige uitlijning!
.wp-container-[id] .alignfull {
max-width: none;
}Zie dat? Door in te schakelen useRootPaddingAwareAlignments en definiëren contentSize en wideSizekrijgen we ook een volledig uitgelijnde CSS-klasse voor in totaal drie containerconfiguraties voor het regelen van de breedte van blokken die aan pagina’s en berichten worden toegevoegd.
Dit is van toepassing op de volgende lay-outspecifieke blokken: Kolommen, Groep, Berichtinhoud en Querylus.
Regelaars voor bloklay-out
Laten we zeggen dat we een van de bovengenoemde lay-outspecifieke blokken aan een pagina toevoegen. Wanneer we het blok selecteren, biedt de gebruikersinterface voor blokinstellingen ons nieuwe lay-outinstellingen op basis van de settings.layout waarden die we hebben gedefinieerd theme.json (of de Global Styles-gebruikersinterface).
We hebben hier te maken met zeer specifieke blokken – blokken waarin andere blokken kunnen zijn genest. Deze lay-outinstellingen gaan dus eigenlijk over het regelen van de breedte en uitlijning van die geneste blokken. De instelling “Binnenste blokken gebruiken inhoudsbreedte” is standaard ingeschakeld. Als we het uitschakelen, hebben we geen max-width op de container en de blokken erin gaan van rand tot rand.
Als we de schakelaar aan laten staan, houden geneste blokken zich aan de contentWidth of wideWidth waarden (daarover later meer). Of we kunnen de numerieke invoer gebruiken om maatwerk te definiëren contentWidth en wideWidth waarden in dit eenmalige geval. Dat is een grote flexibiliteit!
Brede blokken
De instellingen die we zojuist hebben bekeken, zijn ingesteld op het bovenliggende blok. Zodra we een blok erin hebben genest en geselecteerd, hebben we extra opties in dat blok om de contentWidth, wideWidthof ga voor de volle breedte.
Merk op hoe WordPress de aangepaste CSS-eigenschappen voor opvulling op rootniveau vermenigvuldigt met -1 om negatieve marges te creëren bij het selecteren van de optie “Volledige breedte”.
Een beperkte lay-out gebruiken
We hebben zojuist de nieuwe afstanden en uitlijningen besproken die we krijgen met WordPress 6.1. Die zijn specifiek voor blokken en geneste blokken binnen blokken. Maar WordPress 6.1 introduceert ook nieuwe lay-outfuncties voor nog meer flexibiliteit en consistentie in de sjablonen van een thema.
Voorbeeld: WordPress heeft de lay-outtypes Flex en Flow volledig geherstructureerd en ons een beperkt indeling type dat het gemakkelijker maakt om bloklay-outs in thema’s uit te lijnen met behulp van de inhoudsbreedte-instellingen in de gebruikersinterface voor algemene stijlen van de site-editor.
Flex-, Flow- en Beperkte lay-outs
Het verschil tussen deze drie lay-outtypen zijn de stijlen die ze uitvoeren. Isabel Brison heeft een uitstekende beschrijving dat schetst mooi de verschillen, maar laten we ze hier ter referentie parafraseren:
- Stroomindeling: Voegt verticale afstand toe tussen geneste blokken in het
margin-blockrichting. Die geneste blokken kunnen ook links, rechts of in het midden worden uitgelijnd. - Beperkte lay-out: Dezelfde exacte deal als een Flow-lay-out, maar met breedtebeperkingen op geneste blokken die zijn gebaseerd op de
contentWidthenwideWidthinstellingen (ofwel intheme.jsonof globale stijlen). - Flex-indeling: Dit was ongewijzigd in WordPress 6.1. Het gebruikt CSS Flexbox om een lay-out te maken die standaard horizontaal (in een rij) vloeit, maar kan ook verticaal vloeien, zodat blokken op elkaar worden gestapeld. Spatiëring wordt toegepast met behulp van de CSS
gapeigendom.
Deze nieuwe reeks lay-outtypen maakt semantische klassennamen voor elke lay-out:
| Semantische lay-outklasse | Lay-out type | Ondersteunde blokken |
|---|---|---|
.is-layout-flow |
Stroom lay-out | Kolommen, groeperen, postinhoud en querylus. |
.is-layout-constrained |
Beperkte lay-out | Kolommen, groeperen, postinhoud en querylus. |
.is-layout-flex |
Flexibele indeling | Kolommen, knoppen, sociale iconen |
Justin Tadlock heeft een uitgebreid artikel over de verschillende lay-outtypes en semantische klasseninclusief use cases en voorbeelden.
Uw thema bijwerken om beperkte lay-outs te ondersteunen
Als je al een blokthema van je eigen makelij gebruikt, zul je dat willen werk het bij om beperkte lay-outs te ondersteunen. Het enige wat je hoeft te doen, is een paar dingen omwisselen theme.json:
{
"version": 2,
"settings": {
"layout": {
"type": "constrained", // replaces `"inherit": true`
"type": "default", // replaces `"inherit": false`
}
}
}Dit zijn onlangs uitgebrachte blokthema’s die afstandsinstellingen hebben ingeschakeld useRootPaddingAwareAlignments en heb een update theme.json bestand dat een beperkte lay-out definieert:
Lay-outstijlen uitschakelen
De basislay-outstijlen zijn standaardfuncties die worden geleverd in WordPress 6.1 Core. Met andere woorden, ze zijn direct uit de doos ingeschakeld. Maar we kunnen ze indien nodig uitschakelen met dit kleine fragment erin functions.php:
// Remove layout styles.
add_theme_support( 'disable-layout-styles' );Grote waarschuwing hier: ondersteuning voor de standaard lay-outtypen ook uitschakelen verwijdert alle basisstijlen voor die lay-outs. Dat betekent dat u uw eigen stijlen moet gebruiken voor spatiëring, uitlijning en al het andere dat nodig is om inhoud in verschillende sjabloon- en blokcontexten weer te geven.
Afsluiten
Als een grote fan van afbeeldingen over de volledige breedte, zijn de nieuwe WordPress 6.1-lay-out en opvulbewuste uitlijningsfuncties twee van mijn meest favoriete tot nu toe. Samen met andere tools, waaronder betere marge- en opvullingscontrole, vloeiende typografie en bijgewerkte lijst- en citaatblokken, is dit een solide bewijs dat WordPress op weg is naar een betere ervaring voor het maken van inhoud.
Nu moeten we afwachten en kijken hoe de verbeeldingskracht en creativiteit van gewone ontwerpers en makers van inhoud deze ongelooflijke tools gebruiken en naar een nieuw niveau tillen.
Vanwege de lopende iteraties van de site-editor, moeten we altijd anticiperen op een moeilijk pad dat voor ons ligt. Als optimist ben ik echter benieuwd wat er gaat gebeuren in de komende versie van WordPress 6.2. Sommige dingen die ik nauwlettend in de gaten houd, zijn dingen als eigenschappen worden overwogen voor inclusie, ondersteuning voor plakkerige positionering, nieuwe lay-out klassenamen voor binnenblokwikkelaars, bijgewerkte uitlijningsopties voor voettekstenen opties voor beperkte en vloeiende lay-out toevoegen aan Cover-blokken.
Deze GitHub geeft #44720 uit somt de lay-outgerelateerde discussies op gepland voor WordPress 6.2.
Aanvullende middelen
Ik heb veel bronnen geraadpleegd en ernaar verwezen terwijl ik dit allemaal aan het onderzoeken was. Hier is een lange lijst met dingen die ik nuttig vond en waarvan ik denk dat jij ze ook leuk zou vinden.
