Über die wachsende Beliebtheit von Atomic CSS

Auch wenn Sie sich selbst als CSS-Experten betrachten, ist die Wahrscheinlichkeit groß, dass Sie auf einem großen Projekt irgendwann mit einem verworrenen, labyrinthartigen Stylesheet zu tun hatten, das immer weiterwächst. Manche Stylesheets können sich wie ein chaotisch verwickeltes Netz von Vererbung anfühlen.

Die Kaskade ist unglaublich mächtig. Kleine Änderungen können große Auswirkungen haben, was es schwieriger macht, die unmittelbaren Folgen abzuschätzen. Das Refactoring, Ändern und Entfernen von CSS wird als riskant angesehen und mit Furcht angegangen, da es schwierig ist, alle Stellen zu kennen, an denen es verwendet wird.

Eine Sache, die bei neuen Tools oft schwer zu artikulieren ist, ist: wann genau fängt man an, danach zu greifen? Die Antwort ist selten (wenn überhaupt) sofort und in allen Situationen.

Eine dieser Situationen ist meiner begrenzten Erfahrung nach bei großen Teams mit großen Codebasen. Das Gefühl ist, dass das CSS viel zu groß werden kann und die Teammitglieder im Grunde Angst davor bekommen, und das CSS wird scherzhaft, aber zutreffend, "nur zum Anhängen".

Dann kommt ein Tool, das das Versprechen einlöst, viel weniger CSS zu liefern, und zwar so, dass (nach einer Lernkurve) niemand mehr Angst davor hat… Ich kann den Reiz verstehen.

– Chris Coyier

Atomic CSS hält die Dinge einfach

Ich musste nicht mehr darüber nachdenken, wie ich mein CSS organisiere. Ich musste nicht darüber nachdenken, wie ich meine „Komponenten“ benenne, wo ich die Grenze zwischen einer Komponente und einer anderen ziehe, was wo leben sollte und, ganz entscheidend, wie ich Dinge umgestalte, wenn neue Anforderungen hinzukamen.

– Callum Jefferies, Erkenntnisse aus dem Ausprobieren von Tachyons CSS nach langer BEM-Nutzung

Atomic CSS bietet eine einfache, offensichtliche und unkomplizierte Methodik. Klassen sind unveränderlich – sie ändern sich nicht. Dies macht die Anwendung von CSS vorhersehbar und zuverlässig, da Klassen immer genau dasselbe tun werden. Der Umfang des Hinzufügens oder Entfernens einer Utility-Klasse in einer HTML-Datei ist eindeutig, was Ihnen die Gewissheit gibt, dass Sie nichts anderes kaputt machen. Dies kann die kognitive Belastung und den mentalen Overhead reduzieren.

Komponenten zu benennen ist bekanntermaßen schwierig. Einen Klassennamen zu finden, der sowohl aussagekräftig als auch vage genug ist, um wiederverwendbar zu sein, ist zeitaufwendig und mental anstrengend.

Es gibt nur zwei schwierige Dinge in der Informatik: Cache-Invalidierung und das Benennen von Dingen.

– Phil Karlton

Geeignete Abstraktionen zu finden ist schwierig. Das Benennen von Utility-Klassen hingegen ist völlig unkompliziert.

/* naming utility classes */
.relative {
  position: relative;
}
.mt10 {
  margin-top: 10px;
}
.pb10 {
  padding-bottom: 10px;
}

Atomare Klassen sprechen für sich. Ihre Absicht und Wirkung sind sofort ersichtlich. Während das Füllen von HTML mit unzähligen Klassen unordentlich aussehen mag, ist HTML viel einfacher zu verstehen als eine undurchdringlich riesige und unverständliche Wand verworrener Stile.

In einem Team mit unterschiedlichen Fähigkeiten, möglicherweise mit Backend-Entwicklern mit begrenztem Interesse und Wissen über CSS, ist die Wahrscheinlichkeit geringer, dass jemand das Stylesheet durcheinanderbringt.

Umgang mit stilistischen Variationen

Utility-Klassen sind perfekt für den Umgang mit kleinen stilistischen Variationen. Während Designsysteme und Pattern Libraries heutzutage in aller Munde sind, erkennt dieser Ansatz, dass es kontinuierlich neue Anforderungen und Variationen geben wird. All die Reden über Komponentenwiederverwendbarkeit spiegeln sich oft nicht in den Design-Mocks wider, die einem zugespielt werden. Während visuelle und Marken-Konsistenz gut ist, macht die große Vielfalt an Kontexten auf einer großen Website einige Variationen unvermeidlich und gerechtfertigt.

Was, wenn wir möchten, dass eine Komponente nur auf eine einzige kleine Weise von einer anderen abweicht? Wenn Sie eine BEM-Benennungskonvention angenommen haben, könnten die Modifikatorklassen außer Kontrolle geraten – unzählige Modifikatoren, die oft nur eine einzige Sache tun. Nehmen wir Ränder als Beispiel. Die Ränder einer Komponente werden wahrscheinlich nicht universell konsistent bleiben. Der gewünschte Abstand hängt nicht nur von der Komponente ab, sondern auch von ihrer Position auf einer Seite und ihrer Beziehung zu den umgebenden Elementen. Meistens enthalten Designs ähnliche, aber nicht identische UI-Elemente, die mit traditionellem CSS mühsam zu handhaben sind.

Viele Leute mögen es nicht

Wie unterscheidet sich Atomic CSS von Inline-Styles?

Das ist die Frage, die von Kritikern des Atomic CSS immer gestellt wird. Inline-Styles gelten seit den Anfängen des Webs als schlechte Praxis und werden selten verwendet. Kritiker liegen nicht völlig falsch, Atomic CSS mit Inline-Styles gleichzusetzen, da beide unter demselben großen Problem leiden. Hier ist ein Beispiel: Was, wenn wir alles mit einer `black`-Klasse stattdessen marineblau haben wollen? Wir könnten das tun:

.black {
  color: navy;
}

Das ist offensichtlich eine schreckliche Idee.

Texteditoren sind heutzutage ausgeklügelte Dinge. Es fühlt sich etwas gefährlich an, aber es wäre einfach genug, Suchen und Ersetzen zu verwenden, um alle Instanzen der `.black`-Klasse durch eine neue `.navy`-Klasse zu ersetzen. Das eigentliche Problem ist, wenn man nur bestimmte Instanzen von `.black` in `.navy` ändern möchte.

Bei traditionellen CSS-Ansätzen ist die Anpassung des Stylings einer Komponente so einfach wie das Aktualisieren eines einzelnen Werts in einer einzelnen Klasse in einer CSS-Datei. Mit Atomic CSS wird dies zu einer mühsamen Aufgabe, bei der man jede HTML-Datei durchsuchen muss, um jede Instanz der besagten Komponente zu aktualisieren. Egal wie fortschrittlich Code-Editoren werden, daran führt kein Weg vorbei. Selbst wenn Sie Ihr Markup in wiederverwendbare Vorlagen aufteilen, ist dies immer noch ein großer Nachteil. Vielleicht ist diese manuelle Arbeit die Einfachheit dieses Ansatzes wert. Das Aktualisieren von HTML-Dateien mit verschiedenen Klassen mag mühsam, aber nicht schwierig sein. (Obwohl es Zeiten gab, in denen ich vorübergehend stilistische Inkonsistenzen eingeführt habe, indem ich bestimmte Instanzen der relevanten Komponente beim manuellen Aktualisieren übersehen habe.) Wenn sich ein Design ändert, müssen Sie wahrscheinlich Klassen von überall in Ihrem HTML manuell bearbeiten.

Während Atomic CSS den großen Nachteil von Inline-Styles teilt, sind sie kein rückschrittlicher Schritt in die Vergangenheit. Utility-Klassen sind Inline-Styles in vielerlei Hinsicht überlegen.

Atomic CSS vs. Inline-Styles

Atomare Klassen ermöglichen Abstraktion, Inline-Styles nicht

Mit atomaren Klassen ist es möglich, Abstraktionen zu erstellen, die mit Inline-Styles unmöglich wären.

<p style="font-family: helvetica; color: rgb(20, 20, 20)">
  Inline styles suck.
</p>
<p class="helvetica rgb202020">
  Badly written CSS isn't very different.
</p>
<p class="sans-serif color-dark">
  Utility classes allow for abstraction.
</p>

Die ersten beiden oben gezeigten Beispiele würden eine manuelle Suchen-und-Ersetzen-Aktion erfordern, um das Styling zu aktualisieren, falls sich das Design ändern sollte. Die Stile im dritten Beispiel können an einer einzigen Stelle innerhalb eines Stylesheets angepasst werden.

Werkzeuge

Sass, Less, PostCSS, Autoprefixer… Die CSS-Community hat viele nützliche Tools entwickelt, die für Inline-Styles nicht verfügbar waren.

Kürze

Anstatt ausführliche Inline-Styles zu schreiben, können atomare Klassen kurze Abkürzungen für Deklarationen sein. Das ist weniger Tipparbeit: `mt0` vs. `margin-top: 0`, `flex` vs. `display: flex`, usw.

Spezifität

