/* M&D On-Brand — THIS FILE IS THE THEME. Everything that makes the app look like Morris & Dickson is here -- colour, font and control geometry, about forty-five values. It loads after the vendored stock Material theme (wwwroot/lib/kendo-theme/kendo-material-14.1.0.css) and overrides its :root defaults; the bridge (wwwroot/css/webportal-theme.css) then maps these onto --wp-* app tokens, and site.css reads only those. Two families: --kendo-* standard Kendo slots. Overriding one cascades automatically to every shade Kendo derives from it, because the derived values are RELATIVE COLOR expressions evaluated at runtime, not baked literals: --kendo-color-primary-hover: oklch(from var(--kendo-color-primary) calc(l + .029) c h) So setting primary here also moves its hover/active/emphasis/subtle shades. --tb-* values Kendo models no slot for: the nav band, grid surfaces, field neutrals, and the control geometry further down. The bridge var()s these; nothing else may. To change a color: change it here, in this file, and nowhere else. The gates that enforced this (eng/Check-ThemeColors.ps1 on a stray literal, eng/Check-ThemeSlots.ps1 on a dropped slot) are temporarily removed on this branch (see WebPortal.csproj) and will be re-added. */ :root { /* ---- Kendo slots --------------------------------------------------------------- primary = ACTION (what you do), tertiary = NAVIGATION (where you are), secondary = accent. Kendo's "primary" IS its action color -- it fills solid buttons and draws focus rings -- which is why the brand green is parked on tertiary, a slot zero components read by default. Do not "correct" that. */ --kendo-color-primary: #00407A; /* M&D action blue, PMS 541 */ --kendo-color-tertiary: #5D797C; /* M&D brand green, PMS 5487 */ --kendo-color-secondary: #BD9B60; /* M&D gold, PMS 7562 */ --kendo-color-base: #FFFFFF; /* page background (white) */ --kendo-color-surface: #FFFFFF; /* cards, fields, popups */ /* Status. Semantic only -- never reuse these as decoration. */ --kendo-color-error: #D32F2F; --kendo-color-success: #2E7D32; --kendo-color-info: #0288D1; --kendo-color-warning: #ED6C02; /* Chart series. Kendo colours a chart's series from these six slots, in order (the first series takes a, the second b, and so on), so every Kendo Chart in the app draws in M&D colours. Stock Material derives all six from one purple; each is stated here instead. The rules for choosing them: - Brand colours only, from the Brand Standards Guide's primary, secondary and accent palettes, except dark gold (see below). - At least 3:1 against the white plot area, because a column or a line is a graphical object a reader needs (WCAG 1.4.11). That rules out the brand gold #BD9B60 (2.62:1) and bright green #64CCC9 (1.91:1); gold is kept as the derived dark gold #8B6914, the portal's gold-text shade (5.09:1). - Cool and warm alternate, so neighbouring series stay apart for the common colour-vision deficiencies too, under which blue, teal and violet all read as blues: no two of those sit side by side. Colour is still never the only cue: the velocity report's tooltip names every series, and its table view gives the exact figures. Only these six are used. Kendo stretches them into thirty by lightening and darkening each one, and some of those shades fall below 3:1, so the velocity charts cycle these six instead (velocity-report.js, brandChartColors). Not status colours: a series colour means "this series", never success or error. */ --kendo-color-series-a: var(--kendo-color-tertiary); /* brand green, PMS 5487 4.68:1 */ --kendo-color-series-b: var(--kendo-color-primary); /* action blue, PMS 541 10.43:1 */ --kendo-color-series-c: #8B6914; /* dark gold (derived) 5.09:1 */ --kendo-color-series-d: #564770; /* violet, PMS 2112 8.30:1 */ --kendo-color-series-e: #9A3324; /* red brick, PMS 484 7.31:1 */ --kendo-color-series-f: #00677F; /* teal, PMS 315 6.47:1 */ /* The brand face. Kendo Material ships Roboto, so this has to be stated. */ --kendo-font-family: Tahoma, Verdana, Geneva, sans-serif; /* ---- App surfaces Kendo has no slot for ---------------------------------------- Navigation: three distinct PANTONEs, NOT a lightness ramp -- measured OKLCH hues are 204 / 183 / 174 with differing chroma, so deriving two from one would visibly distort them. Each is carried as its own value. */ --tb-nav-green: #3E5D58; /* nav band PMS 5477 */ --tb-nav-deep: #014638; /* header band PMS 3308 */ --tb-nav-divider: #2F605A; /* band divider line */ /* Kendo derives --kendo-color-primary-hover as oklch(l + .029) -- far too subtle for the designed #00407A -> #0055A5 step (delta L ~ .082), so the hover is authored. */ --tb-action-hover: #0055A5; /* Grid surfaces. The zebra row is neutral on purpose: status flags have to read against it, and a tinted zebra fights them. */ --tb-grid-header: #DCDCDA; --tb-grid-row-alt: #F1F1EF; --tb-grid-hover: #CCE1E5; /* Field neutrals. These two are CONTRAST FLOORS, not free knobs -- the design spec's #BFBFBF border (1.84:1) and #A6A6A6 hint (2.43:1) both fail WCAG, so the accessible values win. A field border is a control boundary (1.4.11, needs 3:1) separating two surfaces -- the white field interior and the cream page -- and #8A8A8A is the lightest gray clearing 3:1 against BOTH (3.45 / 3.06). Placeholder text is text (1.4.3, needs 4.5:1), and #767676 is the lightest clearing that on white (4.54). Lighten either and the theme stops being accessible. */ --tb-field-border: #8A8A8A; --tb-hint: #767676; /* Cancel/tertiary button fill. NOT Kendo's "base" variant: that resolves to --kendo-color-base, which IS the cream page background above -- so a base-variant Cancel button renders invisible against the page it sits on. */ --tb-neutral: #E1E1E1; --tb-neutral-hover: #C6C6C6; /* ---- Control geometry ---------------------------------------------------------- Kendo models no slot for any of these -- it derives button and field metrics from its spacing ramp, and the designed values are not on that ramp (a 5px gap sits between Kendo's 4px and 6px steps). So they are carried here, as theme values, for the same reason the nav greens are: the theme owns the decision. Each is used by exactly one rule, and that is fine -- there is one rule per role. A reuse-count test would reject every token on this list; the test that matters is whether the THEME owns the decision, and it does: hotpink already restates them. */ --tb-control-height: 40px; /* buttons and fields share one height, so a row aligns */ --tb-button-pad-x: 12px; --tb-button-gap: 5px; /* label-to-icon inside a button */ --tb-button-radius: 20px; /* a pill at the 40px height above; literal, not derived from the height -- the design states 20px, and deriving it (border-radius-full) reports a computed value of thousands of px, which renders identically but makes every visual regression check unreadable */ --tb-disabled-opacity: .25; --tb-field-radius: 10px; --tb-field-pad-block: 10px; --tb-field-pad-inline: 12px; /* Grid row density. This is the single knob for how tall a grid row is: a row's height is this padding twice over, plus the line box of the 13px grid text (~18.6px). Kendo's own "medium" grid pads a cell 12px top AND bottom (~44px rows); 6px -- half that -- brings a row to ~31px, which fits roughly 40% more records per screenful. Text and icons are untouched; only the padding moves. A row holding a row-action button is set by the button's height rather than by this padding, so those rows sit a few pixels taller. 6px is deliberately the floor: below it the rows start reading as one block of text rather than as separate records. Block axis only, deliberately. The inline padding separates COLUMNS, not rows, so narrowing it costs scannability and buys no height -- Kendo's 12px inline is left alone, which is why there is no matching --tb-grid-cell-pad-inline to keep in step. */ --tb-grid-cell-pad-block: 6px; /* One hairline for every control boundary -- a field's border and a checkbox's outline are the same decision, and Kendo disagrees with itself about it (1px on inputs, 2px on checkboxes), so both are stated here rather than inherited. */ --tb-border-width: 1px; --tb-control-box-size: 15px; /* checkbox + radio; the checked mark scales with it */ /* ---- Header chrome ------------------------------------------------------------- The header is app furniture, not a Kendo widget, so none of this has a Kendo slot to inherit from -- every value is a design decision and belongs here. Two bands: a utility strip (identity + sign-out) over a brand strip (nav entry + logo). */ --tb-header-utility-height: 46px; --tb-header-brand-height: 66px; --tb-header-space: 16px; /* band side inset, and the brand strip's item gap */ --tb-header-gap: 8px; /* between items in the utility strip */ --tb-header-logo-height: 36px; /* the white M&D logo; "WEB PORTAL" sits beside it */ --tb-header-product-size: 15px; /* the "WEB PORTAL" label */ /* The hamburger. Decorative until Phase 2 puts navigation behind it -- but decorative is still designed, and a theme that restyles the chrome has to be able to move it. The bars are the glyph's own construction (three of them, stacked and centred). */ --tb-hamburger-size: 40px; --tb-hamburger-radius: 6px; --tb-hamburger-inset: 25px; /* from the left edge of the brand strip */ --tb-hamburger-bar-width: 30px; --tb-hamburger-bar-height: 3px; --tb-hamburger-bar-gap: 5px; --tb-hamburger-bar-radius: 2px; /* The off-canvas navigation drawer the hamburger opens. Its width is a theme decision because the page content is pushed right by exactly this much -- the drawer and the content offset read one token, so they can never disagree. */ --tb-drawer-width: 16rem; /* Identity pills. They read as pills on the green strip rather than as white form inputs -- they choose context, they are not data entry. The profile pill caps so a long value cannot stretch the strip; the account pill sizes to the selected account, up to the strip's width (site.css). */ --tb-pill-radius: 999px; --tb-pill-max-width: 200px; }