CSS: die unvermeidlichen schlechten Seiten

• Für das Styling von Webseiten reicht bei einem einfachen Blog oder einer GUI eine kleine, erlernbare Teilmenge aus, aber Browser-Defaults und Fallstricke beim Layout können zu tagelanger Fehlersuche führen
• Wenn man zuerst sinnvolle HTML5-Tags verwendet und Wrapper reduziert, lässt sich CSS leichter so schreiben, dass es mit dem vorhandenen Markup arbeitet
• Für CSS-Layouts gibt es keinen universellen Einheitsalgorithmus; nötig ist ein Ansatz, der versteht, welche Anordnungen das jeweilige System überhaupt zulässt
• box-sizing, margin, font-size, line-height, word-break verhalten sich anders als intuitiv erwartet, sodass kleine Änderungen zu umfassenden Layout- oder Lesbarkeitsproblemen werden können
• Für einfache Seiten können CSS reset, classless CSS, flexbox und nicht übertriebene Responsive-Regeln ein praktischer Ausgangspunkt sein

---

Umfang des CSS-Lernens und grundlegende Perspektive

• CSS, HTML und Web APIs sind sehr umfangreich und erfordern Spezialisierung, aber für Arbeiten wie einen Programmierblog oder eine einfache GUI reicht eine passende Teilmenge des modernen Webs aus
• Ich habe noch kein Material gesehen, das nur die für einfache Aufgaben nötige Teilmenge vermittelt, aber über MDN kann man sich einen gewissen Überblick verschaffen
• Das Problem ist, dass unerwartete Fallstricke eine Seite ruinieren können und es Tage dauern kann, die Ursache zu finden
• Das Styling dieser Seite besteht aus etwa 200 Zeilen lesbarem CSS

Die guten Seiten: sinnvolles HTML und classless CSS

• Semantische HTML5-Tags

  • Es lohnt sich, die Elements Reference auf MDN zu überfliegen, und die Zahl der HTML-Elemente ist gar nicht so groß
  • Tags wie main, article, nav, kbd können den Aufbau einer Seite erleichtern
  • ul kann für alle Arten von Listen verwendet werden, etwa für Site-Bereiche innerhalb von header > nav
  • details kann für ein Inhaltsverzeichnis genutzt werden; man kann sich dazu den MDN-Quelltext ansehen
  • dl und dt können für paarweise Listen verwendet werden

• Ein Ansatz mit weniger Wrappern

  • Wenn man sich den Quelltext realer Websites ansieht, findet man oft viele verschachtelte Wrapper-Elemente, sodass es so wirken kann, als würden Layoutprobleme über Wrapper gelöst
  • Ohne ein abschließendes Urteil über Erfahrung mit Produktions-CSS zu fällen, war ein Ansatz leichter verständlich, bei dem man sich auf sinnvolle semantische Tags beschränkt und dann CSS findet, das zu diesem Markup passt

• Classless CSS

  • Man kann Styles nicht vollständig auf einen neutralen Zustand „nichts“ zurücksetzen; auch weißer oder transparenter Text ist weiterhin ein Stil
  • Nach einem Reset kann man gemeinsame HTML-Elemente direkt stylen
  • Wenn man Tags wie main, header, footer, nav verwendet, lässt sich das Seitenlayout festlegen, ohne viele CSS-Selektoren zu brauchen
  • Dieser Ansatz führt dazu, dass CSS Annahmen über die HTML-Struktur trifft, aber wenn es die eigene HTML- und CSS-Basis ist, kann man sie ändern, wenn einem das Ergebnis nicht gefällt

Die schlechten Seiten: Layout, Browser-Defaults, Selektoren

