Sättet vi skriver CSS för WordPress-teman är mitt i genomgripande förändringar. Jag delade nyligen en teknik för lägga till stöd för flytande typ i WordPress i form av theme.json, en ny fil som WordPress har pressat hårt att bli en central källa till sanning för att definiera stilar i WordPress-teman som stöder funktioner för full-site redigering (FSE).

Vänta, nej style.css fil? Det har vi fortfarande. Faktiskt, style.css is fortfarande en nödvändig fil i blockteman, även om dess roll är kraftigt reducerad till metainformation som används för att registrera temat. Som sagt, faktum är det theme.json är fortfarande i aktiv utveckling, vilket innebär att vi befinner oss i en övergångsperiod där du kan hitta stilar definierade där, i styles.css eller till och med på blocknivå.

Så, hur ser styling egentligen ut i dessa WordPress FSE-dagar? Det är vad jag vill ta upp i den här artikeln. Det finns en brist på dokumentation för stylingblockteman i WordPress Theme Developer Handbook, så allt vi tar upp här är vad jag har samlat på mig om var saker och ting är just nu samt diskussioner om framtiden för WordPress-teman.

Utvecklingen av WordPress-stilar

De nya utvecklingsfunktionerna som ingår i WordPress 6.1 för oss närmare ett system av stilar som är helt definierade i theme.json, men det återstår fortfarande mycket arbete innan vi helt kan luta oss mot det. Ett sätt vi kan få en uppfattning om vad som kommer i framtida utgåvor är genom att använda Gutenberg plugin. Det är här experimentella funktioner ofta får en torrkörning.

Ett annat sätt vi kan få en känsla för var vi är är genom att titta på utvecklingen av standard WordPress-teman. Hittills finns det tre standardteman som stöder redigering av hela webbplatsen:

Men börja inte handla in CSS style.css för JSON-egenskapsvärde parar in theme.json ännu. Det finns fortfarande CSS-stylingregler som måste stödjas i theme.json innan vi tänker på att göra det. De återstående viktiga frågorna diskuteras för närvarande i syfte att fullt ut flytta in alla regler för CSS-stil theme.json och konsolidera olika källor till theme.json in en Användargränssnitt för att ställa in globala stilar direkt i WordPress webbplatsredigerare.

Det lämnar oss i en relativt tuff plats. Inte bara finns där ingen tydlig väg för att åsidosätta temastilar, men det är oklart var källan till dessa stilar ens kommer ifrån - är det från olika lager av theme.json filer, style.css, Gutenberg-pluginet eller någon annanstans?

Varför theme.json istället för style.css?

Du kanske undrar varför WordPress går mot en JSON-baserad definition av stilar istället för en traditionell CSS-fil. Ben Dwyer från Gutenbergs utvecklingsteam formulerar vältaligt varför theme.json tillvägagångssätt är en fördel för temautvecklare.

Det är värt att läsa Bens inlägg, men köttet finns i det här citatet:

Åsidosättande av CSS, oavsett om det är layout, förinställd eller blockstil, utgör ett hinder för integration och interoperabilitet: visuell paritet mellan frontend och redigerare blir svårare att upprätthålla, uppgraderingar för att blockera interna kan komma i konflikt med åsidosättningar. Anpassad CSS är dessutom mindre portabel över andra blockteman.

Genom att uppmuntra temaförfattare att använda theme.json API där det är möjligt kan hierarkin av "bas > tema > användare" definierade stilar lösas korrekt.

En av de stora fördelarna med att flytta CSS till JSON är att JSON är ett maskinläsbart format, vilket innebär att det kan exponeras i WordPress Site Editor UI genom att hämta ett API, vilket gör det möjligt för användare att ändra standardvärden och anpassa en webbplats utseende utan skriva vilken CSS som helst. Det ger också ett sätt att utforma block konsekvent, samtidigt som det tillhandahåller en struktur som skapar lager av specificitet så att användarinställningarna har högsta prioritet över de som definieras i theme.json. Det där samspelet mellan stilar på temanivå i theme.json och de användardefinierade stilarna i Global Styles UI är det som gör JSON-metoden så tilltalande.

Utvecklare upprätthåller konsistens i JSON, och användare får flexibilitet med kodlösa anpassningar. Det är en win-win.

