Kategorien
CSS

ITCSS für WordPress Themes

In meinem letzten Beitrag habe ich darüber geschrieben, wie SASS Einzug in das neue Default-Theme Twenty Twenty-One erhalten hat. Mit dazu kam auch eine Struktur der SASS-Dateien, die sich an der ITCSS-Methode anlehnt. Dieser Schritt ist schon etwas besonderes, hat es bisher doch noch keine Präprozessoren in den Default-Themes gegeben. Stattdessen wurde das gesamte CSS in die style.css Datei geschrieben. Wenn man schon seit einigen Jahren mit Präprozessoren arbeitet, dann ist der Gedanke an diese Arbeitsweise doch schon etwas gruselig.

Ich jedenfalls möchte Präprozessoren für CSS gar nicht mehr missen. Angefangen habe ich auch mit SASS, inzwischen arbeite ich lieber mit PostCSS, aber das ist ein bisschen so welche Automarke man gerne fährt. So langsam kommen die Vorteile der Präprozessoren auch im Vanilla CSS an, wie Variablen (CSS Custom Properties) oder auch Verschachtelung (Nesting). Letzteres braucht allerdings noch etwas Zeit, bis es den Weg in die Browser findet. Aber eigentlich ist es egal, für welche Art von Präprozessor man sich entscheidet, ich finde das ist persönlicher Geschmack.

Wie ich mein CSS organisiere

Eine Sache, mit der ich viele Jahre Probleme hatte: wie sortiere/organisiere ich mein CSS sinnvoll? Man fängt entweder irgendwo an oder hat schon eine Code-Basis, z. B. ein Theme, was man selbst erweitern/überarbeiten möchte. Ich denke da hat sich jeder irgendwie eine mehr oder minder sinnvolle Struktur angeeignet. Ich habe auch vieles ausprobiert und bin inzwischen bei ITCSS gelandet. ITCSS steht für Inverted Triangle CSS und hat einen eigentlich logischen Aufbau: man definiert zuerst die Dinge, die global genutzt werden und wird mit jeder Ebene etwas spezifischer. Ich habe die Methode etwas für mich und WordPress Themes angepasst:

Schaubild des Aufbaus der ITCSS-Struktur. Ein umgedrehtes Dreieck, dass in sieben Bereiche aufgeteilt ist. Von oben nach unten stehen die Bereiche neben dem Dreieck: Settings, Tools, Generic, Elements, Blocks, Components und Utilities.

Auf Github habe ich ein Repository angelegt, das ich damals als Vorschlag für Twenty Twenty-One genutzt habe. Da sind auch einige Beispiel-Dateien drin, die den Aufbau etwas erklären. Das Repository ist aber bei weitem nicht vollständig und kann natürlich von jedem nach seinem/ihrem Gusto angepasst werden.

Die Ebenen in ITCSS

Ich habe am Anfang auch erst etwas Hirnschmalz investieren müssen, um den Sinn hinter ITCSS zu verstehen. Aber eigentlich ist es wirklich einfach, es geht vom Groben zum Feinen, vom global gültigen zu sehr spezifischem CSS. Konkret sehen die Ebenen bei mir so aus:

Settings

Hier kommen alle Variablen rein, z. B. Schrift, Farben, Abstände. Brauche ich eine eigene Schriftart im Projekt, lege ich die Regeln mit @font-face in das Settings-Verzeichnis.

Tools

Mixins, also Funktionen jeglicher Art kommen in dieses Verzeichnis. Das können z. B. Mixins für Buttons sein, um alle Buttons das gleiche Grundlayout zu geben. Im Prinzip kommt hier modulares CSS rein, was an mehreren Stellen zum Einsatz kommen kann.

Generic

Während in den ersten zwei Ebenen kein CSS zustande kommt, dass das Aussehen der Seite beeinflusst, geht es auf der Generic-Ebene richtig los. Hier kommt sowas wie die Definition für das Box-Sizing oder Normalize.css vor. Oder was auch immer du gerne als „CSS Reset“ nutzt.

Elements

Mit den ersten drei Ebenen sind die „vorbereitenden Maßnahmen“ nun abgeschlossen und das projektspezifische CSS kann folgen. Auf dieser Ebene werden aber erstmal nur alle HTML-Grundelemente definiert: Links, Tabellen, Bilder, Überschriften, Formulare… Im Prinzip dürfen alle HTML-Tags konkret definiert werden. Allerdings werden hier keine CSS-Klassen oder -IDs definiert. Auch nichts spezifisches von WordPress.

Blocks