• Layout

  • Layoutprobleme sind kein reines Webproblem, sondern auch in vielen GUI-Frameworks schwierig
  • Es gibt verschiedene Möglichkeiten, Rasterbilder mit fester Größe und erklärende Textabsätze in einem Rechteck auf dem Bildschirm anzuordnen
  • Eine typische GUI ist eine Hierarchie von Boxen mit viel „Layout-Freiheit“
  • Das Layout jeder Box beeinflusst das Layout aller anderen Boxen, und normalerweise sollen alle Boxen ohne Abstände oder Überlappungen exakt aneinander anschließen
  • Es gibt keinen universellen Layout-Algorithmus; Systeme nutzen unterschiedliche Heuristiken, von RectCut über constraint solvers bis zum Bereich dazwischen
  • Statt zu fragen „Wie baue ich ein Layout in diesem System?“ ist es besser zu fragen: „Welche Layouts erlaubt dieses System überhaupt?“

• Browser-Defaults und CSS reset

  • Auch sinnvolles HTML ohne CSS bekommt im Browser Standardstile wie Farben, Schriftarten, Größen, große Überschriften und unterstrichene Links
  • Diese Standardstile sind hilfreich, unterscheiden sich aber zwischen Browsern; wenn man sich auf nicht explizit gesetzte Defaults verlässt, kann das in anderen Browsern anders aussehen
  • Die übliche Lösung ist ein CSS reset oder eine Normalisierung, bei der man zu Beginn des CSS mit expliziten Regeln die Defaults überschreibt
  • Nicht die Defaults an sich sind das Problem, sondern ihre Inkonsistenz
  • Welche Regeln man konkret überschreiben sollte, erkennt man am besten durch den Vergleich mehrerer vorhandener CSS-Resets

• Sollte man Webseiten überhaupt stylen?

  • Auf der Webplattform existieren zugleich die Perspektive eines flexiblen, adaptiven visuellen Mediums und die Sicht, dass es primär um die Auslieferung von Inhalten gehen sollte und Nutzer die Darstellung selbst anpassen können sollten
  • Unformatierte Seiten sind standardmäßig wenig benutzbar und sehen nicht gut aus
  • Eine Welt, in der CSS-lose Seiten von sich aus gut lesbar wären, wäre besser, aber in der aktuellen Umgebung ist es hilfreich, Inhalte zu stylen
  • Es ist gut, fortgeschrittenen Nutzern zu erlauben, ihr eigenes CSS einzubringen
  • Das HTML-Markup sollte vernünftig sein, nicht auf CSS überangepasst werden, und die Seite sollte im Reader Mode funktionieren

• CSS-Selektoren

  • Grundlegendes CSS wirkt wie starke Vererbung, sodass jedes Gestaltungselement einer Webseite von mehreren Regeln beeinflusst wird
  • Durch Anhängen an eine CSS-Datei kann man vorhandene Elemente jederzeit „monkey patchen“
  • CSS-Selektoren werden als eine Abstraktionserweiterung entlang der falschen Achse betrachtet, weshalb auch ein Ansatz mit classless CSS und inline styles möglich ist
  • Tools wie Tailwind können die Unbequemlichkeit von Inline-Styling verringern, und Template-Engines mit JSX oder Komposition können HTML-Wiederholungen reduzieren
  • Mit CSS nesting lassen sich weit ausgreifende Selektoren verringern und Styles komponentenweise schreiben

Box-Modell und Anordnung: box-sizing, margin, Standard-Flow, flexbox

• box-sizing

  • UIs sind rekursive Rechtecke, und Layout ist der Prozess, festzulegen, wo jedes Rechteck platziert wird
  • In den HTML-Defaults schließen width und height eines Elements border und padding nicht ein, was wenig intuitiv ist
  • Wenn man an einer Stelle das Padding vergrößert, kann dadurch ein zuvor perfekt wirkendes Gesamtlayout unerwartet verrutschen
  • * { box-sizing: border-box; } kann gut die erste Zeile eines CSS-Resets sein, weil das Hinzufügen eines Borders damit zu einer lokalen Änderung wird

