Das Dilemma der Benennung von Schriftgrößen Variablen

Normalerweise hat ein Projekt eine Reihe von vordefinierten Schriftgrößen, normalerweise als Variablen benannt, auf eine Weise, die einen gewissen Anschein von Ordnung und Konsistenz anstrebt. Jedes Projekt von beträchtlicher Größe kann so etwas nutzen. Es gibt immer Überschriften, Absätze, Listen usw. Sie *könnten* Schriftgrößen explizit und direkt überall festlegen (z. B. font-size: 18px). Rohes CSS, sozusagen. Das sehe ich gelegentlich – eine gedankenlose Vermischung nicht nur von Größen, sondern auch von Einheiten wie px, rem und em im reinen Chaos.

Deshalb verwendet das CSS eines Projekts typischerweise Variablen oder Mixins – wir streben nach Struktur, Wartbarkeit und letztendlich Konsistenz. Wir alle wissen, dass Benennung schwierig ist, und man muss nicht weiter als bis zur Benennung von Schriftgrößenvariablen schauen, um zu verstehen, warum. Wie sollten wir eine kleine Schriftgrößenvariable benennen, damit klar ist, dass sie kleiner ist als eine große Schriftgrößenvariable? Und was passiert, wenn wir eine neue Variable dazwischen einfügen müssen – wird diese so benannt, dass ihre Beziehung zu den anderen Größenvariablen klar erklärt wird?

Wir werden in diesem Beitrag weiter über die Benennung von Schriftgrößenvariablen sprechen. Aber eigentlich erstreckt sich das Problem über Schriftgrößen hinaus auf jede Art von Größen- oder Längenwert. Denken Sie an Abstände, Ränder, Breiten, Höhen, Radien von Rahmen usw. Diese Dinge benötigen ebenfalls Struktur und Konsistenz!

Wie definieren Sie Schriftgrößen in Ihrem Projekt? Sieht es in etwa so aus mit benutzerdefinierten Variablen

:root {
  /* Font size variables */
  --small: 12px;
  --medium: 16px;
  --large: 24px;
}

Oder vielleicht haben Sie in Sass (was wir in diesem Artikel verwenden werden) Variablen für $small, $medium und $large Schriftgrößen.

In Ordnung. Nach einer Weile sagen wir, der Designer fügt eine neue <h1> Überschrift für einen Hero-Bereich hinzu. Und sie ist *sehr* groß. Größer als alles, was Sie im Projekt haben. Kein Problem, antworten Sie. Sie fügen ein $xlarge zum Projekt hinzu und machen weiter.

Am nächsten Tag erstellt der Designer ein schönes Formularlabel, das wieder eine neue Schriftgröße hat. Diese neue Größe ist zwar größer als klein, aber kleiner als mittel.

Jetzt geht's los.

Wie nennen Sie das? $small-medium? $small-2? $smedium? Wie auch immer Sie es nennen, Sie werden damit nicht zufrieden sein. Weil es dafür kein Wort gibt.

Oder sollten Sie es vielleicht refaktorieren? Ein neues $xsmall erstellen und alle Instanzen von $small in $xsmall ändern? Und dann können Sie $small für das Formularlabel verwenden? Es besteht ein geringes Risiko, dass Sie vergessen, es an einer Stelle zu ändern, und zack: ein Fehler. Was passiert beim nächsten Mal, wenn etwas eingeführt wird, das eine größere Größe als der Wert der $medium Variable hat? Müssen wir dann auch $large und $xlarge refaktorieren?

Ich schlage vor, sich immer an eine Skala zu halten. Eine einfache Lösung wäre eine weitere Abstraktion, vielleicht das Verwerfen von Zahlen und Größen zugunsten von Funktionsnamen, wie $form-label anstelle von $small-2 oder $xsmall.

Aber stellen Sie sich einen Satz von Schriftgrößen wie diesen vor

$small: 12px;
$form-label: 14px;
$medium: 16px;
$large: 24px;

Das ist eine fehlerhafte Skala. Es ist ein Größenkonzept und ein Komponentenkonzept miteinander vermischt. Es wirft Fragen auf. Sollte ein Alert oder ein Button $form-label verwenden dürfen? Igitt.

Vielleicht haben Sie ein griechisches Ding am Laufen und benennen die Variablen $alpha, $beta, $gamma? Dann frage ich Sie: Was ist größer als $alpha? $alpha-large? Oder Moment, ist $alpha die *kleine*?

