SCSS-Architektur: Das System Hinter Unseren Themes

Wenn ein Projekt über ein paar Seiten hinauswächst, wird CSS das erste, was zurückschlägt. Spezifitätskriege, duplizierte Werte, ein Breakpoint in drei verschiedenen Dateien definiert. Eine bekannte Geschichte. Die Art, wie wir SCSS in unserem Mena-Theme strukturiert haben, entstand nicht über Nacht — sie entwickelte sich durch echte Projekte, echte Deadlines und echten Schmerz.

Dieser Beitrag führt durch unsere Architektur Schicht für Schicht: was jeder Ordner macht, warum er da ist, und die spezifischen Werkzeuge, die ihn zum Laufen bringen. Wenn Sie WordPress-Themes oder CSS-intensive Projekte bauen, gibt es hier etwas Wertvolles zu übernehmen.

Die Ordnerstruktur

Alles liegt unter resources/scss/. Der Einstiegspunkt ist style.scss — eine einzelne Datei, die nichts anderes tut als importieren. Sie enthält niemals tatsächliche Regeln. Ihre einzige Aufgabe ist es, die Ladereihenfolge mit der modernen @use-Syntax zu deklarieren:

@use 'abstracts' → @use 'vendor/normalize' → @use 'base' → @use 'layout' → @use 'blocks/index' → @use 'components' → @use 'elements' → @use 'pages'

Diese Reihenfolge ist wichtig. Abstraktionen (Variablen, Mixins) müssen vor allem laden, was sie verwendet. Vendor-Resets kommen vor unserer Basis. Layout vor Komponenten. Es liest sich wie ein Abhängigkeitsgraph, weil es einer ist.

Abstracts: Die Design-Token-Schicht

Der abstracts/-Ordner ist das Gehirn des Systems. Er gibt selbst kein CSS aus — es sind reine Deklarationen. Variablen, Funktionen, Mixins. Alles, was andere Schichten verbrauchen.

Variablen. Breakpoints werden einmal als Sass-Map definiert: xs: 440px, sm: 640px, md: 768px, lg: 1024px, xl: 1280px, xxl: 1536px. Farben sind ebenfalls eine Map — und hier wird es interessant. Wir iterieren über diese Map, um automatisch sowohl CSS Custom Properties (--color-primary) als auch Utility-Klassen (.color-primary, .background-primary) zu generieren. Eine Quelle, drei Ausgaben.

Das Breakpoint-Mixin. Anstatt überall rohe Media Queries zu schreiben, haben wir ein einzelnes Mixin, das min-width, max-width, Bereiche und benutzerdefinierte Bedingungen behandelt. @include breakpoint(md) gibt @media screen and (min-width: 768px) aus. @include breakpoint(xs, xl) liefert den Bereich. @include breakpoint($to: lg) begrenzt auf 1023px. Eine konsistente API, null Magic Numbers über Dateien verstreut.

Fluid-Typografie. Das ist eine der Techniken, bei der wir am bewusstesten vorgehen. Anstatt zwischen zwei festen Schriftgrößen mit einem Breakpoint zu springen, verwenden wir eine CSS-calc()-Formel, die die Schriftgröße linear mit der Viewport-Breite wachsen lässt. Eine Überschrift kann bei 375px 2.5rem sein und bei 1600px sanft 3rem erreichen — ohne plötzlichen Sprung, ohne zusätzlichen Breakpoint, nur eine Kurve.

Fluid-Spacing. Das gleiche Prinzip auf Margins und Padding angewendet. Der obere Margin eines .content-block skaliert von 28px auf Mobilgeräten bis 60px auf Desktop. Das Mixin fluid-spacing() nimmt einen Property-Namen, einen Mobilwert und einen Desktop-Wert und macht die Mathematik. Blöcke mit Hintergründen erhalten automatisch passendes Fluid-Padding.

Base: Die Globalen Defaults