• Margin Collapsing

  • Wenn man um ein Element herum 8px Abstand möchte und dafür Padding verwendet, kann der Abstand zwischen zwei benachbarten Elementen zu 16px werden
  • margin funktioniert so, dass benachbarte Margins nicht addiert, sondern per max kombiniert werden
  • Margin Collapsing ist sehr nützlich, kann aber überraschendes Verhalten erzeugen
  • Man kann es so verstehen, dass der Margin eines Kinds außerhalb des Elternelements herausragen kann, aber ein wirklich intuitives Verständnis von Margin fehlt noch
  • Julia Evans’ Artikel Moving away from Tailwind, and learning to structure my CSS behandelt allgemein den Owl-Selector-Ansatz, bei dem nicht das Element selbst Margin bekommt, sondern das Elternelement die Abstände zwischen seinen Kindern steuert
  • Die Idee, bei section allen Kindern außer dem ersten Margin zu geben, erscheint als Ansatz, um Margin-Probleme zu reduzieren
  • Es ist unerquicklich, dass man solche Dinge kaum lernt, wenn man nicht professioneller Webentwickler wird oder andere CSS-Frameworks reverse-engineert

• Standard-Flow-Layout

  • Der Standard-Layout-Algorithmus hängt mit den Ursprüngen von HTML als Dokumentensprache zusammen und scheint auf Anwendungsfälle zur Erzeugung papierartiger Dokumente mit Text und Bildern ausgerichtet zu sein
  • Für Fließtext verhält sich der Standard-Flow tatsächlich ziemlich nah an dem, was man will
  • Wenn man die räumliche Anordnung von Seitenelementen direkt steuern will, braucht man etwas anderes als den Standard-Flow

• Flexbox

  • flexbox ist ein Layoutsystem, das eine Reihe von Elementen vertikal oder horizontal anordnet und an den verfügbaren Platz anpasst
  • Früher brauchte man selbst für Anordnungen wie „das links, das rechts“ tiefes CSS-Wissen oder undurchsichtige CSS-Frameworks
  • Flexbox ist ziemlich komplex, sodass man immer wieder bei MDN nachschauen muss, aber meistens bekommt man damit erledigt, was man will

• Responsive Design

  • Modernes CSS kann Bildschirmgrößen abfragen und bedingte Logik abhängig von Einschränkungen des User Agents umsetzen
  • HTML ist seinem Wesen nach responsiv; anders als bei PostScript oder PDF werden Absätze beim Ändern der Fenstergröße automatisch neu umbrochen
  • Es ist besser, explizite Responsive-Regeln möglichst zu vermeiden und das Layout einfach vernünftig arbeiten zu lassen
  • Dieser Blog sieht auf Mobilgeräten, Tablets und Desktops auch ohne explizite @media-Queries ordentlich aus
  • Es reicht oft schon, für die Hauptspalte des Fließtexts schlicht ein max-width zu setzen

Größen und Text: Pixel, Schrift, Zeilenhöhe, Umbrüche

• Pixel

  • 1px tut das, was man erwartet, bedeutet aber nicht ein einzelnes physisches Pixel des Displays
  • 1px in CSS ist eine Einheit des Sehwinkels und darauf ausgelegt, auf verschiedenen Displays wahrnehmungsmäßig ähnlich zu erscheinen
  • Je nach Bildschirmgröße, Pixeldichte und üblichem Betrachtungsabstand wird es in unterschiedlich viele physische Pixel umgesetzt
  • Deshalb kann man alle Größen in Pixeln angeben, ohne die Pixeldichte verschiedener Displays gesondert berücksichtigen zu müssen
  • Auch scheinbar „reale“ CSS-Einheiten wie Zentimeter und Zoll sind relativ zu Pixeln definiert und verhalten sich daher ebenfalls eher wie Winkelgrößen

