Web Awesome Bridge

webawesome-bridge.css mappt Web Awesomes --wa-color-{familie}-{fill|border|on}-{quiet|normal|loud}-Variablen auf dieselben ncss-Farbtokens, damit z.B. <wa-button> und .ncss-btn optisch zusammenpassen - statt zwei getrennte Paletten zu pflegen. Web Awesome (Free) und Font Awesome (Free) sind selbst gehostet unter vendor/.

Voraussetzungen

Laden über einen echten HTTP-Server - Web Awesome ist ES-Module-basiert, funktioniert nicht über file://.
data-webawesome="<pfad>" auf dem Loader-<script>, sonst verdoppelt sich der Basis-Pfad bei relativem src.

<link rel="stylesheet" href="vendor/webawesome/dist-cdn/styles/themes/default.css">
<link rel="stylesheet" href="dist/ncss.css">
<link rel="stylesheet" href="dist/integrations/webawesome-bridge.css">
<script type="module" src="vendor/webawesome/dist-cdn/webawesome.loader.js"
        data-webawesome="vendor/webawesome/dist-cdn"></script>

<wa-button variant="brand">Passt optisch zu .ncss-btn--primary</wa-button>

dist/integrations/webawesome-bridge.css ist komplett opt-in - ncss.css importiert sie NICHT automatisch, damit ein Projekt ohne Web Awesome keine Zeile davon ausliefert. Der Layer "webawesome-bridge" ist trotzdem schon an der richtigen Prioritätsposition registriert (siehe Architektur), unabhängig von der eigenen <link>-Reihenfolge.

Formular-Text auf farbigen Flächen

Ein <wa-input>/<wa-textarea>/<wa-select>/<wa-checkbox>/<wa-radio>/<wa-switch> rendert Label/Wert/Hinweistext im eigenen Shadow DOM - eine Textfarbe auf einem Light-DOM-Vorfahren erreicht das nicht. Web Awesomes eigene --wa-form-control-label-color/-value-color/-hint-color sind selbst var(--wa-color-text-normal) - aber Custom Properties lösen var()-Referenzen innerhalb ihres eigenen Werts am Ort ihrer eigenen Deklaration auf (hier: einmalig an :root), nicht erneut an jedem Verwendungsort. Der echte Fix deklariert diese Tokens direkt auf .ncss-surface--brand/-brand-2/-neutral, .ncss-gradient-brand, .ncss-text-light, .ncss-text-dark als currentColor.

Opt-in-Fallback-Scripts

Jedes Script prüft selbst, ob die native CSS-Technik bereits greift, und tut dann nichts - kein doppelt arbeitender Mechanismus.

Datei	Wofür
`js/wa-close-on-scroll.js`	Schließt jedes offene `<wa-dropdown>`/`<wa-popover>`-Panel beim Scrollen - sitzt der Anker in einer `position:sticky`-Kopfleiste, kann die Neupositionierung sonst sichtbar glitchen (u.a. ein bekannter iOS-Safari-Bug)
`js/hide-on-scroll-fallback.js`	`.ncss-hide-on-scroll` (Scroll & Sichtbarkeit) ist rein CSS-basiert nur in Chromium aktiv (`container-type: scroll-state`). Prüft per `CSS.supports`, ob die native Technik greift, sonst ein `requestAnimationFrame`-gedrosselter Scroll-Listener
`js/scroll-stack-fallback.js`	Bringt das echte gepinnte Scroll-Stapel-Erlebnis (Komponenten-Referenz, `.ncss-stack-section`) auch nach Firefox/älterem Safari, statt nur des garantiert funktionierenden, aber unanimierten `@supports not()`-Fallbacks. Prüft per `CSS.supports("view-timeline-name", ...)`, respektiert `prefers-reduced-motion`

<script src="js/wa-close-on-scroll.js" defer></script>
<script src="js/hide-on-scroll-fallback.js" defer></script>
<script src="js/scroll-stack-fallback.js" defer></script>