Den måde, vi skriver CSS til WordPress-temaer på, er midt i gennemgribende ændringer. Jeg delte for nylig en teknik til tilføje flydende type support i WordPress ved hjælp af theme.json, en ny fil, der WordPress har presset hårdt på at blive en central kilde til sandhed til at definere stilarter i WordPress-temaer, der understøtter fuld-site redigering (FSE) funktioner.

Vent, nej style.css fil? Det har vi stadig. Faktisk, style.css is stadig en påkrævet fil i bloktemaer, selvom dens rolle i høj grad er reduceret til metainformation, der bruges til at registrere temaet. Når det er sagt, er faktum det theme.json er stadig i aktiv udvikling, hvilket betyder, at vi er i en overgangsperiode, hvor du måske kan finde stilarter defineret der, i styles.css eller endda på blokniveau.

Så hvordan ser styling egentlig ud i disse WordPress FSE-dage? Det er det, jeg vil dække i denne artikel. Der er mangel på dokumentation for styling af bloktemaer i WordPress Theme Developer Håndbog, så alt, hvad vi dækker her, er, hvad jeg har samlet om, hvor tingene er i øjeblikket, samt diskussioner om fremtiden for WordPress-temaer.

Udviklingen af ​​WordPress-stile

De nye udviklingsfunktioner, der er inkluderet i WordPress 6.1 få os tættere på et system af stilarter, der er fuldstændigt defineret i theme.json, men der er stadig masser af arbejde at gøre, før vi fuldt ud kan læne os op ad det. En måde, vi kan få en idé om, hvad der kommer i fremtidige udgivelser, er ved at bruge Gutenberg plugin. Det er her, eksperimentelle funktioner ofte får en tør omgang.

En anden måde, vi kan få en fornemmelse af, hvor vi er, er ved at se på udviklingen af standard WordPress-temaer. Til dato er der tre standardtemaer, der understøtter redigering af hele webstedet:

Men begynd ikke at handle med CSS'en style.css for JSON-egenskabsværdi parrer ind theme.json lige endnu. Der er stadig CSS-stylingregler, der skal understøttes i theme.json før vi tænker på at gøre det. De resterende væsentlige spørgsmål diskuteres i øjeblikket med det formål at flytte alle CSS-stilreglerne fuldt ud theme.json og konsolidere forskellige kilder til theme.json i en Brugergrænseflade til at indstille globale stilarter direkte i WordPress Site Editor.

Det efterlader os i en forholdsvis svær situation. Ikke kun er der ingen klar vej til at tilsidesætte temastilarter, men det er uklart, hvor kilden til disse stilarter overhovedet kommer fra - er det fra forskellige lag af theme.json filer, style.css, Gutenberg-plugin'et eller et andet sted?

Hvorfor theme.json i stedet for style.css?

Du undrer dig måske over, hvorfor WordPress bevæger sig mod en JSON-baseret definition af stilarter i stedet for en traditionel CSS-fil. Ben Dwyer fra Gutenbergs udviklingsteam formulerer veltalende, hvorfor theme.json tilgang er en fordel for temaudviklere.

Det er værd at læse Bens indlæg, men kødet er i dette citat:

Tilsidesættelse af CSS, uanset om det er layout, forudindstillede eller blokerede stilarter, udgør en hindring for integration og interoperabilitet: visuel paritet mellem frontend og editor bliver sværere at vedligeholde, opgraderinger til intern blokering kan være i konflikt med tilsidesættelser. Custom CSS er desuden mindre bærbar på tværs af andre bloktemaer.

Ved at opmuntre temaforfattere til at bruge theme.json API hvor det er muligt, kan hierarkiet af "base > tema > bruger" definerede stilarter løses korrekt.

En af de største fordele ved at flytte CSS til JSON er, at JSON er et maskinlæsbart format, hvilket betyder, at det kan eksponeres i WordPress Site Editor UI ved at hente en API, hvilket giver brugerne mulighed for at ændre standardværdier og tilpasse et websteds udseende uden at skrive enhver CSS overhovedet. Det giver også en måde at style blokke konsekvent på, samtidig med at den giver en struktur, der skaber lag af specificitet, således at brugerindstillingerne har højeste prioritet over dem, der er defineret i theme.json. Det samspil mellem stilarter på temaniveau i theme.json og de brugerdefinerede stilarter i Global Styles UI er det, der gør JSON-tilgangen så tiltalende.

Udviklere opretholder ensartethed i JSON, og brugere opnår fleksibilitet med kodeløse tilpasninger. Det er en win-win.

