Verwaltung von CSS-Stilen in einem WordPress Block Theme

Die Art und Weise, wie wir CSS für WordPress-Themes schreiben, unterliegt tiefgreifenden Änderungen. Ich habe kürzlich eine Technik zum Hinzufügen von fluidem Typografie-Support in WordPress mithilfe von theme.json vorgestellt, einer neuen Datei, die WordPress stark vorantreibt, um eine zentrale Wahrheitsquelle für die Definition von Stilen in WordPress-Themes zu werden, die Full-Site-Editing (FSE)-Funktionen unterstützen.

Moment mal, keine style.css Datei? Die haben wir immer noch. Tatsächlich ist style.css immer noch eine erforderliche Datei in Block-Themes, obwohl ihre Rolle stark auf Metainformationen reduziert ist, die zur Registrierung des Themes verwendet werden. Das gesagt, ist theme.json noch in aktiver Entwicklung, was bedeutet, dass wir uns in einer Übergangsphase befinden, in der Sie möglicherweise Stile dort, in styles.css oder sogar auf Blockebene definiert finden.

Wie sieht also das Styling in diesen WordPress FSE-Tagen tatsächlich aus? Das möchte ich in diesem Artikel behandeln. Es gibt einen Mangel an Dokumentation für das Styling von Block-Themes im WordPress Theme Developer Handbook, daher sind alles, was wir hier behandeln, das, was ich über den aktuellen Stand sowie Diskussionen über die Zukunft des WordPress-Themings gesammelt habe.

Die Entwicklung von WordPress-Stilen

Die neuen Entwicklungsfeatures, die in WordPress 6.1 enthalten sind, bringen uns näher an ein Stilsystem, das vollständig in theme.json definiert ist, aber es gibt noch viel zu tun, bevor wir uns vollständig darauf verlassen können. Eine Möglichkeit, eine Vorstellung davon zu bekommen, was in zukünftigen Releases kommt, ist die Verwendung des Gutenberg-Plugins. Hier werden experimentelle Features oft auf Herz und Nieren geprüft.

Eine weitere Möglichkeit, ein Gefühl dafür zu bekommen, wo wir stehen, ist die Betrachtung der Entwicklung von Standard-WordPress-Themes. Bis heute gibt es drei Standard-Themes, die Full-Site-Editing unterstützen

• Twenty Twenty-One (TT1): Dies ist die erste klassische Version eines Block-kompatiblen Standard-Themes. Es gibt auch eine Block-Version (TT1 blocks) und sie war seitdem eine Anlaufstelle für Block-Theming. Allerdings sind alle 5.900 Zeilen CSS in TT1 in style.css enthalten. Es gibt keine theme.json Datei. TT1 Blocks ist der erste Einblick, den wir in das Styling im Zeitalter des Block Editors bekamen, und wir können es eher als Teaser denn als Modell betrachten.
• Twenty Twenty-Two (TT2): Dies ist das erste echte Block-basierte Standard-WordPress-Theme, und hier treffen wir zum ersten Mal auf theme.json. Die Datei enthält nur 373 Zeilen Code. Seine leitenden Entwickler haben sich stark bemüht, es zu einem CSS-losen Theme zu machen; dennoch enthielt style.css immer noch knapp 150 Zeilen Code, da nicht alle Probleme mit theme.json im experimentellen Gutenberg-Plugin vor der Veröffentlichung gelöst wurden.
• Twenty Twenty-Three (TT3): Dies ist das, was mit WordPress 6.1 ausgeliefert wurde, und es ist das erste Beispiel eines Themes ohne jegliches CSS in der erforderlichen style.css Datei.

Aber tauschen Sie die CSS-Regeln in style.css noch nicht gegen JSON-Eigenschaft-Wert-Paare in theme.json aus. Es gibt immer noch CSS-Styling-Regeln, die in theme.json unterstützt werden müssen, bevor wir darüber nachdenken, dies zu tun. Die verbleibenden wichtigen Probleme werden derzeit mit dem Ziel diskutiert, alle CSS-Styling-Regeln vollständig in theme.json zu verschieben und verschiedene Quellen von theme.json in einer Benutzeroberfläche zur Einstellung globaler Stile direkt im WordPress Site Editor zu konsolidieren.