• font-size

  • Bei font-size: 16px ist 16px nicht die Größe eines bestimmten Glyphen, sondern die Größe einer virtuellen Box um die Glyphe herum
  • Diese Box passt nicht exakt zur Glyphe, und die tatsächliche Größe der Glyphe hängt von der Schriftart ab
  • font-size-adjust kann font-size über verschiedene Schriftarten hinweg konsistenter machen
  • Aktuell wirkt font-size-adjust wie eine sehr spezielle Nischenfunktion; persönlich würde ich gern neben box-sizing auch font-size-adjust: ex-height 0.53; setzen, aber nur wenige Seiten tun das
  • Der Default für font-size ist zwischen Browsern relativ konsistent, und 16px ist mit großem Abstand der häufigste Standardwert
  • Je nach Schriftart kann 16px klein wirken, und manche Standardschriften wirken besonders klein
  • Auf Apple-Systemen sieht font-family: serif deutlich kleiner aus als sans-serif und ist bei 16px fast unangenehm zu lesen
  • Wenn man font-size in CSS setzt, deaktiviert man die Art, wie Browser standardmäßig mit Änderungen der voreingestellten Schriftgröße umgehen
  • Man sollte nicht annehmen, dass Text standardmäßig gut lesbar ist, sondern dies mit anderen Einstellungen überprüfen
  • Wenn man mit font-size-adjust Freiheitsgrade reduziert und die Bedeutung von font-size stabilisiert, ist man fertig, sobald es mit der Default-Schriftgröße von 16px gut aussieht
  • Falls nicht, sollte man font-size auf einen größeren Wert setzen und anschließend prüfen, ob die Seite auch im Reader Mode noch gut lesbar ist

• line-height

  • Anders als der Name vermuten lässt, legt line-height nicht die Höhe einer einzelnen Zeile fest
  • line-height ist die Höhe eines Glyphen-Clusters, der mit derselben Schrift gesetzt ist
  • Wenn der gesamte Text dieselbe Schrift verwendet, stimmen Zeilenhöhe und Höhe des Glyphen-Clusters überein
  • Wenn einzelne Wörter in monospace gesetzt werden, kann das zu unerwarteten Ergebnissen führen
  • font-size-adjust korrigiert zwar die Größe der Glyphen innerhalb der Box, legt aber nicht ihre relative Position fest
  • Wenn Textblöcke in verschiedenen Schriften vertikal so ausgerichtet werden, dass sie dieselbe Baseline teilen, geraten ihre jeweiligen line-height-Line-Boxes gegeneinander aus dem Takt
  • Die Gesamthöhe der Zeile kann dann gewissermaßen als Vereinigung entstehen und größer ausfallen als erwartet
  • Dieser Effekt wird in Deep dive CSS: font metrics, line-height and vertical-align ausführlich behandelt

• Vertical Rhythm

  • Vertical Rhythm ist die Idee, die Zeilenpositionen zwischen Absätzen auch bei Überschriften, Bildern usw. auf denselben relativen Rasterpositionen zu halten
  • Beschrieben wird das oft so, als liege hinter der Webseite unsichtbares liniertes Papier
  • Für einspaltige Layouts scheint das nicht besonders nützlich zu sein
  • Bei zweispaltigen Layouts kann man dagegen wollen, dass die Zeilen links und rechts ausgerichtet sind
  • Für eine einzelne Spalte so viel Komplexität zu investieren, ergibt wenig Sinn

• word-break

  • Ein Vorteil des Flow-Layouts ist sein dynamisches Verhalten: Wenn das Fenster schmaler wird, verteilt sich Text sauber auf Zeilen
  • Zeilen können aber nur an Leerzeichen oder Stellen für Trennstriche umbrechen
  • Lange Sequenzen wie inline code oder URLs lassen sich möglicherweise nicht umbrechen
  • Dieses Problem verursacht auf Mobilgeräten horizontalen Overflow und fällt einem meist erst nach der Veröffentlichung auf
  • Es gibt keinen einzelnen Trick, der alles löst, aber in Against Horizontal Scroll stehen einige Tipps

Praktisches Fazit

• Um einen einfachen Blog zu erstellen, braucht es Material, das nur die wirklich nötigen Teile von HTML und CSS knapp erklärt
• Abschließend wird nach einem kurzen Buch von etwa 100 Seiten gefragt, das HTML und CSS so erklärt, dass man einen einfachen Blog bauen kann, ohne an Problemen wie Margin Collapsing zu scheitern

[GN⁺]

Lobste.rs-Meinungen

