FluentUI: Design-Tokens

Zurück: FluentUI (Design-System-Bibliothek)

Status: Tier 1 — beschreibt tatsächlich umgesetzten Code (lib/plugins/wkfluentui/style.css).

wkfluentui/style.css definiert dieselbe „cross-template Contract“-Sektion wie premium-navy-ivory/css/tokens.css:33-176 (ink/paper/accent/gold/surface/text/link/border/ highlight/sidebar/success/warning/error/admin-accent — dieselben Namen wie lib/tpl/flat/css/color-palette.css). Werte: flats eigene Palette (DokuWikis Stock-Referenz-Template — die neutralste, unabhängigste Wahl für einen generischen Default, keine der WvdS-Marken-Paletten wird bevorzugt). Vollständige Token-Liste: Styles-Contract (--wk-*).

Quelle: src/vs/workbench/browser/media/{style,part}.css (VSCode/ADS gemeinsam, https://github.com/microsoft/vscode) + ADS-spezifische Form-/Dialog-CSS unter src/sql/** (https://github.com/microsoft/azuredatastudio). Alle Werte sind pixel-zitiert, nicht geschätzt.

Nicht übernommene Werte: Part-Content-Text-Override (ADS: 12px, part.css:91), Icon- Größe klein (13px, ADS designer.css:119), Radius Toggle/Hover/Tooltip (3px, toggle.css:13, hover.css:104), Dialog-Breiten (500/800/1200px, ADS modal.css:60-72) — dokumentiert als Referenzwerte in FluentUI: Basic Layout (vertieft) und FluentUI: Basis-Widget-Katalog, aber (noch) nicht als eigene wkfluentui-Tokens ausgeliefert, da kein aktueller Verbraucher.

Anders als die Größen-/Radius-/Spacing-Skala oben sind dies keine neu pixel-gemessenen ADS-Werte, sondern Alias-Tokens: jeder Fallback verweist auf einen bereits bestehenden –wk-*-Token, kein neuer Hex-/Pixel-Wert wird erfunden (Ausnahme: –wk-shell-statusbar-h, pixel-zitiert aus derselben ADS-Quelle wie die Basic-Layout-Tabelle in FluentUI (Design-System-Bibliothek), Region (7)). Erster Konsument: wksqlitedss .wkq-shell-Grid (siehe FluentUI: Basic Layout (vertieft)).

Bewusst nicht ausgeliefert: –wk-shell-titlebar-*/–wk-shell-rail-* — kein aktueller Verbraucher (Titlebar/Activity Bar werden von premium-navy-ivorys Wiki-Shell geerbt, nicht von wksqliteds neu gebaut; siehe „Nicht übernommene Werte“-Konvention oben).

Fünf Token für die Frage „wie groß ist das auf einem Finger„. Sie stehen hier und nicht bei den Shell-Regionen, weil sie zeigergerätabhängig sind: unter @media (pointer: coarse) nehmen zwei von ihnen einen anderen Wert an. Ein Verbraucher schreibt einen Namen und bekommt auf beiden Geräteklassen die richtige Zahl — die Medienabfrage in jedem Aufrufer zu wiederholen ist der Weg, auf dem zwei Umschaltpunkt-Systeme entstehen.

premium-navy-ivorys –wk-admin-fs-*/–wk-admin-radius-Skala (tokens.css) wurde am 2026-07-14 forensisch gegen den ADS-Quellcode nachverifiziert; die Kommentarblöcke direkt an den Token-Definitionen dokumentieren je Wert Quelle und Befund. Ergebnis: keine Wertänderung nötig. –wk-admin-radius 2px ist gegen ADS bestätigt (button.css:11; das heutige VSCode nutzt seit dem Rounded-Refresh 4px — bewusst der ältere ADS-Stand). Die Karten-Rundung 4px und die Schriftskala sind dokumentierte, gewollte Abweichungen: die ADS-Karte (card.css:89, 8px) ist eine Marketing-Kachel und passt nicht in die flache Admin-Optik; die Admin-Schriftgrößen liegen eine Stufe über der ADS-Basis 11/13/15 — Lesbarkeits-Entscheidung des Nutzers vom 2026-07-11, ausdrücklich nicht zurückzunehmen.

lib/exe/css.phps css_out() komponiert: Core-Styles → Plugin-Styles (css_pluginstyles(), bindet wkfluentui/style.css automatisch ein) → Template-Styles (z. B. wkbizway/css/tokens.css, via style.ini-stylesheets-Liste) → User-Styles. Template-Regeln laden nach Plugin-Regeln — bei gleicher Selektor-Spezifität (:root) gewinnt die zuletzt definierte, d. h. ein aktives Template mit eigenen –wk-*-Werten überschreibt wkfluentuis Defaults automatisch; ist kein Template mit eigenen Tokens aktiv, bleiben wkfluentuis Werte als Site-weiter Fallback bestehen.

Ein Teil der Tokens sind keine Werte, sondern Ableitungen: ihr Wert liest über var() ein anderes Token, damit eine Änderung an der Basis alles mitzieht, was daraus folgt. Dabei gilt eine Eigenschaft, die man der Schreibweise nicht ansieht:

Am 4. August 2026 über Bausatz und Hausvorlage gemessen: 13 Ableitungen in :root lesen eine Basis, die eine Fläche unterhalb von :root umbelegt. Zwei davon waren belegt falsch. Beispiel: die Anmeldekarte setzt --wk-radius-md: 0 – sie will eckige Ecken –, und innerhalb dieser Fläche antwortete das abgeleitete --wk-radius weiterhin 5px.

Seither gilt die Regel, und ein Prüflauf des Repositories hält sie nach. Für jede solche Ableitung ist genau eine von zwei Antworten zulässig:

Unzulässig ist die dritte Möglichkeit: unentschieden.

Ein Zustand wird hier als Anteil geführt, nicht als Farbe – und das folgt unmittelbar aus der Regel darüber.

Ein Zustandston als Farbtoken in :root rechnete gegen die Wurzelpalette und folgte keiner Fläche, die die Feldfarben umbelegt – die Anmeldekarte tut genau das. Ein Anteil wird dagegen in der Komponentenregel verrechnet:

background: color-mix(in srgb, var(--wk-field-fg) var(--wk-state-readonly-tint),
                               var(--wk-field-bg));

Dort löst var() am Element auf. Der Zustand folgt damit jeder Fläche, jedem Schema, jeder Haut und jedem Akzent – aus einer Deklaration, statt je Achsenblock wiederholt zu werden.

Zeigen und Drücken kamen am 5. August 2026 – zusammen mit den Regeln, die sie zeichnen, wie es die frühere Fassung dieses Abschnitts angekündigt hatte. Ein Token, das niemand liest, ist dieselbe Bauform wie ein Token, das gelesen und nie definiert wird; deshalb standen sie bis dahin nicht hier.

Der Unterscheider ist, wessen Farbe die Fläche ist.

Ein Bedienelement, das die Fläche des Schemas erbt – ein Eingabefeld, eine sachliche Schaltfläche –, bekommt die Mischung von oben. Sie ist selbstrichtend: im hellen Schema ist die Schrift dunkel und die Fläche wandert nach dunkel, im dunklen Schema umgekehrt. Eine Deklaration deckt damit alle drei Schemata ab.

Ein Bedienelement mit eigener Farbe – Hauptaktion, Gefahr, Erfolg – bekommt stattdessen eine Helligkeitsstufe. Seine eigene Schrift hineinzumischen würde es im hellen Schema heller machen, während sein Hover-Wert es dunkler macht: eine Geste, zwei Richtungen. Eine Helligkeitsstufe kennt ebenfalls keine Farbe, braucht keine Farbfunktion und hält beide Zustände auf einer Achse.

Am 5. August 2026 wurde die Palette erstmals als Ganzes ausgerechnet: jedes Wertepaar aus Schriftfarbe und Fläche, das der Bausatz tatsächlich rendert, gegen die Kontrastanforderung der WCAG 2.2 (Erfolgskriterium 1.4.3, Stufe AA: 4,5:1 für Fließtext; Erfolgskriterium 1.4.11: 3:1 für die Kante, die ein Bedienelement identifizierbar macht).

Ein Tokenname trug zwei Aufgaben. --wk-border bemalte die Zierlinie zwischen zwei Tabellenzeilen und die Kante eines Eingabefeldes. Für die Zierlinie sind 1,71:1 richtig – eine Trennlinie, die 3:1 erreicht, ist ein Balken. Für die Feldkante ist derselbe Wert ein Verstoß gegen 1.4.11, denn die Kante ist das Einzige, was das Feld als Feld erkennbar macht. Ein Wert kann nicht beides richtig sein; die Feldkante hat seither einen eigenen.

Dieselbe Verwechslung bei den Zuständen: --wk-warning war zugleich Signal (Symbol, Kante, Füllung) und Schrift auf dem Warngrund und Schrift auf der Seite. Als Signal ist ein Gold richtig; als Schrift erreichte dasselbe Gold 2,39:1, und Weiß auf der goldenen Zählmarke 2,10:1. Die Familie hat deshalb drei Tokens: Signal, Schrift, und die Tinte auf dem Signal.

Das dunkle Schema war unvollständig. Es belegte Flächen, Schrift, Schale und Seitenleiste neu, aber weder die Akzent- noch die Zustandsfamilie. Ein dunkler Bildschirm zeigte also den hellen Erfolgskasten, und der Verweis stand bei 3,71:1 bzw. 2,22:1 im Zeigen-Zustand.

Heritage ist keine dritte Helligkeit zwischen hell und dunkel. Für den Browser ist es eine helle Welt, und color-scheme: light sagt das auch – sonst zeichnete er die nativen Bedienelemente gegen die falsche Annahme. Ein Schema zu sein verdient es dadurch, dass es Material umbelegt: Flächen und Schrift, sonst nichts.

Rot ist die Konstante der Akzentsprache des Hauses und ausdrücklich keiner der drei: es ist der Alarm, und ein Alarm, der zugleich die Marke ist, hört auf, ein Alarm zu sein. Getrennt werden die Familien über ihre zweite Farbe – und Graphit ist im Satz, weil es als einziges kein Buntton-Nachbar der beiden anderen ist und die drei damit auf einem dichten Datenbildschirm auseinanderzuhalten bleiben.

Vorher standen dort vier Farbnamen (blau, orange, grün, violett) mit je drei handgeschriebenen Werten. Jeder dieser Werte war in genau einem Schema richtig: „blau“ hatte einen Hexwert, und der war entweder ein lesbarer Verweis auf Papier oder auf nahezu Schwarz, nie beides.

Drei Familien mal drei Schemata wären neun von Hand gleichgehaltene Blöcke. Stattdessen nennt jede Familie einen Grundton, und das Schema sagt, wie viel davon bleibt:

--wk-accent: color-mix(in srgb, var(--wk-accent-base) var(--wk-accent-keep, 100%),
                                var(--wk-accent-lift, #FFFFFF));

Der zweite Regler ist der interessantere: „gedrückt„ ist eine Richtung, keine Helligkeit. Auf heller Fläche ist der Druckzustand dunkler, auf dunkler heller – und keine Akzentfamilie muss dafür wissen, dass es ein dunkles Schema gibt.

Die Regel aus dem Abschnitt „Wo eine Ableitung stehen darf“ gilt eine Ebene höher noch einmal. Ein Token, das in :root als var(X) deklariert ist, wird an der Wurzel beantwortet. Sitzt das Schema ebenfalls an der Wurzel – der gewöhnliche Fall, serverseitig gestempelt –, stimmt das. Sitzt es auf einem Container, wie es die Modul-Auszeichnung tut, hat die Wurzel schon geantwortet.

Gemessen an einem Prüfelement: --wk-btn-primary-text blieb weiß, während --wk-text-on-accent daneben nahezu schwarz war – die Hauptschaltfläche verlor ihre Beschriftung bei 3,20:1. Gefunden hat das der Browser, nicht der Prüflauf.

Seither gilt: ein Achsenblock, der eine Basis umbelegt, wiederholt die kontrastrelevanten Ableitungen daraus. Der Prüflauf hält das nach – beschränkt auf die Paarungen, weil dieselbe Regel auf alle Ableitungen angewandt rund 200 wiederholte Deklarationen verlangte und damit genau die Doppelung zurückkaufte, gegen die die Palette gebaut ist. Die übrigen 71 werden gezählt und gemeldet, nicht gefordert.

Der Kontrast-Prüflauf rechnet 34 Paarungen in 12 Kombinationen (drei Schemata mal vier Akzente einschließlich der Vorgabe), seit dem 9. August zusätzlich über die Hautachse gekreuzt mit dem Schema, und prüft daneben Achsenliste, Beschriftungen in fünf Sprachen und die Nullprozent-Regel: 514 Prüfungen.

Er ist eine Ratsche in beide Richtungen. Ein Wert, der schlechter wird, schlägt fehl – und eine Paarung, die sich nicht mehr auflösen lässt, ebenso: ein Tor, das nur in eine Richtung misst, hört unbemerkt auf zu messen, und dafür hat dieses Projekt schon dreimal bezahlt.

Bis zum 5. August 2026 kannte der Prüflauf zwei Achsen. Die Häute waren damit ungemessen – sie belegten je 26 Werte neu und erbten alle übrigen, und ob die geerbten zu den neu belegten passen, hatte nie jemand ausgerechnet.

Die erste Messung fand 72 Einzelverstöße in 19 Paarungen, und beim Nachsehen, woher sie kommen, lag die Ursache eine Ebene tiefer als der Kontrast.

Alle vier Achsen sind als :root[data-wk-<achse>="<wert>"] geschrieben und wiegen damit gleich. Bei gleicher Gewichtung entscheidet allein die Reihenfolge im Bündel – und dort standen die Hautblöcke nach den Schemablöcken, bei denselben neun Neutralen.

Gemessen am 9. August 2026: 105 Belegungen, bei denen eine Haut das Schema überschrieb, 25 der 26 Hauttokens allein gegen das Dunkelschema. Die Folge war nicht subtil – skin="wxi" zusammen mit scheme="dark" rendert weißes Papier.

Eine Haut nennt seither ihre Neutralen je Helligkeitswelt (--wk-n-<welt>-<rolle>), ein Schema liest eine Welt und belegt daraus die semantischen Tokens. Die beiden Mengen überschneiden sich nicht mehr, und damit hört die Reihenfolge auf, zwischen ihnen zu entscheiden – die einzige Form von Orthogonalität, die es übersteht, dass jemand einen Block verschiebt.

Der Akzent bleibt die gewollte Ausnahme: er soll Haut und Schema überstimmen, steht deshalb zuletzt, und ein Tor sichert zu, dass er dort bleibt.

Warum nicht wie beim Akzent aus einem Grundton abgeleitet: ein Farbton ist wirklich eine Sache unter verschiedenem Licht, Neutrale sind das nicht. Die neun hellen Stufen dieses Hauses sind keine gerade Mischung zwischen ihren eigenen Enden – vor der ersten Zeile durchgerechnet, verfehlt ein Zwei-Punkt-Mix --wk-border um neun Werte je Kanal, und mehrere Stufen tragen eine erkämpfte Kontrastkorrektur, die dabei verloren ginge.

Eine Haut nennt nur die Welten, die sie hat. wxi hat eine helle und eine dunkle Lesart und keine Heritage-Lesart, fällt unter scheme="heritage" also auf die Hausrampe zurück. Das ist die vorgesehene Antwort, keine Lücke.

Der Rückgang ist dabei untertrieben: der Sweep misst seither die dreifache Zahl an Kombinationen. Und es wurde nichts umgefärbt – die verbliebenen sieben Paarungen sind WXIs eigene gedämpfte Graustufen (2,85:1 hell, 2,99:1 dunkel), unverändert übernommen, damit der offene Befund weiter beschreibt, was im Baum steht.

wxi-darkness und wxi-clearness sind dabei als Hautnamen entfallen. Die erste war eine Helligkeitswelt mit Hautnamen – erkennbar daran, dass sie ihr color-scheme selbst tragen musste, was eine Welt sagt und ein Charakter nicht; sie ist jetzt skin="wxi" scheme="dark". Die zweite war WXIs helle Lesart mit einem anderen Blau, und nach dem Umzug des Akzents auf eine eigene Achse blieb nichts übrig, was sie von wxi unterschieden hätte.

Festgenagelt wird die Menge, nicht die Zahl. Eine Obergrenze auf die Anzahl ließe eine Verschiebung durch: ein Verstoß behoben, ein neuer entstanden, Summe unverändert, Meldung „unverändert“ für ein Stilblatt, das sich bewegt hat. Verglichen wird deshalb die Liste der betroffenen Paarungen, und der Prüflauf nennt, was dazugekommen und was verschwunden ist.

Was er ausdrücklich nicht misst, ist die gerenderte Seite: eine berechnete Farbe kann aus einer Regel kommen, die er nie sieht. Der Prüflauf belegt, dass die Palette stimmt; der Browsercheck belegt, dass die Regeln sie ausgeben.

Verifiziert gegen: wkfluentui@462fab6 (2026-08-09), wk-dw-msqlite-plugin@240c064