Das lässt uns in einer relativ schwierigen Lage. Nicht nur gibt es keinen klaren Weg, Theme-Stile zu überschreiben, sondern es ist unklar, woher diese Stile überhaupt stammen – stammen sie aus verschiedenen Ebenen von theme.json-Dateien, style.css, dem Gutenberg-Plugin oder woanders?

Warum theme.json statt style.css?

Sie fragen sich vielleicht, warum WordPress sich in Richtung einer JSON-basierten Stildefinition bewegt und nicht hin zu einer traditionellen CSS-Datei. Ben Dwyer vom Gutenberg-Entwicklungsteam erklärt eloquent, warum der theme.json-Ansatz ein Vorteil für Theme-Entwickler ist.

Es lohnt sich, Bens Beitrag zu lesen, aber der Kernpunkt liegt in diesem Zitat:

Das Überschreiben von CSS, sei es für Layout, Presets oder Blockstile, stellt ein Hindernis für Integration und Interoperabilität dar: Visuelle Parität zwischen Frontend und Editor wird schwieriger aufrechtzuerhalten, Upgrades von Block-Interna können mit Überschreibungen in Konflikt geraten. Custom CSS ist außerdem weniger portabel über andere Block-Themes hinweg.

Durch die Ermutigung von Theme-Autoren, die theme.json API zu verwenden, wo immer möglich, kann die Hierarchie von "Basis > Theme > Benutzer" definierten Stilen korrekt aufgelöst werden.

Einer der Hauptvorteile der Verlagerung von CSS nach JSON ist, dass JSON ein maschinenlesbares Format ist, was bedeutet, dass es in der WordPress Site Editor UI über eine API-Abfrage angezeigt werden kann, was den Benutzern ermöglicht, Standardwerte zu ändern und das Erscheinungsbild einer Website zu personalisieren, ohne überhaupt CSS schreiben zu müssen. Es bietet auch eine Möglichkeit, Blöcke konsistent zu stylen, während es eine Struktur schafft, die Ebenen der Spezifität erzeugt, sodass Benutzereinstellungen die höchste Priorität gegenüber denen in theme.json definierten haben. Dieses Zusammenspiel zwischen Theme-Level-Stilen in theme.json und den benutzefinierten Stilen in der Global Styles UI macht den JSON-Ansatz so attraktiv.

Entwickler wahren Konsistenz in JSON, und Benutzer gewinnen Flexibilität mit Code-losen Anpassungen. Das ist ein Win-Win.

Es gibt sicher noch weitere Vorteile, und Mike McAlister von WP Engine listet mehrere in diesem Twitter-Thread auf. Weitere Vorteile finden Sie in dieser ausführlichen Diskussion im Make WordPress Core Blog. Und sobald Sie das gelesen haben, vergleichen Sie die Vorteile des JSON-Ansatzes mit den verfügbaren Methoden zur Definition und zum Überschreiben von Stilen in klassischen Themes.

Stile mit JSON-Elementen definieren

Wir haben bereits viel Fortschritt gesehen, was die Teile eines Themes angeht, die theme.json stylen kann. Vor WordPress 6.1 konnten wir wirklich nur Überschriften und Links stylen. Jetzt, mit WordPress 6.1, können wir Schaltflächen, Bildunterschriften, Zitate und Überschriften hinzufügen.

Und das tun wir, indem wir JSON-Elemente definieren. Betrachten Sie Elemente als einzelne Komponenten, die in einem WordPress-Block leben. Nehmen wir an, wir haben einen Block, der eine Überschrift, einen Absatz und eine Schaltfläche enthält. Diese einzelnen Teile sind Elemente, und es gibt ein elements-Objekt in theme.json, in dem wir ihre Stile definieren.

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

