Utility-First CSS

Jede Webseite besteht aus zwei Teilen: dem Inhalt und den Gestaltungsregeln, die bestimmen, wie dieser Inhalt aussieht. Diese Regeln legen Dinge fest wie Schriftgröße, Farbe oder Abstände. Klassisch schreibt man solche Regeln in eigene Dateien und gibt ihnen sprechende Namen wie « Hauptmenü » oder « Produktkarte ». Utility-First CSS dreht das um. Hier gibt es Hunderte winziger Regeln, die je genau eine Sache tun: eine für roten Text, eine für vier Pixel Abstand, eine für fette Schrift. Der Entwickler kombiniert diese Bausteine direkt dort, wo der Inhalt steht.

Warum Entwickler sich Namen sparen wollen

Das größte Problem klassischer Gestaltungsregeln ist das Benennen. Für jedes neue Element muss sich jemand einen Namen ausdenken. Heißt der Kasten nun « Infobox », « Hinweis » oder « Karte klein »? In großen Projekten mit vielen Beteiligten entstehen so schnell Hunderte Namen, die niemand mehr überblickt.

Dazu kommt ein zweites Problem. Niemand traut sich, alte Regeln zu löschen. Vielleicht benutzt sie ja noch irgendeine Seite, die man gerade nicht im Kopf hat. Also wächst die Gestaltungsdatei immer weiter, auch wenn die Hälfte davon längst tot ist. Bei Utility-First CSS gibt es dieses Wachstum nicht, weil die Bausteine von vornherein feststehen und immer wieder verwendet werden.

Der Ansatz ist deshalb vor allem eine Antwort auf ein Organisationsproblem, nicht auf ein technisches. Die Seite wird dadurch nicht schneller oder schöner. Sie wird für ein Team leichter zu pflegen. Genau das ist der Grund, warum der Ansatz in den letzten Jahren so verbreitet ist.

Bausteine statt eigener Regeln

Ein Utility ist eine Regel, die genau eine Eigenschaft setzt. Sie trägt einen kurzen, technischen Namen, der beschreibt, was sie tut. Ein Baustein namens « text-red » färbt Text rot, « p-4 » erzeugt einen Innenabstand. Diese Namen sind bewusst nicht kreativ, sondern systematisch aufgebaut.

Ein blauer Knopf mit runden Ecken entsteht dann nicht aus einer Regel namens « Knopf ». Er entsteht aus vier oder fünf Bausteinen nebeneinander: blauer Hintergrund, weiße Schrift, Innenabstand, runde Ecken. Wer den Knopf ändern will, tauscht einen Baustein aus und sieht sofort, was passiert. Man muss dafür in keine andere Datei springen.

Damit die Seite nicht mit Tausenden ungenutzten Bausteinen ausgeliefert wird, gibt es einen Zwischenschritt. Ein Programm durchsucht vor der Veröffentlichung den gesamten Projektcode und behält nur die Bausteine, die wirklich vorkommen. Übrig bleiben oft nur wenige Kilobyte. Ohne diesen Schritt wäre der Ansatz kaum praktikabel.

Tailwind, Bootstrap und die Kritik

Das bekannteste Werkzeug dieser Art ist Tailwind CSS, das seit 2017 existiert und heute in sehr vielen neuen Webprojekten steckt. Wer den Quelltext moderner Seiten anschaut, erkennt es an langen Ketten kurzer Klassennamen im Code. Auch fertige Baukästen für Oberflächen bauen inzwischen darauf auf.

Abzugrenzen ist der Ansatz von Bibliotheken wie Bootstrap. Die liefern fertige Bauteile, also einen kompletten Knopf oder ein komplettes Menü. Utility-First liefert nur die Einzelteile und überlässt das Zusammensetzen dem Entwickler. Das ist aufwendiger, führt aber zu Designs, die weniger nach Standardvorlage aussehen.

Kritik gibt es reichlich. Der Code wird unübersichtlich, weil in einer einzigen Zeile zehn Bausteine stehen können. Manche halten das für einen Rückschritt in die Anfangszeit des Web. Verteidiger antworten, dass sich Wiederholungen in modernen Baukästen ohnehin in wiederverwendbaren Komponenten bündeln lassen. Die Debatte darüber gehört zu den langlebigsten Streitpunkten in der Webentwicklung.