Måten vi skriver CSS for WordPress-temaer på er midt i omfattende endringer. Jeg delte nylig en teknikk for legge til flytende støtte i WordPress ved hjelp av theme.json, en ny fil som WordPress har presset hardt på å bli en sentral kilde til sannhet for å definere stiler i WordPress-temaer som støtter funksjoner for full-site redigering (FSE).

Vent, nei style.css fil? Det har vi fortsatt. Faktisk, style.css is fortsatt en nødvendig fil i blokktemaer, selv om rollen er sterkt redusert til metainformasjon som brukes til å registrere temaet. Når det er sagt, er faktum det theme.json er fortsatt i aktiv utvikling, noe som betyr at vi er i en overgangsperiode hvor du kan finne stiler definert der, i styles.css eller til og med på blokknivå.

Så, hvordan ser styling faktisk ut i disse WordPress FSE-dagene? Det er det jeg vil dekke i denne artikkelen. Det er mangel på dokumentasjon for stylingblokktemaer i Håndbok for WordPress Theme Developer, så alt vi dekker her er det jeg har samlet om hvor ting er for tiden, samt diskusjoner om fremtiden til WordPress-tema.

Utviklingen av WordPress-stiler

De nye utviklingsfunksjonene som er inkludert i WordPress 6.1 få oss nærmere et system av stiler som er fullstendig definert i theme.json, men det er fortsatt mye arbeid å gjøre før vi kan stole helt på det. En måte vi kan få en ide om hva som kommer i fremtidige utgivelser er ved å bruke Gutenberg-plugin. Det er her eksperimentelle funksjoner ofte får en tørrkjøring.

En annen måte vi kan få en følelse av hvor vi er, er ved å se på utviklingen av standard WordPress-temaer. Til dags dato er det tre standardtemaer som støtter redigering av hele nettstedet:

Men ikke begynn å bytte inn CSS style.css for JSON-egenskapsverdi-par inn theme.json ennå. Det er fortsatt CSS-stylingregler som må støttes i theme.json før vi tenker på å gjøre det. De gjenværende viktige problemene diskuteres for tiden med et mål om å fullt ut flytte alle CSS-stilreglene inn theme.json og konsolidere ulike kilder til theme.json inn i en UI for for å sette globale stiler direkte i WordPress Site Editor.

Det setter oss i en relativt tøff plass. Ikke bare er der ingen klar vei for å overstyre temastiler, men det er uklart hvor kilden til disse stilene til og med kommer fra - er det fra forskjellige lag av theme.json filer, style.css, Gutenberg-pluginen eller et annet sted?

Hvorfor theme.json istedenfor style.css?

Du lurer kanskje på hvorfor WordPress beveger seg mot en JSON-basert definisjon av stiler i stedet for en tradisjonell CSS-fil. Ben Dwyer fra Gutenbergs utviklingsteam artikulerer veltalende hvorfor theme.json tilnærming er en fordel for temautviklere.

Det er verdt å lese Bens innlegg, men kjøttet er i dette sitatet:

Overstyring av CSS, enten det er layout, forhåndsinnstilte eller blokkeringsstiler, utgjør en hindring for integrasjon og interoperabilitet: visuell paritet mellom frontend og editor blir vanskeligere å opprettholde, oppgraderinger til blokkering av interne elementer kan komme i konflikt med overstyringer. Tilpasset CSS er dessuten mindre bærbar på tvers av andre blokktemaer.

Ved å oppmuntre temaforfattere til å bruke theme.json API der det er mulig, kan hierarkiet av "base > tema > bruker" definerte stiler løses riktig.

En av de største fordelene med å flytte CSS til JSON er at JSON er et maskinlesbart format, noe som betyr at det kan eksponeres i WordPress Site Editor UI ved å hente en API, og dermed tillate brukere å endre standardverdier og tilpasse et nettsteds utseende uten skrive hvilken som helst CSS i det hele tatt. Det gir også en måte å style blokker konsekvent på, samtidig som den gir en struktur som skaper lag med spesifisitet slik at brukerinnstillingene har høyeste prioritet over de som er definert i theme.json. Det samspillet mellom stiler på temanivå i theme.json og de brukerdefinerte stilene i Global Styles UI er det som gjør JSON-tilnærmingen så tiltalende.

Utviklere opprettholder konsistens i JSON, og brukere får fleksibilitet med kodeløse tilpasninger. Det er en vinn-vinn.