• Eine kleine Anmerkung, aber die Definition von responsive design ist, „dafür zu sorgen, dass auf unterschiedlichen Geräten und bei verschiedenen Fenster-/Bildschirmgrößen gut gerendert wird, um Nutzbarkeit und Zufriedenheit sicherzustellen“.
  Media Queries oder Container Queries sind nur Werkzeuge, um das umzusetzen, und responsives Design ist eher eine Denkweise als „lasst uns für alles Media Queries verwenden“.
  Deshalb scheint es richtiger zu sein, das „Schlechte“ nicht im responsiven Design selbst zu sehen, sondern in Media Queries oder im übermäßigen Einsatz von Breakpoints.

• Der Abschnitt zu „Browser defaults“ ist ziemlich irreführend. Reset-Stylesheets und Normalize-Stylesheets unterscheiden sich in Ziel und Verhalten stark, im Artikel werden sie aber vermischt.
  Ein Reset entfernt nicht in erster Linie Unterschiede zwischen Browsern, sondern die standardmäßigen Unterschiede zwischen Elementen, etwa padding-inline-start bei ol oder das Standardaussehen von button, damit man Styles nicht auf dem User-Agent-Stylesheet aufbaut, sondern auf einer leeren Seite beginnt.
  Normalize ist ein Ansatz, der mit dem User-Agent-Stylesheet zusammenarbeiten will, und mischt Teile, die Browserunterschiede angleichen, mit Teilen, die Standards auf aus ihrer Sicht „vernünftigere“ Werte ändern.
  Heute gibt es nicht mehr viele Fälle, in denen sich Browser-Defaults noch sinnvoll unterscheiden, daher können normale Autoren von Web-Content das fast komplett ignorieren. Ausnahmen sind Chromium has the wrong table border-color, WebKit fixed theirs 1½ years ago, Abstände/Größenunterschiede bei einigen Form-Elementen, appearance und das Styling von WebKits <summary> ::marker.
  Ich bin auch gegen box-sizing: border-box. border-box ist auf Layout ausgerichtet, content-box auf Content, deshalb halte ich es für besser, wenn das Elternteil das Layout übernimmt und man in Bezug auf den Content entwirft. Wenn man mit Proportionen arbeitet, braucht man content-box, und Fälle, in denen border-box wirklich nützlich ist, beschränken sich praktisch darauf, den body auf den Viewport zu füllen.
  Auch bei font-size-adjust bin ich skeptisch. Es ersetzt ein weithin bekanntes Problem durch ein schlechter verifiziertes Problem; für manche wird es ein wenig besser, für andere ein wenig schlechter. Das Grundproblem lässt sich nicht lösen, und man trifft unbegründete Annahmen über Schriftverhältnisse und Metriken der Nutzer.
  Auch line-height und die Formulierung „auf dieselbe Schrift setzen“ sind nicht präzise. Tatsächlich spielen Schriftgröße, Sprachwechsel, font-family: monospace, vertical-align, <sup>, <sub> und Font-Metriken zusammen, sodass es schwer ist, das einfach als Problem „derselben Schrift“ zu sehen.
  Margin Collapsing ist komplexer, als der Artikel vermuten lässt, aber auch ziemlich praktisch. Wenn man für gewöhnlichen Content flex oder grid nutzt, muss man ständig an gap oder Margins schrauben, wodurch alles leicht fragil wird. Mit display: flow-root kann man verhindern, dass Kind-Margins mit den Margins des Elternelements kollabieren.
  Dem großen Rahmen zur responsiven Gestaltung stimme ich zwar nicht zu, aber die Richtung stimmt: unnötige Media Queries reduzieren und nicht gegen den Browser kämpfen. Wenn sich Layoutänderungen anhand des Contents ausdrücken lassen, ist das im Allgemeinen besser.
  In letzter Zeit nutze ich viel lineare clamp-Interpolation mit Viewport-Einheiten: margin-inline: --vw-lerp(1rem at 20rem, 2.5rem at 60rem); wird etwa zu margin-inline: clamp(1rem,1rem + ((2.5 - 1)/(60 - 20)*(100vw - 20rem)),2.5rem); erweitert.
  Letztes Jahr habe ich das als LightningCSS-Visitor implementiert; unterhalb von 20rem Viewport bleibt es bei 1rem, steigt bis 60rem sanft auf 2.5rem an und stoppt dann, ganz ohne Breakpoints und mit angenehmer Anpassung an die vom Nutzer gewählte Schriftgröße.

  • Ich bin mir nicht sicher, ob font-size-adjust tatsächlich so funktioniert. Der Name ist irreführend, aber ich verstehe es so, dass font-size die Größe der em-Box ändert und font-size-adjust die Glyphengröße innerhalb der em-Box.
    Deshalb bleiben em und rem unverändert, ch dagegen ändert sich. Aber ch ist ohnehin schriftabhängig, also ist es richtig, dass es sich verändert.
    Ich hätte gern einen Artikel zu font-size-adjust. Ich bin kein Experte und daher nicht sehr sicher, aber bisher wirkt es auf mich wie eine kaum bekannte und doch enorme Verbesserung. Natürlich kann man nicht zwei beliebige Schriften in jedem Kontext automatisch angleichen, aber allein die Größe von x statt der em-Box anzugleichen, dürfte 90 % der Schrift-/Kontextfälle abdecken.

