/* =========================================================================== Metronic token bridge =========================================================================== Metronic's lvx-* components paint from ITS semantic tokens (--primary, --background, --input, --ring, ...), not from ours. Before this file, no lvxd stylesheet referenced a single Metronic token - verified by grep, zero hits across all 13 files - so the moment a control becomes .lvx-btn-primary it renders Metronic's blue-500, not the Hub cyan. That would silently undo two decisions this codebase made on purpose and documented at length: - lvxd-onboarding.css:40-53. Light mode used to be Metronic's #1b84ff by inheritance, never by choice. The Hub's primary is the mark's cyan stop, carried at 4.64:1 on white. - lvxd-onboarding.css:82-85. Metronic's #f8285a was rejected as the danger colour: it measured 3.83:1 on white and failed AA for the 12.5px field error text that used it. So this file is the one place the two systems meet. Everything below maps a Metronic token onto the lvxd token that already owns that role. Adding a Metronic component from here on needs no new bridging - it inherits. LOAD ORDER: after assets/css/styles.css (which defines the Metronic defaults being overridden) AND after lvxd-onboarding.css (which defines the --lvxd-* values being read). See _Layout.cshtml. WHY ONE :root BLOCK COVERS LIGHT AND DARK ----------------------------------------- var() inside a custom property is substituted at computed-value time on the element where the property is DECLARED, not where it is used. That would normally mean a :root mapping freezes the light values. It does not here, because .dark is applied to , which IS :root - same element, so --lvxd-surface has already resolved to its dark value before these declarations read it. Dim is the exception; see the bottom of this file. WHAT IS DELIBERATELY NOT MAPPED ------------------------------- --radius. Metronic ships 0.5rem and the Hub's hand-rolled corners were 10-16px. Taking Metronic's density as-shipped was an explicit owner call (2026-08-17), so the smaller radius is the intended outcome, not an oversight. Do not "restore" 12px here - that reverses the decision for every component at once. DENSITY SWITCH - read before changing any control height -------------------------------------------------------- Control size is currently Metronic's own: .lvx-input-lg / .lvx-btn-lg are 40px (calc(var(--spacing) * 10)), against the 46px the hand-rolled .lvxd-workspace-* controls used. Nothing overrides that here, deliberately - an override that restates the value it is overriding is dead code that reads like an intention. If the 40px is judged wrong once it has been seen on screen, change it HERE and nowhere else. Uncommenting the block below moves every converted control in the app at once; editing individual component rules is how the 28 font-sizes and 23 radii this sweep exists to remove got there in the first place. :root { --lvxd-control-h: 46px; } (or 34px for stock density) .lvx-input-lg, .lvx-btn-lg { height: var(--lvxd-control-h); } :root { --radius: 0.75rem; } (only if 12px corners come back with the taller control) Corollary: anything restyled to SIT BESIDE these controls - the combobox (lvxd-combobox.css), the savebar buttons - must read the same source rather than hardcoding 40px, or the switch stops being one line. =========================================================================== */ :root { /* Surfaces. Metronic uses --background for both the page and the fill of inputs/buttons; the Hub paints controls with --lvxd-surface (see .lvxd-workspace-input and .lvxd-workspace-form-card, both `background: var(--lvxd-surface)`), NOT with --lvxd-bg-canvas. Mapping to bg-canvas here would make every input the same colour as the page behind it and erase the field boundary. */ --background: var(--lvxd-surface); --foreground: var(--lvxd-text-body); --card: var(--lvxd-surface); --card-foreground: var(--lvxd-text-body); --popover: var(--lvxd-surface); --popover-foreground: var(--lvxd-text-body); /* Brand. This is the pair that matters most - it is what stops lvx-btn-primary rendering Metronic blue. --lvxd-on-accent rather than plain white because the dark theme's accent is the bright mark stop, where white ink fails; the token already carries that per-theme difference (#fff light, #062a35 dark). */ --primary: var(--lvxd-accent); --primary-foreground: var(--lvxd-on-accent); /* Secondary = the Hub's outline button: surface fill, body ink, visible border. Matches .lvxd-workspace-btn-secondary. */ --secondary: var(--lvxd-surface); --secondary-foreground: var(--lvxd-text-body); --muted: var(--lvxd-surface-muted); --muted-foreground: var(--lvxd-text-muted); /* TRAP: Metronic's --accent is NOT a brand colour. It is the neutral hover wash on menu items, dropdown rows and ghost buttons (zinc-100 in stock Metronic). It only shares a name with --lvxd-accent. Mapping it to the Hub accent turns every hover state teal - which looks like a theming bug, not a brand. It maps to the neutral chip surface instead. */ --accent: var(--lvxd-chip-bg, var(--lvxd-surface-muted)); --accent-foreground: var(--lvxd-text-heading); --destructive: var(--lvxd-danger); --destructive-foreground: var(--lvxd-on-danger); /* Metronic's "mono" is its high-contrast neutral button (near-black fill, white ink; inverted in dark). The Hub has no equivalent component, but the token is consumed by lvx-btn-mono and a few badges, so it is bridged to the heading/surface pair rather than left at Metronic's zinc. */ --mono: var(--lvxd-text-heading); --mono-foreground: var(--lvxd-surface); --border: var(--lvxd-border); /* Metronic's --input is the input BORDER colour, not its fill (.lvx-input { border-color: var(--input) }). The fill comes from --background above. Named confusingly upstream; mapped correctly here. */ --input: var(--lvxd-border); /* Focus ring. Stock Metronic rings in zinc-400, a grey halo; every Hub control already rings in the accent (see .lvxd-workspace-input:focus, `box-shadow: 0 0 0 4px var(--lvxd-accent-soft)`). Keeping the accent ring is what makes converted and unconverted controls focus identically during the sweep. */ --ring: var(--lvxd-accent); } /* --------------------------------------------------------------------------- Dim (phase-11-06) - the one place the single-:root shortcut does not hold. Dim is the LIGHT palette everywhere except the sidebar, which takes Dark's, scoped onto .lvxd-hub-sidebar and reaching its children by custom-property inheritance. Because that override lives on the sidebar ELEMENT rather than on , the :root block above has already computed --background, --primary and the rest from Light's values by the time the cascade reaches it. Re-declaring --lvxd-surface there does not retroactively update them. So the Metronic tokens have to be re-mapped on the same element, mirroring what lvxd-onboarding.css:2671 does for the lvxd tokens. Without this, any lvx-* component placed in the sidebar renders white-on-white in Dim while looking correct in Light and Dark - the exact failure mode that block's comment warns about. The declarations are identical to :root's on purpose. They are not re-stating values, they are re-resolving the same mapping against the sidebar's overridden --lvxd-* values. ------------------------------------------------------------------------- */ .dim .lvxd-hub-sidebar { --background: var(--lvxd-surface); --foreground: var(--lvxd-text-body); --card: var(--lvxd-surface); --card-foreground: var(--lvxd-text-body); --popover: var(--lvxd-surface); --popover-foreground: var(--lvxd-text-body); --primary: var(--lvxd-accent); --primary-foreground: var(--lvxd-on-accent); --secondary: var(--lvxd-surface); --secondary-foreground: var(--lvxd-text-body); --muted: var(--lvxd-surface-muted); --muted-foreground: var(--lvxd-text-muted); --accent: var(--lvxd-surface-muted); --accent-foreground: var(--lvxd-text-heading); --mono: var(--lvxd-text-heading); --mono-foreground: var(--lvxd-surface); --border: var(--lvxd-border); --input: var(--lvxd-border); --ring: var(--lvxd-accent); } /* --------------------------------------------------------------------------- COMPONENT OVERRIDES - where a Metronic variant paints from the raw Tailwind --color-blue-* ramp instead of the semantic --primary this file already bridges. Those variants bypass the token map above, so a token remap can't reach them; they have to be corrected per component. Only the SOFT primary BADGE variants do this (verified 2026-08-31 by grep of styles.css for --color-blue-*): the solid .lvx-badge-primary, every button, .lvx-link and the .lvx-tabs-line active tab all already read var(--primary), so they were correctly cyan and are deliberately left alone. The blue ramp is otherwise only Metronic's own --primary default (overridden above) and the .lvx-avatar-status-away dot (a real "away" semantic - must stay blue), so the ramp itself is NOT remapped. Selectors carry the extra .lvx-badge class purely for specificity: the stock dark rules are `.lvx-badge-outline.lvx-badge-primary:is(.dark *)` (0,3,0), so a two-class override would lose in dark. Three classes tie that and win on source order (this file loads after styles.css). The --lvxd-accent* tokens are already theme-aware, so one rule each covers Light, Dim and Dark - no separate dark block needed. This is the is-active look the theme menu already uses. */ .lvx-badge.lvx-badge-outline.lvx-badge-primary { border-color: color-mix(in srgb, var(--lvxd-accent) 30%, transparent); background-color: var(--lvxd-accent-soft); color: var(--lvxd-accent); } .lvx-badge.lvx-badge-light.lvx-badge-primary { background-color: var(--lvxd-accent-soft); color: var(--lvxd-accent); }