Gestaltung zwischen Bereichen

CSS wird langsam geschrieben, Zeile für Zeile, und mit jedem vergehenden Moment schränken wir den Raum dessen ein, was für unser Designsystem möglich ist. Nehmen wir dieses Beispiel

body {
  font-family: 'Proxima-Nova', sans-serif;
  color: #333;
}

Mit nur wenigen Zeilen CSS haben wir die Standardeinstellungen für unsere gesamte Codebasis festgelegt. Die meisten Elemente (wie Absätze, Listen und einfache divs) erben diese Anweisungen. Aber was wir beim Schreiben von CSS selten bedenken, ist, dass wir von nun an diese Regeln ständig überschreiben müssen, wenn wir eine andere Schriftart oder Farbe wünschen. Und es sind diese Überschreibungen, die viele Probleme in Bezug auf Wartung und Skalierbarkeit verursachen. Und es sind diese Probleme, die uns Herzschmerz, Zeit und Geld kosten.

Im obigen Beispiel ist das wahrscheinlich kein Problem, aber ich denke, im Allgemeinen erkennen wir nicht die wahre Stärke und die Gefahren der Kaskade und was sie für unsere Designsysteme bedeutet; die meisten Leute denken, dass die Kaskade dazu dient, frühere Anweisungen zu überschreiben, aber ich würde davor warnen. Jedes Mal, wenn wir einen Stil überschreiben, der geerbt wird, machen wir unsere Codebasis um ein Vielfaches komplexer. Wie viele Stunden haben Sie damit verbracht, ein Element zu inspizieren und durch jede Regel zu scrollen, um zu verstehen, warum ein Element so aussieht, wie es aussieht, oder wie die lange Kette von Vererbung Ihre Stile komplett durcheinandergebracht hat?

Ich denke, der Grund dafür ist, dass wir oft nicht die richtigen Standardstile für unsere Elemente festlegen. Und wenn wir den Stil eines Elements ändern wollen, anstatt uns die Zeit zu nehmen, diese Standardstile zu hinterfragen und neu zu gestalten, überschreiben wir sie einfach – was die Sache noch schlimmer macht.

Daher habe ich viel darüber nachgedacht, wie wir eine Codebasis erstellen sollten, die uns alle dazu anregt, besseren Code zu schreiben, und wie wir unser CSS so gestalten, dass es andere Leute nicht dazu ermutigt, hacky Klassen zu erstellen, um Dinge zu überschreiben.

Einer meiner Lieblingsartikel zu diesem Thema wurde Anfang dieses Monats von Brandon Smith geschrieben, wo er die Wege beschreibt, wie CSS so kompliziert werden kann (Hervorhebung von mir)

…sei nie expliziter als nötig. Webseiten sind standardmäßig responsiv. Gutes CSS zu schreiben bedeutet, diese Tatsache zu nutzen, anstatt sie zu überschreiben. Verwenden Sie Prozentangaben oder Viewport-Einheiten anstelle von Media Queries, wenn möglich. Verwenden Sie min-width anstelle von width, wo Sie können. Denken Sie in Begriffen von Regeln, in Begriffen dessen, was Sie wirklich sagen wollen, anstatt nur Eigenschaften hinzuzufügen, bis die Dinge richtig aussehen. Versuchen Sie, ein Gefühl dafür zu bekommen, wie der Browser Layout und Größen bestimmt, und nehmen Sie Ihre Änderungen und Ergänzungen vorsichtig darauf vor. **Arbeiten Sie mit CSS, nicht dagegen.**

Einer von Brandons Vorschlägen ist, die width-Eigenschaft ganz zu vermeiden und stattdessen bei max-width oder min-width zu bleiben. In dem gesamten Beitrag erinnert er uns daran, dass alles, was wir bauen, zwischen Bereichen, zwischen zwei Extremen liegen sollte. Hier ist also ein Beispiel für eine Klasse mit einem schlechten Standardstil

.button {
  width: 300px;
}

Ist dieser Button wahrscheinlich immer, *überall* diese Breite zu haben? Auf Mobilgeräten? In jeder Media Query? In jedem Zustand? Das bezweifle ich stark, und tatsächlich glaube ich, dass diese Klasse geradezu danach schreit, mit einer weiteren Klasse überschrieben zu werden

.button-thats-just-a-bit-bigger {
  width: 310px;
}

Das ist ein albernes Beispiel, aber ich habe so etwas in vielen Teams gesehen – und das nicht, weil die Person schlechten Code geschrieben hat, sondern weil **das System sie dazu ermutigt hat, schlechten Code zu schreiben**. Jeder hat eine Frist für den Versand eines Produkts, und die meisten Leute haben nicht die Zeit oder die Neigung, sich in eine große Codebasis einzutauchen und diese Kern-Standardstile, die ich erwähnt habe, neu zu gestalten. Es ist einfacher, einfach weiterhin CSS zu schreiben, weil es sofort alle ihre Probleme löst.

In diesem Zusammenhang schrieb Jeremy Keith gerade neulich über dieses Problem

Im Gegensatz zu einer Programmiersprache, die Kenntnisse über Schleifen, Variablen und andere Konzepte erfordert, ist CSS ziemlich einfach zu erlernen. Vielleicht hat es deshalb den Ruf, einfach zu sein. Es ist einfach im Sinne von "nicht komplex", aber das bedeutet nicht, dass es leicht ist. "Einfach" mit "leicht" zu verwechseln, führt nur zu Herzschmerz.

Ich denke, das ist einigen Programmierern passiert, die zum ersten Mal mit CSS in Berührung kommen. Sie haben gehört, dass es einfach ist, also gehen sie davon aus, dass es leicht ist. Aber wenn sie es dann versuchen zu benutzen, funktioniert es nicht. Es muss die Schuld der Sprache sein, denn sie wissen, dass sie klug sind und dass das leicht sein soll. Also geben sie der Sprache die Schuld. Sie sagen, sie sei kaputt. Und so versuchen sie, sie zu "reparieren", indem sie sie an eine programmatischere Denkweise anpassen.

Ich kann nicht umhin zu denken, dass sie weniger frustriert wären, wenn sie akzeptieren würden, dass CSS nicht leicht ist. Einfach, ja, aber nicht leicht.

Der Grund, warum CSS einfach ist, ist die Kaskade, aber es ist wegen der Kaskade auch nicht so leicht, wie wir vielleicht zuerst denken. Es sind diese Standardstile, die sich in alles filtern, was die größte Stärke und größte Schwäche der Sprache ist. Und ich glaube nicht, dass JavaScript-basierte Lösungen dabei so viel helfen werden, wie alle gegenteiliges behaupten.

Also, was ist die Lösung? Ich denke, dass das Gestalten in einem Bereich, das Denken zwischen Zuständen und das Betrachten jeder einzelnen Zeile CSS als Vorschlag anstelle eines absoluten, unzerbrechlichen Gesetzes der erste Schritt ist. Was ist der nächste Schritt? Container-Abfragen. Container-Abfragen. Container-Abfragen.