Unverständnis von CSS

Es gibt zahlreiche Blogartikel und Twitter-Threads, die sich um das vermeintlich unverständliche CSS drehen. Sie stammen eigentlich immer aus der Feder eines JavaScript-Entwicklers. Aktuell kam mir ein Artikel von Golo Roden in einem Blog des heise-Verlags unter. Ich habe Golo als kenntnisreichen Sprecher über JavaScript kennengelernt und schon einen Workshop zu Funktionalem JavaScript bei ihm besucht.

CSS scheint aber ausweislich seines Artikels nicht zu seinen Stärken zu gehören. Trotzdem traut er sich eine öffentliche Einschätzung zu. Ich kann sie nicht unwidersprochen durchgehen lassen.

Worum geht es?

Im Artikel geht es um die alte Geschichte, dass viele JavaScript-Entwickler – vor allem die React-Entwickler – einen Narren an der Idee gefressen haben, dass man CSS innerhalb ihrer JS-Dateien schreiben soll.
Kombiniert wird dieser Gedanke immer mit dem als Vorwurf gemeinten Statement, CSS sei global und das widerspreche der sonstigen Entwicklung.

Es geht in dem ganzen Artikel eigentlich nie um CSS, sondern nur darum, wie Menschen, die hauptsächlich mit JS arbeiten und sich für die Eigenarten von CSS nicht interessieren, möglichst einfach und fehlerfrei mit CSS umgehen können.

Es geht auch nie um modernes CSS, auch wenn er es immer wieder so benennt. „Modernes CSS“ existiert nicht dadurch, dass man CSS-Regeln in JS-Dateien verpackt. Es existiert auch nicht automatisch durch die Nutzung eines Präprozessors. Beides sind nur Tools. Modernes CSS existiert, wenn man bspw. CSS-Grids, CSS-Shapes, Custom Properties (vulgo CSS-Variablen) oder 3D-Transformationen benutzt. Mit React oder Sass kann ich selbstverständlich auch absolut Positionieren oder Floaten, was wiederum sehr altes CSS wäre.

Golo benutzt auch gerne „Moderne Webentwicklung“, wenn er eigentlich von React-Entwicklung spricht. Kann man machen, macht aber keinen vertieften Sinn. Schliesslich ist das 2013 veröffentlichte React nur ein Tool, mit dem ich etwas modernes, aber auch etwas sehr altbackenes machen kann. Und wenn ich serverside Rendering nutze, ist es nichts anderes als eine Neuerfindung von PHP.

Reihenfolge der Sprachen

Im Teaser schreibt Golo:

„CSS ist die dritte große Sprache der Webentwicklung, neben HTML und JavaScript. Im Gegensatz zu diesen beiden wird CSS allerdings von vielen Entwicklerinnen und Entwicklern eher stiefmütterlich behandelt.“

Nun, dann wollen wir mal exakt sein: der Logik und der Geschichte nach ist JavaScript die dritte Sprache im Frontend. Sie ist zudem diejenige, die man am Ehesten weglassen kann (meine private Webseite benutzt keine Zeile JS – wozu auch?). Und sollte man mit JS arbeiten, dann tut man dies sehr oft, um am Ende HTML und CSS zu erzeugen.

Letzteres wird sehr gerne übersehen, denn es bedeutet, dass man HTML und CSS auch als JS-Entwickler können sollte – oder jemanden kennen sollte, der dies tut. Es ist wie mit Backend-Code: „Am Ende ist doch alles HTML“ (und CSS).

HTML strukturiert die Webseite, CSS macht sie im Idealfall lesbarer und attraktiver. JavaScript benötigt man nur für Dynamik. Nicht immer ist der Einsatz sinnvoll und gerechtfertigt.

Der Bildungshintergrund ist wichtig