Wer mit dem Block-Editor/Gutenberg arbeitet, der kann das Theme-spezifische CSS für die Blöcke auf dieser Ebene einfügen. Ich habe diese Ebene hier hin gepackt, da die Blöcke auf verschiedenen Seiten zum Einsatz kommen können und in Zukunft, wenn das Full Site Editing Einzug halten wird, auch auf die Bereiche wie Header und Footer anwendbar sind. Wer mag, kann hier auch für jeden Standard-Block einen Unterordner einfügen und darin Dateien jeweils für das Frontend und das Backend anlegen, wie es z. B. bei Twenty Twenty-One der Fall ist.

Components

Hier kommt alles rein, was spezifisch für einen Bereich wie Header, Navigation, Footer, Sidebar deklariert wird. Auch WordPress-spezifische Elemente wie Archive, Kommentare, Single oder Page dürfen in dieser Ebene eingesetzt werden.

Utilities

Die letzte Ebene ist quasi ein Sammelbecken für spezifische Klassen, die an verschiedenen Stellen eingesetzt werden können, aber keinem der vorher genannten Bereiche zugeordnet werden können. Das sind so Sachen wie Dinge zur Barrierefreiheit, Farbpaletten, Standard-Klassen wie alignwide und alignfull oder jegliche Helfer-Klassen, die man in seinem Theme benötigt.

Fazit

Ich habe oben im Beitrag einen Artikel zu ITCSS verlinkt, der das ursprüngliche Konzept ziemlich gut erklärt und weitere Ressourcen bereithält. Wenn man dieses mit meiner Version vergleicht sieht man ein paar Unterschiede bei den Ebenen – im Prinzip habe ich das Konzept nur an WordPress angepasst. Für mich funktioniert das so richtig gut und ich fühle mich in dieser Struktur sehr wohl und finde mich da gut zurecht. Wenn ich ein bestehendes Theme mit eigenem CSS erweitern / verbessern möchte, nutze ich nicht die volle Struktur davon, sondern nur einen Teil. So fällt die Generic-Ebene raus, da meistens sowas schon vom Parent-Theme kommt. Die anderen Ebenen enthalten dann auch nur die Sachen, die ich im Child-Theme definieren muss. Manchmal habe ich dann auch nur fünf oder sechs einzelne Dateien statt eine komplette Ordner-Struktur. Aber da kann sich jeder selbst eine Arbeitsweise überlegen. Wie sortierst du dein CSS?

4 Antworten auf „ITCSS für WordPress Themes“

Super interessanter Ansatz, Jessica! Hast du zufällig Erfahrung oder Ideen oder Lesestoff dazu, ob und wie sich das CSS für die Blocks, anstatt in einer globalen CSS-Datei, granular ausliefern lässt? Also für jeden Block nur dann, wenn er im Frontend geladen wird? Und dann auch nicht doppelt und dreifach, wenn der gleiche Block mehrmals auftaucht? Wurde sowas schon mal für ein default Theme diskutiert?

Ich weiß gar nicht, ob sich jemand schon mal die Mühe gemacht hat, das CSS für jeden einzelnen Block granular aufzusplitten, um es dann einzubinden. Ich arbeite eigentlich so, dass ich die Standard-Styles nehme und dann nur das überschreibe, was ich zum Anpassen an mein vorgegebenes oder gewünschtes Design brauche. Geladen wird ja alles, damit alles auch immer überall verfügbar ist. Das ist meiner Meinung nach bei Gutenberg noch im absolut akzeptablen Rahmen, bei den bekannten Page Buildern sieht es dann halt schon ganz anders aus.

Was die Default-Themes angeht, da mahlen die Mühlen sehr langsam meiner Einschätzung nach. Weil man will es ja so einfach wie möglich halten, um auch unerfahrenen Einsteigern die Möglichkeit zu geben, das zu verstehen. Das limitiert natürlich jegliche Professionalität und somit auch komplexere Strukturen, nicht nur im CSS.

Danke für die Einschätzung! Stimmt, für ein Default Theme wäre das vielleicht nicht vereinbar mit dem Bildungsanspruch.

Ansonsten fände ich es schon ein interessantes Experiment im Hinblick auf Web Vitals. Häufig ist ja „Remove unused CSS“ eine der letzten Empfehlungen, die bei einer gut optimierten Seite noch stehen bleiben. Bei Inhalten wie diesem Artikel hier fällt das sicherlich weniger ins Gewicht (geschätzte Einsparung: 0,15s nach meiner Messung eben), aber bei komplexeren Sites mit mehr CSS kann es eventuell schon noch mal an der Performance-Schraube drehen.

Auf jeden Fall danke nochmal für den erleuchtenden Beitrag, hab’ was gelernt! 🎉

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert