/**
* ncss - Web Awesome Bridge (Layer "webawesome-bridge", höchste Priorität - siehe
* ncss.css für die Layer-Order, die das seitenweit garantiert, unabhängig von -
* Reihenfolge im HTML).
*
* Zweck: Web Awesome NICHT mit eigenen, parallelen Farb-/Abstands-/Typografie-Werten
* laufen lassen - stattdessen werden Web Awesomes eigene CSS Custom Properties hier auf
* unsere ncss-Tokens gemappt. ncss-Tokens (tokens.css/colors.css) bleiben die EINZIGE
* Quelle der Wahrheit; diese Datei ist reine Übersetzung, keine zweite Werteliste.
*
* Web Awesomes Komponenten (Button, Badge, Input, Tooltip, Dialog, ...) beziehen ihre
* Farben/Radien/Schriften fast ausschließlich aus genau diesen globalen "semantischen"
* Tokens (--wa-color-{familie}-{fill|border|on}-{quiet|normal|loud}, --wa-font-*,
* --wa-space-*, --wa-border-radius-*) - siehe vendor/webawesome/dist-cdn/styles/themes/
* default.css. Kein Component-CSS selbst anfassen, kein ::part()-Gefrickel nötig, um den
* Look zu übernehmen - EIN Bridge-Layer auf :root reicht für die große Mehrheit der Fälle.
*
* Web Awesomes eigenes Theme schaltet Light/Dark über Klassen (.wa-light/.wa-dark) um -
* ncss dagegen über light-dark() + color-scheme (siehe colors.css). Statt beide Mechanismen
* synchron zu halten (fragil, zwei Zustände die auseinanderlaufen können), übersteuern wir
* hier direkt auf die FERTIGEN, bereits theme-fähigen ncss-Tokens - die WA-Klassen werden
* dadurch für die gemappten Werte irrelevant, ncss' color-scheme entscheidet.
*
* "quiet/normal/loud" ~ unsere 100/300/500(-900)-Farbskala: quiet = dezente Fläche
* (Badge-/Callout-Hintergrund), normal = etwas kräftiger (Rahmen/Hover/gefüllte Buttons je
* nach Komponente - Web Awesome nutzt "normal" z.B. für ),
* loud = die volle Markenfarbe. "on-*" ist die dazu passende Textfarbe.
*
* WICHTIG (per echtem Dark-Mode-Screenshot als Bug gefunden, dann behoben): on-quiet/
* on-normal NICHT auf einen einzelnen fixen Wert wie X-700 mappen. X-100/-300 sind seit
* colors.css' Fix selbst light-dark()-gewrappt (dezent im Light Mode Richtung weiß, im
* Dark Mode Richtung schwarz gemischt) - ein Text, der im Light Mode auf der hellen
* X-100/300-Fläche funktioniert (dunkel, z.B. X-700), wäre im Dark Mode auf der jetzt
* DUNKLEN X-100/300-Fläche selbst wieder unlesbar. Beide brauchen daher das ebenfalls in
* colors.css zentral definierte --ncss-color-X-on-soft (selbst light-dark(X-700, X) -
* im Dark Mode reicht die Basisfarbe X als Text, die dort ohnehin schon hell/leuchtend
* ist). Gilt genauso für den Fall OHNE Füllung (appearance="outlined"/"plain", Text sitzt
* direkt auf Seite/Card statt auf einem Chip) - dieselbe Logik passt zufällig auch dort,
* weil beide Fälle "dunkler Text im Light Mode, heller Text im Dark Mode" wollen. Derselbe
* -on-soft-Token wird auch von components/badge.css und demo/landing.css verwendet -
* eine Definition statt der Formel an mehreren Stellen dupliziert.
*/
:root, :host {
/* --- Oberflächen/Text/Rahmen ------------------------------------------------------ */
--wa-color-surface-default: var(--ncss-color-bg);
--wa-color-surface-raised: var(--ncss-color-surface);
--wa-color-surface-lowered: var(--ncss-color-bg-subtle);
--wa-color-surface-border: var(--ncss-color-border);
--wa-color-text-normal: var(--ncss-color-text);
--wa-color-text-quiet: var(--ncss-color-text-muted);
--wa-color-text-link: var(--ncss-color-brand);
--wa-color-focus: var(--ncss-color-focus-ring);
--wa-focus-ring: solid var(--ncss-focus-ring-width) var(--ncss-color-focus-ring);
/* Gleiches Token wie .ncss-modal::backdrop (components/modal.css, colors.css) - Web
Awesomes eigene Dialog-/Drawer-Overlays sollen optisch nicht von unseren nativen