Golo hat Recht, dass CSS von Entwicklern sehr häufig stiefmütterlich behandelt wird. Aber er sollte vollständig formulieren: HTML und CSS werden sehr häufig von JavaScript-fokussierten Entwicklern stiefmütterlich behandelt.
Die Seite „HTMHell“ von Manuel Matuzovic zeugt von der grausamenn Misshandlung unschuldiger HTML-Elemente durch ignorante und ungebildete Entwickler.

Es ist das alte Problem des Wissens. So wie Aberglauben (und Religion) dadurch in die Welt kommt, dass Phänomene nicht erklärt werden können, so scheint sich bei vielen JS-fokussierten Entwicklern der Mythos zu halten, CSS sei kaputt, defekt, einfach schlecht designt.

Klar, wenn man mit der Brille des JS-Entwicklers auf CSS blickt, ist diese Sprache seltsam und kaputt. Umgekehrt klappt das übrigens auch: ich bin kein studierter Entwickler, sondern Politikwissenschaftler. Ich hatte zu Beginn meiner Karriere enorme Schwierigkeiten mit dem Verständnis von JavaScript. Alles wurde einfacher und verständlicher, als jQuery in mein Leben trat. Ich habe es immer als „JavaScript für Nichtkönner“ bezeichnet.

Welcher JS-Entwickler würde nun also meine Kritik an JS akzeptieren, weil es nicht so schön einfach und elegant wie jQuery in seiner Gänze ist? Selbst die mittlerweile jQuery nachempfundenen Veränderungen der Sprache haben nicht die ursprüngliche Eleganz des Originals. Ich kann mich noch super erinnern, dass mir bei der Lobpreisung von jQuery immer entgegenschallte, ich solle doch endlich richtig JavaScript lernen.

Dem stimme ich zu und muss mittlerweile einsehen, dass ich mich mit reinem JS niemals so wohl und sicher fühlen werde, wie mit jQuery. Doch der mal gut gemeinte, mal aggressive Rat an mich, richtet sich auch umgekehrt an Golo und die anderen, denen CSS nicht geheuer ist: Lernt CSS!

Lernt CSS!

Das Wichtigste dabei ist, sich auf eine andere Sprache einzulassen. Sie ist nicht einfach ein Bruder von JavaScript und gehorcht den gleichen Gesetzen. CSS ist eine eigene Sprache und hat seinen eigenen Zwecke. Deshalb kann man nicht mit einem React-Mindset an die Sache herangehen. Umgekehrt funktioniert es auch nicht, das wiederum ist jedem klar.

Zu Beginn seines Artikels schreibt Golo:

„Außerdem tendiert CSS dazu, rasch unübersichtlich zu werden, wofür es mehrere Gründe gibt. Zum einen fehlen klar in der Sprache definierte Regeln, wie CSS zu strukturieren ist. Zum anderen ist CSS per Definition global, weshalb es häufig unerwünschte Seiteneffekte gibt, die zu Konflikten zwischen eigentlich unabhängigen Komponenten führen.“

So viele Missverständnisse in so wenigen Worten. Es sind aber die gängigen Missverständnisse.

Ja, CSS fehlen klar definierte Regeln, wie man CSS strukturieren soll. Mir sind umgekehrt keine bei JavaScript bekannt. Wenn React solche bieten sollte (ich habe von React keine Ahnung), dann ist das sehr nett. Aber dann liegt es daran, dass sich jemand für ein Framework, das die Sprache JavaScript nutzt, diese Gedanken gemacht hat. Ein Vergleich in der CSS-Welt sind Frameworks wie Bootstrap, Tailwind oder auch BEM (das viel mehr als nur die Notationsregeln ist). Bootstrap gibt wenig Hlfestellung, Tailwind und BEM hingegen definieren Denkweisen, also das, was Golo fehlt.

CSS ist global, das ist richtig. Und das ist auch gut so. Denn es ist dafür geschaffen, ganze Seiten und Sites zu gestalten. Wenn man nun mit CSS jedem Absatz, Link, Headline und List-Item seine Eigenschaften mitgeben müsste, wäre dies sehr ineffizient.

