-
Reset
- Die Preflight-Styles von Tailwind wurden anfangs in Form von etwa 200 Zeilen aus
tailwind.css kopiert und verwendet
- An das Tailwind-Reset hatte man sich über lange Zeit gewöhnt, und die Regel, auf alle Elemente
box-sizing: border-box anzuwenden, sorgt dafür, dass die Breite eines Elements auch das Padding einschließt
* { box-sizing: border-box; }
- Es ist gut möglich, dass auch von anderen Reset-Regeln wie
html {line-height: 1.5;} unbewusst abhängt wird; ohne solche Regeln CSS zu schreiben würde wohl eine größere Umgewöhnung erfordern
-
Components
- Der Großteil des CSS wird in komponentenspezifischen Dateien organisiert, ähnlich wie bei Vue- oder React-Komponenten
- Jede Komponente hat eine eigene Klasse, damit das CSS einer Komponente nicht das CSS einer anderen überschreibt
- Rund 80 % des CSS, das tatsächlich geändert werden soll, liegt in diesen Komponentendateien; beim Bearbeiten einer 100-Zeilen-Komponente muss also nur über diese 100 Zeilen nachgedacht werden
- Eine
.zine-Komponente kann zum Beispiel folgendes HTML haben
<figure class="zine horizontal">
<img src="whatever.jpg">
</figure>
- Im CSS werden Zustände wie
.horizontal, .vertical und :hover mit verschachtelten Selektoren innerhalb der Komponente gesammelt
.zine {
...
&.horizontal {
...
}
&.vertical {
...
}
&:hover {
...
}
}
- Eine programmgesteuerte Abschirmung zwischen Komponenten wie bei Web Components oder
@scope gibt es zwar nicht, aber schon klare Konventionen bringen spürbare Verbesserungen
-
Farben
- In
colours.css werden CSS-Variablen gesammelt, die bei Bedarf verwendet werden können
- Farben sind schwierig, und weil die Farbnutzung in diesem Refactoring nicht neu bewertet werden sollte, blieb der bestehende Ansatz erhalten
- Die einzige Regel lautet, alle auf der Website verwendeten Farben in dieser Datei aufzulisten
:root {
--pink: #fea0c2;
--pink-light: #F9B9B9;
--red: #f91a55;
--orange: rgb(222, 117, 31);
...
}
-
Schriftgrößen
- In Tailwind reichte es, eine Größenstufe wie
text-lg, xl oder 2xl zu wählen, ohne sich merken zu müssen, ob em, px oder rem verwendet wird
- Um das auch in Vanilla-CSS beizubehalten, wurden aus Tailwind übernommene Größenvariablen definiert
--size-xs: 0.75rem;
--line-height-xs: 1rem;
--size-sm: 0.875rem;
--line-height-sm: 1.25rem;
- Schriftgrößen werden per Variablen gesetzt; das ist etwas ausführlicher als in Tailwind, wirkt derzeit aber zufriedenstellend
h3 {
font-size: var(--size-lg);
line-weight: var(--line-weight-lg);
}
-
Utilities
- Elemente wie Buttons, die in mehreren Komponenten wiederkehren, werden als Utilities eingeordnet
- Einige Utility-Klassen wie
.sr-only für Inhalte, die nur für Screenreader-Nutzer sichtbar sein sollen, wurden aus Tailwind übernommen
- Dieser Bereich soll klein bleiben, und Änderungen daran sollen vorsichtig erfolgen
-
Base
- „Base“-Stile sind Stile, die direkt auf die gesamte Website angewendet werden
- Weil nicht genug Sicherheit besteht, der ganzen Website viele Stilregeln aufzuzwingen, bleibt dieser Bereich sehr klein
- Derzeit gibt es nur zwei Regeln, die sich gut anfühlen: für
<section> und a; die <section>-Regel könnte später noch geändert werden
/* put a 950px column in the middle of each <section> */
section {
--inner-width: 950px;
padding: 3rem max(1rem, (100% - var(--inner-width))/2);
}
a {
color: var(--orange);
}
- Am einfachsten scheint es, Base-Stile anfangs fast leer zu lassen und gemeinsam gewünschte Regeln später bottom-up aus Komponenten in den Base-Bereich zu verschieben
-
Abstände
- Wie Padding und Margin verwaltet werden sollen, ist noch nicht vollständig entschieden
- Mit Tailwind wurden Padding und Margin oft spontan hier und da ergänzt, bis es richtig aussah; jetzt wird nach einem prinzipielleren Ansatz gesucht
- Derzeit soll möglichst die äußere Layout-Komponente für Abstände verantwortlich sein
- Wenn in einem
<section> mit mehreren Kindelementen gleichmäßige Abstände zwischen den Kindern gewünscht sind, kann folgende Regel verwendet werden
section > *+* {
margin-top: 1rem;
}
-
Responsives Design
- In Tailwind wurde häufig eine media-query-basierte Syntax wie
md:text-xl verwendet, um den Stil text-xl ab einer bestimmten Größe anzuwenden
- Jetzt geht es darum, flexiblere CSS-Grid-Layouts zu bauen, die möglichst ohne viele Breakpoints auskommen
- Mit
auto-fit lassen sich auf großen Bildschirmen automatisch 2 Spalten und auf kleinen 1 Spalte nutzen
display: grid;
grid-template-columns: repeat(auto-fit, minmax(min(100%, 400px), max-content));
justify-content: center;
-
Build-System
- Während der Entwicklung ist kein separates Build-System nötig
- CSS hat eingebaute
@import-Anweisungen, mit denen sich Dateien aufteilen und einbinden lassen
@import "reset.css";
@import "typography.css";
@import "colors.css";
- Auch verschachtelte Selektoren sind in CSS eingebaut
.page {
h2 { ...}
}
- Wenn CSS-Dateien für Produktion gebündelt werden sollen, kann
esbuild verwendet werden
esbuild style.css --bundle --loader:.svg=dataurl --loader:.woff2=file --outfile=/tmp/out.css
- Build-Systeme für CSS und JS werden normalerweise eher vermieden, aber
esbuild wirkt akzeptabel, weil es auf Web-Standards basiert und ein statisches Go-Binary ist
- Über
esbuild wurde 2021 bereits ein Artikel zu esbuild und Vue geschrieben
1 Kommentare
Lobste.rs-Meinungen
In persönlichen Projekten verwende ich inzwischen fast keine CSS-/JavaScript-Frameworks mehr
Denn ohne Abhängigkeiten können auch keine Supply-Chain-Schwachstellen entstehen. Natürlich sind das nicht die einzigen Schwachstellen, aber es hilft
Das ist das Ergebnis aus Framework-Müdigkeit,
npm audit-Overload und der Tatsache, dass ich mir dank LLMs weniger Gedanken darüber machen muss, wie andere meine Implementierungsweise bewerten. Zum Beispiel bei Fragen wie „Warum verwendest du nicht React und Tailwind?“So funktioniert CSS eben
Wenn ich sehe, wie Leute Tailwind blind verwenden, ohne das zu wissen, möchte ich am liebsten nach draußen gehen und die Wolken anschreien. Meiner Ansicht nach sind 90 % von Tailwind nur Inline-Styles mit anderer Syntax und höchstens eine Stufe besser als das
<FONT>-TagDieser Blogpost erklärt genau die Dinge, die ich tatsächlich wissen musste
Tailwind funktioniert ziemlich anders als Inline-Styles und ist CSS in Wirklichkeit viel ähnlicher. Wie der Artikel auch hervorhebt, sind viele der guten Gewohnheiten, die einen gut mit Tailwind arbeiten lassen, dieselben Gewohnheiten, die man auch für effektives CSS braucht. Tailwind kommt eher einem CSS-Block mit implizitem Scope für jedes Element nahe, nur eben mit einer eigenen DSL
Ich verstehe gut, wie CSS funktioniert, finde plain CSS aber immer noch belastend und bin auch nicht besonders stark im Grafikdesign, daher verwende ich weiterhin Tailwind. Dieser Artikel liefert Ideen, wie man CSS ausgehend von Tailwind strukturieren kann
Aus der Sicht von jemandem, der die jüngeren Entwicklungen nicht gut verfolgt hat, scheint dieser Artikel moderne CSS-Praktiken ziemlich gut zu zeigen
Mir gefällt auch, dass es viele Links zu Texten gibt, von denen er sich inspirieren ließ. Das sieht nach gutem Lesestoff aus, auch wenn ich bisher nur "no outer margin" gelesen habe
Allerdings bin ich beim Ansatz, Basis-Styles „von unten nach oben“ festzulegen, etwas skeptisch. Ich weiß nicht, was ich stattdessen tun würde, und es wirkt ausprobierenswert, aber Basis-Styles sind im Kern eher knifflig
Ich fand diesen Artikel wirklich großartig
Ich habe CSS auch nach und nach gelernt, während ich viele kleine Websites gebaut habe, und ich glaube, es hätte geholfen, von Anfang an stärker systemisch zu denken. Ich habe eine ziemliche Abneigung gegen Frameworks, aber weil ich sie nicht nutze, habe ich oft das Gefühl, zwar umsetzen zu können, was ich will, aber ohne Struktur im luftleeren Raum zu schweben
Gut daran ist, dass es nicht heißt „Tailwind ist schlecht, also nutze einfach CSS“, sondern eher „Tailwind ist großartig, aber vielleicht brauchst du es jetzt nicht mehr“
Ich hatte immer Schwierigkeiten damit, CSS von Hand zu strukturieren, und dieser Artikel hat mich dazu gebracht, ganz anders darüber nachzudenken
Beim Ordnen von CSS war diese Strukturierungstechnik ziemlich nützlich: https://rstacruz.github.io/rscss/
Insgesamt passt das gut zu dem, was jvns im Originalbeitrag erklärt, und ergänzt noch etwas mehr Struktur und Ordnung obendrauf