Det er sikkert andre fordeler, og Mike McAlister fra WP Engine lister opp flere i denne Twitter-tråden. Du kan finne enda flere fordeler i dette grundig diskusjon over på Make WordPress Core-bloggen. Og når du har lest det, kan du sammenligne fordelene med JSON-tilnærmingen med de tilgjengelige måtene å definere og overstyre stiler i klassiske temaer.

Definere stiler med JSON-elementer

Vi har allerede sett mye fremgang når det gjelder hvilke deler av et tema theme.json er i stand til å style. Før WordPress 6.1 var alt vi egentlig kunne gjøre stil med overskrifter og lenker. Nå, med WordPress 6.1, vi kan legge til knapper, bildetekster, sitater og overskrifter til blandingen.

Og det gjør vi ved å definere JSON-elementer. Tenk på elementer som individuelle komponenter som lever i en WordPress-blokk. La oss si at vi har en blokk som inneholder en overskrift, et avsnitt og en knapp. Disse individuelle brikkene er elementer, og det er en elements objekt i theme.json hvor vi definerer stilene deres:

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

En bedre måte å beskrive JSON-elementer på er som komponenter på lavt nivå for temaer og blokker som ikke trenger kompleksiteten til blokker. De er representasjoner av HTML-primitiver som ikke er definert i en blokk, men kan brukes på tvers av blokker. Hvordan de støttes i WordPress (og Gutenberg-pluginen) er beskrevet i Block Editor Håndbok og denne Opplæring i full sideredigering av Carolina Nymark.

For eksempel er lenker stylet i elements objekt, men er ikke en blokk i seg selv. Men en lenke kan brukes i en blokk, og den vil arve stilene som er definert på elements.link objekt i theme.json. Dette innkapsler imidlertid ikke helt definisjonen av et element, ettersom noen elementer også er registrert som blokker, for eksempel Heading- og Button-blokkene - men disse blokkene kan fortsatt brukes i andre blokker.

Her er en tabell over elementene som for øyeblikket er tilgjengelige å style inn theme.json, med tillatelse fra Carolina:

Som du kan se, er det fortsatt tidlig, og mye må fortsatt flyttes fra Gutenberg-pluginet til WordPress Core. Men du kan se hvor raskt det ville være å gjøre noe som å style alle overskrifter i et tema globalt uten å lete etter velgere i CSS-filer eller DevTools.

Videre kan du også begynne å se hvordan strukturen til theme.json danner slags lag av spesifisitet, som går fra globale elementer (f.eks. headings) til individuelle elementer (f.eks. h1), og stiler på blokknivå (f.eks. h1 inneholdt i en blokk).

Ytterligere informasjon om JSON-elementer er tilgjengelig i dette Lag WordPress-forslag og denne åpne billetten i Gutenberg-pluginens GitHub-repo.

JSON- og CSS-spesifisitet

La oss fortsette å snakke om CSS-spesifisitet. Jeg nevnte tidligere at JSON-tilnærmingen til styling etablerer et hierarki. Og det er sant. Stiler som er definert på JSON-elementer i theme.json regnes som standard temastiler. Og alt som er angitt av brukeren i Global Styles UI vil overstyre standardinnstillingene.

Med andre ord: brukerstiler har mer spesifisitet enn standardtemastiler. La oss ta en titt på knappeblokken for å få en følelse av hvordan dette fungerer.

jeg bruker Tomt tema, et tomt WordPress-tema uten CSS-styling. Jeg skal legge til en knappeblokk på en ny side.

OK, vi vet at WordPress Core leveres med litt lett styling. Nå skal jeg bytte til standard TT3-temaet fra WordPress 6.1 og aktivere det. Hvis jeg oppdaterer siden min med knappen, endrer knappen stil.

Du kan se nøyaktig hvor de nye stilene kommer fra i TT3 theme.json fil. Dette forteller oss at JSON-elementstilene har forrang over WordPress Core-stiler.

Nå skal jeg modifisere TT3 ved å overstyre den med en theme.json fil i et undertema, der standard bakgrunnsfarge for knappeblokken er satt til rød.

Men legg merke til søkeknappen i det siste skjermbildet. Den skal være rød også, ikke sant? Det må bety at det er stilt på et annet nivå hvis endringen jeg gjorde er på globalt nivå. Hvis vi ønsker å endre både knapper, kunne vi gjøre det på brukernivå ved å bruke Global Styles UI i nettstedredigereren.

Vi endret bakgrunnsfargen på begge knappene til blå og modifiserte også teksten ved å bruke Global styles UI. Legg merke til at det blå derfra gikk foran temastilene!

Stilmotoren