Und wie oft muss man auf einer Webseite komplett unterschiedlich aussehende Formulare gestalten? Meist reduziert es sich darauf, dass das Suchformular in der Hauptnavigation anders aussieht, als normale Textfelder. Alle anderen Formulare sehen aber gleich aus. Dafür ist es natürlich hilfreich, wenn man globale Styles hat.

JavaScript hingegen ist im Wesentlich für kleine Effekte geschaffen. Dass es mittlerweile anders genutzt wird, steht auf einem anderen Blatt. Der Fokus der Sprachen unterscheidet sich, aber es gibt immer Lösungen um das jeweilige Problem herum. Für CSS ist es einfach: jede Klasse und jeder Kontextselektor bringt eine Abweichnung vom Standard. Das ist in der Sprache angelegt und gewollt. Es ist kein Fehler der Sprache, wenn manche Entwickler das nicht begreifen oder wissen. Seiteneffekte zwischen Komponenten treten immer dann auf, wenn man nicht gut genug geplant hat. Aber es möchte mir doch bitte niemand sagen, dass es solche Momente nicht auch in der JavaScript-Entwicklung gibt? Werden da keine if-Bedingungen mehr genutzt?

Ziel „moderner Webentwicklung“

Als nächstes kommt eine klare Ansage:

„Das Ziel der modernen Webentwicklung muss daher sein, CSS möglichst lokal und isoliert zu verwenden, sodass Seiteneffekte keinen Einfluss außerhalb des gewünschten Bereichs nehmen können.“

Kurze Antwort: Nö.

Lange Antwort: Es geht auch hier wieder nicht um „moderne Webentwicklung“, sondern um JS-Applikationen. Es geht desweiteren um Entwickler, die keine Lust haben, sich um die Funktionsweise von CSS zu kümmern und die Sprache ihren Stärken und Schwächen adäquat zu benutzen. Deshalb sollen wir in die Anfangszeit des Web zurück, als wir unsere Editoren haben sehr viel Inline-CSS haben schreiben lassen. Spätestens in diesem Kontext sollte Golo der Ehrlichkeit halber nicht mehr von „Moderner Webentwicklung“, sondern von „JavaScript-fokussierter Webentwicklung“ schreiben. Das wäre ehrlicher. Es würde sich sicherlich auch noch ein weniger neutral formulierter, aber noch besser passender Begriff finden lassen.

Warum keine Klassen?

Glücklicherweise erklärt Golo kurz und knapp, warum echte Inline-Styles uns nicht weiter helfen: sie haben sehr beschränkte Möglichkeiten.
Er könnte nun aber für die Nutzung von Atomic CSS plädieren, also bspw. das aktuell gehypte TailwindCSS. Nicht dass ich dem allzu viel abgewinnen könnte. Aber die Argumentation bliebe innerhalb des CSS-Universums.

Stattdessen erklärt Golo ausführlich die Vor- und Nachteile von CSS-Modules und Styled-Components. Womit wir wieder im JS-Universum wären.

Nachdem er beide vorgestellt hat, erklärt er BEM für die „moderne Webentwicklung“ als ausgedient und irrelevant. Auch Präprozessoren werden seiner Ansicht nach auf einmal unwichtiger. Kann es sein, dass React nicht gut mit Sass zusammenspielt und er es deshalb nicht besser weiss?

Sein Verständnis von Themes

Themes sollen laut Golo zweierlei:

1. „die Auswahl an Größen, Abständen, Farben & Co. limitieren“
2. „verschiedene Designs umsetzen, zwischen denen Anwenderinnen und Anwender gegebenenfalls wechseln können“

In meinen Augen gehören beide Punkte zusammen und zudem werden Themes auf Webseiten sehr selten bis nie zur Erbauung der Anwender erstellt. Das mag bei Applikationen der Fall sein. Aber auf Webseiten sind Themes wichtig, um Abteilungen eine leicht andere Optik zu geben oder um die gleiche Website an mehrere Kunden mit eigener Optik zu lizensieren (White-Label).

