Ich habe mir endlich mal Tailwind angeschaut. Ich wollte wissen, was man von dem neuen Framework lernen kann und wie Tailwind und WordPress zusammenpassen.

Anfang des Jahres flatterte ein Artikel in meinen Feed, in dem es um die die StateOfCSS-Umfrage 2020 geht: State of CSS Report 2020. Darin heißt es sinngemäß: CSS entwickelt sich weiter. Nicht nur neue Specs kommen dazu, auch neue Methoden wie “utility first”. Und die gehen nicht mehr weg, gewöhnt euch dran.

Was mit “utility first” gemeint ist kann man hier nachlesen und nachgucken: Utility-First Tailwind CSS  

Die Utility-First-Methode hat mich spontan erst Mal nicht angesprochen. Da bemühen wir uns jahrelang, semantisches, gut lesbares CSS zu schreiben und das HTML möglichst „clean“ zu halten. Und das soll jetzt plötzlich nicht mehr gelten? *krückstockfuchtel

Bei der semantischen Methode denkt man sich Namen für Klassen aus, die möglichst verständlich und nachvollziehbar sein sollen.
Im HTML sieht das dann so aus:

<div class=”card">Code-Sprache: HTML, XML (xml)

Bei Tailwind haben die Klassen abstrakte Bezeichnungen:

<div class="relative px-4 py-10 bg-white shadow-lg sm:rounded-3xl sm:p-20">Code-Sprache: JavaScript (javascript)

Das Tailwind-Markup kann man “lesen”, wenn man gelernt hat, was die Abkürzungen bedeuten. Was die Klasse “card” alles beinhaltet, weiß ich dagegen erst, wenn ich sie in der CSS-Datei gefunden habe. 

A propos Abkürzungen: Ich arbeite in VS Code mit der Extension Tailwind CSS Intellisense. Die Extension schlägt per Autocomplete die richtigen Tailwind-Klassen-Namen vor. Und wenn man im HTML über eine Klasse geht, wird das CSS dazu angezeigt. Das ist schon sehr cool.

Aber die Semantik!

Ganz ehrlich – das Ausdenken von sinnvollen Namen für CSS Klassen ist mir nie ganz gelungen. Wenn ich mir ein Projekt anschaue, das ich vor einem Jahr bearbeitet habe, stolpere ich früher oder später über Namen, die mir rein gar nichts sagen. 

Wenn ich schon meinen eigenen Code nicht mehr verstehe, wie geht es dann jemandem, der mein CSS übernehmen muss? Utility-First-Klassen, die so heißen, wie sie funktionieren, versteht hingegen jeder (fast) sofort.

Tailwind

Ich kann nur jedem empfehlen, sich Tailwind mal näher anzuschauen. Ich kann gut verstehen, warum die Leute davon so begeistert sind. Tailwind ist wirklich eindrucksvoll und super smart gemacht. Es gibt sogar einen Playground, wo man das Ganze ausprobieren kann. 

Der Clou: PurgeCSS

PurgeCSS sorgt dafür, dass am Ende nur die CSS-Klassen aus dem Tailwind-Framework in der style.css vorkommen, die auch tatsächlich im Projekt verwendet werden. PurgeCSS geht alle HTML, PHP und JavaScript-Dateien durch und gleicht sie mit den in Tailwind definierten CSS-Klassen ab. 

Die Tailwind-Klassen bringen zusammen rund 3 MB auf die Waage. Nach dem Purge-Vorgang reduziert sich die Dateigröße in der Regel auf wenige Kilobyte. Bei anderen Frameworks wie Bootstrap muss man eine Menge Ballast mit sich herumschleppen. Unter anderem deshalb bin ich damit nie warm geworden.

Lots of Tooling

Um Tailwind zu nutzen und zu betreiben, braucht man eine professionelle Entwicklungsumgebung. Viele Helferlein müssen übers Terminal installiert und gesteuert werden. Ohne diese Tools funktioniert Tailwind nicht. Hier die Anleitung zur Installation.

Mir hat CodeKit einiges abgenommen. Freundlicherweise haben die Entwickler im Februar 2021 ein Update rausgebracht, mit dem man sich ganz fix ein Tailwind-Projekt aufsetzen kann. Oder man nutzt ein Projekt wie TailPress von Jeffrey van Rossum. Da ist alles sehr schön vorkonfiguriert und das Installieren geht wirklich schnell.

Ein Tailwind-WordPress-Theme ist zunächst mal ungewohnt, weil die CSS-Informationen nicht mehr alle schön übersichtlich in einer style.css stecken. Es gibt viele json-Dateien, über die ich mir mein Tailwind-Projekt konfigurieren kann.

Man muss sich also umstellen, aber da geht es in Zukunft lang: Bei Block Based Themes und Global Styles gehört eine json-Datei ganz selbstverständlich zum Theme dazu.

Tailwind und WordPress

WordPress und der Editor bringen viele CSS-Klassen schon mit. Diese Klassen kann ich nicht einfach durch Tailwind-Klassen ersetzen, ich kann sie nur ergänzen. Will ich Tailwind integrieren, muss ich die Tailwind-CSS-Klassen per @apply in bestehende Klassen einbinden.

Wenn ich über @apply arbeite, schreibe ich die Tailwind-Klassen einfach hintereinander:

.site-main{
@apply relative py-3 sm:max-w-xl sm:mx-auto;
}

Fazit

Ich habe einiges mitgenommen von meinem Ausflug in die Welt von Tailwind. Durch die vielen vorgegebenen WordPress-CSS-Klassen ist ein WordPress-Theme kein “weißes Blatt” und man muss Kompromisse machen. Aber es gibt durchaus Spielraum, in dem Tailwind sein Potenzial entfalten kann.

Ein wichtiger Punkt für die Entscheidung Pro oder Contra Tailwind ist sicher die Größe eines Projekts. In Projekten mit vielen tausend Zeilen Code mit einem großen Team ist ein gut lesbares CSS enorm wichtig. Tailwind gibt hier klare Regeln vor. Ich denke, dass es sinnvoll sein kann, bei großen Projekten auch im WordPress-Kontext Tailwind einzusetzen. 

Ich vermute, dass noch etwas eine Rolle spielt: Mit Tailwind kann auch jemand den CSS-Part übernehmen, dessen Schwerpunkt weniger auf CSS liegt. Um Tailwind anzuwenden, reicht ein grundlegendes CSS-Verständnis. CSS-Systematik, Spezifität und so weiter spielen erst Mal keine große Rolle.

Meine Projekte sind klein bis mittelgroß. Die Code-Basis ist übersichtlich, mein CSS kann ich über die ITCSS-Systematik und Sass schlank halten. Hier kommen die Vorteile von Tailwind momentan nicht so richtig zum Tragen.