Zum Inhalt

CSS-Architektur

Die Grundidee

Die theme.json ist die einzige Quelle für Gestaltungswerte. SCSS liefert nur noch, was sich damit nicht ausdrücken lässt.

Drei Ziele stehen dahinter:

  • Editor und Frontend zeigen dasselbe, weil beide dieselben Variablen benutzen.
  • Kein externes CSS-Framework als Grundabhängigkeit.
  • Ein Child kann die Gestaltung ändern, ohne Stylesheets zu berühren.

Was daraus folgt: Eine Farbe oder ein Abstand wird nie im Stylesheet festgelegt. Steht ein Wert nur im SCSS, kennt ihn der Editor nicht — und die Vorschau weicht vom Frontend ab.

Was wohin gehört

Gehört in die theme.json Gehört ins SCSS
Farben, Schriften, Abstände Komponentenlogik
Layoutbreiten Verhalten bei Interaktion
Grundgestaltung von Blöcken Feinheiten einzelner Blöcke
Typografie-Skala Utility-Klassen

Das Schichtenmodell

Die Stylesheets sind in sieben Schichten aufgebaut. Die Reihenfolge ist bindend — eine spätere Schicht darf eine frühere überschreiben, nicht umgekehrt.

Schicht Inhalt
1. tokens Die CSS-Variablen aus der theme.json nutzen. Eigene Variablen nur als Aliasse, nie als zweite Quelle.
2. base body, Grundtypografie, Links, Tabellen, Formulargrundlagen
3. layout Container, Raster-Utilities, Abstände zwischen Abschnitten
4. utilities Schlanke Klassen für Abstand, Anzeige, Position, Seitenverhältnis
5. components Komponenten des Themes: Schaltflächen, Karten, Paginierung, Brotkrumen, Megamenü
6. blocks Anpassungen je Core- oder Theme-Block
7. compat Zeitlich begrenzte Regeln für Altlasten

Die siebte Schicht ist als schrumpfend gedacht. Was dort landet, hat ein Ablaufdatum.

Zwei Variablenpräfixe

Präfix Herkunft Beispiel
--wp--preset--* von WordPress aus der theme.json erzeugt --wp--preset--color--primary
--tw-* eigene Variablen des Themes im Stylesheet --tw-header-height

Die zweite Gruppe ist ausdrücklich ein Alias-Layer, keine zweite Wahrheitsquelle. Eine --tw--Variable darf einen Preset-Wert weiterreichen oder etwas ausdrücken, das in der theme.json keinen Platz hat — aber keine Farbe neben der Palette definieren.

Die theme.json enthält bewusst keinen settings.custom-Bereich. Es gibt daher keine --wp--custom--*-Variablen; alles Eigene trägt --tw-.

Spezifität niedrig halten

Als Anker dienen .wp-site-blocks, Blockklassen und Utility-Klassen. Keine ID-Selektoren, kein !important außer in compat, und keine globale Überschreibung von Core-Block-Stilen ohne Geltungsbereich.

Der Grund ist praktisch: Ein Child muss mit gewöhnlichem CSS gewinnen können. Je höher die Spezifität im Parent, desto mehr muss ein Child dagegen aufbieten.

Quellen und Ausgaben

Ort Was
source/scss/ Partials und Einstiegsdateien
source/scss/style.scss Haupteinstieg
source/scss/components/, mixins/, modules/, pages/ nach Bereich sortierte Partials
source/scss/feature-*.scss bedingt geladene Feature-Stylesheets
assets/css/ gebaute Ergebnisse

Bearbeitet wird immer source/. Dateien in assets/ sind Build-Ergebnisse und werden beim nächsten Lauf überschrieben.

Module bringen ihre eigenen Stylesheets mit und tragen sie in ihrer module.json ein. Siehe Modul-Vertrag.

Nicht alles gehört ins Haupt-Bundle

Feature-Stylesheets für News, Stock, Mockup, Breadcrumb und Download werden bedingt geladen, gesteuert von includes/feature-css.php. Sie dürfen nicht in source/scss/style.scss importiert werden — sonst landen sie doch in main.css und die bedingte Ladung ist wirkungslos.

Blöcke gestalten

Die Grundgestaltung eines Blocks kommt aus der theme.json, unter styles.blocks. Nur was dort nicht ausdrückbar ist, gehört in die blocks-Schicht des SCSS.

Für wiederkehrende Varianten sind Blockstile der richtige Weg, nicht eigene CSS-Klassen: Sie erscheinen im Editor unter Stile und sind damit auffindbar. Welche es gibt, steht unter Blöcke.

Icons werden Gutenberg-zuerst gedacht: Ihre Stile liegen in der blocks-Schicht, nicht in components.

Anforderungen an das Megamenü

Das Megamenü kommt ohne JavaScript-Framework aus. Diese Interaktionen sind verbindlich, nicht optional:

  • Öffnen und Schließen per Klick und Touch
  • Tastaturnavigation mit Tab, Shift+Tab und Pfeiltasten, wo sinnvoll
  • Escape schließt geöffnete Menüs
  • Ein Klick außerhalb schließt geöffnete Menüs
  • Fokusverwaltung, samt Rücksprung auf das auslösende Element
  • Gleiches Verhalten auf Mobil und Desktop

Regeln für das Child

  • Tokens zuerst über die theme.json überschreiben, nicht über CSS.
  • Komponenten-Overrides nur in einer eigenen Schicht des Childs.
  • Keine Eingriffe in die Kernschichten des Parents.

Siehe Child-Theme.

Wann ist die Architektur in Ordnung

  • Kein externes CSS-Framework in Build und ausgelieferten Assets.
  • Keine Abhängigkeit von Framework-Klassennamen im Markup.
  • Editor und Frontend sehen gleich aus.
  • Die Funktionsgleichheit des Megamenüs ist nachgewiesen, mit Barrierefreiheits- und Interaktionstests.
  • Die compat-Schicht schrumpft.

Weiter