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: .

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.

5 Responses to “Unverständnis von CSS”

  1. Vielen Dank Jens,

    Dein Beitrag zu dieser Sache entspricht genau meiner Denkweise. Ich gebe zu selbst in den letzten Jahren viel unstrukturiertes CSS geschrieben zu haben, weil mit im Projekt die Zeit fehlte oder ich nur glaubte, dass mir die Zeit fehlte.

    Jetzt wage ich einen kompletten Neuanfang und gehe dahin zurück, wo CSS eben stark ist: globale Gestaltung und was ist auf Websites immer noch das wichtigste: globale Informationsgestaltung. Dazu brauche ich all diese Custom-Styles, Custom-Elemente überhaupt nicht. Und wenn ich für das Content-Design einen globalen Weg einschlage, dann ist die CSS-Datei nicht wirklich mehr ein schlecht strukturiertes Dokument sondern ein einfach strukturiertes.

    Atomic-Design wie bei Tailwind lehne ich komplett ab. Wenn ich sehe für was es alles css-Definitionen gibt – das war doch nicht der Gedanke von CSS, dass eins alles atomisiert individuell gestaltet. In den meisten Fehlen ist doch die Dokumentenstruktur so einfach – oder sollte so sein, dass ich gut ohne all die atomisierten Klassen auskomme. Tailwind ist ein Trend, ein Hype, er wird vorüberziehen.

  2. Christian sagt:

    Toller Artikel, entspricht ziemlich dem, was ich mir beim lesen von Golos Artikel dachte. Eigtl. Schade, denn die Erklärbärreihe ist sonst ziemlich gut mMn. Habe da sehr viel für mich mitgenommen.
    Aber CSS-in-JS schüttelt mich immer noch… Bin selbst erst wieder in Frontend-Architektur eingestiegen und habe ITCSS/BEM und Konsorten neu entdeckt.

    Ich hab erst mit React angefangen, daher habe ich nur einen beschränkten Erfahrungsschatz. Aber CSS Module gehen wunderbar mit Sass. Das kann es also nicht sein 🙂

    Nachdem ich mir erst nicht vorstellen konnte, für was denn CSS Module überhaupt sinnvoll sind (man kann ja Komponenten auch in ITCSS/BEM abbilden), habe ich mich bei einem mir bekannten Software-Architekten erkundigt. Dessen Erklärung für den Einsatz war mir dann schlüssig. Qquasi bei vielen, verteilten Komponenten/Entwicklerteams, wo man die Nutzung/Entwicklung nur noch bedingt unter Kontrolle hat -> Framework/Library und das globale CSS/Theme nicht gefährden möchte. Sowas hatte ich mir nämlich auch skizziert.

    Man kann sich ja immer noch ein globales Themeing aufbauen und wenn Komponenten etwas spezielles nutzen, kommt dass dann per CSS Modulen, was dann auch durch Webpack mehr oder weniger performant ausgeliefert wird. So mache ich es jetzt zum Beispiel in meinem Lernprojekt.

    Es gibt imo einfach nicht die absolute Wahrheit, dieses Schwarz/Weiss denken (von beiden Seiten) finde ich grausam.

  3. Hachseufzschmacht, Jens, ich könnte einige Zeilen deines Artikels knutschen!
    Spricht mir aus der Seele. Vielen Dank!

  4. Tim Kraut sagt:

    Hi Jens,

    ich will eine kleine Lanze für React und JavaScript-basierte CSS-Deklarationen brechen – ohne dir widersprechen zu wollen. In dem erwähnten Artikel von Golo gibt es einige Punkte, denen ich nicht zustimmen würde bzw. die ich eher für suboptimal formuliert halte. Aber der Reihe nach:
    Ich stimme Golo dahingehend zu, dass CSS von vielen Entwicklern (gilt nicht nur für JavaScript-Entwickler sondern auch für viele Backend-Entwickler) eher stiefmütterlich behandelt wird. Es gibt durchaus auch Aspekte in CSS, die nicht unbedingt als Musterbeispiel für Konsequenz oder intuitives Verhalten durchgehen dürften wie z.B. Collapsing Margins oder Whitespace zwischen Elementen trotz margin:0 z.B. Das größte Problem für komponenten-basierte Webapplikationen (unabhängig von React und Co) dürfte aber sein, dass es in CSS nicht trivial ist, Deklarationen wieder zu entfernen. Wenn man nicht von Anfang an konsequent eine Methodologie à la BEM, SMACSS etc. befolgt hat, hat man RICHTIG VIEL Spaß mit CSS… NICHT. Dazu kommt die trügerische Einfachheit, dass man alle möglichen Selektoren verwenden kann, die sich an einer bestimmten HTML-/DOM-Struktur orientieren. Als schnelle Lösung super, auf lange Sicht eine unwartbare Katastrophe.

    Das Problem kann man auf 2 Arten lösen: CSS-Methodologien lernen oder eben eine CSS-in-JS-Lösung verwenden, die das Problem auf technische Art und Weise löst. Auch wenn ich persönlich eher für die erstere Lösung bin, kann ich durchaus verstehen, dass es z.B. JavaScript-Entwickler gibt, die eine technische Lösung der Problematik bevorzugen.

    Styled Components und Konsorten bieten aber noch mehr als das Feature „Ich muss nicht CSS-Methodologien lernen“:
    – Man kann Styled dynamisch erzeugen (das kann in bestimmten Edge Cases sehr hilfreich sein und zu weniger CSS-Code führen)
    – Man kann semantische Element-Lookalikes verwenden, die lesbarer sind ( vs. )
    – Es ist sehr viel einfacher zu sagen, welche CSS-Deklarationen nicht mehr benötigt werden, da man üblicherweise die CSS-Deklarationen in der Datei mit dem „Template“ (im Falle von React: JSX) definiert oder in die entsprechende Datei importiert. Das heißt, das chirurgische Entfernen einer Komponente wird deutlich leichter
    – Dynamisch Komponenten (inklusive dazugehörigem CSS) nachzuladen wird viel leichter, weil man alles an einem Ort hat
    – Man kann Bedingungen in Styles relativ leicht testen (man testet, ob bestimmte Styles auf einem Element liegen anstatt zu testen, ob eine bestimmte Klasse gesetzt ist, die ja theoretisch kein CSS-Pendant haben könnte)
    – Man kann sehr leicht Variablen zwischen CSS und JavaScript teilen. Ein Breakpoint soll identisch in beiden Technologien sein? Das ist trivial. In JavaScript und nicht CSS-in-JS-Lösungen muss man nach kreativen Lösungen suchen oder ein Stück Sicherheit aufgeben
    – Styles mit Typsicherheit (dank TypeScript) sind genial

    Gibt aber auch Nachteile:
    – Da alles in JavaScript definiert ist, braucht man eine besondere Lösung für den JavaScript-Deaktiviert-Fall (z.B. Server-Side Rendering – was aber wieder Aufwand erzeugt)
    – Da alles in JavaScript definiert ist, lädt man sehr viel JavaScript, was erstmal geparst werden muss (bei zum Teil mehreren 100 KB kann das eher schwachbrüstige Geräte schon mal fordern)
    – Da alles in JavaScript definiert, bekommt man das Caching von CSS-Dateien nicht out-of-the-box
    – Auch wenn der Artikel das suggeriert, gibt es durchaus einen Unterschied zwischen Styled Components und PostCSS-basierten Vendor Prefixes-Einfügetools (aka Autoprefixer): Styled Components fügt die Vendor-Prefixes per JavaScript ein, schreibt aber Regeln nicht um (soweit ich weiß). Das ist ein Problem, wenn man CSS Grids in alten IEs zum Laufen bekommen möchte. Mit Autoprefixer geht da einiges, mit Styled Components guckt man in die Röhre und darf sich eine andere Lösung überlegen
    – Stylelint funktioniert grundlegend auch mit CSS-in-JS, der Autofixer allerdings nicht
    – Man kann relativ problemlos technische Lösungen mit CSS-in-JS bauen, die Prettier überfordern

    Abgesehen davon: In React (gilt auch für die anderen größeren Frameworks) gibt es absolut nichts, was verhindert, dass man Sass (oder irgendeinen anderen Präprozessor der Wahl) verwendet. In der React-Entwicklung ist Create-React-App (https://create-react-app.dev) mittlerweile eine gängige Option um Projekte zu starten bzw. allgemein einen gut funktionierenden Build-Prozess zu bekommen. In der Doku dazu gibt es sogar explizit einen Abschnitt zu Sass: https://create-react-app.dev/docs/adding-a-sass-stylesheet. Ich weiß auch aus eigener Erfahrung, dass sich React-Projekte mit BEM-basierten Methodologien sehr gut realisieren lassen. Ich kann dich dahingehend also beruhigen: React spielt nicht besser oder schlechter mit Sass zusammen als z.B. jQuery-basierte Lösungen.

    „Moderne Webentwicklung“ scheinbar mit JS-Framework-basiert gleichzusetzen, macht für mich auch eher wenig Sinn. Ich würde sogar soweit gehen zu behaupten, dass der Trend aktuell wieder weggeht von client-seitigen „Monster“-Frameworks. Man könnte auch sagen, dass wir uns langsam dem Punkt annähern, dass wir nicht mehr versuchen, mit dem neuen Spezialhammer alle Schrauben in die Wand zu bekommen. Oder anders gesagt: Wir verwenden Werkzeuge wie React oder Styled Components zunehmend für die Anwendungsfälle, wo es Sinn ergibt. Und diese Fälle gibt es unbestreitbar.

    Bei dem Punkt, dass Sass und Co an Bedeutung verlieren, stimme ich Golo zu. Das heißt natürlich nicht, dass diese Tools bedeutungslos werden. Es gibt allerdings einige neue Werkzeuge, die ihre eigenen Stärken und Schwächen haben (die ja auch Sass zweifelsohne hat). Das Styling-Universum wird in erster Linie diverser.

  5. Hans Blank sagt:

    Wohin der ganze Tailwind-Hype (und das Unverständnis von CSS) führen kann, sieht man m. E. gut am Quelltext von https://www.spiegel.de/ & https://www.manager-magazin.de/ (beides aus dem Hause https://www.spiegel-techlab.de/).

    Statt sinnvoll die CSS-Kaskade zu verwenden, wird für das „Zusammenklicken“ vom Layout via Tailwind eine DIV-Suppe ohne Gleichen gebastelt:

    “ Übermäßige DOM-Größe vermeiden: 6.285 Elemente “
    -> https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwww.spiegel.de%2F

    Vielleicht bin ich ja inzwischen zu alt, um so etwas zu verstehen. Performance-Optimierung für den Client geht jedenfalls anders…