• Die Stoßrichtung des Artikels ist gut, und die Perspektive von Leuten, die nicht vollständig in HTML/CSS aufgehen, ist wichtig, aber vieles von dem „Schlechten“ kann je nach Kontext auch gut sein.
  CSS-Selektoren lassen sich leicht überstrapazieren, sind aber nicht inhärent schlecht. Statt auf A oder B hinauszulaufen, kann man allgemeine Regeln/Selektoren haben und bei Bedarf ausnahmebasierte Klassen oder Utility-Klassen darüberstreuen.
  Im Artikel selbst gibt es auch ein gutes Selektor-Beispiel:

  section > *+* {  
    margin-top: 1rem;  
  }  
  

  Auch Media Queries sind möglicherweise unnötig, wenn sich das mit container queries lösen lässt.
  CSS kann sich von seinem Umfang her riesig anfühlen, und weil es weit verbreitet ist und viel leisten kann, gibt es auch häufig Meinungsverschiedenheiten. Trotzdem sollte man sehen, wie weit CSS gekommen ist und was man mit relativ wenig Code erreichen kann, wenn man die Konzepte akzeptiert.
  Wer mehr lernen will: https://every-layout.dev/ hat mir sehr geholfen zu verstehen, wie verschiedene Elemente in CSS zusammenspielen.

  • Noch eine Stimme für Every Layout. Ich mag CSS immer noch nicht wirklich, und persönlich halte ich die Kaskade als Layoutmodell grundsätzlich für ziemlich schwach, aber inzwischen kann man Dinge auf Desktop und Mobilgeräten meist einigermaßen plausibel und responsiv aussehen lassen.
    Ich begann Web-Layouts zu verstehen, als mir klar wurde, dass gute Websites im Kern vertikal entworfen sind. Elemente sollten sich grundsätzlich untereinander stapeln; man entwirft zuerst für den mobilen Bildschirm und klappt es auf größeren Bildschirmen dann als Bonus weiter auf.

• Dieser Behauptung ist schwer zuzustimmen. CSS-Nesting ist nur syntaktischer Zucker und hilft nicht dabei, das Problem übermäßig spezifischer Selektoren nennenswert zu vermeiden.
  Schon vor 15 Jahren wurde mit Sass viel Selektor-Nesting verwendet, und am Ende kam man nach und nach zu dem Schluss, dass man sich damit selbst ein Bein stellt, weil CSS-Selektoren zu eng an die HTML-Struktur gebunden werden.
  Die Fallen von Nesting zeigen sich zu Beginn eines Projekts meist nicht deutlich. In der Greenfield-Phase, in der vor allem neue Features gebaut werden, wirkt CSS auf diese Weise sogar sehr attraktiv.
  Beginnt man einige Monate später mit größeren Layout-Änderungen und einem Redesign, wechseln Wrapper-Elemente im HTML ihre Position, und das CSS daran anzupassen fühlt sich an, als würde man auf LSD einen Rubik’s Cube lösen.
  Die Verwaltung der Selektor-Spezifität war meiner Ansicht nach am besten, wenn man den Großteil auf einfache Selektoren – also eine einzelne Klasse – niedrig hielt und nur wenige kombinierte Selektoren sowie Verknüpfungen wie a:hover verwendete. Das war die Hochphase von BEM, OOCSS und ähnlichen Ansätzen; danach verlagerte sich das Interesse schnell auf JS-zentrierte Tools.