Det er en veldig rask, men god idé om hvordan CSS-spesifisitet administreres i WordPress-blokktemaer. Men det er ikke det komplette bildet fordi det fortsatt er uklart hvor disse stilene genereres. WordPress har sine egne standardstiler som kommer fra et sted, bruker dataene inn theme.json for flere stilregler, og overstyrer de med alt angitt i Global Styles.

Er disse stilene innebygd? Er de i et eget stilark? Kanskje de er injisert på siden i en ?

Det er det nye Stilmotor forhåpentligvis vil løse seg. Stilmotoren er en ny API i WordPress 6.1 som er ment å bringe konsistens i hvordan stiler genereres og hvor stiler brukes. Med andre ord, den tar alle mulige kilder til styling og er enestående ansvarlig for riktig generering av blokkstiler. Jeg vet jeg vet. Nok en abstraksjon på toppen av andre abstraksjoner bare for å skrive noen stiler. Men å ha en sentralisert API for stiler er sannsynligvis den mest elegante løsningen gitt at stiler kan komme fra en rekke steder.

Vi får bare en første titt på Style Engine. Faktisk, her er det som er fullført så langt, i følge billetten:

• Revider og konsolider der koden genererer blokkstøtte CSS i bakenden slik at de leveres fra samme sted (i motsetning til flere steder). Dette dekker CSS-regler som margin, utfylling, typografi, farger og kantlinjer.
• Fjern repeterende layoutspesifikke stiler og generer semantiske klassenavn.
• Reduser antall innebygde stil-tagger vi skriver ut på siden for blokk-, layout- og elementstøtte.

I utgangspunktet er dette grunnlaget for å etablere et enkelt API som inneholder alle CSS-stilreglene for et tema, uansett hvor de kommer fra. Det rydder opp måten WordPress ville injisert innebygde stiler før 6.1 og etablerer et system for semantiske klassenavn.

Ytterligere detaljer om de langsiktige og kortsiktige målene til Style Engine finner du i denne Lag WordPress Core-diskusjon. Du kan også følge med sporingsproblem og prosjektstyret for flere oppdateringer.

Arbeid med JSON-elementer

Vi snakket litt om JSON-elementer i theme.json filen og hvordan de i utgangspunktet er HTML-primitiver for å definere standardstiler for blant annet overskrifter, knapper og lenker. Nå, la oss se på faktisk ved hjelp av et JSON-element og hvordan det oppfører seg i ulike stylingsammenhenger.

JSON-elementer har generelt to sammenhenger: den globalt nivå og blokknivå. Stilene på globalt nivå er definert med mindre spesifisitet enn de er på blokknivå for å sikre at blokkspesifikke stiler har forrang for konsistens uansett hvor blokker brukes.

Globale stiler for JSON-elementer

La oss se på det nye standard TT3-temaet og undersøke hvordan knappene er stilt. Følgende er en forkortet copy-paste av TT3 theme.json fil (her er full kode) viser den globale stilseksjonen, men du kan finne den originale koden her.