Ich habe auch Namen wie $button-font-size, $label-font-size, $blockquote-font-size gesehen. Das scheint mir eine Variable pro verwendetes Element zu sein, anstatt einer Skala, und es klingt so, als könnte es viel doppelten Code geben, wenn derselbe Wert an mehreren Stellen mit unterschiedlichen Namen verwendet wird.

Vielleicht arbeiten Sie mit einer Basis-Schriftgröße und nur mit Prozentangaben? Sicher, aber ich würde sagen, Sie brauchen Variablen für die Prozentangaben. So handhabt Geoff die Schriftgrößen, und selbst er gibt zu, dass das Setup seine eigenen Augenbrauen hochzieht. Berechnungen mit subjektiv benannten Variablen mögen für Sie klar sein, aber für jeden anderen, der in das Projekt einsteigt, sehen sie seltsam und kompliziert aus.

h1 {
  font-size: clamp(var(--text-size-large), calc(var(--text-size-base) * var(--text-size-scaler)), var(--text-size-huge));
}

Wir brauchen ein besseres System

Das *ständige* Hinzufügen und Entfernen von Dingen ist die Art und Weise, wie wir arbeiten *wollen*. Das ist moderne Entwicklung – MVP, Agile und all die anderen heißen Schlagworte.

Was wir brauchen, ist eine Skalensyntax, die Raum für Änderungen lässt. Das Hinzufügen einer neuen Größe zur Skala sollte einfach sein, ohne dass es zu Bruchänderungen kommt. Ich denke dabei an eine Art Skala, die sowohl **flexibel** als auch **unendlich** ist. Sie muss anspruchsvoller sein als $small, $medium und $large.

Sie sollte auch **beschreibend** und **intuitiv** sein. Idealerweise müssen Sie die Variablennamen nicht in der Einstellungsdatei oder der Konfiguration nachschlagen, oder wo auch immer Sie diese Dinge speichern. Ich habe keine Ahnung, ob $epsilon vor oder nach $sigma kommt. Sie?

Verwendung bestehender Systeme

Bevor wir versuchen, etwas Neues zu erfinden, gibt es eine bestehende Syntax oder ein System, das wir nutzen können? Hier sind einige, die ich angetroffen habe.

Internationales System der Einheiten

Sicherlich sind Ihnen Begriffe wie „Kilobyte“ und „Megabyte“ vertraut. Europäer sind sehr an „Millimeter“ und „Zentimeter“ gewöhnt. Andere Beispiele sind „Giga“, „Tera“ und „Peta“. Diese Präfixe können für Länge, Gewicht, Volumen und mehr verwendet werden. Könnte eine $centi Schriftgröße funktionieren? Sie ist bis zu einem gewissen Grad intuitiv, d.h. wenn Sie mit dem metrischen System vertraut sind. Das ist eine endliche Skala. Und es gibt keinen Raum, neue Größen hinzuzufügen, da sie bereits festgelegt sind.

Traditionelle Punktgrößen-Namen

Lange vor Computern und Desktop-Publishing wurden Bücher und Zeitungen mit Bleisatz gedruckt. Die Setzer hatten unterschiedliche Namen für verschiedene Größen. Die Größen beziehen sich auf eine Punktgröße (pt) und könnten theoretisch für Pixelgrößen (px) verwendet werden.

Die Schriftgrößen in diesem System heißen „Nonpareil“, „Pica“, „Cicero“ und „Great Primer“, um nur einige zu nennen. Die Namen sind je nach Kontinent und Land unterschiedlich. Außerdem kann derselbe Name unterschiedliche Größen haben, also… ziemlich verwirrend.

Dennoch gefällt mir dieses System in gewisser Weise, weil es eine Hommage an ein altes Handwerk aus vergangenen Zeiten wäre. Aber die Namen sind so seltsam und speziell für die Schriftgrößen gedacht, dass es weit hergeholt wirkt, sie für Dinge wie Breakpoints und Abstände zu verwenden.

Alltagsgegenstände auf einer Skala platzieren

Wie wäre es, Dinge aus unserem Alltag zu verwenden? Sagen wir Chilis.

Es gibt viele Arten von Chilis. Der $habanero ist schärfer als der $cayenne, der schärfer ist als der $jalapeno. Das wäre doch lustig, oder?