Der er helt sikkert andre fordele, og Mike McAlister fra WP Engine lister flere i denne Twitter-tråd. Du kan finde endnu flere fordele ved dette dybdegående diskussion over på Make WordPress Core-bloggen. Og når du har læst det, kan du sammenligne fordelene ved JSON-tilgangen med de tilgængelige måder at definere og tilsidesætte stilarter i klassiske temaer.

Definition af stilarter med JSON-elementer

Vi har allerede set en masse fremskridt med hensyn til hvilke dele af et tema theme.json er i stand til at style. Før WordPress 6.1 var alt, hvad vi egentlig kunne gøre, stil overskrifter og links. Nu, med WordPress 6.1, vi kan tilføje knapper, billedtekster, citater og overskrifter til blandingen.

Og det gør vi ved at definere JSON-elementer. Tænk på elementer som individuelle komponenter, der lever i en WordPress-blok. Lad os sige, at vi har en blok, der indeholder en overskrift, et afsnit og en knap. Disse individuelle stykker er elementer, og der er en elements objekt i theme.json hvor vi definerer deres stilarter:

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

En bedre måde at beskrive JSON-elementer på er som komponenter på lavt niveau til temaer og blokke, der ikke har brug for kompleksiteten af ​​blokke. De er repræsentationer af HTML-primitiver som ikke er defineret i en blok, men kan bruges på tværs af blokke. Hvordan de understøttes i WordPress (og Gutenberg plugin) er beskrevet i Block Editor Håndbog og dette Fuld webstedsredigering tutorial af Carolina Nymark.

For eksempel er links stylet i elements objekt, men er ikke en blok i sig selv. Men et link kan bruges i en blok, og det vil arve de stilarter, der er defineret på elements.link objekt i theme.json. Dette indkapsler dog ikke helt definitionen af ​​et element, da nogle elementer også er registreret som blokke, såsom overskrifts- og knapblokkene - men disse blokke kan stadig bruges i andre blokke.

Her er en tabel over de elementer, der i øjeblikket er tilgængelige at style i theme.json, høflighed af Carolina:

Som du kan se, er det stadig tidligt, og der mangler stadig at flytte fra Gutenberg-pluginet til WordPress Core. Men du kan se, hvor hurtigt det ville være at gøre noget som at style alle overskrifter i et tema globalt uden at lede efter vælgere i CSS-filer eller DevTools.

Yderligere kan du også begynde at se, hvordan strukturen af theme.json danner slags lag af specificitet, der går fra globale elementer (f headings) til individuelle elementer (f.eks h1), og stilarter på blokniveau (f.eks h1 indeholdt i en blok).

Yderligere oplysninger om JSON-elementer er tilgængelig i dette Lav et WordPress-forslag , denne åbne billet i Gutenberg-plugin's GitHub-repo.

JSON og CSS specificitet

Lad os blive ved med at tale om CSS-specificitet. Jeg nævnte tidligere, at JSON-tilgangen til styling etablerer et hierarki. Og det er sandt. Typografier, der er defineret på JSON-elementer i theme.json betragtes som standard temastile. Og alt, der er indstillet af brugeren i Global Styles UI, vil tilsidesætte standardindstillingerne.

Med andre ord: brugerstile har mere specificitet end standardtemastile. Lad os tage et kig på knapblokken for at få en fornemmelse af, hvordan dette fungerer.

Jeg bruger Tomt tema, et tomt WordPress-tema uden CSS-styling. Jeg vil tilføje en knapblok på en ny side.

OK, vi ved, at WordPress Core leveres med noget let styling. Nu vil jeg skifte til standard TT3-temaet fra WordPress 6.1 og aktivere det. Hvis jeg opdaterer min side med knappen, skifter knappen stil.

Du kan se nøjagtigt hvor de nye stilarter kommer fra i TT3'er theme.json fil. Dette fortæller os, at JSON-elementstilene har forrang over WordPress Core-stilarter.

Nu vil jeg ændre TT3 ved at tilsidesætte den med en theme.json fil i et undertema, hvor standardbaggrundsfarven for knapblokken er sat til rød.

Men læg mærke til søgeknappen i det sidste skærmbillede. Den skal også være rød, ikke? Det må betyde, at det er stylet på et andet niveau, hvis den ændring, jeg lavede, er på globalt plan. Hvis vi vil ændre os både knapper, kunne vi gøre det på brugerniveau ved hjælp af Global Styles UI i webstedseditoren.

Vi ændrede baggrundsfarven på begge knapper til blå og ændrede også teksten ved hjælp af Global styles UI. Bemærk, at det blå derfra tog forrang over temastilene!