{
  "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 knappene er stilt på globalt nivå (styles.elements.button).

Vi kan bekrefte dette i DevTools også. Legg merke til at en klasse ringte .wp-element-button er velgeren. Den samme klassen brukes til å style de interaktive tilstandene også.

Igjen, denne stylingen skjer på globalt nivå, og kommer fra theme.json. Når vi bruker en knapp, kommer den til å ha samme bakgrunn fordi de deler den samme velgeren og ingen andre stilregler overstyrer den.

Som en side la WordPress 6.1 til støtte for styling av interaktive tilstander for visse elementer, som knapper og lenker, ved å bruke pseudo-klasser i theme.json - gjelder også :hover, :focusog :active – eller Global Styles UI. Automatisk ingeniør Dave Smith demonstrerer denne funksjonen i en YouTube-video.

Vi kunne overstyre knappens bakgrunnsfarge enten i theme.json (fortrinnsvis i et undertema siden vi bruker et standard WordPress-tema) eller i Global Styles-innstillingene i nettstedsredigereren (ingen underordnet tema nødvendig siden det ikke krever kodeendring).

Men da vil knappene endres på en gang. Hva om vi ønsker å overstyre bakgrunnsfargen når knappen er en del av en bestemt blokk? Det er her stiler på blokknivå kommer inn i bildet.

Stiler på blokknivå for elementer

For å forstå hvordan vi kan bruke og tilpasse stiler på blokknivå, la oss endre bakgrunnsfargen på knappen som finnes i søkeblokken. Husk at det er en knappeblokk, men det vi gjør er å overstyre bakgrunnsfargen på blokknivået til søkeblokken. På den måten bruker vi bare den nye fargen der, i motsetning til å bruke den globalt på alle knapper.

For å gjøre det, definerer vi stilene på styles.blocks objekt i theme.json. Det stemmer, hvis vi definerer de globale stilene for alle knappene på styles.elements, kan vi definere de blokkspesifikke stilene for knappeelementer på styles.block, som følger en lignende struktur:

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

Se det? Jeg stiller inn background og text eiendommer på styles.blocks.core/search.elements.button med to CSS-variabler som er forhåndsinnstilt i WordPress.

Resultatet? Søk-knappen er nå rød (--wp--preset--color--quaternary), og standard knappeblokk beholder sin lysegrønne bakgrunn.

Vi kan se endringen i DevTools også.

Det samme gjelder hvis vi ønsker å style knapper som er inkludert i andre blokker. Og knapper er bare ett eksempel, så la oss se på et annet.

Eksempel: Styling av overskrifter på hvert nivå

La oss kjøre all denne informasjonen hjem med et eksempel. Denne gangen skal vi:

• Stil alle overskrifter globalt
• Stil alle overskrift 2-elementer
• Style Heading 2-elementer i Query Loop-blokken

Først, la oss starte med den grunnleggende strukturen for theme.json:

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

Dette etablerer omrisset for våre globale stiler og stiler på blokknivå.

Stil alle overskrifter globalt

La oss legge til headings protestere mot våre globale stiler og bruke noen stiler:

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

Det setter fargen for alle overskrifter til den forhåndsinnstilte grunnfargen i WordPress. La oss endre fargen og skriftstørrelsen til overskrift 2-elementer på globalt nivå også:

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

Nå er alle overskrift 2-elementer satt til å være den primære forhåndsinnstilte fargen med en flytende skriftstørrelse. Men kanskje vi vil ha en fast fontSize for Heading 2-elementet når det brukes i Query Look-blokken:

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

Nå har vi tre stilnivåer for Overskrift 2-elementer: alle overskrifter, alle Overskrift 2-elementer og Overskrift 2-elementer som brukes i Query Loop-blokken.

Eksisterende temaeksempler

Mens vi bare så på stylingeksemplene for knapper og overskrifter i denne artikkelen, støtter WordPress 6.1 styling av tilleggselementer. Det er en tabell som skisserer dem i "Definere stiler med JSON-elementer" seksjon.

Du lurer sikkert på hvilke JSON-elementer som støtter hvilke CSS-egenskaper, for ikke å nevne hvordan du til og med ville erklære dem. Mens vi venter på offisiell dokumentasjon, er de beste ressursene vi har theme.json filer for eksisterende temaer. Jeg skal gi lenker til temaer basert på elementene de tilpasser, og påpeke hvilke egenskaper som er tilpasset.

Sørg for å gi hver theme.json ta en god titt fordi disse temaene inkluderer utmerkede eksempler på styling på blokknivå på styles.blocks gjenstand.

Innpakning opp

Hyppige endringer i hele nettstedets editor er i ferd med å bli en store kilder til irritasjon for mange mennesker, Herunder teknisk kunnskapsrike Gutenberg-brukere. Selv veldig enkle CSS-regler, som fungerer bra med klassiske temaer, ser ikke ut til å fungere for blokktemaer på grunn av nye lag av spesifisitet vi dekket tidligere.

Angående a GitHub-forslag for å redesigne nettstedredigereren i en ny nettlesermodus, Det skriver Sara Gooding i et WP Tavern-innlegg:

Det er lett å gå seg vill mens du prøver å komme deg rundt i Site Editor med mindre du jobber dag og natt inne i verktøyet. Navigasjonen er hoppende og forvirrende, spesielt når du går fra malsøking til malredigering til å endre individuelle blokker.

Selv som en ivrig tidlig rytter i Gutenbergs blokkredaktør- og blokkøye-temaer, har jeg tonnevis av mine egne frustrasjoner. Jeg er imidlertid optimistisk, og forventer at nettstedsredigereren, når den er fullført, vil være et revolusjonerende verktøy for både brukere og teknologikyndige temautviklere. Dette håpefull tweet bekrefter det allerede. I mellomtiden ser det ut til at vi bør forberede oss på flere endringer, og kanskje til og med en humpete tur.

Referanser

Jeg lister opp alle ressursene jeg brukte mens jeg undersøkte informasjon for denne artikkelen.

JSON-elementer

Globale stiler

Stilmotor

Takk for at du leste! Jeg vil gjerne høre dine egne refleksjoner om bruk av blokktemaene og hvordan du administrerer CSS.