-
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
3 Kommentare
Ist es durch die Umstellung auf Zero-Config nicht etwas besser geworden?
Hacker-News-Kommentare
Ich lehre schon lange semantisches HTML und barrierefreies Markup und habe auch viele Websites und Apps für Screenreader betreut. Das größte Problem bei Tailwind ist, dass es die Reihenfolge umkehrt, in der man über HTML und CSS nachdenken sollte
HTML dient dazu, die Bedeutung eines Dokuments auszudrücken, also sollte man dort beginnen und erst danach mit CSS stylen. Wenn man wegen des Stylings zusätzliche Elemente braucht, kann man
divoderspanverwenden, sollte aber zuerst überlegen, ob es nicht ein besseres Element gibtTailwind drängt Entwickler zu einem CSS-zuerst-Ansatz, sodass sie zuerst an die gewünschte Tailwind-Klasse denken und dann noch ein weiteres
divin den DOM einfügen, nur um diese Klasse anzubringenZu den Fähigkeiten eines Webentwicklers sollte auch künftig gehören, HTML und CSS zu schreiben, die langfristig lesbar sind, von allen Nutzern verwendet werden können und im Großen und Ganzen den HTML/CSS-Spezifikationen entsprechen. Tailwind verschlechtert diese Fähigkeiten. Sogar das erste Beispiel auf der Tailwind-Website besteht nur aus
divundspan, was neue Entwickler schlecht schult, und ich denke, es hat auch zu dem Trend beigetragen, dass LLMs ohne besondere Anweisung div-Suppe ausgebenJedes Werkzeug kann falsch verwendet werden, und Tailwind ist da keine Ausnahme. Ich arbeite seit etwa 20 Jahren mit CSS und habe auch Less, SASS/SCSS, Stylus und PostCSS genutzt, bin aber in den letzten Jahren gerade deshalb bei Tailwind geblieben, weil es robusteres Application-Styling ermöglicht
Man muss Stil-/Klassenabstraktionen nicht überstrapazieren, die Styles direkt am betroffenen Markup zu haben senkt die kognitive Last, unbeabsichtigte Stiländerungen durch lose Selektoren treten seltener auf und Debugging wird einfacher. Verglichen mit Codebases mit eigenem CSS-Framework sind Tailwind-Codebases abgesehen von einfachen Websites/Apps oft weniger komplex und weniger fragil
Wenn man konsistente Skalen für Schriftarten, Farben und Größen, kleinere Bundles, Konsistenz zwischen Entwicklern mit Tailwind-Kenntnissen, ein starkes Ökosystem und LLM-Freundlichkeit mit einbezieht, ist es für viele Teams eine hervorragende Wahl. Letztlich gilt wie bei den meisten Tools: Es kann gut oder schlecht eingesetzt werden, je nachdem, wer es benutzt
Das Chaos von HTML/CSS/JS sehe ich als notwendiges Übel, wenn man für Browser entwickelt; für mich ist das nur die Darstellungsschicht. Im Beruf lege ich deutlich mehr Wert auf die Korrektheit von Datenbankschemata oder Business-Logik im Backend
Wenn aus einer schmutzigen Darstellungsschicht mit möglichst wenig Einsatz halbwegs wartbarer Code wird, reicht mir das völlig, und dafür passt Tailwind gut. LLMs schreiben es gut, neue Entwickler verstehen es schnell, und später lässt es sich ebenfalls recht leicht lesen und ändern
Ich stimme völlig zu, dass ein Tailwind-Projekt nicht der beste Weg ist, damit neue Entwickler HTML/CSS lernen, aber ich würde trotzdem lieber sehen, dass sie sich auf gute Datenbankschemata, intuitive APIs und testbare Business-Logik konzentrieren
In Tailwind selbst gibt es nichts, das einen zwingt,
divundspananstelle passender HTML-Tags zu verwendenDokumente und Interfaces sind unterschiedlich, und bei Interfaces ergibt Tailwind deutlich mehr Sinn. Für Interfaces kann man Tailwind verwenden und für andere Inhalte HTML-Selektoren mit begrenztem Geltungsbereich
Dass Tailwind etwa viermal schneller ist als das Schreiben komplexer CSS-Codebases und praktisch keinen Overhead hat, bleibt unabhängig von jeder Bewertung ein Vorteil
Kurz gesagt ist es eine Methode, CSS nach der Reihenfolge der Spezifität zu schreiben:
/scss/
├── 1-settings. <- globale Einstellungen
├── 2-design-tokens <- Schriftarten, Farben, Abstände usw.
├── 3-tools <- Sass-Mixins, CSS-Funktionen usw.
├── 4-generic <- Resets, Box-Sizing, Normalisierung usw.
├── 5-elements <- Basisstile für Überschriften, Buttons, Links
├── 6-skeleton <- Layout-Grids usw.
├── 7-components <- Cards, Carousel usw.
├── 8-utilities <- Utility- und Helper-Klassen
├── _shame.scss <- Hacks, die man später beheben will
└── main.scss
ITCSS beseitigt Kämpfe um Spezifität in einer CSS-Codebase praktisch vollständig. Normalerweise ist die einzige Schicht, in der
!importantvorkommt, die Utility-Schicht[1]: https://matthiasott.com/notes/how-i-structure-my-css
Wenn man sich Component Libraries ansieht, enthalten sie auch
aria-Attribute: https://tailwindcss.com/plus/ui-blocks/marketing/sections/pr...Sofern es sich nicht um etwas wie eine Landingpage handelt, die eher einem digitalen Prospekt ähnelt, beginne ich immer mit dem Markup und füge dann CSS-Klassen darüber hinzu
Zwei gute Dinge an Tailwind sind, dass in den AI-Trainingsdaten bereits viele Klasseninformationen enthalten sind und dass es keine Stilkonflikte gibt
Deshalb muss AI beim Erstellen neuer Styles nicht auf bestehende Stylesheets Bezug nehmen, was gut für das Kontextmanagement ist
Bei eigenem CSS muss AI bestehende Stylesheets lesen, um Konflikte oder doppelte Definitionen zu vermeiden, aber große Stylesheets können viel vom Speicherfenster der AI belegen, was problematisch sein kann
Ich mag die Texte von Julia Evans wirklich sehr
Sie schreibt aus einer Haltung von Verletzlichkeit und Ehrlichkeit heraus. Viele schreiben, um klug zu wirken, aber Julia schreibt mit der Haltung: „Ich weiß auch nicht alles, aber ich habe etwas entdeckt, das ich gern teilen möchte.“ Auch ohne sie persönlich zu kennen, fühlt es sich an, als würde sie mit Menschen, die sie liebt, etwas teilen
Bei der letzten Strange Loop hat sie zusammen mit Randall Munroe präsentiert. Nach dem Vortrag warteten manche darauf, mit ihm zu sprechen, aber ich wartete darauf, mit Julia zu sprechen. Es tut mir aufrichtig leid, dass sie meinen Witz offenbar nicht verstanden hat, mein bash-Skript in Perl neu zu schreiben
Ich bin nicht Julia, aber ich habe fast dieselbe Philosophie zu öffentlichen Vorträgen oder Präsentationen und habe versucht, sie auch Kollegen zu vermitteln, denen Präsentationen schwerfallen. Es ist ein großes Privileg, Kollegen und Menschen, die man liebt, Wissen weitergeben zu können, mit dem man selbst etwas vertrauter ist und das ihnen helfen kann
CSS Modules sind eine einfachere Lösung für das Cascading-Problem. Sie verhindern Klassenkonflikte, indem sie eindeutige Klassennamen erzeugen [1]
Außerdem haben sie nicht zwei große Nachteile von Tailwind: Lesbarkeit [2] und Tooling-Support. Vor allem beim Debugging und interaktiven Experimentieren in Chrome und FireFox DevTools finde ich den Tooling-Support besser
[1] https://x.com/efortis/status/1888304658080256099
[2] https://github.com/ericfortis/tailwind-eye
Was mich an Tailwind immer beeindruckt hat, ist, dass fast jedes Argument der Befürworter letztlich darauf hinausläuft: „Ich habe CSS nie über Junior-Niveau hinaus gelernt“
Oft hört man Dinge wie: „Ohne Tailwind wächst eine einzige große, unaufgeräumte CSS-Datei unkontrollierbar weiter und ist voller Altlasten und
!important“, aber CSS ist wie jede andere technische Fähigkeit eben auch eine FähigkeitWenn man nur so viel lernt, dass es irgendwie richtig aussieht, und dann nur flickt, überholt der eigene Anspruch sehr schnell die Fähigkeit, den Code sauber zu halten
Es ist wirklich frustrierend, wenn man mit jemandem über Tailwind und CSS spricht und plötzlich merkt, dass die Person nicht nur nicht weiß, was „cascading“ bedeutet, sondern noch nie auf den Gedanken gekommen ist, dass dieses Konzept im Kontext von Stylesheets nützlich sein könnte
Ich habe seit den 90ern viel mit CSS gearbeitet, mir dann Tailwind angesehen und meide, seit ich es verstanden habe, größtenteils reines CSS. In gewisser Weise tauscht man ein Chaos gegen ein anderes, aber persönlich arbeite ich lieber mit lokalisierter Klassensuppe als mit überlappender und widersprüchlicher Cascade über mehrere Dateien hinweg
Beides kann sauber umgesetzt werden, aber Tailwind-Chaos aufzuräumen ist deutlich besser als CSS-Chaos, und der gesamte Entwicklungsprozess fühlt sich angenehmer an
Ich programmiere selbst seit über 20 Jahren und mache seit fast 15 Jahren Webentwicklung, aber ich finde es schwer, Motivation zu haben, CSS wirklich gründlich zu lernen. Es gibt zu viele technische Fähigkeiten, mit denen man Schritt halten muss, und CSS steht auf meiner Prioritätenliste ziemlich weit unten
Ich würde es lieber Experten überlassen, aber Unternehmen wollen keine dedizierten Frontend-Entwickler einstellen
Ich schreibe gerade einen sauberen Webentwicklungsleitfaden, der sich auf HTML und CSS konzentriert, die gut skalieren: https://webdev.bryanhogan.com/
Vielleicht ist das für Leute hier nützlich. Beim Styling verwende ich nichts wie Tailwind, sondern nur moderne Frameworks wie Astro oder Svelte und CSS
In jedem Projekt habe ich
reset.css,var.css,global.cssundutil.css, und alle übrigen Styles sind auf die jeweilige Komponente oder das jeweilige Layout begrenztGuter Artikel
Ich entferne gern Abhängigkeiten von externen Bibliotheken und baue Lösungen von Grund auf selbst, aber bei Tailwind gibt es einen klaren Grund, das nicht zu tun: Es liefert Produktionsoptimierung und stellt sicher, dass tatsächlich nur das minimal nötige CSS ausgeliefert wird
Selbst wenn man in
globals.cssoder anderswo alle Optionen für Farben, Abstände usw. aufzählt, muss man sich in der Produktion keine Sorgen machen, ob all diese Varianten auch wirklich verwendet werden. Wenn man in Frameworks wie Next.js arbeitet, passiert dieser Minimierungsschritt beim Build sogar automatisch, und allein das ist für mich schon ein ausreichender Grund, nicht von Tailwind wegzugehenIch hatte auch nie das Gefühl, dass Inline-CSS in Tailwind schwer zu tragende Einschränkungen mit sich bringt, und auch mit den Grid-Tools von Tailwind hatte ich keine größeren Probleme, responsive Grids über verschiedene Bildschirmbreiten hinweg umzusetzen. Die im Artikel genannten Szenarien habe ich alle entweder mit Tailwind oder mit einer Kombination aus Tailwind und CSS gelöst, und es stimmt zwar, dass
grid-column-areasnicht standardmäßig dabei ist, aber bei responsiven Grid-Layouts habe ich das bisher noch nicht als große Einschränkung empfundenDas größte Problem bei Tailwind ist, dass es lange dauert, bis man sich ans Lesen gewöhnt hat. Man lernt ja eher, dass Inline-CSS schlecht und globales CSS mit Scope gut sei, und man gewöhnt sich an sauberes HTML; echter Tailwind-Code, besonders in langen Zeilen, wirkt am Anfang deshalb wirklich schwer lesbar. Mit der Zeit habe ich mich vollständig an diese Form gewöhnt und bin letztlich zu dem Schluss gekommen, dass Tailwind für mich effizienter, wartbarer und sogar lesbarer ist, aber das hat ziemlich lange gedauert
Ein Ansatz, der mir in letzter Zeit wirklich gefällt, ist die Kombination aus Tailwind und Scoped Styles (in Svelte und Vue)
So behält man den Komfort von Tailwind bei und minimiert gleichzeitig die Verschmutzung der Templates:
+
{{ count }}
Für mich haben Svelte und LLMs die Notwendigkeit von Tailwind vollständig beseitigt
Wie sich herausgestellt hat, habe ich Tailwind vor allem nicht wegen selbst auferlegter Einschränkungen genutzt, sondern um CSS-Konflikte zu vermeiden und wegen einer Syntax, die sich für mich logischer anfühlt
Das Beste an Tailwind ist für mich, dass man keine provisorischen Klassennamen mehr erfinden muss. Man muss BEM nicht mehr verwenden
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