Abstände-Tokens: Benennung und Stufen
Abstände-Tokens sind benannte Einträge für die Stufen einer Abstände-Skala —
space-4 oder space-md statt eines rohen 23px — gespeichert in einer
einzigen Quelle und von Design-Tools und Code gleichermaßen genutzt. Sie
verwandeln eine Liste von Zahlen in ein gemeinsames Vokabular: Ein Abstand wird
über seinen Namen ausgewählt, und der Name löst sich überall, wo er auftaucht,
in denselben Wert auf.
Dieser Artikel behandelt die zwei vorherrschenden Namenskonventionen und ihre Kompromisse, semantische Aliase, wie viele Stufen du offenlegen solltest und den Export-Weg, der eine Skala nach CSS, Tailwind und Figma trägt. Er setzt voraus, dass eine Skala bereits existiert — der Hub Abstände-System behandelt, wie man eine aufbaut.
Warum die Stufen überhaupt benennen?
Weil Namen der Weg sind, auf dem aus einem Menü etwas Gemeinsames wird. Eine
Abstände-Skala begrenzt, welche Werte
existieren; Tokens machen die Wahl zwischen ihnen kommunizierbar. Zwei Personen,
die nach „dem Abstand zwischen Formularfeldern” greifen, landen beim selben
Token — beim selben Wert würden sie es vielleicht nicht. Außerdem lassen sich
acht benannte Stufen leichter im Kopf behalten als acht Pixelwerte: Niemand
streitet darüber, ob ein Abstand 23px oder 26px sein soll, wenn die eigentliche
Wahl zwischen space-4 und space-5 liegt. Das Gespräch steigt eine Ebene
höher — eine Stufe mehr oder eine Stufe weniger — und genau auf dieser Ebene
gehören Abstände-Entscheidungen hin.
Sollten Abstände-Tokens Zahlen oder T-Shirt-Größen verwenden?
Die zwei weit verbreiteten Konventionen im Vergleich:
| Aspekt | Numerisch (space-1…space-7) | T-Shirt (xs…3xl) |
|---|---|---|
| Die Reihenfolge ablesen | Offensichtlich — die Zahlen sortieren sich von selbst | Gelernt, jenseits von xl etwas unscharf |
| Was der Name verrät | Nur die Position — space-4 sagt nichts über den Einsatz | Ein grobes Größengefühl, aber immer noch nicht den Einsatz |
| Eine Stufe oben anhängen | space-8 anhängen | 4xl anhängen |
| Eine Stufe in der Mitte einfügen | Neu nummerieren oder mit space-4-5 leben | Kein natürlicher Name zwischen md und lg |
Keine Spalte gewinnt. Numerische Namen skalieren elegant und bleiben ehrlich darin, Positionen auf einer Skala zu sein; T-Shirt-Namen sagen und merken sich freundlicher. Was wehtut, ist der spätere Wechsel: Token-Namen breiten sich in Komponenten, Stylesheets, Design-Bibliotheken und Dokumentation aus, und eine Umbenennung berührt jede einzelne davon. Wähle früh eine Konvention und lass sie langweilig sein.
Zur Anzahl der Stufen: Leg die ganze Skala offen und halte die Skala kurz — irgendwo zwischen 6 und 10 Stufen reicht für viele Produkte. Ein Token-Set, das deutlich größer ist als die Skala dahinter, ist ein Zeichen dafür, dass sich Einmalwerte unter neuen Namen wieder einschleichen.
Was sind semantische Abstände-Tokens?
Aliase, die eine Absicht benennen und auf eine Stufe zeigen: ein gap-section,
das sich zu space-7 auflöst, ein padding-card, das sich zu space-4 auflöst.
Die rohen Stufen bleiben die einzige Quelle der Werte; die Aliase halten fest,
warum ein Wert gewählt wurde.
Der Gewinn zeigt sich, wenn sich die Skala ändert. Skaliere das System neu — eine größere Basis, ein anderes Verhältnis — und jeder Abschnitts-Abstand im Produkt verschiebt sich mit, weil jeder auf ein Alias zeigt, das auf eine Stufe zeigt. Die Layout-Absicht überlebt die Neuskalierung, und niemand jagt hartkodierten 64ern hinterher. Halte die Aliase wenige und wirklich strukturell (Abschnitte, Karten, Formular-Rhythmus); ein Alias pro Komponente führt genau den Wildwuchs wieder ein, den die Skala beseitigen sollte.
Wie kommen die Tokens vom Design in den Code?
Über ein werkzeug-neutrales Dateiformat. Die Design Tokens Community Group definiert ein JSON-Format — DTCG — für design tokens, sodass eine Datei viele Tools versorgen kann. Eine Abstände-Skala, exportiert im DTCG-Format, sieht so aus:
{
"space": {
"1": { "$value": "8px", "$type": "dimension" },
"2": { "$value": "11px", "$type": "dimension" },
"3": { "$value": "16px", "$type": "dimension" },
"4": { "$value": "23px", "$type": "dimension" },
"5": { "$value": "32px", "$type": "dimension" },
"6": { "$value": "45px", "$type": "dimension" },
"7": { "$value": "64px", "$type": "dimension" }
}
}Die Werte sind nicht willkürlich — sie bilden eine echte Skala (Basis 16, Verhältnis 2, zwei Noten pro Intervall), und genau das ist der Punkt: Die Token-Datei wird aus drei Zahlen generiert, nicht von Hand zusammengesetzt.
Aus dieser einzigen Quelle werden dieselben Stufen als CSS Custom Properties, als Tailwind-v4-Theme-Block und als Figma Variables gerendert. Öffne die Export-Ansicht in Scale Composer — dieselbe Skala, gerendert als DTCG-Tokens, CSS Custom Properties, Tailwind v4 und Figma Variables. Ändere einen Skalen-Parameter, und jeder Export übernimmt es, weil alle vier aus denselben Stufen gelesen werden.
Warum ist es ein Token-Problem, Figma und Code synchron zu halten?
Weil die Abweichung strukturell ist, nicht moralisch. Wenn Designer eine Abstände-Liste in Figma pflegen und Entwickler eine andere in CSS, driften die beiden irgendwann auseinander — jemand fügt auf einer Seite eine Stufe hinzu, rundet auf der anderen einen Wert, und sechs Monate später beschreiben die Designdatei und das Produkt klammheimlich unterschiedliche Systeme. Alle zu bitten, sorgfältiger zu sein, behandelt ein Quellenproblem als Disziplinproblem. Mit einer generierten Quelle, die beide Seiten versorgt — Figma Variables für die Designdatei, Custom Properties oder ein Theme für den Code — bekommen die Listen gar nicht erst die Chance auseinanderzulaufen, weil keine Seite eine Liste pflegt. Beide lesen dieselbe.
Exportiere dieselbe Skala in deinen Stack
Probiere das Code-Ende des Wegs aus:
Exportiere diese Skala als Tailwind-v4-Theme — die Stufen kommen
als @theme-Block an, bereit zum Einfügen in ein Stylesheet. Füge dann der
Skala eine Note hinzu und exportiere erneut: Die Zwischenstufen erscheinen im
Block, benannt und geordnet, ohne einen einzigen von Hand gewählten Wert.