# UI Theme Component — Design **Date:** 2026-06-01 **Status:** Approved (brainstorming) → ready for writing-plans **Goal:** Normalize UI theming across the three sister apps and realize it as a single shared .NET 10 Razor Class Library, `ZB.MOM.WW.Theme` — mirroring the auth component's "path to shared code" treatment. --- ## 1. Motivation (code-verified, 2026-06-01) All three sister apps have Blazor SSR + Bootstrap 5 UIs (four surfaces total): | App | UI surface(s) | Nav layout today | |---|---|---| | OtOpcUa | `ZB.MOM.WW.OtOpcUa.AdminUI` | **side rail** (`NavSidebar.razor`) | | MxAccessGateway | `ZB.MOM.WW.MxGateway.Server` Dashboard | **top nav bar** | | ScadaBridge | `ZB.MOM.WW.ScadaBridge.Host` + `.CentralUI` (RCL) | own `MainLayout` + `NavMenu` | Each ships a hand-copied **`theme.css`** — the "Technical-Light" design system (379 lines: IBM Plex `@font-face`, design tokens `:root { --paper, --card, --ink, --ink-soft, --rule, --accent, --ok, --warn, --bad, --idle }`, status palette, typography). **The three copies are byte-for-byte identical except for three lines** — the font `src:` URL prefix (`fonts/` vs `/fonts/` vs `../fonts/`), a per-app deployment path, not a design difference. IBM Plex `.woff2` fonts are vendored separately into each app's `wwwroot/fonts/`. This is the textbook drift situation: a shared design system maintained as three copy-pasted files that have *already* begun to diverge. The split between shared and per-project is unusually clean — see §6. Verified paths: - `OtOpcUa/src/Server/ZB.MOM.WW.OtOpcUa.AdminUI/wwwroot/css/theme.css` (+ `site.css`, `fonts/`) - `MxAccessGateway/src/ZB.MOM.WW.MxGateway.Server/wwwroot/css/theme.css` (+ `site.css`, `fonts/`) - `ScadaBridge/src/ZB.MOM.WW.ScadaBridge.CentralUI/wwwroot/css/theme.css` (+ `site.css`, `fonts/`) ## 2. Decisions (from brainstorming) | Decision | Choice | |---|---| | Depth/goal | **Full shared UI kit** — beyond tokens: extract layout shell + components into the RCL | | Layout model | **One canonical layout** — a single side-rail shell; top-bar / menu apps migrate onto it | | Branding | **Name + accent + logo per app** — uniform chassis, per-app identity via parameters | | Kit contents | Canonical shell + tokens + fonts **and** Status indicators **and** Login card **and** Common form controls | | Packaging | **Single RCL `ZB.MOM.WW.Theme`** (Approach A) — one package, one version | Packaging alternatives considered and rejected: (B) split CSS/fonts vs components — YAGNI, no tokens-only consumer exists, and splitting later is non-breaking; (C) plain content package, no components — contradicts the "full kit" decision. ## 3. Architecture Two deliverables, same shape as the auth component: 1. **`components/ui-theme/`** — the normalization docs (spec / design-tokens / shared-contract / per-project current-state / GAPS). 2. **`ZB.MOM.WW.Theme/`** — the built RCL, living at `scadaproj/ZB.MOM.WW.Theme/` (its own folder in this repo, exactly like `ZB.MOM.WW.Auth/`). **The RCL ships:** - **Static web assets** — the canonical `theme.css` + the IBM Plex `.woff2` files, served at `_content/ZB.MOM.WW.Theme/css/theme.css` and `_content/ZB.MOM.WW.Theme/fonts/…`. This alone kills the copy-paste drift, and fixes the font-path divergence for free: the RCL's static-asset base path makes the `src: url(../fonts/…)` reference canonical and identical for every consumer. - **Razor components** — the canonical side-rail shell + the chosen widgets (§4). **Accent/branding mechanism:** `ThemeLayout` renders its root as `
`, so a per-app accent overrides the `--accent` custom property for that subtree. Product name and logo are parameters. Everything else in Technical-Light stays shared and un-overridable. **Adoption is follow-on, per repo** (like auth's GAPS #8). Building the RCL is self-contained in `scadaproj`; apps referencing it, deleting their `theme.css`/fonts/`MainLayout`/login card, and migrating top-bar → rail (MxGateway) is tracked in `GAPS.md`, not done in this repo. ## 4. Component contract (RCL public API) Namespace `ZB.MOM.WW.Theme`. Components are themed purely via CSS custom properties — no hardcoded colors in markup. **Static-asset entry point** - `` — dropped in `` (App.razor); emits the `` to `_content/ZB.MOM.WW.Theme/css/theme.css`. One line replaces each app's hand-rolled wiring. **Layout shell (canonical chassis)** - `ThemeLayout : LayoutComponentBase` — the one side-rail shell. Params: `string Product`, `string? Accent` (overrides `--accent`), `RenderFragment? Logo`, `RenderFragment Nav` (rail nav items), `RenderFragment? RailFooter` (e.g. user/sign-out), `RenderFragment ChildContent` (page body). Renders `BrandBar` in the rail header + the `Nav` slot + a `
` body region. - `BrandBar` — logo + product name; standalone, used internally by `ThemeLayout`. - `NavRailItem` — one rail link: `string Href`, `string Text`, `RenderFragment? Icon`, `NavLinkMatch Match`. Active state via Blazor `NavLink`. Apps fill the `Nav` slot with these. **Status (highest-value shared widget)** - `StatusPill` — `StatusState State` (`Ok | Warn | Bad | Idle | Info`) + `ChildContent` label. Maps state → the `--ok / --warn / --bad / --idle` tokens. `enum StatusState` public. **Auth surface** - `LoginCard` — centered branded card: `string Product`, `RenderFragment? Logo`, `EventCallback OnSubmit`, `string? Error`, `bool Busy`. UI-only — raises `OnSubmit`; **no auth logic** (the app wires it to `ZB.MOM.WW.Auth`). `readonly record struct LoginSubmit(string Username, string Password)`. **Common controls (thin themed wrappers over Bootstrap 5)** - `TechButton` — `ButtonVariant Variant` (`Primary | Secondary | Danger | Ghost`), `bool Busy`, `ChildContent`; passes through `type`/`onclick`. - `TechCard` — `string? Title`, `RenderFragment? Header`, `ChildContent`, `RenderFragment? Footer`. - `TechField` — labeled input wrapper: `string Label`, `string? Hint`, `string? Error`, `ChildContent` (the ``/`