Für beides gibt es unterschiedliche Realisierungsmöglichkeiten, seit vielen Jahren. Sie sind gut erprobt und oft beschrieben. JavaScript wir dafür definitiv nicht benötigt. Der wirkliche Gamechanger sind hier die Custom Properties (vulgo CSS-Variablen), aber nicht irgendeine JS-getriebene Technik.

Seltsames CSS-Verständnis

Im Kapitel über Styled Components findet sich dies:

„Auf dem Weg ist man als Entwicklerin oder Entwickler gezwungen, jedem gestalteten Element einen eigenen fachlichen Namen zu geben, sodass man nicht (wie häufig bei klassischem CSS) mit zahllosen div-Elementen hantieren muss, sondern von vornherein eine fachliche Struktur aufbauen kann.“

Aus dem Abschnitt wird nicht klar, was Golo mit dem „fachlichen Namen“ meint. Ich fürchte, er meint damit einen eigenen Namen, der dann als WebComponent realisiert wird.

Ich würde doch erst einmal davon ausgehen, dass wir unsere Seite mit HTML strukturieren. Die „fachlichen Namen“ hier heissen „Elemente“ und werden durch „Tags“ repräsentiert. Sollten wir also einen Button benötigen, nutzen wir das Button-Element und schreiben <button>. All diejenigen, denen HTML (und meist auch CSS) vollkommen egal ist, tendieren dazu, an Stelle des Button-Elements ein <div> zu schreiben und den Rest dann sinnloserweise die JS-Magie tun zu lassen. „Das kannste schon so machen, dann isses aber halt Kacke!„

Wenn wir Ahnung von unserer Profession haben und mit DIV-Elementen hantieren, kann das mehrere Gründe haben:

1. Wir nutzen das DIV zur Strukturierung von Seitenbestandteilen.
2. Wir nutzen das DIV zur Erstellung eines Layouts. Die DIV-Container fungieren dabei wie Kästchen in einem Setzkasten.
3. Wir nutzen das DIV für einen Wrapper, um darin bspw. einen iframe absolut zu positionieren und damit skalierbar zu machen.
4. Wir haben kurze Textfragmente, die kein kompletter Satz sind und deshalb – jedenfalls meiner bescheidenen Meinung nach – nicht in einen Absatz gehören.
5. Leider hat das W3C viel zu wenige Formularelemente geschaffen. Deshalb müssen wir manchmal mit JS nachhelfen. Ein ansonten eigenschaftsloser DIV-Container ist dafür bestens geeignet.

Es ist aber nicht so, dass wir einfach nur DIVs mit CSS gestalten. Wer dies tut, ist kein guter Frontend-Entwickler.

Mein Fazit

Normale Webseiten sind nicht wirklich Gegenstand des Artikels. Golo schreibt offensichtlich nur mit dem Fokus auf React/JavaScript-Entwickler.

Die meisten beschriebenen Probleme sind keine. Sie sind einfach ein Mangel an Information. Zudem liessen sich auch viele Probleme mit CSS-Mitteln lösen, indem ein Atomic CSS-Ansatz wie TailwindCSS genutzt wird.

Aber egal was ein Entwickler tut, eines ändert sich nie: egal ob ich handgeklöppeltes CSS nehme, es durch Sass oder Styled Components generieren lasse, ich sollte wissen, was ich in dieses CSS schreibe. Kein Tool macht das hineingegebene CSS besser. Wenn man diese Sprache nicht begriffen hat, hilft React kein Stück weiter.

Es ist also alles Spiegelfechterei. Lernt CSS, dann wird Euer CSS, egal über welchen Transportweg, auch gut. Wenn ihr keine Ahnung von CSS habt, hilft Euch leider auch kein Tool.