Eine bessere Beschreibung für JSON-Elemente sind Low-Level-Komponenten für Themes und Blöcke, die nicht die Komplexität von Blöcken benötigen. Sie sind Repräsentationen von HTML-Primitiven, die nicht in einem Block definiert sind, aber über Blöcke hinweg verwendet werden können. Wie sie in WordPress (und dem Gutenberg-Plugin) unterstützt werden, wird im Block Editor Handbook und diesem Full Site Editing Tutorial von Carolina Nymark beschrieben.

Zum Beispiel werden Links im elements-Objekt gestylt, sind aber kein eigenständiger Block. Ein Link kann jedoch in einem Block verwendet werden und erbt die auf dem elements.link-Objekt in theme.json definierten Stile. Dies kapselt jedoch nicht vollständig die Definition eines Elements, da einige Elemente auch als Blöcke registriert sind, wie z. B. die Blöcke für Überschriften und Schaltflächen – aber diese Blöcke können immer noch innerhalb anderer Blöcke verwendet werden.

Hier ist eine Tabelle der Elemente, die vor WordPress 6.1 in theme.json gestylt werden können, mit freundlicher Genehmigung von Carolina

Wie Sie sehen, stecken wir noch in den Kinderschuhen und vieles muss noch vom Gutenberg-Plugin in den WordPress Core übernommen werden. Aber Sie können sehen, wie schnell es wäre, so etwas wie alle Überschriften in einem Theme global zu stylen, ohne nach Selektoren in CSS-Dateien oder DevTools suchen zu müssen.

Darüber hinaus können Sie auch beginnen zu sehen, wie die Struktur von theme.json quasi Ebenen der Spezifität bildet, von globalen Elementen (z. B. headings) bis zu einzelnen Elementen (z. B. h1) und Block-Level-Stilen (z. B. h1 in einem Block enthalten).

Zusätzliche Informationen zu JSON-Elementen finden Sie in diesem Make WordPress-Vorschlag und diesem offenen Ticket im GitHub-Repo des Gutenberg-Plugins.

JSON und CSS-Spezifität

Lassen Sie uns weiter über CSS-Spezifität sprechen. Ich habe bereits erwähnt, dass der JSON-Ansatz zum Stylen eine Hierarchie etabliert. Und das stimmt auch. Stile, die auf JSON-Elementen in theme.json definiert sind, gelten als Standard-Theme-Stile. Und alles, was vom Benutzer in der Global Styles UI eingestellt wird, überschreibt die Standardwerte.

Mit anderen Worten: Benutzerdefinierte Stile haben eine höhere Spezifität als Standard-Theme-Stile. Werfen wir einen Blick auf den Button-Block, um ein Gefühl dafür zu bekommen, wie das funktioniert.

Ich verwende Emptytheme, ein leeres WordPress-Theme ohne CSS-Styling. Ich werde einen Button-Block auf einer neuen Seite hinzufügen.

OK, wir wissen, dass WordPress Core einige leichte Stile mitliefert. Jetzt wechsle ich zum Standard-Theme TT3 von WordPress 6.1 und aktiviere es. Wenn ich meine Seite mit dem Button aktualisiere, ändert sich der Button im Stil.

Sie können genau sehen, woher diese neuen Stile in der theme.json-Datei von TT3 stammen. Das sagt uns, dass die JSON-Element-Stile Vorrang vor den WordPress Core-Stilen haben.

Jetzt modifiziere ich TT3, indem ich es mit einer theme.json-Datei in einem Child-Theme überschreibe, wo die Standard-Hintergrundfarbe des Button-Blocks auf Rot gesetzt ist.

Aber beachten Sie den Suchbutton im letzten Screenshot. Der sollte doch auch rot sein, oder? Das muss bedeuten, dass er auf einer anderen Ebene gestylt wird, wenn die von mir vorgenommene Änderung auf globaler Ebene ist. Wenn wir *beide* Buttons ändern wollen, könnten wir das auf Benutzerebene über die Global Styles UI im Site Editor tun.