Det finns säkert andra fördelar, och Mike McAlister från WP Engine listar flera i denna Twitter-tråd. Du kan hitta ännu fler fördelar i detta fördjupad diskussion på bloggen Make WordPress Core. Och när du har läst det, jämför fördelarna med JSON-metoden med de tillgängliga sätten att definiera och åsidosätta stilar i klassiska teman.

Definiera stilar med JSON-element

Vi har redan sett en hel del framsteg när det gäller vilka delar av ett tema theme.json är kapabel att styla. Före WordPress 6.1 var allt vi egentligen kunde göra stil med rubriker och länkar. Nu, med WordPress 6.1, vi kan lägga till knappar, bildtexter, citat och rubriker till blandningen.

Och det gör vi genom att definiera JSON-element. Tänk på element som enskilda komponenter som finns i ett WordPress-block. Säg att vi har ett block som innehåller en rubrik, ett stycke och en knapp. De enskilda bitarna är element, och det finns en elements objekt i theme.json där vi definierar deras stilar:

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

Ett bättre sätt att beskriva JSON-element är som komponenter på låg nivå för teman och block som inte behöver komplexiteten hos block. De är representationer av HTML-primitiver som inte är definierade i ett block utan kan användas över block. Hur de stöds i WordPress (och Gutenberg-pluginen) beskrivs i Block Editor Handbook och detta Handledning för fullständig webbplatsredigering av Carolina Nymark.

Till exempel är länkar utformade i elements objekt men är inte ett block i sig. Men en länk kan användas i ett block och den kommer att ärva de stilar som definierats på elements.link objekt i theme.json. Detta kapslar dock inte in definitionen av ett element helt, eftersom vissa element också är registrerade som block, såsom rubrik- och knappblocken - men dessa block kan fortfarande användas inom andra block.

Här är en tabell över de element som för närvarande är tillgängliga att styla i theme.json, med tillstånd av Carolina:

Som du kan se är det fortfarande tidiga dagar och mycket behöver fortfarande flyttas från Gutenberg-pluginet till WordPress Core. Men du kan se hur snabbt det skulle vara att göra något som stilar alla rubriker i ett tema globalt utan att leta efter väljare i CSS-filer eller DevTools.

Vidare kan du också börja se hur strukturen av theme.json bildar slags lager av specificitet, som går från globala element (t.ex headings) till enskilda element (t.ex h1), och stilar på blocknivå (t.ex h1 som finns i ett block).

Ytterligare information om JSON-element finns tillgänglig i detta Gör WordPress-förslag och denna öppna biljett i Gutenberg-pluginens GitHub-repo.

JSON- och CSS-specificitet

Låt oss fortsätta prata om CSS-specificitet. Jag nämnde tidigare att JSON-metoden för styling etablerar en hierarki. Och det är sant. Stilar som är definierade på JSON-element i theme.json anses vara standardtemastilar. Och allt som ställs in av användaren i Global Styles UI kommer att åsidosätta standardinställningarna.

Med andra ord: användarstilar har mer specificitet än standardtemastilar. Låt oss ta en titt på knappblocket för att få en känsla för hur detta fungerar.

Jag använder Tomt tema, ett tomt WordPress-tema utan CSS-styling. Jag ska lägga till ett knappblock på en ny sida.

OK, vi vet att WordPress Core levereras med lite lätt styling. Nu ska jag byta till standard TT3-temat från WordPress 6.1 och aktivera det. Om jag uppdaterar min sida med knappen ändrar knappen stil.

Du kan se exakt var de nya stilarna kommer ifrån i TT3:s theme.json fil. Detta berättar för oss att JSON-elementstilarna har företräde framför WordPress Core-stilar.

Nu ska jag modifiera TT3 genom att åsidosätta den med en theme.json fil i ett undertema, där standardbakgrundsfärgen för knappblocket är inställd på röd.

Men lägg märke till sökknappen i den sista skärmdumpen. Det borde väl vara rött också? Det måste betyda att den är utformad på en annan nivå om förändringen jag gjorde är på global nivå. Om vi ​​vill förändra båda knappar, kunde vi göra det på användarnivå med hjälp av Global Styles UI i webbplatsredigeraren.

Vi ändrade bakgrundsfärgen på båda knapparna till blå och modifierade även texten med hjälp av Global styles UI. Lägg märke till att det blå därifrån tog företräde framför temastilarna!

Stilmotorn