• Interessanter Artikel, aber es wirkt so, als würde der Autor verschachtelte Selektoren an einer Stelle ohne jeden Effekt verwenden.

  header { /* Site Header */  
    margin-bottom: 2rem;  
    & nav { /* ampersand redundant here? */  
      /* Styles, specific to nav in the Header. */  
    }  
  }  
  

  • Manche halten es für einen Fehler, dass man & weglassen kann, und verwenden deshalb immer &. Ich finde das eine ziemlich nachvollziehbare Position.
    Ich selbst bin noch unentschlossen. Zuerst hielt ich es auch für einen Fehler, aber wenn man bereits viele Styles geschrieben hat und den Gültigkeitsbereich einfach durch ein umschließendes header { … } einschränken kann, ist das ziemlich praktisch. Schön wäre auch, wenn man darin nicht selektorbasierte At-Regeln wie @keyframes verwenden könnte.

• Das ist ehrlich gesagt wirklich ein sehr schlechter Ratschlag. Ich mag Maklads Artikel, aber das hier wirkt eindeutig so, als sei es von jemandem geschrieben worden, der nie professionell mit CSS gearbeitet hat.
  Fast alles daran sind schlechte amateurhafte Praktiken, die man bei professionellem CSS vermeidet.

  • Etwas konkreter: Für Amateure ist das wichtigste Gestaltungsziel meist die Content-Box. Ein CMS spuckt Absätze, Hervorhebungen, Links und Listen aus, und die meiste Zeit geht dafür drauf, genau das zu stylen.
    Wenn man das ohne Klassen stylt, gestaltet man auch <main> oder <nav> ohne Klassen.
    In professionellen Umgebungen verbringt man dagegen nur sehr wenig Zeit mit dem Entwurf von Content-Boxen. Man baut sie einmal zu Beginn des Projekts und behebt später nur noch langsam kleine Bugs daran.
    Die meiste Zeit fließt in benutzerdefinierte oder wiederverwendbare Komponenten. Wiederverwendbare Komponenten sind schwieriger, und faktisch baut man einen Bootstrap-Klon nur für die eigene Website.
    Benutzerdefinierte Komponenten sind einfacher, erzeugen aber viel Code, und damit sie nicht unbeabsichtigt mit anderen Komponenten interferieren, braucht man Strategien wie BEM, OOCSS oder Utility-Klassen wie bei Tailwind.
    Die Schlussfolgerung ist, dass jede Technik zu einer anderen Größenordnung passt. Wenn professionelle CSS-Schreibweisen nutzlos erscheinen, liegt das wahrscheinlich daran, dass man ein Problem in einer anderen Größenordnung löst.
  • Im Artikel wird sogar ausdrücklich gesagt, dass der Autor noch nie „production CSS“ geschrieben hat.
    Trotzdem stimme ich Bad: Wrappers zu. Ich habe CSS-Experten gesehen, die eine ganze Website in ein oder zwei Dateien schreiben, und auch Leute, die extrem viel CSS schreiben.
    Der letztere Weg führt am Ende leicht zu falschen Ansätzen wie BEM, nur um große Mengen CSS überhaupt verwalten zu können.

• Im Artikel scheint es widersprüchliche Ratschläge zu geben.
  Good: Classless CSS und Bad: CSS selectors stehen nebeneinander, aber wenn man klassenloses CSS verwenden will, ist man gerade noch stärker auf CSS-Selektoren angewiesen.
  Siehe: https://www.keithcirkel.co.uk/css-classes-considered-harmful/

• Der Gedanke einer vertical rhythm, „als läge hinter der Webseite ein unsichtbares liniertes Blatt“, lässt sich mit EM-Werten gut umsetzen.
  Wenn man unterschiedliche Fonts mischt, kann es wegen abweichender Metriken etwas wackeln, aber selbst dann kann man in Flexbox align-items: baseline verwenden.