Der base/-Ordner legt die Grundregeln fest. Normalize.css setzt zuerst Browser-Inkonsistenzen zurück. Dann unsere Basisstile: box-sizing, line-height, font-family, Link-Defaults, Paragraph-Margins. Typografie wird programmatisch generiert — wir definieren eine Map der Überschriftsgrößen (Min und Max für jedes h1–h6), dann iterieren wir darüber und wenden das fluid-type-Mixin auf jedes an. Das Hinzufügen oder Ändern einer Überschriftsgröße ist eine einzeilige Änderung in der Map.

Die Datei _helpers.scss enthält unsere Utility-Klassen: Layout-Helfer wie .flex, .grid, Spacing-Utilities wie .mt-4, .gap-3 und Display-Shortcuts. Das ist kein Ersatz für Tailwind — es ist ein kleines, kuratiertes Set von Klassen, das 80% der Layout-Anforderungen abdeckt, ohne eine vollständige Utility-Framework-Abhängigkeit hinzuzufügen.

Layout, Komponenten, Elemente

Layout behandelt strukturelle Hüllen: das Grid-System, Header, Footer, Content-Bereich und WordPress-Standard-Block-Stile. Das sind die großen Container. Komponenten sind die wiederverwendbaren Teile, die in Layouts leben: Navigationsmenüs, Beitragskarten, Social Links. Elemente sind die atomaren UI-Teile: Buttons, Form-Inputs.

Buttons veranschaulichen, wie wir BEM verwenden. Die Basisklasse ist .c-button. Varianten sind Modifier: .c-button--primary, .c-button--secondary, .c-button--bordered. Ein Icon innerhalb des Buttons ist ein Element: .c-button__icon. Die Struktur ist vorhersehbar. Wenn ein Entwickler .c-button--primary sieht, weiß er genau, wo er im SCSS-Baum nachschauen muss.

Blocks: Die Gutenberg-Schicht

Der blocks/-Ordner ist speziell für unser WordPress-Setup. Jeder benutzerdefinierte Gutenberg-Block bekommt seinen eigenen SCSS-Partial, und dieser Partial wird automatisch registriert, wenn ein neuer Block über unser create-block.js-Skript gescaffoldet wird. Die Datei blocks/index.scss wird automatisch aktualisiert — Entwickler fassen sie nie manuell an.

Block-Stile sind isoliert. Die Stile eines Blocks laufen nicht in andere Blocks über. Das ist kritisch, wenn ein Theme 20, 30 oder 50 Blocks ansammelt — Sie brauchen die Gewissheit, dass das Ändern des CSS eines Blocks nichts Unerwartetes woanders auslöst.

Warum @use Statt @import

Das gesamte System verwendet die modernen @use- und @forward-APIs anstelle des Legacy-@import. Das ist keine bloße Präferenz — es löst ein echtes Problem. Mit @import war jede Variable, jedes Mixin und jede Funktion überall global verfügbar. Das klingt praktisch, bis man einen Spezifitätsfehler debuggt, der durch ein Mixin verursacht wurde, von dem man nicht wusste, dass es angewendet wird.

Mit @use deklariert jede Datei explizit, was sie braucht. Nichts schleicht sich still ein. Eine Komponentendatei, die das Breakpoint-Mixin benötigt, schreibt @use '../abstracts' as * oben drauf. Das ist ihr Abhängigkeitsvertrag. Das System ist transparent, und diese Transparenz macht Refactoring sicher.

Die Auszahlung

Ein gut strukturiertes SCSS-System zahlt sich auf drei Arten aus. Geschwindigkeit: Entwickler wissen genau, wo neue Stile hingehören und wo bestehende zu finden sind. Kein Suchen, kein Raten. Konsistenz: Spacing, Typografie und Farben kommen aus einer einzigen Wahrheitsquelle. Die Primärfarbe zu ändern ist eine einzeilige Änderung in _variables.scss. Wartbarkeit: Wenn ein Projekt sechs Monate später für Updates zurückkommt, ist die Codebasis noch navigierbar. Sie erben kein Chaos.

Das SCSS des Mena-Themes ist nicht perfekt — kein System ist es. Aber jede Entscheidung darin wurde bewusst getroffen, und diese Bewusstheit ist das, was eine Codebasis, die skaliert, von einer unterscheidet, die unter ihrem eigenen Gewicht zusammenbricht.