/* Material Design 3 color roles, as CSS custom properties — for any element that isn't a MudBlazor component (which already brings its own --mud-palette-* variable system, fed from Theming/HorusMudTheme.cs with this same palette). Same seed and same palette as HorusMudTheme.cs and HorusStudio.Erp.Mobile.Maui/Resources/Styles/Md3Light.xaml / Md3Dark.xaml. Don't edit by hand — see Arquitectura.md, Design System section. data-theme is set on from two places (see App.razor and ThemeToggle.razor.js): server-side from the cookie when it exists, or by the inline script in (system, no cookie yet). The @media fallback covers the instant before any script runs. */ :root, :root[data-theme="light"] { --md-sys-color-primary: #C00014; --md-sys-color-on-primary: #FFFFFF; --md-sys-color-primary-container: #FFDAD6; --md-sys-color-on-primary-container: #410002; --md-sys-color-secondary: #775653; --md-sys-color-on-secondary: #FFFFFF; --md-sys-color-secondary-container: #FFDAD6; --md-sys-color-on-secondary-container: #2C1513; /* Tertiary is the one family NOT derived from the two brand seeds — see Arquitectura.md §8. */ --md-sys-color-tertiary: #355DA4; --md-sys-color-on-tertiary: #FFFFFF; --md-sys-color-tertiary-container: #D8E2FF; --md-sys-color-on-tertiary-container: #001A41; --md-sys-color-error: #BA1A1A; --md-sys-color-on-error: #FFFFFF; --md-sys-color-error-container: #FFDAD6; --md-sys-color-on-error-container: #410002; /* Background/Surface are deliberately two different tones — see the same comment in HorusMudTheme.cs (T96/T100 stops of the Neutral tonal palette, not eyeballed). */ --md-sys-color-background: #EEEDF1; --md-sys-color-on-background: #1A1C1E; --md-sys-color-surface: #FFFFFF; --md-sys-color-on-surface: #1A1C1E; --md-sys-color-surface-variant: #F5DDDA; --md-sys-color-on-surface-variant: #42474E; --md-sys-color-outline: #857371; --md-sys-color-outline-variant: #D8C2BF; /* Inverse Surface/On-Surface — MD3's own pair for content that needs to pop OUT of the current theme (its whole point is deliberately high contrast against whatever surface it's sitting on), e.g. tooltips and snackbars. Approximated from the dark theme's own Background/on-Background below rather than generated via material-color-utilities from the neutral seed — this isn't the exact HCT tone MD3 would compute (a true inverse-surface sits at a slightly different tonal stop than plain Background), but for a two-color pair that only needs to read as "unmistakably the opposite of the page" it's a reasonable, honest stand-in: it already comes from the same neutral tonal palette everything else here does, just borrowed from the other theme. Revisit with a real HCT computation if this pair needs to carry more than tooltips someday. */ --md-sys-color-inverse-surface: #1A1C1E; --md-sys-color-inverse-on-surface: #E2E2E5; /* ── Disabled states ────────────────────────────────────────────────────── NOT a `--md-sys-color-*` role, hence the different prefix: MD3 has no colour role for "disabled". It defines disabled as an OPACITY applied to on-surface, and the same two numbers apply to every component — text, icons, containers, outlines — not to any one screen: · disabled CONTENT (text + icons) → on-surface @ 38% · disabled CONTAINER / outline → on-surface @ 12% Declared once here rather than per theme: the value is a color-mix over --md-sys-color-on-surface, which is itself redefined in each theme block below, so it resolves correctly in both without being repeated. Not the same as MudBlazor's --mud-palette-text-disabled, which these replace on plain-HTML elements: that one is a flat black/white wash and sits at only 20% in dark, dimmer than the spec intends. Use --mud-palette-text-disabled only when styling an actual MudBlazor component. Both are STATE LAYERS: they belong ON TOP of the element's own container, to flatten it against its surroundings. Don't use one to REPLACE a background against the page canvas — on-surface flips lightness between themes, so the layer darkens in light and lightens in dark, which inverts the hierarchy instead of muting it. (Learned the hard way on the timesheet calendar; see .horus-ts-outside in md3-components.css.) For "there is nothing here", the role is --md-sys-color-background, not a disabled layer. --horus-disabled-container has no callers yet — kept because documenting only half of a state pair is how the other half gets reinvented by hand. */ /* 65% in LIGHT, 38% in dark (see the dark blocks below) — not the single 38% MD3 specifies, because that figure assumes the disabled content sits on the element's own surface, and here it lands on the page canvas instead. Measured on the timesheet grid, where this token colours the column headers, the empty-cell dash and the locked-month padlock: over the light canvas (#EEEDF1) 38% yields 2.3:1, under even the 3:1 WCAG asks of non-text graphics, and reported as barely visible. 65% gives 4.99:1, past the 4.5:1 for small text — the headers are 12px. Dark was fine as it was (light-on-dark composites the other way) and is left untouched, per the report. */ --horus-disabled-content: color-mix(in srgb, var(--md-sys-color-on-surface) 65%, transparent); --horus-disabled-container: color-mix(in srgb, var(--md-sys-color-on-surface) 12%, transparent); /* ── Empty-state disc ───────────────────────────────────────────────────── The tinted circle behind EmptyState.razor's icon — explicit user request for "a very transparent shade of red, visually pink". Built from Error rather than a hardcoded pink so it tracks the palette, and declared here (not next to the component's own rules in md3-components.css) for the same reason --horus-disabled-content is: the TINT STRENGTH has to differ per theme, which only the theme blocks below can express. Only the percentage is redefined per theme; the mix itself is written once, and resolves correctly in both because --md-sys-color-error/-surface are themselves redefined on :root by each block (same mechanism as --horus-disabled-content — see its comment). 12% in LIGHT vs 22% in dark, for equal PERCEIVED pinkness rather than an equal number. Measured in the live app: light's Error (#BA1A1A) over white leaves an r−b spread of 20 at 12%, while dark's Error (#FFB4AB, already a pale tone) over #282A2D leaves only 6 at the same 12% — a disc that reads flat gray, not pink. 22% brings dark back to 14, close enough to read as the same blush without the disc turning into a bright plate. Deliberately OPAQUE (mixed against surface, not `transparent`): the component fills its badge notch with this exact value to fake a cut-out, which needs a real colour rather than a translucent layer. See .horus-empty-state-figure in md3-components.css. */ --horus-empty-state-tint: 12%; --horus-empty-state-bg: color-mix(in srgb, var(--md-sys-color-error) var(--horus-empty-state-tint), var(--md-sys-color-surface)); /* ── De-emphasized TEXT ─────────────────────────────────────────────────── Secondary text and icons: the "quieter than the main line" level, used by page subtitles, column captions, helper text, the timesheet hour figures, and so on. NOT `--md-sys-color-on-surface-variant`, which is what all of those used to point at, and the reason for the split is a measurement: on-surface-variant sits only **1.83:1** away from on-surface in light and **1.31:1** in dark — at that distance the two read as the same colour, which is exactly what was reported. There was plenty of room to move: secondary text was at 9.36:1 (light) / 8.47:1 (dark) against surface, far above the 4.5:1 it needs. Derived, not picked: on-surface mixed over surface. That keeps it on the palette (no invented hue) and makes it track any future change to the neutral seed. Resulting separation from on-surface: 3.20:1 in light, 2.23:1 in dark — and it still clears 4.5:1 on BOTH grounds it appears over (light 5.33 on surface / 5.00 on the canvas; dark 5.00 / 5.56). The percentage differs per theme for the same reason --horus-disabled-content's does: light-on-dark composites the other way, so the same number buys less separation in dark. 65% is as far as light can go while staying past 4.5:1 on the canvas; 60% is dark's equivalent. `on-surface-variant` is deliberately LEFT ALONE — it is a real MD3 role and it still has a job here: the assignments Gantt uses it as the person band's fill (its one non-text use in the whole stylesheet). Moving the role would have dragged that band along and cost it the contrast it was measured and approved at. */ --horus-text-secondary-mix: 65%; --horus-text-secondary: color-mix(in srgb, var(--md-sys-color-on-surface) var(--horus-text-secondary-mix), var(--md-sys-color-surface)); /* What an "ahead" tile of the home dashboard is tinted OVER (Arquitectura.md §72). It diverges by theme because a tint lightens in dark: over the white surface in light the accent wash stays light enough for secondary text; in dark, over the card it lifted the tile until that same text fell to 3.98:1, so dark tints over the neutral tile's own darker gray instead. */ --horus-dashboard-tile-ahead-base: var(--md-sys-color-surface); /* Brand red for FOREGROUND use (text and icons), which is NOT the same as --md-sys-color-primary here. By brand decision this palette freezes primary at #C00014 in both themes — correct for fills, where the pairing is white-on-red, but it fails as a foreground in dark: measured 2.65:1 against the dark canvas, under the 4.5:1 AA needs. MD3 normally solves this by making dark's primary a LIGHT tone of the primary tonal palette; this token restores exactly that for foregrounds only, leaving every filled component untouched. Light keeps #C00014 (5.54:1, passes). Dark uses primary T70 (#FF897E, 7.43:1) and NOT the T80 (#FFB4AB) MD3 would pick by default: T80 is the exact value this palette already uses for Error in dark, so brand text there would read as an error message. */ --horus-primary-text: #C00014; /* ── Warning alert (LIGHT ONLY — dark keeps MudBlazor's own values) ─────── MD3 defines no `warning` role, so Warning is left at MudBlazor's defaults (see HorusMudTheme.cs). Its Text-variant alert paints `--mud-palette-warning-hover` (a 6% wash of #FF9800) as the fill and `--mud-palette-warning-darken` (#D68100) as the content — and in LIGHT that pair fails twice over, reported and then measured in the live app: · The 6% wash is TRANSLUCENT, so on the page canvas (#EEEDF1) it composites to rgb(239,232,227) — one point of red away from the canvas it sits on. The yellow never registers; the alert reads as a slightly warm grey rectangle. · #D68100 on that composite is 2.47:1, under the 4.5:1 AA needs for body text. DARK was measured too and is genuinely fine (5.2:1 — a warm tint over a cool dark ground separates on its own), so it is left byte-for-byte as MudBlazor has it: the dark blocks below point these tokens straight back at the two Mud variables. That is the whole reason this is a token pair rather than a flat rule in md3-components.css — only a per-theme declaration can say "change one theme and not the other". Light's fill is mixed over SURFACE, not `transparent` (the user's own suggestion: "a second white background so the yellow transparency actually shows"). Same device as --horus-empty-state-bg above: an OPAQUE tint can't be washed out by whatever happens to sit behind the alert, which also means it looks the same on the canvas as inside a card. 18% lands on rgb(255,237,209) — unmistakably amber against the canvas without going saturated enough to read as an error. The content is mixed 30% toward ON-SURFACE rather than picked by hand, so it tracks the palette: rgb(95,65,21), 8.12:1 on that fill. */ --horus-alert-warning-bg: color-mix(in srgb, var(--mud-palette-warning) 10%, var(--md-sys-color-surface) 70%); /* 55%, not the mark's 70%: this one is TEXT, so it answers to 4.5:1 rather than 3:1. Measured against the fill above (rgb(255,245,229) over surface, rgb(252,241,227) over the canvas): 4.84:1 and 4.69:1. At the mark's 70% it would sit at 3.5:1 — fine for a glyph, short for a sentence. */ --horus-alert-warning-text: color-mix(in srgb, var(--mud-palette-warning) 55%, var(--md-sys-color-on-surface)); /* The icon gets its OWN token rather than reusing -text, purely so dark can keep MudBlazor's full-strength #FF9800 untouched (see the dark blocks). In light it has to follow the content tone: MudBlazor pins the icon to the undarkened warning, which lands at 1.88:1 on the fill above — below the 3:1 WCAG asks of non-text graphics. The amber fill is what carries the "this is a warning" signal here; the icon only has to be legible. */ --horus-alert-warning-icon: var(--horus-warning-mark); /* ---- Text and icon of EVERY info `Variant.Text` alert (global, see md3-components.css) ---- Same disease the warning pair above was treated for, found on the settlement's aguinaldo offer and measured on every info alert in the app (5 screens): MudBlazor paints the message with `info-darken` — rgb(12,128,223) — over its own 6% fill, which composites to rgb(226,232,241) on the canvas. That is 3,29:1, short of the 4,5:1 a sentence answers to. The fill is fine and is left alone; only the content tone diverges. 65% toward ON-SURFACE, the LIGHTEST step that clears it: 4,56:1 on the canvas and 5,27:1 over a white card. At 70% it would be 4,17 — the curve is steep here, so the step below is not a safety margin, it is the answer. The ICON needs its own rule and does NOT inherit: MudBlazor pins it to the full-strength info (`.mud-alert-text-info .mud-alert-icon`), which lands at 2,54:1 — under the 3:1 WCAG asks of a non-text graphic. 85% is the lightest step over that line (3,22:1) and keeps it reading as blue rather than as a second line of text. */ --horus-alert-info-text: color-mix(in srgb, var(--mud-palette-info) 65%, var(--md-sys-color-on-surface)); --horus-alert-info-icon: color-mix(in srgb, var(--mud-palette-info) 85%, var(--md-sys-color-on-surface)); /* ---- Fill of EVERY `Variant.Text` chip (global, see md3-components.css) ---- MudBlazor's Text-variant chip fills itself with the colour at 6% alpha, which over our surfaces composites to rgb(243,251,246) in light and rgb(41,50,49) in dark: 1.06:1 and 1.10:1 against the card behind them. Measured, after Pablo reported it — the label was legible in both themes (4.6:1 and 5.0:1), the PILL was not there at all. The recipe is the same for both themes (color-mix against tokens that each theme block redefines, so what flips is the DIRECTION), but **the FILL percentages diverge per theme**, just like the amber alert's and for the same reason: over white the mixes yield quite a bit less. With the dark values, in light the pill ended up at 1.38-1.46:1 and Pablo reported it as "a bit controversial"; in dark, "pretty good". Measured, pill against the card / label over the pill: LIGHT (fill from here) DARK (blocks below) neutral 24% → 1.66:1 / 10.3:1 18% → 1.64:1 / 6.8:1 success 36% → 1.64:1 / 5.37:1 28% → 1.62:1 / 4.62:1 info 44% → 1.62:1 / 4.71:1 30% → 1.60:1 / 4.66:1 All three end up with the SAME pill weight (~1.6) in both themes, which is what keeps a date chip and a status chip from competing with each other. The TEXT % does not diverge: it is the same in both themes because the `on-surface` end of the mix always contrasts with the surface (near-black in light, near-white in dark). And it is measured PER COLOUR: MudBlazor's `info` is lighter than `success`, so with green's 55% its text sat at 4.50:1, right on the line. */ --horus-chip-bg: color-mix(in srgb, var(--md-sys-color-on-surface) 24%, var(--md-sys-color-surface)); --horus-chip-text: var(--md-sys-color-on-surface); --horus-chip-success-bg: color-mix(in srgb, var(--mud-palette-success) 36%, var(--md-sys-color-surface)); --horus-chip-success-text: color-mix(in srgb, var(--mud-palette-success) 55%, var(--md-sys-color-on-surface)); --horus-chip-info-bg: color-mix(in srgb, var(--mud-palette-info) 44%, var(--md-sys-color-surface)); --horus-chip-info-text: color-mix(in srgb, var(--mud-palette-info) 48%, var(--md-sys-color-on-surface)); /* The fourth colour, measured separately as the rule demands — the other three's percentages do NOT carry over: MudBlazor's warning (#FF9800) is the lightest of the four, so with info's 44% the pill went well above 1.6:1 and with the text's 48% it fell below 4.5:1. It is the colour of "facturado de más" and "facturado sin horas" in /reports/reconciliation. Measurements in the comment above. */ --horus-chip-warning-bg: color-mix(in srgb, var(--mud-palette-warning) 60%, var(--md-sys-color-surface)); --horus-chip-warning-text: color-mix(in srgb, var(--mud-palette-warning) 32%, var(--md-sys-color-on-surface)); /* THE warning amber that is legible as a MARK on our light surfaces, promoted out of the alert tokens when a second consumer appeared (the timesheet progress bar and its warning icon — same criterion as promoting a Common_* resource key). MudBlazor's own warning is full-strength #FF9800, which measures 1.85:1 against the timesheet grid's plane and 1.88:1 on the alert fill: below the 3:1 WCAG asks of non-text graphics, i.e. a signal nobody can see. Mixed 30% toward on-surface rather than picked by hand, so it tracks the palette — rgb(95,65,21), 8:1 against the grid plane. DARK keeps MudBlazor's full-strength amber (see the dark blocks): it was measured at 8.83:1 there and needs nothing. That asymmetry is the whole reason this is a token per theme and not a flat rule. */ /* 75%, chosen by the user with the whole curve in front of them — settled, don't re-tune it. History, because the number looks arbitrary and is not: this was 30% (rgb(95,65,21)), which measures 9.32:1 against white — the contrast of BLACK TEXT for a glyph that only has to clear 3:1. It had stopped reading as amber at all and was reported as such ("it's too dark and I don't like it"). What 75% costs, measured live: rgb(198,121,8) is 3.42:1 on a white cell and 2.93:1 on the tinted ones, i.e. a hair under the 3:1 WCAG asks of non-text graphics on the tinted half. Accepted deliberately — the day's own total carries the same signal in bold, so the icon is not the only channel. 73% was the last value clearing both (3.55 / 3.05) and 80% the lightest tried (3.11 / 2.67). Full-strength #FF9800 is 2.16:1, which is what the darkening existed to fix in the first place. The alert's TEXT keeps its own 55% (see that token): a sentence answers to 4.5:1, and this value would leave it at ~3.2:1. */ --horus-warning-mark: color-mix(in srgb, var(--mud-palette-warning) 75%, var(--md-sys-color-on-surface)); } :root[data-theme="dark"] { /* Intentional exception: Primary/on-primary are NOT the tones generated by HCT for dark (light red + dark text, MD3's standard convention) — by brand decision, they are identical to light. See the same comment in HorusMudTheme.cs and Md3Dark.xaml (Mobile). */ --md-sys-color-primary: #C00014; --md-sys-color-on-primary: #FFFFFF; --md-sys-color-primary-container: #93000C; --md-sys-color-on-primary-container: #FFDAD6; --md-sys-color-secondary: #E7BDB8; --md-sys-color-on-secondary: #442927; --md-sys-color-secondary-container: #5D3F3C; --md-sys-color-on-secondary-container: #FFDAD6; --md-sys-color-tertiary: #ADC6FF; --md-sys-color-on-tertiary: #002E69; --md-sys-color-tertiary-container: #17458A; --md-sys-color-on-tertiary-container: #D8E2FF; --md-sys-color-error: #FFB4AB; --md-sys-color-on-error: #690005; --md-sys-color-error-container: #93000A; --md-sys-color-on-error-container: #FFB4AB; /* T10/T17 stops — Surface (the card tone) reads LIGHTER than Background (the canvas) here, matching MD3 dark-mode elevation (elevated = lighter, not darker). */ --md-sys-color-background: #1A1C1E; --md-sys-color-on-background: #E2E2E5; --md-sys-color-surface: #282A2D; --md-sys-color-on-surface: #E2E2E5; --md-sys-color-surface-variant: #534341; --md-sys-color-on-surface-variant: #C2C7CF; --md-sys-color-outline: #A08C8A; --md-sys-color-outline-variant: #534341; /* Same pair, inverted — see the comment in the light block above. Here it's borrowed from LIGHT's own Background/on-Background, so a tooltip stays a near-opposite-tone pop-out regardless of which theme is active. */ --md-sys-color-inverse-surface: #EEEDF1; --md-sys-color-inverse-on-surface: #1A1C1E; /* primary T70 — see the comment in the light block. */ --horus-primary-text: #FF897E; /* Back to MD3's 38% here: dark composites a LIGHT on-surface over a dark ground, which lands well clear of the contrast floor on its own. The light block's 65% is a fix for that theme only — see its comment. */ --horus-disabled-content: color-mix(in srgb, var(--md-sys-color-on-surface) 38%, transparent); /* Dark's Error is already a pale tone, so it needs a stronger mix to read as pink at all — see the light block's comment for the measurements. */ --horus-empty-state-tint: 22%; /* 60%, not light's 65% — light-on-dark composites the other way, so the same number buys less separation. See the light block for the measurements. */ --horus-text-secondary-mix: 60%; --horus-dashboard-tile-ahead-base: color-mix(in srgb, var(--md-sys-color-background) 70%, var(--md-sys-color-surface)); /* The chip fills, softer than in light: over a dark card the same mix yields more. Only the `-bg` — the `-text` above already resolves well in both themes because it mixes toward `on-surface`. Measurements in the light block. */ --horus-chip-bg: color-mix(in srgb, var(--md-sys-color-on-surface) 18%, var(--md-sys-color-surface)); --horus-chip-success-bg: color-mix(in srgb, var(--mud-palette-success) 28%, var(--md-sys-color-surface)); --horus-chip-info-bg: color-mix(in srgb, var(--mud-palette-info) 30%, var(--md-sys-color-surface)); --horus-chip-warning-bg: color-mix(in srgb, var(--mud-palette-warning) 24%, var(--md-sys-color-surface)); /* Dark was measured at 5.2:1 and reported as fine, so it keeps MudBlazor's own pair verbatim — these are the exact two variables its Text-variant alert would have used anyway. See the light block's comment for why only light diverges. */ --horus-alert-warning-bg: var(--mud-palette-warning-hover); --horus-alert-warning-text: var(--mud-palette-warning-darken); --horus-alert-warning-icon: var(--horus-warning-mark); /* Dark's problem is smaller but real: MudBlazor's `info-darken` measures 4,37:1 on the canvas and 3,66:1 over a card, both under 4,5. Mixed 90% toward on-surface it is 5,79 / 4,85 and still unmistakably blue. The ICON keeps MudBlazor's own info here (5,37 / 4,50), same call the warning pair makes in this block. */ --horus-alert-info-text: color-mix(in srgb, var(--mud-palette-info) 90%, var(--md-sys-color-on-surface)); --horus-alert-info-icon: var(--mud-palette-info); /* Measured at 8.83:1 against the timesheet grid's plane — dark needs no darkening, so the mark IS MudBlazor's own amber here. */ --horus-warning-mark: var(--mud-palette-warning); } @media (prefers-color-scheme: dark) { :root:not([data-theme]) { --md-sys-color-primary: #C00014; --md-sys-color-on-primary: #FFFFFF; --md-sys-color-primary-container: #93000C; --md-sys-color-on-primary-container: #FFDAD6; --md-sys-color-secondary: #E7BDB8; --md-sys-color-on-secondary: #442927; /* Error/on-error were missing from this block while the explicit [data-theme="dark"] one above had them, which would leave LIGHT's #BA1A1A (a deep red meant to sit on white) in force over a dark surface. In practice this block rarely governs anything: App.razor stamps data-theme server-side from the cookie, and an inline script fills it in before first paint when it couldn't — so :root:not([data-theme]) only holds for the instant before that script runs, or with JS off entirely. Filling the gap anyway: a half-populated fallback is how a theme bug hides for months. Noticed while adding --horus-empty-state-bg below, which is mixed from Error and so would have inherited the inconsistency. */ --md-sys-color-error: #FFB4AB; --md-sys-color-on-error: #690005; --md-sys-color-background: #1A1C1E; --md-sys-color-on-background: #E2E2E5; --md-sys-color-surface: #282A2D; --md-sys-color-on-surface: #E2E2E5; --md-sys-color-surface-variant: #534341; --md-sys-color-on-surface-variant: #C2C7CF; --md-sys-color-outline: #A08C8A; --md-sys-color-outline-variant: #534341; --horus-primary-text: #FF897E; /* All three mirror the explicit dark block above — see its comments. */ --horus-disabled-content: color-mix(in srgb, var(--md-sys-color-on-surface) 38%, transparent); --horus-empty-state-tint: 22%; --horus-text-secondary-mix: 60%; --horus-dashboard-tile-ahead-base: color-mix(in srgb, var(--md-sys-color-background) 70%, var(--md-sys-color-surface)); /* Mirror of the explicit dark block — see its comments. */ --horus-chip-bg: color-mix(in srgb, var(--md-sys-color-on-surface) 18%, var(--md-sys-color-surface)); --horus-chip-success-bg: color-mix(in srgb, var(--mud-palette-success) 28%, var(--md-sys-color-surface)); --horus-chip-info-bg: color-mix(in srgb, var(--mud-palette-info) 30%, var(--md-sys-color-surface)); --horus-chip-warning-bg: color-mix(in srgb, var(--mud-palette-warning) 24%, var(--md-sys-color-surface)); --horus-alert-warning-bg: var(--mud-palette-warning-hover); --horus-alert-warning-text: var(--mud-palette-warning-darken); --horus-alert-warning-icon: var(--horus-warning-mark); /* Mirror of the explicit dark block — see its comments there. */ --horus-alert-info-text: color-mix(in srgb, var(--mud-palette-info) 90%, var(--md-sys-color-on-surface)); --horus-alert-info-icon: var(--mud-palette-info); --horus-warning-mark: var(--mud-palette-warning); } }