Wir haben die Hintergrundfarbe beider Buttons über die Global Styles UI auf Blau geändert und auch den Text angepasst. Beachten Sie, dass das Blau von dort Vorrang vor den Theme-Stilen hatte!

Die Style Engine

Das ist ein sehr schneller, aber guter Überblick darüber, wie CSS-Spezifität in WordPress Block-Themes verwaltet wird. Aber es ist kein vollständiges Bild, weil noch unklar ist, *woher* diese Stile generiert werden. WordPress hat seine eigenen Standardstile, die irgendwoher kommen, verbraucht die Daten in theme.json für weitere Stilregeln und überschreibt diese mit allem, was in Global Styles eingestellt wurde.

Sind diese Stile inline? Sind sie in einem separaten Stylesheet? Vielleicht werden sie auf der Seite in einem <script> eingefügt?

Das ist es, was die neue Style Engine hoffentlich lösen wird. Die Style Engine ist eine neue API in WordPress 6.1, die darauf abzielt, Konsistenz bei der Generierung und Anwendung von Stilen zu schaffen. Mit anderen Worten, sie nimmt alle möglichen Styling-Quellen und ist allein dafür verantwortlich, Blockstile korrekt zu generieren. Ich weiß, ich weiß. Noch eine Abstraktion über anderen Abstraktionen, nur um einige Stile zu erstellen. Aber eine zentralisierte API für Stile zu haben, ist wahrscheinlich die eleganteste Lösung, da Stile aus einer Vielzahl von Quellen stammen können.

Wir erhalten nur einen ersten Einblick in die Style Engine. Tatsächlich ist hier, was bisher abgeschlossen wurde, laut dem Ticket

• Überprüfen und konsolidieren Sie, wo der Code Block-Support-CSS im Backend generiert, sodass sie von derselben Stelle (im Gegensatz zu mehreren Stellen) geliefert werden. Dies umfasst CSS-Regeln wie Margin, Padding, Typografie, Farben und Ränder.
• Entfernen Sie sich wiederholende Layout-spezifische Stile und generieren Sie semantische Klassennamen.
• Reduzieren Sie die Anzahl der Inline-Style-Tags, die wir für Block-, Layout- und Element-Support auf die Seite drucken.

Im Grunde ist dies die Grundlage für die Etablierung einer einzigen API, die alle CSS-Stilregeln für ein Theme enthält, wo auch immer sie herkommen. Sie bereinigt die Art und Weise, wie WordPress Inline-Stile vor 6.1 einfügte, und etabliert ein System für semantische Klassennamen.

Weitere Details zu den Langzeit- und Kurzzeitzielen der Style Engine finden Sie in dieser Make WordPress Core-Diskussion. Sie können auch dem Tracking-Issue und dem Projektboard für weitere Updates folgen.

Arbeiten mit JSON-Elementen

Wir haben ein wenig über JSON-Elemente in der theme.json-Datei gesprochen und wie sie im Grunde HTML-Primitive für die Definition von Standardstilen für Dinge wie Überschriften, Schaltflächen und Links sind, unter anderem. Nun wollen wir uns ansehen, wie man ein JSON-Element tatsächlich *verwendet* und wie es sich in verschiedenen Styling-Kontexten verhält.

JSON-Elemente haben im Allgemeinen zwei Kontexte: die globale Ebene und die Blockebene. Die globalen Stile werden mit geringerer Spezifität definiert als auf der Blockebene, um sicherzustellen, dass blockspezifische Stile für Konsistenz, wo immer Blöcke verwendet werden, Vorrang haben.

Globale Stile für JSON-Elemente

Betrachten wir das neue Standard-Theme TT3 und untersuchen wir, wie seine Schaltflächen gestylt sind. Das Folgende ist eine gekürzte Kopie des TT3 theme.json-Files (hier der vollständige Code), das den globalen Stilbereich zeigt, aber Sie können den Originalcode hier finden.

