De nieuwe beperkte lay-out gebruiken in WordPress-blokthema's

Een van de hoofddoelen van de WordPress Site Editor (en ja, dat is nu de "Officiele naam) is om de basisblokstijl te verplaatsen oppompen van 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 (graag willen :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 bestand.

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 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.json. 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 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 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?

Voer ...

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

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 . 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.

omgeving appearanceTools ingesteld op true kiest automatisch blokken voor marge en opvulling zonder ook maar iets in te stellen settings.spacing.padding or setting.spacing.margin naar true.

Wanneer we inschakelen useRootPaddingAwareAlignments, krijgen we aangepaste eigenschappen met rootpadding-waarden die zijn ingesteld op de 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. U kunt alles leren over het beheren van blokthemastijlen in mijn laatste artikel.

• contentSize is de standaardbreedte voor blokken.
• wideSize biedt 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 wideSize, krijgen 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 or 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, wideWidth, of 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 gedwongen lay-out 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-block richting. 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 contentWidth en wideWidth instellingen (ofwel in theme.json of globale stijlen).
• Flexibele 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 ook verticaal kan vloeien, zodat blokken op elkaar worden gestapeld. Spatiëring wordt toegepast met behulp van de CSS gap eigendom.

Deze nieuwe reeks lay-outtypen maakt semantische klassennamen voor elke lay-out:

Semantische lay-outklasse	Lay-outtype	Ondersteunde blokken
.is-layout-flow	Stroom lay-out	Kolommen, groeperen, inhoud posten en querylus.
.is-layout-constrained	Beperkte lay-out	Kolommen, groeperen, inhoud posten en querylus.
.is-layout-flex	Flexibele indeling	Kolommen, knoppen, sociale iconen

Justin Tadlock heeft een uitgebreid artikel over de verschillende lay-outtypes en semantische klassen, inclusief 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 List- en Quote-blokken, zijn onder andere een solide bewijs dat WordPress op weg is naar een betere ervaring voor het maken van content.

Nu moeten we afwachten 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 voetteksten en 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.

Extra 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.

Tutorials

WordPress-berichten

GitHub pull-aanvragen en problemen