/* DataHex overrides for OpenMetadata's SPA. * * WHY THIS FILE EXISTS (see docs/plan/om-ui-customisation-framework.md §3): * Styling and layout changes belong at TIER 2 — a build-time transform — not at tier 4, patching * components. This stylesheet is appended last, so it wins over antd and OM's Less without touching * a single upstream file. Every rule here costs nothing at OM-upgrade time; the same change made by * patching a component would have to be rebased on every release. * * RULES OF THE ROAD * - Prefer overriding CSS custom properties over hard-coding values, so one change propagates. * - Target OM/antd class names, which are stable across patch releases; avoid generated hashes. * - If a change cannot be expressed here, THEN consider a patch — and say why in the patch. * * Tokens mirror frontend/src/catalog/tokens.css so the two apps stay recognisably one product. */ /* ---- Tokens: ONE block, and the primary is not ours to define ---- * * The single source of truth for the brand colour is OM's own theme config * (`customUiThemePreference.customTheme.primaryColor`) — written by scripts/brand-om-ui.sh and * editable by an admin at /settings/preferences/appearance. OM runs antd 4 in CSS-VARIABLE mode * (styles/antd-master.less imports antd/dist/antd.variable.less), so ConfigProvider publishes that * colour to :root as --ant-primary-color at runtime. Consuming it means the appearance page * re-themes this stylesheet too, instead of the two drifting apart. * * The fallback is deliberately the same navy brand-om-ui.sh writes: if the variable is ever absent, * every rule below behaves exactly as it did when the value was hard-coded. * * TINT and HOVER are DERIVED, not read from OM's `hoverColor`/`selectedColor` fields. Those are * free-form colour pickers, and each background here is paired with a fixed ink (navy on tint, * white on dark). A dark `hoverColor` would put navy ink on a dark row — unreadable. Deriving keeps * the tint near-white and the dark-hover near-primary for ANY primary, so no admin setting can * produce an unreadable state. */ :root { --dh-primary: var(--ant-primary-color, #002147); /* deep institutional navy by default */ --dh-primary-fg: #fafafa; --dh-border: #e5e5e5; --dh-primary-tint: color-mix(in srgb, var(--dh-primary) 10%, #fff); /* light row: navy ink */ --dh-primary-hover: color-mix(in srgb, var(--dh-primary) 88%, #fff); /* dark row: white ink */ } /* ---- Correct antd's palette ramp for a DARK primary ---- * * ROOT CAUSE of every stray blue in this app. OM derives an 11-step palette from primaryColor * (styles/colorPallet.ts) with fixed HSL deltas that ADD lightness at the low indices — palette[2] * is `l + 0.4`. Those deltas assume a mid-lightness primary like OM's default #1570ef (l≈0.51). * Our navy is l≈0.14, so the ramp INVERTS: slots antd uses for pale tints come out as bright blues. * Measured in the browser for #002147 — --ant-primary-1 = #149aff, -2 = #0094f4, -25 = #38a5ff. * These were never antd's #1890ff defaults; they are OM's own generator misfiring on a dark colour. * * Only `hoverColor` (slot 1) and `selectedColor` (slot 7) have a config surface — tested, and it * fixes 2 of the 8 wrong slots. The rest can only be corrected here, so the whole ramp is corrected * here for coherence, keeping primaryColor as the single configured value. * * `!important` on a custom property in a stylesheet BEATS the non-important inline value that * AntDConfigProvider writes with documentElement.style.setProperty. Verified in the browser. * * antd's semantics: 1..9 run light -> dark with 6 as the base. Deriving each step from the primary * means an admin changing primaryColor re-themes the entire ramp correctly, at any lightness. */ :root { --ant-primary-25: color-mix(in srgb, var(--dh-primary) 4%, #fff) !important; --ant-primary-50: color-mix(in srgb, var(--dh-primary) 7%, #fff) !important; --ant-primary-1: var(--dh-primary-tint) !important; /* 10% — subtle hover backgrounds */ --ant-primary-2: color-mix(in srgb, var(--dh-primary) 18%, #fff) !important; --ant-primary-3: color-mix(in srgb, var(--dh-primary) 30%, #fff) !important; --ant-primary-4: color-mix(in srgb, var(--dh-primary) 45%, #fff) !important; /* submenu border */ --ant-primary-5: color-mix(in srgb, var(--dh-primary) 70%, #fff) !important; --ant-primary-6: var(--dh-primary) !important; /* the base step */ --ant-primary-7: var(--dh-primary) !important; /* active/pressed */ --ant-primary-8: color-mix(in srgb, var(--dh-primary) 85%, #000) !important; --ant-primary-9: color-mix(in srgb, var(--dh-primary) 70%, #000) !important; --ant-primary-color-hover: var(--dh-primary-hover) !important; --ant-primary-color-active: var(--dh-primary) !important; } /* Top bar: OM's is white and undifferentiated from the page. DataHex leads with the navy band, which is the single most recognisable brand cue and the cheapest one to apply. */ .app-bar-container, [data-testid='app-bar'] { background: var(--dh-primary) !important; border-bottom: 1px solid var(--dh-primary) !important; } /* Anything sitting on the navy band needs inverted ink, or it disappears. */ .app-bar-container .ant-typography, .app-bar-container a, .app-bar-container button, [data-testid='app-bar'] .ant-typography, [data-testid='app-bar'] a, [data-testid='app-bar'] button { color: var(--dh-primary-fg) !important; } /* Brand lockup: OM's slot is ~40px tall and clamps the logo with `h-full`. Give it a little more room so the wordmark lands at v1's scale (.dh-brand__wm is 18px in the DataHex app). */ img[src*="datahex-logo"] { height: 40px !important; max-height: none !important; width: auto !important; } /* SIX co-brand logo — the other half of the brand toggle (OM logo switched to /six-logo.svg via brand-om-ui.sh's LOGO). The SIX wordmark is wide and short (368x102), so it sits a touch under the 40px slot to read balanced against the nav height. */ img[src*="six-logo"] { height: 30px !important; max-height: none !important; width: auto !important; } /* ---- The one rule the corrected ramp cannot express: hover feedback on DARK rows ---- * * Everything else that used to live here (≈110 lines of per-state menu selectors) was whack-a-mole * against the broken ramp above, and was deleted once the ramp was fixed at the source. This is the * genuine remainder: antd expresses hover as a LIGHT TINT (--ant-primary-1), which is invisible on a * navy row, so a selected item or an open submenu title gets no feedback at all. Verified in the * browser — hovering the selected item left the background at exactly rgb(0, 33, 71). * * Dark rows therefore LIGHTEN instead of tinting: same hue, raised lightness, which reads as a * press/hover on navy. Derived from the primary, so it holds for any configured brand colour. */ .ant-menu-item-selected:hover, .ant-menu-submenu-open > .ant-menu-submenu-title:hover, .ant-menu-submenu-selected > .ant-menu-submenu-title:hover { background: var(--dh-primary-hover) !important; transition: background 120ms ease; } /* Keep the ink white through that hover — antd's hover rule otherwise recolours the label to the primary, which on a navy row is navy-on-navy. */ .ant-menu-item-selected:hover, .ant-menu-item-selected:hover *, .ant-menu-submenu-open > .ant-menu-submenu-title:hover, .ant-menu-submenu-open > .ant-menu-submenu-title:hover * { color: var(--dh-primary-fg) !important; } /* ============================================================================ * RESPONSIVE GATE for everything below — read this before editing the top nav * ---------------------------------------------------------------------------- * The whole top-nav transformation is scoped to a MIN-WIDTH. Below the breakpoint not one rule * applies and OM's native left sidebar returns, unmodified and fully functional. * * Why a hard fallback rather than a squeezed top bar: the bar's content does not compress. Measured * at equal-width tabs — brand 204px + 7 tabs x 166px (1162px) + Settings/Logout 184px + the identity * cluster ~340px + gaps = ~1950px. There is no honest way to fit that in 1100px; every alternative * (truncating labels, hiding items, wrapping to two rows) trades a working nav for a broken-looking * one. A vertical rail is the correct shape for a narrow viewport, and OM already ships one. * * So: 1280px+ -> top nav. Below -> OM's sidebar. Nothing to maintain for the small case. * ========================================================================== */ @media (min-width: 1280px) { /* ============================================================================ * TOP NAV — move OM's left sidebar into a horizontal bar, matching app.localhost * ---------------------------------------------------------------------------- * TIER 2, no patch. OM renders the nav as an antd inside an *