{
  "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 Schaltflächen werden auf globaler Ebene gestylt (styles.elements.button).

Das können wir auch in DevTools bestätigen. Beachten Sie, dass eine Klasse namens .wp-element-button der Selektor ist. Die gleiche Klasse wird auch zur Darstellung der interaktiven Zustände verwendet.

Auch hier geschieht das Styling auf globaler Ebene und stammt aus theme.json. Wann immer wir eine Schaltfläche verwenden, wird sie die gleiche Hintergrundfarbe haben, da sie den gleichen Selektor teilen und keine anderen Stilregeln sie überschreiben.

Als Randnotiz: WordPress 6.1 hat die Unterstützung für das Styling interaktiver Zustände für bestimmte Elemente wie Schaltflächen und Links hinzugefügt, unter Verwendung von Pseudo-Klassen in theme.json – einschließlich :hover, :focus und :active – oder der Global Styles UI. Automattic Engineer Dave Smith demonstriert diese Funktion in einem YouTube-Video.

Wir könnten die Hintergrundfarbe der Schaltfläche entweder in theme.json (vorzugsweise in einem Child Theme, da wir ein Standard-WordPress-Theme verwenden) oder in den Global Styles Einstellungen im Site Editor überschreiben (kein Child Theme erforderlich, da dies keine Codeänderung erfordert).

Aber dann ändern sich die Schaltflächen alle auf einmal. Was ist, wenn wir die Hintergrundfarbe überschreiben wollen, wenn die Schaltfläche Teil eines bestimmten Blocks ist? Da kommen Block-Level-Stile ins Spiel.

Block-Level-Stile für Elemente

Um zu verstehen, wie wir Stile auf Blockebene verwenden und anpassen können, ändern wir die Hintergrundfarbe der Schaltfläche, die im Search Block enthalten ist. Denken Sie daran, es gibt einen Button-Block, aber wir überschreiben die Hintergrundfarbe auf Blockebene des Search Blocks. So wenden wir die neue Farbe nur dort an, anstatt sie global auf alle Schaltflächen anzuwenden.

Dazu definieren wir die Stile im styles.blocks-Objekt in theme.json. Das stimmt, wenn wir die globalen Stile für alle Schaltflächen unter styles.elements definieren, können wir die blockspezifischen Stile für Schaltflächenelemente unter styles.block definieren, was eine ähnliche Struktur hat.

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

Sehen Sie das? Ich habe die Eigenschaften background und text auf styles.blocks.core/search.elements.button mit zwei CSS-Variablen gesetzt, die in WordPress voreingestellt sind.

Das Ergebnis? Die Suchschaltfläche ist jetzt rot (--wp--preset--color--quaternary), und der Standard-Button-Block behält seinen leuchtend grünen Hintergrund.

Wir können die Änderung auch in DevTools sehen.

Dasselbe gilt, wenn wir Schaltflächen stylen wollen, die in anderen Blöcken enthalten sind. Und Schaltflächen sind nur ein Beispiel, also schauen wir uns ein weiteres an.

Beispiel: Überschriften auf jeder Ebene stylen

Um all diese Informationen zu verdeutlichen, hier ein Beispiel. Dieses Mal werden wir

• Alle Überschriften global stylen
• Alle Überschriften der zweiten Ebene stylen
• Überschriften der zweiten Ebene im Query Loop Block stylen

Zuerst beginnen wir mit der grundlegenden Struktur für theme.json

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

Dies legt den Rahmen für unsere globalen und block-level Stile fest.

Alle Überschriften global stylen

Fügen wir das headings-Objekt zu unseren globalen Stilen hinzu und wenden einige Stile an.

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

Das setzt die Farbe für alle Überschriften auf die voreingestellte Basisfarbe in WordPress. Ändern wir auch die Farbe und Schriftgröße von Überschriften der zweiten Ebene auf globaler Ebene.

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

Jetzt sind alle Überschriften der zweiten Ebene auf die primäre Preset-Farbe mit einer fluiden Schriftgröße eingestellt. Aber vielleicht wollen wir eine feste fontSize für das Überschriften-Element der zweiten Ebene, wenn es im Query Look Block verwendet wird.

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

Jetzt haben wir drei Ebenen von Stilen für Überschriften der zweiten Ebene: alle Überschriften, alle Überschriften der zweiten Ebene und Überschriften der zweiten Ebene, die im Query Loop Block verwendet werden.

Beispiele für bestehende Themes

Obwohl wir in diesem Artikel nur die Styling-Beispiele für Schaltflächen und Überschriften betrachtet haben, unterstützt WordPress 6.1 das Styling zusätzlicher Elemente. Eine Tabelle, die sie auflistet, finden Sie im Abschnitt "Stile mit JSON-Elementen definieren".

Sie fragen sich wahrscheinlich, welche JSON-Elemente welche CSS-Eigenschaften unterstützen, ganz zu schweigen davon, wie man diese überhaupt deklarieren würde. Während wir auf die offizielle Dokumentation warten, sind die besten Ressourcen, die wir haben, die theme.json-Dateien für bestehende Themes. Ich werde Links zu Themes bereitstellen, basierend auf den von ihnen angepassten Elementen, und darauf hinweisen, welche Eigenschaften angepasst werden.

Schauen Sie sich jede theme.json-Datei genau an, denn diese Themes enthalten ausgezeichnete Beispiele für Block-Level-Styling im Objekt styles.blocks.

Zusammenfassung

Häufige Änderungen am Full-Site-Editor werden zu Hauptärgernis für viele Leute, einschließlich technikaffinen Gutenberg-Nutzern. Selbst sehr einfache CSS-Regeln, die mit klassischen Themes gut funktionieren, scheinen bei Block-Themes aufgrund der neuen Spezifitätsebenen, die wir zuvor behandelt haben, nicht zu funktionieren.

Bezüglich eines GitHub-Vorschlags zur Neugestaltung des Site Editors in einem neuen Browser-Modus schreibt Sara Gooding in einem WP Tavern-Beitrag

Es ist leicht, sich zu verirren, wenn man versucht, sich im Site Editor zurechtzufinden, es sei denn, man arbeitet Tag und Nacht mit dem Tool. Die Navigation ist sprunghaft und verwirrend, besonders beim Wechseln von der Vorlagen-Ansicht zur Vorlagen-Bearbeitung zur Änderung einzelner Blöcke.

Selbst als begeisterter Frühnutzer der Gutenberg Block Editor und Block-Eye Themes habe ich unzählige eigene Frustrationen. Ich bin jedoch optimistisch und gehe davon aus, dass der Site Editor, sobald er fertiggestellt ist, ein revolutionäres Werkzeug für Benutzer und technikaffine Theme-Entwickler gleichermaßen sein wird. Dieser hoffnungsvolle Tweet bestätigt das bereits. In der Zwischenzeit scheint es, dass wir uns auf weitere Änderungen vorbereiten sollten, und vielleicht sogar auf eine holprige Fahrt.

Referenzen

Ich liste alle Ressourcen auf, die ich bei der Recherche für diesen Artikel verwendet habe.

JSON-Elemente

• Elements API (Gutenberg GitHub Repo)
• Theme.json-Elemente (Full Site Editing)
• Element-Stile (Block Editor Handbook)

Globale Stile

• Roadmap für globale Stile (Gutenberg GitHub-Issue)
• Globale Stile: Tracking von Element-Support (Gutenberg GitHub-Issue)

Style Engine

• Block Editor Styles: Initiativen und Ziele (Make WordPress Blog)
• Generierung von Blockstilen (Style Engine) (Make WordPress Blog)
• Core Styles und Theme-Anpassung: die nächsten Schritte (Make WordPress Blog)

Danke fürs Lesen! Ich würde gerne Ihre eigenen Überlegungen zur Nutzung von Block-Themes hören und wie Sie Ihr CSS verwalten.