Det är en mycket snabb, men bra, uppfattning om hur CSS-specificitet hanteras i WordPress-blockteman. Men det är inte hela bilden eftersom det fortfarande är oklart var dessa stilar genereras. WordPress har sina egna standardstilar som kommer någonstans ifrån, förbrukar data in theme.json för fler stilregler, och åsidosätter de med vad som helst i Global Styles.

Är dessa stilar inbyggda? Finns de i en separat stilmall? Kanske de injiceras på sidan i en ?

Det är det nya Stil motor kommer förhoppningsvis att lösa sig. Style Engine är ett nytt API i WordPress 6.1 som är tänkt att ge konsekvens i hur stilar genereras och var stilar tillämpas. Med andra ord, det tar alla möjliga källor till styling och är enskilt ansvarigt för att korrekt generera blockstilar. Jag vet jag vet. Ännu en abstraktion ovanpå andra abstraktioner bara för att skriva några stilar. Men att ha ett centraliserat API för stilar är förmodligen den mest eleganta lösningen med tanke på att stilar kan komma från ett antal ställen.

Vi får bara en första titt på Style Engine. I själva verket, här är vad som har slutförts hittills, enligt biljetten:

• Granska och konsolidera där koden genererar blockstöd CSS i backend så att de levereras från samma plats (i motsats till flera platser). Detta täcker CSS-regler som marginal, utfyllnad, typografi, färger och kanter.
• Ta bort repetitiva layoutspecifika stilar och generera semantiska klassnamn.
• Minska antalet inline-stiltaggar som vi skriver ut på sidan för stöd för block, layout och element.

I grund och botten är detta grunden för att etablera ett enda API som innehåller alla CSS-stilregler för ett tema, var de än kommer ifrån. Det rensar upp hur WordPress skulle injicera inline-stilar före 6.1 och etablerar ett system för semantiska klassnamn.

Ytterligare detaljer om de långsiktiga och kortsiktiga målen för Style Engine finns i denna Gör WordPress Core-diskussion. Du kan också följa spårningsfråga och projektstyrelsen för fler uppdateringar.

Arbeta med JSON-element

Vi pratade lite om JSON-element i theme.json fil och hur de i grunden är HTML-primitiver för att definiera standardstilar för saker som rubriker, knappar och länkar, bland annat. Nu ska vi titta på faktiskt med hjälp av ett JSON-element och hur det beter sig i olika stylingsammanhang.

JSON-element har i allmänhet två sammanhang: den global nivå och blocknivå. Stilarna på global nivå definieras med mindre specificitet än de är på blocknivå för att säkerställa att blockspecifika stilar har företräde för konsistens varhelst block används.

Globala stilar för JSON-element

Låt oss titta på det nya standard TT3-temat och undersöka hur dess knappar är utformade. Följande är en förkortad copy-paste av TT3 theme.json fil (här är fullständig kod) visar den globala stilsektionen, men du kan hitta originalkoden här.

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

Alla knappar är utformade på global nivå (styles.elements.button).

Vi kan också bekräfta detta i DevTools. Lägg märke till att en klass ringde .wp-element-button är väljaren. Samma klass används för att utforma de interaktiva tillstånden också.

Återigen, den här stylingen sker på global nivå, från theme.json. När vi använder en knapp kommer den att ha samma bakgrund eftersom de delar samma väljare och inga andra stilregler åsidosätter den.

Som en sida lades WordPress 6.1 till stöd för styling av interaktiva tillstånd för vissa element, som knappar och länkar, med hjälp av pseudoklasser i theme.json - Inklusive :hover, :focusoch :active — eller Global Styles UI. Automatisk ingenjör Dave Smith demonstrerar denna funktion i en YouTube-video.

Vi kan åsidosätta knappens bakgrundsfärg antingen i theme.json (helst i ett barntema eftersom vi använder ett standard WordPress-tema) eller i Global Styles-inställningarna i webbplatsredigeraren (inget underordnat tema behövs eftersom det inte kräver en kodändring).

Men då ändras knapparna på en gång. Vad händer om vi vill åsidosätta bakgrundsfärgen när knappen är en del av ett visst block? Det är där stilar på blocknivå kommer in i bilden.

Stilar på blocknivå för element

