FluentUI: Design-Tokens

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

Status: Stufe 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.

Wo die Größe steht. Das Maß eines gemeinsamen Bedienelements gehört in den Vertrag, nicht in eine von mehreren möglichen Vorlagen. Eine Vorlagenregel wie .dokuwiki input[type="checkbox"] (Gewicht 0-2-1) schlüge jede Klassenregel des Bausatzes (0-2-0); die Vorlage liest deshalb die Marke, statt einen eigenen Wert zu setzen.

Der Umschalter folgt nicht. Er ist 34×18px und per Selektor ausgenommen, nicht per Quellreihenfolge. Keine eigene Marke für die Trefferfläche: --wk-touch-min tut das bereits.

Warum es bei zwei Bewegungsmarken bleibt. In beiden Referenzen haben Listenzeile, Knopf und Kontrollkästchen keinen Übergang; insgesamt stehen dort 27 Übergänge in 154 Stylesheets und keine Keyframes. Bewegt wird dort, was sich bewegt – Einblendung, Schalter, Aufklappen. Ein Zustand (Zeiger, Auswahl, Fokus, Druck) wechselt seine Farbe sofort. Das ist keine Lücke, sondern die Regel: wer den Zeiger über dreißig Zeilen zieht, will dreißig sofortige Antworten und nicht dreißig nachlaufende Blenden.

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 nicht als eigene wkfluentui-Tokens ausgeliefert, da kein Verbraucher sie braucht.

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) ist gegen den ADS-Quellcode belegt; die Kommentarblöcke direkt an den Token-Definitionen nennen je Wert die Quelle. –wk-admin-radius 2px entspricht ADS (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 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 zugunsten der Lesbarkeit eine Stufe über der ADS-Basis 11/13/15.

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:

Beispiel: die Anmeldekarte setzt --wk-radius-md: 0 – sie will eckige Ecken –; ein in :root abgeleitetes --wk-radius antwortet innerhalb dieser Fläche trotzdem 5px.

Für jede Ableitung in :root, deren Basis eine Fläche weiter unten umbelegt, ist deshalb genau eine von zwei Antworten zulässig; ein Prüflauf des Repositories hält das nach:

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.

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.

Neben den Marken für das Chrom des Rasters (Bandfarben, Kopffarben, Bandhöhe, Zeilenhöhe) führt die Gruppe Grid vier Zustände – eigene Marken, damit der Zeilen-Hover eines Rasters geändert werden kann, ohne den Hover jeder Verwaltungsfläche mitzuändern.

Jede der vier löst auf die Marke in der Spalte „Wert“ auf; das gewählte Farbschema bleibt unangetastet.

Warum vier und nicht sieben. Das Vorbild führt sieben Rasterzustände. Drei davon – ausgewählt-und-überfahren, Aktion-Hover und Verweis-Hover in der Zelle – zeichnet dieser Bausatz nicht. Sie entstehen mit den Regeln, die sie brauchen; eine Marke, die niemand liest, ist teurer als keine.

Warum --wk-admin-row-selected-bg bleibt. Die ältere Marke löst in jedem Schema auf denselben Wert auf wie --wk-highlight, ist also eine Zwischenstufe ohne eigenen Wert. Sie hat aber vier Leseseiten in wkbizway und wkblog. Die neue Marke leitet sich aus ihr ab, statt ihren Wert zu wiederholen: setzt eine Vorlage die ältere, folgt das Raster.

Die Palette wird als Ganzes gerechnet: 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 Stilblatt kann nicht fehlschlagen: ein fast lesbarer Wert sieht aus wie eine Gestaltungsentscheidung.

--wk-border bemalt die Zierlinie zwischen zwei Tabellenzeilen; die Kante eines Eingabefeldes hat einen eigenen Token. Für die Zierlinie sind 1,71:1 richtig – eine Trennlinie, die 3:1 erreicht, ist ein Balken. Für die Feldkante wäre derselbe Wert ein Verstoß gegen 1.4.11, denn die Kante ist das Einzige, was das Feld als Feld erkennbar macht.

Ebenso die Zustände: die Familie --wk-warning hat drei Tokens – Signal (Symbol, Kante, Füllung), Schrift, und die Tinte auf dem Signal. Als Signal ist ein Gold richtig; als Schrift erreicht dasselbe Gold nur 2,39:1, und Weiß auf der goldenen Zählmarke 2,10:1.

Das dunkle Schema belegt neben Flächen, Schrift, Schale und Seitenleiste auch die Akzent- und die Zustandsfamilie neu; sonst zeigte ein dunkler Bildschirm den hellen Erfolgskasten.

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.

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.

Ohne Wiederholung bleibt etwa --wk-btn-primary-text weiß, während --wk-text-on-accent daneben nahezu schwarz ist – die Hauptschaltfläche verliert ihre Beschriftung bei 3,20:1.

Deshalb 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), zusätzlich über die Hautachse gekreuzt mit dem Schema, und prüft daneben Achsenliste, Beschriftungen in fünf Sprachen und die Nullprozent-Regel.

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.

Eine Haut belegt je 26 Werte neu und erbt alle übrigen; ob die geerbten zu den neu belegten passen, rechnet der Prüflauf deshalb über die Kombination Haut × Schema × Akzent.

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. Belegten Haut- und Schemablöcke dieselben Neutralen, überschriebe der hintere Block den vorderen – skin="wxi" zusammen mit scheme="dark" zeigte dann weißes Papier.

Eine Haut nennt 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, und damit entscheidet die Reihenfolge nicht zwischen ihnen – 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 – ein Zwei-Punkt-Mix verfehlt --wk-border um neun Werte je Kanal, und mehrere Stufen tragen eine 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.

Bekannte Einschränkung: sieben Paarungen der Hautachse bleiben unter dem Maß – WXIs eigene gedämpfte Graustufen (2,85:1 hell, 2,99:1 dunkel), unverändert aus WXI übernommen.

Die früheren Hautnamen wxi-darkness und wxi-clearness gibt es nicht mehr. wxi-darkness war eine Helligkeitswelt mit Hautnamen – erkennbar daran, dass sie ihr color-scheme selbst tragen musste, was eine Welt sagt und ein Charakter nicht; sie entspricht skin="wxi" scheme="dark". wxi-clearness war WXIs helle Lesart mit einem anderen Blau; seit der Akzent eine eigene Achse ist, unterscheidet sie nichts mehr von wxi.

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.