Kategorien
CSS

SASS in Twenty Twenty-One

Gerade wird die Beta 1 von WordPress 5.6 vorbereitet, während ich diesen Satz hier tippe. Eines der großen Neuerungen für das Release, was am 8. Dezember erscheinen soll, ist das neue Standard-Theme Twenty Twenty-One. Seit einem Monat kann fleißig auf Github mitgeholfen werden, das Theme zum Release schön rund zu bekommen.

Als technische Basis diente diesmal das Theme Seedlet, welches von Automattic erstellt wurde und auf wordpress.org sowie wordpress.com verfügbar ist. Als ich mir die Theme-Dateien das erste Mal angeschaut habe, ist mir gleich die doch recht komplexe SASS-Struktur ins Auge gefallen.

Präprozessor oder nicht?

Es wurde intern diskutiert, ob man wie bisher einfach mit einer riesigen CSS-Datei, nämlich der regulären style.css (natürlich dann auch noch analog die style-editor.css) das Theme umsetzen sollte, oder ob man doch endlich Präprozessor einführt, um den Entwicklungsprozess zu beschleunigen. Da ich nun schon seit vielen Jahren mit SASS und PostCSS arbeite, habe ich mich persönlich für letzteres ausgesprochen.

Die Standard-Themes von WordPress sind dahingehend ausgelegt, dass sie einfach zu verstehen sein sollen, um unerfahrenen Personen die Möglichkeit zu geben, selbst Änderungen vorzunehmen. Am besten natürlich in einem Child-Theme. Mit Blick auf das von Seedlet mitgelieferte SASS war es alles andere als „einfach“: sehr viele CSS-Variablen, verstreut auf viele einzelne Dateien machten das nicht „mal eben“ durchschaubar.

Also habe ich einen Vorschlag unterbreitet, das SASS in eine einfachere Struktur zu setzen, die etwas mehr selbsterklärend und nicht so überfordernd ist. Ich persönlich arbeite seit über einem Jahr sehr gerne it der Methode des ITCSS, also des Inverted Triangle CSS. Dabei habe ich es für den Anwendungsfall von WordPress etwas abgewandelt und in einem Github Repository zur Verfügung gestellt. Mein Vorschlag wurde für gut befunden und das bisherige SASS von Seedlet wurde in die neue Struktur gegossen.

Es funktioniert

Nach einigen anfänglichen Wehwehchen und mit verbesserter Handhabung der Kompilierung durch eine Github Action läuft es inzwischen tatsächlich sehr rund. Durch das „eine Quelle, zwei Outputs“ ist auch das Erstellen einer zusätzlichen Stylesheet-Datei für den Block-Editor einfach eine sehr willkommene Arbeitserleichterung. Stellt euch vor, man hätte alles von einer in die andere Datei bei jedem Commit kopieren müssen. Ich wäre da persönlich wahnsinnig geworden. 😀

Im nächsten Blogpost stelle ich dann meinen Vorschlag etwas genauer vor, warum der Weg mit ITCSS für mich aktuell am besten funktioniert.

Eine Antwort auf „SASS in Twenty Twenty-One“

Was sind denn deiner Ansicht nach die wichtigsten Aspekte, die für den PostCSS Workflow sprechen? Autoprefixing und linting kann man ja auch im Sass Workflow gut integrieren. Welche PostCSS Plugins sind es, auf die du nicht verzichten wolltest? (Ich hänge immer noch bei Sass).

Schreibe einen Kommentar

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