Stilmotoren

Det er en meget hurtig, men god idé om, hvordan CSS-specificitet administreres i WordPress-bloktemaer. Men det er ikke det komplette billede, fordi det stadig er uklart hvor disse stilarter er genereret. WordPress har sine egne standardstile, der kommer fra et sted, forbruger dataene ind theme.json for at få flere stilregler og tilsidesætter dem med alt angivet i Global Styles.

Er disse stilarter inline? Er de i et separat stylesheet? Måske er de injiceret på siden i en ?

Det er det nye Stil motor forhåbentlig løses. Style Engine er en ny API i WordPress 6.1, der er beregnet til at bringe sammenhæng i, hvordan stilarter genereres, og hvor stilarter anvendes. Med andre ord tager den alle mulige kilder til styling og er enestående ansvarlig for korrekt generering af blokstile. Jeg ved, jeg ved det. Endnu en abstraktion oven i andre abstraktioner bare for at skrive nogle stilarter. Men at have en centraliseret API til styles er nok den mest elegante løsning, da styles kan komme fra en række steder.

Vi får kun et første kig på Style Engine. Faktisk er her, hvad der er blevet afsluttet indtil videre, ifølge billetten:

• Revider og konsolider, hvor koden genererer blokstøtte CSS i bagenden, så de leveres fra samme sted (i modsætning til flere steder). Dette dækker CSS-regler såsom margen, polstring, typografi, farver og kanter.
• Fjern gentagne layout-specifikke stilarter og generer semantiske klassenavne.
• Reducer antallet af inline-stiltags, vi udskriver på siden til blok-, layout- og elementunderstøttelse.

Grundlæggende er dette grundlaget for at etablere en enkelt API, der indeholder alle CSS-stilreglerne for et tema, uanset hvor de kommer fra. Det rydder op i den måde, WordPress ville injicere inline-stile før 6.1 og etablerer et system til semantiske klassenavne.

Yderligere detaljer om de langsigtede og kortsigtede mål for Style Engine kan findes i denne Lav WordPress Core-diskussion. Du kan også følge med sporingsproblem , projekt bestyrelse for yderligere opdateringer.

Arbejde med JSON-elementer

Vi talte lidt om JSON-elementer i theme.json fil, og hvordan de dybest set er HTML-primitiver til at definere standardstile for ting som overskrifter, knapper og links, blandt andre. Lad os nu se på faktisk ved brug af et JSON-element, og hvordan det opfører sig i forskellige stylingsammenhænge.

JSON-elementer har generelt to sammenhænge: den globalt plan og blok niveau. Styles på globalt niveau er defineret med mindre specificitet, end de er på blokniveau for at sikre, at blokspecifikke stilarter har forrang for konsistens, uanset hvor blokke bruges.

Globale stilarter til JSON-elementer

Lad os se på det nye standard TT3-tema og undersøge, hvordan dets knapper er stylet. Det følgende er en forkortet copy-paste af TT3 theme.json fil (her er fuld kode) viser den globale stilsektion, men du kan finde den originale kode 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 knapper er stylet på globalt niveau (styles.elements.button).

Vi kan også bekræfte dette i DevTools. Bemærk, at en klasse ringede .wp-element-button er vælgeren. Den samme klasse bruges også til at style de interaktive tilstande.

Igen, denne styling sker alt sammen på globalt plan, og kommer fra theme.json. Når vi bruger en knap, vil den have den samme baggrund, fordi de deler den samme vælger, og ingen andre stilregler tilsidesætter den.

Som en sidebemærkning tilføjede WordPress 6.1 understøttelse af styling af interaktive tilstande for visse elementer, såsom knapper og links, ved hjælp af pseudo-klasser i theme.json - inklusive :hover, :focusog :active — eller Global Styles UI. Automatisk ingeniør Dave Smith demonstrerer denne funktion i en YouTube-video.

Vi kunne tilsidesætte knappens baggrundsfarve enten i theme.json (helst i et undertema, da vi bruger et standard WordPress-tema) eller i Global Styles-indstillingerne i webstedseditoren (intet underordnet tema nødvendigt, da det ikke kræver en kodeændring).

Men så skifter knapperne på én gang. Hvad hvis vi vil tilsidesætte baggrundsfarven, når knappen er en del af en bestemt blok? Det er her, stilarter på blokniveau kommer i spil.

Stilarter på blokniveau for elementer

