Web Awesome Bridge

webawesome-bridge.css maps Web Awesome's --wa-color-{family}-{fill|border|on}-{quiet|normal|loud} variables onto the same ncss color tokens, so that e.g. <wa-button> and .ncss-btn visually match - instead of maintaining two separate palettes. Web Awesome (Free) and Font Awesome (Free) are self-hosted under vendor/.

Prerequisites

Load via a real HTTP server - Web Awesome is ES-module-based, doesn't work over file://.
data-webawesome="<path>" on the loader <script>, otherwise the base path doubles up for relative 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">Matches .ncss-btn--primary visually</wa-button>

dist/integrations/webawesome-bridge.css is fully opt-in - ncss.css does NOT import it automatically, so a project without Web Awesome ships none of it. The "webawesome-bridge" layer is already registered at the right priority position regardless (see Architecture), independent of your own <link> order.

Form Text on Colored Surfaces

A <wa-input>/<wa-textarea>/<wa-select>/<wa-checkbox>/<wa-radio>/<wa-switch> renders its label/value/hint text in its own shadow DOM - a text color on a light-DOM ancestor doesn't reach it. Web Awesome's own --wa-form-control-label-color/-value-color/-hint-color are themselves var(--wa-color-text-normal) - but custom properties resolve var() references inside their own value at the site of their own declaration (here: once, on :root), not again at every point of use. The actual fix declares these tokens directly on .ncss-surface--brand/-brand-2/-neutral, .ncss-gradient-brand, .ncss-text-light, .ncss-text-dark as currentColor.

Opt-in Fallback Scripts

Each script checks itself whether the native CSS technique already applies, and does nothing if so - no doubled-up mechanism.

File	What for
`js/wa-close-on-scroll.js`	Closes any open `<wa-dropdown>`/`<wa-popover>` panel on scroll - if the anchor sits in a `position:sticky` header bar, repositioning can otherwise glitch visibly (among others a known iOS Safari bug)
`js/hide-on-scroll-fallback.js`	`.ncss-hide-on-scroll` (Scroll & Visibility) is CSS-only and active only in Chromium (`container-type: scroll-state`). Checks via `CSS.supports` whether the native technique applies, otherwise a `requestAnimationFrame`-throttled scroll listener
`js/scroll-stack-fallback.js`	Brings the real pinned scroll-stack experience (Component Reference, `.ncss-stack-section`) to Firefox/older Safari too, instead of just the guaranteed-working but unanimated `@supports not()` fallback. Checks via `CSS.supports("view-timeline-name", ...)`, respects `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>