Dies ist ein umstrittener Punkt. Wenn eine Klasse oder ein Inline-Style nur eine einzige Sache tut, ist die Wahrscheinlichkeit groß, dass man will, dass es diese Sache tut. Einige Leute haben sogar empfohlen, `!important` für alle Utility-Klassen zu verwenden, um sicherzustellen, dass sie alles andere überschreiben. Ähnlich sehen Befürworter von Inline-Styles ihre Unfähigkeit, überschrieben zu werden (durch nichts außer !important), als Verkaufsargument – es bedeutet, dass man sicher sein kann, dass der Stil angewendet wird. Eine Klasse allein ist jedoch spezifisch genug, um jeden Basisstil zu überschreiben. Die geringere Spezifität von atomaren Klassen im Vergleich zu Inline-Styles ist eine gute Sache. Sie ermöglicht mehr Vielseitigkeit. Wir sind es alle gewohnt, Klassen in JavaScript zu ändern, um Stile zu ändern. Inline-Styles erschweren dies.

Klassen in Stylesheets können Dinge tun, die Inline-Styles nicht können

Inline-Styles unterstützen keine Medienabfragen, Pseudo-Selektoren, @supports oder CSS-Animationen. Vielleicht möchten Sie einen einzigen Hover-Effekt auf verschiedene Elemente anwenden und nicht nur auf eine Komponente.

.circle {
  border-radius: 50%;
}

.hover-radius0:hover {
  border-radius: 0;
}

Einfache, wiederverwendbare Media-Query-Regeln können auch in eine Utility-Klasse umgewandelt werden. Es ist üblich, ein Klassennamen-Präfix für kleine, mittlere und große Bildschirmgrößen zu verwenden. Hier ist ein Beispiel für eine Flexbox-Klasse, die nur auf mittleren und großen Bildschirmgrößen angewendet wird:

@media (min-width: 600px) {
  .md-flex {
    display: flex;
  }
}

Dies wäre mit einem Inline-Style nicht möglich.

Vielleicht möchten Sie ein wiederverwendbares Pseudo-Inhalts-Symbol oder -Label?

.with-icon::after {
  content: 'some icon goes here!';
}

Wahlbeschränkung kann gut sein

Inline-Styles können alles sein. Diese Freiheit könnte leicht zu Designanarchie und Inkonsistenz führen. Durch die Vordefinition von Klassen für alles kann Atomic CSS ein gewisses Maß an stilistischer Konsistenz gewährleisten. Anstatt Farben und Werte aus unendlich vielen Optionen frei zu wählen, bieten Utility-Klassen eine kuratierte Auswahl vordefinierter Optionen. Entwickler wählen aus dieser begrenzten Menge von Einzweck-Utility-Klassen. Diese Einschränkung kann sowohl das Problem eines ständig wachsenden Stylesheets beseitigen als auch die visuelle Konsistenz aufrechterhalten.

Nehmen Sie den `box-shadow` als Beispiel. Ein Inline-Style bietet eine nahezu unbegrenzte Anzahl von Optionen für Offset, Streuung, Farbe, Deckkraft und Unschärferadius.

<div style="box-shadow: 2px 2px 2px rgba(10, 10, 250, .4)">stuff</div>

Mit einem atomaren Ansatz können CSS-Autoren den bevorzugten Stil definieren, der dann einfach angewendet wird, ohne die Möglichkeit stilistischer Inkonsistenzen.

<div class="box-shadow">stuff</div>

Atomic CSS ist kein Alles-oder-Nichts-Prinzip

Es besteht kein Zweifel, dass Utility-Klassen-Frameworks wie Tachyons an Popularität gewonnen haben. Allerdings schließen sich CSS-Ansätze nicht gegenseitig aus. Es gibt viele Fälle, in denen Utility-Klassen nicht die beste Option sind.

• Wenn Sie viele Stile für eine bestimmte Komponente innerhalb einer Medienabfrage ändern müssen.
• Wenn Sie mehrere Stile mit JavaScript ändern möchten, ist es einfacher, dies in einer einzigen Klasse zu abstrahieren.

Utility-Klassen können mit anderen Ansätzen koexistieren. Es ist wahrscheinlich eine gute Idee, Basisstile und vernünftige Standardwerte global zu definieren. Wenn Sie dieselbe lange Zeichenfolge von Utility-Klassen immer wieder duplizieren, besteht die Wahrscheinlichkeit, dass die Stile in eine einzige Klasse abstrahiert werden sollten. Sie können Komponentenklassen einbinden, aber nur dann, wenn Sie wissen, dass sie wiederverwendet werden.

Einen komponentenbasierten Ansatz für CSS zu verfolgen bedeutet, dass Sie Komponenten für Dinge erstellen, selbst wenn diese niemals wiederverwendet werden. Diese vorzeitige Abstraktion ist die Ursache für viel Aufblähung und Komplexität in Stylesheets.

– Adam Wathan

Je kleiner die Einheit, desto wiederverwendbarer ist sie.

– Thierry Koblentz

Betrachtet man die neueste Version von Bootstrap, so werden nun eine ganze Reihe von Utility-Klassen angeboten, während die traditionellen Komponenten weiterhin enthalten sind. Immer mehr beliebte Frameworks verfolgen diesen gemischten Ansatz.