For at forstå, hvordan vi kan bruge og tilpasse stilarter på blokniveau, lad os ændre baggrundsfarven på knappen, der er indeholdt i søgeblokken. Husk, at der er en knapblok, men det, vi gør, er at tilsidesætte baggrundsfarven på blokniveauet i søgeblokken. På den måde anvender vi kun den nye farve der i modsætning til at anvende den globalt på alle knapper.

For at gøre det definerer vi stilarterne på styles.blocks objekt i theme.json. Det er rigtigt, hvis vi definerer de globale stilarter for alle knapper på styles.elements, kan vi definere de blokspecifikke stilarter for knapelementer 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)"
            }
          }
        },
        // ...
      }
    }
  }
}

Kan du se det? Jeg indstillede background , text ejendomme på styles.blocks.core/search.elements.button med to CSS-variabler, der er forudindstillet i WordPress.

Resultatet? Søgeknappen er nu rød (--wp--preset--color--quaternary), og standardknapblokken bevarer sin lyse grønne baggrund.

Vi kan også se ændringen i DevTools.

Det samme gælder, hvis vi vil style knapper, der er inkluderet i andre blokke. Og knapper er kun ét eksempel, så lad os se på et andet.

Eksempel: Styling af overskrifter på hvert niveau

Lad os køre al denne information hjem med et eksempel. Denne gang vil vi:

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

Lad os først starte med den grundlæggende struktur for theme.json:

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

Dette etablerer omridset for vores globale stilarter og stilarter på blokniveau.

Stil alle overskrifter globalt

Lad os tilføje headings gøre indsigelse mod vores globale stilarter og anvende nogle stile:

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

Det indstiller farven for alle overskrifter til den forudindstillede basisfarve i WordPress. Lad os også ændre farven og skriftstørrelsen på overskrift 2-elementer på globalt niveau:

{
  "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 er alle Overskrift 2-elementer indstillet til at være den primære forudindstillede farve med en flydende skriftstørrelse. Men måske vil vi have en fast fontSize for Overskrift 2-elementet, når det bruges 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
            }
          }
        }
      }
    }
  }
}

Nu har vi tre niveauer af typografier for Overskrift 2-elementer: alle overskrifter, alle Overskrift 2-elementer og Overskrift 2-elementer, der bruges i Query Loop-blokken.

Eksisterende temaeksempler

Mens vi kun har set på stylingeksemplerne for knapper og overskrifter i denne artikel, understøtter WordPress 6.1 styling af yderligere elementer. Der er en tabel, der skitserer dem i "Definition af stilarter med JSON-elementer" sektion.

Du spekulerer sikkert på, hvilke JSON-elementer der understøtter hvilke CSS-egenskaber, for ikke at nævne hvordan du overhovedet ville erklære dem. Mens vi venter på officiel dokumentation, vil de bedste ressourcer, vi har, være theme.json filer til eksisterende temaer. Jeg vil give links til temaer baseret på de elementer, de tilpasser, og påpege, hvilke egenskaber der er tilpasset.

Sørg for at give hver theme.json giv et godt kig, fordi disse temaer inkluderer fremragende eksempler på styling på blokniveau på styles.blocks objekt.

Indpakning op

Hyppige ændringer af hele webstedseditoren er ved at blive en store kilder til irritation for mange mennesker, herunder teknisk kyndige Gutenberg-brugere. Selv meget simple CSS-regler, som fungerer godt med klassiske temaer, virker ikke til bloktemaer pga. nye lag af specificitet vi dækkede tidligere.

Vedrørende a GitHub forslag at omdesigne webstedseditoren i en ny browsertilstand, Det skriver Sara Gooding i et WP Tavern-indlæg:

Det er nemt at fare vild, mens du forsøger at komme rundt i Site Editor, medmindre du arbejder dag og nat inde i værktøjet. Navigationen er nervøs og forvirrende, især når man går fra skabelongennemsyn til skabelonredigering til ændring af individuelle blokke.

Selv som en ivrig early rider i Gutenberg-blokredaktørens verden og block-eye-temaer, har jeg tonsvis af mine egne frustrationer. Jeg er dog optimistisk og forventer, at webstedseditoren, når den er færdig, vil være et revolutionerende værktøj for både brugere og teknokyndige temaudviklere. Dette håbefuldt tweet bekræfter det allerede. I mellemtiden ser det ud til, at vi burde forberede os på flere ændringer og måske endda en ujævn tur.

Referencer

Jeg lister alle de ressourcer, jeg brugte, mens jeg undersøgte oplysninger til denne artikel.

JSON-elementer

Globale Styles

Stil motor

Tak fordi du læste med! Jeg ville elske at høre dine egne overvejelser om brugen af ​​bloktemaerne og hvordan du administrerer din CSS.