Aber so sehr ich die Idee, font-size: $tabasco zu schreiben, genieße, sehe ich zwei Probleme. Wenn Sie sich nicht mit Chilis auskennen, wissen Sie nicht, welcher Chili schärfer ist als ein anderer – er ist also nicht universell intuitiv. Außerdem hat die Gemüsepaprika auf der Scoville-Skala eine 0 und nichts ist darunter. Carolina Reaper ist die schärfste Paprika der Welt, also ist die Skala endlich.

Und ja, Paprika sind skalenmäßig nicht größer oder kleiner, sie sind schärfer. Schlechtes Konzept. Vielleicht etwas Gängigeres, wie Ballarten?

Es gibt eine große Bandbreite an verschiedenen Ballarten. Sie haben Handbälle, Fußbälle, Volleybälle usw. Brauchen Sie etwas Größeres als einen Medizinball? Nehmen Sie $beach. Etwas Kleineres als ein Tennisball? Nehmen Sie $pingpong. Das ist sehr intuitiv, da ich mir vorstelle, dass jeder schon einmal mit allen möglichen Bällen gespielt hat oder zumindest damit aus dem Sport vertraut ist.

Aber ist ein Tischtennisball größer als ein Golfball? Wer weiß? Außerdem sind ein Bowlingball und ein Fußball tatsächlich gleich groß. Also… wieder nicht perfekt.

Das Hochskalieren auf Planeten könnte funktionieren, aber dazu müsste man sich mit Astronomie auskennen.

Wie wäre es mit reinen Zahlen? Wir können nicht nur Zahlen verwenden, weil Tools wie stylelint protestieren werden. Aber würde so etwas funktionieren

$font-14: 14px;
$font-16: 16px;
$font-24: 24px;

Nun, es ist unendlich, da immer Platz für neue Ergänzungen ist. Aber es ist auch unglaublich spezifisch, und es gibt einige Nachteile, wenn der tatsächliche Wert Teil des Namens ist. Nehmen wir an, $font-18 wird an vielen Stellen verwendet. Und jetzt sagen sie, alle Stellen mit 18px müssen auf 19px geändert werden (aus verschiedenen Gründen). Jetzt müssen wir die Variable von $font-18 in $font-19 umbenennen und dann den Wert von $font-19 von 18px auf 19px ändern. Und das, bevor wir endlich alle Stellen, die $font-18 verwenden, auf $font-19 aktualisieren. Das ist fast so, als würde man rohes CSS verwenden. Niedrige Punktzahl für Wartbarkeit.

Was ist mit dem Tierreich?

Mutter Natur hat uns eine Fülle von Arten auf dieser Erde geschenkt, was in dieser Situation nützlich ist. Stellen Sie sich etwas wie das hier vor

$mouse: 12px;
$dog: 16px;
$hippo: 24px;

Brauchen Sie etwas Kleineres als eine Maus? Nehmen Sie $bee, $ant oder $flea. Größer als ein Bär? Versuchen Sie $moose oder $hippo. Größer als ein Elefant? Nun, da haben Sie den $whale, oder, wir können prähistorisch gehen und $t-rex verwenden. Es gibt immer ein Tier, das man hier noch unterbringen kann. Sehr vielseitig, sehr intuitiv, auch unendlich (fast). Und lustig obendrein – ich hätte nichts dagegen, font-size: $squirrel zu schreiben. 🤩

Aber auch das erfordert möglicherweise die Referenzierung der Variablen, es sei denn, wir wissen genau, welche Tiere in unserem Zoo von Schriftgrößen enthalten sind. Aber vielleicht ist das keine große Sache, solange es skaliert.

Ich habe viel zu viel Zeit damit verbracht, darüber nachzudenken

Oder habe ich das? Die Codebasis ist, wo Sie Ihre Arbeitsstunden verbringen. Es ist Ihre Arbeitsumgebung, genau wie Stühle und Monitore. Und der Arbeitsplatz sollte ein schöner Ort sein.

Wie handhaben Sie Ihre Schriftgrößen-Skalen? Haben Sie ein System für Schriftarten und ein anderes für Dinge wie Ränder? Kann jemand direkt in Ihren Code einsteigen und verstehen, wie alles organisiert ist? Erzählen Sie es uns in den Kommentaren!