För att förstå hur vi kan använda och anpassa stilar på blocknivå, låt oss ändra bakgrundsfärgen på knappen som finns i sökblocket. Kom ihåg att det finns ett knappblock, men det vi gör är att åsidosätta bakgrundsfärgen på blocknivå i sökblocket. På så sätt tillämpar vi bara den nya färgen där i motsats till att tillämpa den globalt på alla knappar.

För att göra det definierar vi stilarna på styles.blocks objekt i theme.json. Det stämmer, om vi definierar de globala stilarna för alla knappar på styles.elements, kan vi definiera blockspecifika stilar för knappelement på styles.block, som följer en liknande 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? Jag ställer in background och text fastigheter på styles.blocks.core/search.elements.button med två CSS-variabler som är förinställda i WordPress.

Resultatet? Sökknappen är nu röd (--wp--preset--color--quaternary), och standardknappblocket behåller sin ljusgröna bakgrund.

Vi kan se förändringen i DevTools också.

Detsamma gäller om vi vill styla knappar som ingår i andra block. Och knappar är bara ett exempel, så låt oss titta på ett annat.

Exempel: Styling av rubriker på varje nivå

Låt oss köra hem all denna information med ett exempel. Den här gången ska vi:

• Style alla rubriker globalt
• Stil alla Rubrik 2-element
• Style Rubrik 2-element i Query Loop-blocket

Låt oss först börja med den grundläggande strukturen för theme.json:

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

Detta fastställer konturerna för våra globala stilar och stilar på blocknivå.

Style alla rubriker globalt

Låt oss lägga till headings invända mot våra globala stilar och tillämpa några stilar:

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

Det ställer in färgen för alla rubriker till den förinställda basfärgen i WordPress. Låt oss även ändra färg och teckenstorlek för Rubrik 2-element på global nivå:

{
  "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 är alla Rubrik 2-element inställda på att vara den primära förinställda färgen med en flytande teckenstorlek. Men vi kanske vill ha en fixad fontSize för Rubrik 2-elementet när det används i Query Look-blocket:

{
  "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 stilnivåer för Rubrik 2-element: alla rubriker, alla Rubrik 2-element och Rubrik 2-element som används i Query Loop-blocket.

Befintliga temaexempel

Medan vi bara tittade på stilexemplen för knappar och rubriker i den här artikeln, stöder WordPress 6.1 ytterligare stylingelement. Det finns en tabell som beskriver dem i "Definiera stilar med JSON-element" sektion.

Du undrar förmodligen vilka JSON-element som stöder vilka CSS-egenskaper, för att inte tala om hur du ens skulle deklarera dem. Medan vi väntar på officiell dokumentation kommer de bästa resurserna vi har att vara theme.json filer för befintliga teman. Jag kommer att ge länkar till teman baserat på de element de anpassar, och peka ut vilka egenskaper som är anpassade.

Se till att ge varje theme.json göra en bra titt eftersom dessa teman inkluderar utmärkta exempel på stil på blocknivå på styles.blocks objekt.

Inslagning upp

Frekventa ändringar av hela webbplatsredigeraren håller på att bli en stora källor till irritation för många människor, Inklusive tekniskt kunniga Gutenberg-användare. Även mycket enkla CSS-regler, som fungerar bra med klassiska teman, verkar inte fungera för blockteman på grund av nya lager av specificitet vi täckte tidigare.

När det gäller en GitHub-förslag för att omdesigna webbplatsredigeraren i ett nytt webbläsarläge, Det skriver Sara Gooding i ett WP Tavern-inlägg:

Det är lätt att gå vilse när du försöker ta dig runt i Site Editor om du inte arbetar dag och natt i verktyget. Navigeringen är nervös och förvirrande, särskilt när man går från mallsökning till mallredigering till att ändra enskilda block.

Även som en angelägen tidig ryttare i Gutenbergs värld av blockredigerare och blocköga-teman, har jag massor av mina egna frustrationer. Jag är dock optimistisk och räknar med att webbplatsredigeraren, när den är färdig, kommer att vara ett revolutionerande verktyg för både användare och teknikkunniga temautvecklare. Detta hoppfull tweet bekräftar det redan. Under tiden verkar det som att vi borde förbereda oss för fler förändringar, och kanske till och med en ojämn tur.

Referensprojekt

Jag listar alla resurser jag använde när jag undersökte information för den här artikeln.

JSON-element

Globala stilar

Stil motor

Tack för att du läser! Jag skulle gärna höra dina egna reflektioner om hur du använder blockteman och hur du hanterar din CSS.