/* ── Color tokens ────────────────────────────────────────────── Two tiers, never conflated: 1. Palette - the ten raw corporate hues, exactly as specified (Issue 45). Reference values only - nothing in a component ever reads a --palette-* variable directly. They exist so every derived token below can point back to the swatch it came from, and so the full corporate palette is genuinely present in the token architecture, not just in a design brief. 2. Semantic - six independent families, never mixed: Brand - primary/secondary CTA, .eyebrow, .cta-block's accent border. Deliberately narrow (Issue 45 revision): a small, high-energy set of "act now" moments, not the color of ordinary navigation, links, icons or every active tab. Interactive - the far more common role Brand used to fill: ordinary link hover, nav hover/active, focus rings, table-of-contents/media-picker selection, toolbar hover. "You're navigating or interacting here," not "act now." Neutral - text, headings, surfaces, borders. Where --palette-dark-grey (#202732) becomes the primary text/heading foundation. Status - business state (published/draft, open/closed, success/warning/error/info). Meaning first, aesthetics second. Used by badges, alerts, form validation - nowhere else. Accent - two separate, deliberately non-overlapping sets: - Content/product accents (--accent-*) - a recognisable identity per content family (Profile, Projects, Articles, Offerings, Legal, Technologies, Requests), applied narrowly to an icon, a border, a single accent - never a whole card. Shared between Website Studio and the public site wherever the same content family appears (e.g. Articles' green shows up both on the Studio dashboard card and on a public article's pull-quote). - Decorative surfaces (--surface-*) - soft pastel panels for one-off emphasis (a callout), no content-family identity of their own. Components consume semantic tokens; they never hardcode a hex value and never reach for a --palette-* primitive directly. See ../README.md for the usage rules in full, and ../../../../docs/architecture/color-system-palette-migration-decision.md for the accessibility math, the full before/after semantic map, and the reasoning behind every value below (Issue 45 and its revision). */ :root { /* ── Palette (Issue 45 corporate colors) - reference only ──── */ /* --palette-orange has no semantic-token consumer as of Issue 45 v2 (approved mockup: "Orange should effectively disappear from the primary public/Studio visual language") - kept declared because all ten corporate hues stay present in this reference tier regardless of current UI use (Issue 45's original mandate). Do not repoint any semantic token back to it without a new, explicitly approved design decision. */ --palette-orange: #FD570A; --palette-red: #F30013; --palette-green: #00D56F; --palette-blue: #0F74D3; --palette-yellow: #FED718; --palette-light-grey: #ECEDED; --palette-dark-grey: #202732; --palette-sand: #EEC78A; --palette-brown: #7A6B62; --palette-light-pink: #FCA6CB; /* ── Brand ─────────────────────────────────────────────────── */ /* Issue 45 v2 (approved mockup, doc/mockup/UI-refactored-first- version.png): Brand moves from Orange to Red - orange is retired from the primary visual language entirely, red becomes the site's one "act now" color (.btn-primary, .eyebrow default, .cta-block's accent border, the required-field asterisk). --palette-red (#F30013) is 4.36:1 against white - just under the 4.5:1 text/button minimum, and critically not a token to darken with the *same* recipe --status-danger-text already uses (plain darken-toward-black), since that recipe applied to the same raw hue lands on --status-danger-text's own value (#D60011) almost exactly - a brand button and a danger alert would become the same red. Instead, --color-primary is Red mixed 20% toward --palette-dark-grey (desaturate, not just darken) - the same technique --accent-editorial-fg already uses to keep Articles' green off --status-success-text's recipe. Result: #C90819, 5.95:1 against white, visibly a distinct "brand crimson" next to danger's brighter, purer red - and the two only ever appear in very different contexts anyway (a solid filled button vs. pale-background alert text). */ --color-primary: #C90819; --color-primary-hover: #AF0C1D; --color-primary-light: #FEEBEC; /* ── Interactive (blue retired, reuses Brand red) ───────────── This is the system's single most-reused semantic color after Neutral text: ordinary link hover/focus, every nav's hover/ active state (site nav, subnav, workspace nav), the global :focus-visible ring, table-of-contents active item, media- picker hover/selection, content-editor toolbar hover, password- toggle, embed-facade hover, back-to-top, code-block copy button, and Website Studio's "Manage Entity →" links. Centralising all of these on one token is what actually fixes "everything is orange" - not recoloring each site individually. Was --palette-blue darkened 10% (#0E68BE) through Issue 45's revision. Design system correction: "no blue as an interactive colour anywhere" - aliased to --color-primary/-light verbatim rather than deriving a second, slightly different red, so the hover/focus signal and .nav-links a.is-active's "you are here" signal (already --color-primary, see below) read as the same red. Projects' and Requests' domain identity (--accent- technical-*, --accent-inbox-*) used to reuse this token too, on the old reasoning "technical/interactive is exactly what Interactive means" - now decoupled to their own literal Blue values at those declarations so recoloring *interaction* doesn't drag those two content families' identity along with it; that was never the point of this change. */ --color-interactive: var(--color-primary); --color-interactive-light: var(--color-primary-light); /* ── Background / surface neutrals ──────────────────────────── White is the dominant canvas. --color-surface-muted is for secondary panels (form fields, empty states) - never the default page background. Derived from --palette-light-grey; --color-border uses that palette color at full strength (a hairline needs no further tinting), --color-surface-muted and --color-surface are progressively lighter mixes toward white so the three stay visually ordered: border > surface-muted > surface > white. */ --color-background: #FFFFFF; --color-surface: #F8F8F8; --color-surface-muted: #F3F3F3; --color-border: #ECEDED; /* ── Footer (dark anchor) ───────────────────────────────────── Issue 45 composition revision: white can't be the only large surface in the system, and the footer is the one place a full --palette-dark-grey field terminates the page instead of fading into it. A dark background needs its own foreground set - reusing --color-text/--color-interactive here would fail contrast outright (both were tuned for white). Each is the same palette hue LIGHTENED toward white instead of darkened, the mirror image of how every light-surface token in this file was built. */ --color-footer-bg: #202732; --color-footer-text: #ECEDED; /* --palette-light-grey as-is - 12.81:1 on footer-bg */ --color-footer-text-muted: #A99F99; /* --palette-brown lightened 35% - 5.80:1 - also footer links' resting color, matching the sitewide "ordinary link inherits, only hover is colored" convention */ --color-footer-link-hover: #F75966; /* Issue 45 v2: --palette-red lightened 35% toward white (was Orange, retired) - 4.70:1 against footer-bg, a warm-red pop against the dark field */ --color-footer-border: #3B414B; /* --palette-dark-grey lightened 12% - a hairline visible against footer-bg, not a text color */ /* ── Typography neutrals ───────────────────────────────────── */ /* --palette-dark-grey (#202732) is 15:1 against white - the primary text/dark-neutral foundation the issue calls for, used at full strength for headings and 10% lightened for body copy (a small step, the same relationship the previous heading/text pair had). --color-text-muted (Issue 45, fourth pass - corrected): --palette-dark-grey lightened 33% - a neutral grey, not --palette-brown. The very first pass used Brown here reasoning "a genuinely warm, on-palette neutral instead of a generic grey" - which turned out wrong in practice: --color-text-muted is the single token behind nearly every nav label, card description, and secondary/metadata line across the whole system (45 consumers), so "warm brown" became the de facto color of most interface text, reading as muddy/weak rather than as a deliberate accent. #202732 lightened 33% (5.12:1, matching the old brown value's 5.11:1 almost exactly - same visual weight in the hierarchy, corrected hue) keeps the dark neutral family internally consistent: heading, body, and muted text are now three steps of the *same* hue, the way the issue originally specified "#202732 remains the primary text/dark- neutral foundation" to mean. Warm Brown still exists at full character exactly where it was always a deliberate accent, not default text - --palette-brown itself, and Technologies' `--accent-infrastructure-fg`/`-strong` (unchanged, independent literal/var values, not aliased to this token). See the decision doc's Section 12 for the full before/after. */ --color-heading: #202732; --color-text: #363D46; --color-text-muted: #6A6E76; /* ── Semantic status ─────────────────────────────────────────── Business meaning, not decoration. Use for Published/Draft, Open/Closed, and validation/alert states - see README for the full status → variant mapping. Each -text value is its palette hue darkened toward black until it clears 4.5:1 both against white and against its own -bg tint (never assume the raw palette hue is text-safe - green and yellow in particular are far too light on their own). -bg is the palette hue lightened 90% toward white; -border sits at 65%, roughly midway between the two so the badge/alert boundary reads as a visible but restrained outline. */ --status-success-bg: #E6FBF1; --status-success-border: #A6F0CD; --status-success-text: #008043; --status-info-bg: #E7F1FB; --status-info-border: #ABCEF0; --status-info-text: #0E68BE; --status-warning-bg: #FFFBE8; --status-warning-border: #FFF1AE; --status-warning-text: #7F6C0C; --status-danger-bg: #FEE6E7; --status-danger-border: #FBA6AC; --status-danger-text: #D60011; --status-neutral-bg: #F4F4F5; --status-neutral-border: #D7D8DA; --status-neutral-text: #5E636B; /* ── Content/product accents (Issue 45 revision, third pass) ───── One recognisable identity per content family - Profile, Projects, Articles, Offerings, Legal, Technologies, Requests - each a three-tier scale, not a single darken-for-text value: -strong non-text UI only (icon fills, left/top accent bars, a card's edge) - the 3:1 WCAG "UI component boundary" minimum, not 4.5:1. This is deliberately as close to the raw --palette-* hue as contrast allows, often the raw hue itself (Orange, Blue, Brown, Dark grey all already clear 3:1 unmixed) - the bold, saturated tier that gives a domain its actual visual identity. -fg literal TEXT use only (.eyebrow, a nav active tab's label) - darkened further, to the stricter 4.5:1 text minimum. Necessarily more muted than -strong for Pink/Sand/Green, whose raw hues are nowhere near 4.5:1 - see the decision doc for the exact numbers. -bg a very pale tint, reserved for small, transient supporting use (e.g. a card's own :hover state) - never a card or panel's resting background. Using this as a *resting* full-surface fill is exactly the "pastel admin dashboard" mistake this third pass corrects; see the decision doc's Section 11 for the before/after. Applied to one small-to-medium surface at a time (an icon, a border, a transient hover tint) - never a card's resting background - and shared verbatim between Website Studio and the public site wherever that same content family shows up (Articles' green is the same tokens on the Studio dashboard card and on a public article's feature panel). Deliberately excludes Yellow entirely - Status-only in this system (warning), and a decorative reuse is exactly the ambiguity Issue 45 warned against. Red is Status' danger color too, but Issue 45 v2's approved mockup makes Red double as Brand/CTA (see "Brand" above) - Offerings inherits that collision-aware derivation by reusing Brand verbatim, the same way it always has, rather than getting a second independent red. Green is used once (Articles) but with its own distinct derivation (desaturated toward --palette-dark-grey, not simply darkened toward black the way --status-success-text is) specifically so an Articles icon never reads as a success badge - see the decision doc for the side-by-side hex comparison. Offerings and Projects don't get their own derivation at all: Offerings reuses Brand (--color-primary, Red) verbatim - it's the sellable catalogue, the one content family where "product accent" and "CTA energy" are genuinely the same idea - and Projects reuses Blue verbatim (originally via Interactive, since "technical/interactive" was exactly what Interactive meant at the time; now via its own literal value at --accent-technical-fg/-bg, decoupled after Interactive was reassigned to Brand red - see "Interactive" above). Issue 45 v2 (approved mockup) reassigns two of the seven: Brown is now "optional secondary accent only," not a domain identity, so Technologies moves off Brown onto a dedicated neutral dark-grey scale instead (this is the exact scale Requests used to hold, under its old "inbox" name - only the *domain* it's assigned to changed, the values didn't need recomputing). Requests moves onto Blue instead, the same way Projects does (also now its own literal value, decoupled from Interactive for the same reason) - the mockup shows both with the same blue icon identity, which is fine: two domains sharing one accent isn't the ambiguity Issue 45 warned against the way Red-as-both-Brand-and-Status was - neither Requests nor Projects has a second, competing meaning for blue elsewhere in the system. */ --accent-personality-strong: #C2809C; /* Profile - Light Pink, darkened 23% (3:1 minimum) */ --accent-personality-fg: #8B5B70; /* Light Pink, darkened 45% (4.5:1 minimum, text use only) */ --accent-personality-bg: #FFF2F7; /* Light Pink, lightened 85% - small supporting tint only */ --accent-technical-strong: var(--palette-blue); /* Projects - raw Blue already clears 4.71:1 */ /* Was var(--color-interactive)/-light - decoupled now that Interactive means Brand red (see "Interactive" above). Literal values below are exactly Interactive's old resolved Blue, so Projects' domain identity (eyebrow, spotlight icon/link, Studio dashboard card) is unchanged; this is content-family identity, not the Project *card* accent (--color-heading) and not an interactive/hover state. */ --accent-technical-fg: #0E68BE; --accent-technical-bg: #E7F1FB; --accent-editorial-strong: #00AA59; /* Articles - Green, darkened 20% (3:1 minimum) */ --accent-editorial-fg: #12754D; /* Green desaturated 55% toward dark grey, then darkened (4.5:1, text use only) - NOT --status-success-text's recipe */ --accent-editorial-bg: #E3EEEA; /* small supporting tint only */ --accent-commercial-strong: var(--palette-red); /* Offerings - raw Red, 4.36:1 against white, 3:1-safe for the strong/non-text tier */ --accent-commercial-fg: var(--color-primary); --accent-commercial-bg: var(--color-primary-light); --accent-document-strong: #AB8F63; /* Legal - Sand, darkened 28% (3:1 minimum) */ --accent-document-fg: #776445; /* Sand, darkened 50% (4.5:1, text use only) */ --accent-document-bg: #FCF5EA; /* small supporting tint only */ --accent-infrastructure-strong: var(--palette-dark-grey); /* Technologies (Issue 45 v2 - was Brown) - raw dark grey (= --color-heading), a neutral identity per the approved mockup */ --accent-infrastructure-fg: #414751; /* dark grey lightened 15% - a neutral-strong *text* identity, not full heading-black */ --accent-infrastructure-bg: #F2F2F3; /* small supporting tint only */ --accent-inbox-strong: var(--palette-blue); /* Requests (Issue 45 v2 - was dark grey) - reuses Interactive/Blue verbatim, same recipe as Projects */ /* Decoupled from --color-interactive/-light for the same reason as --accent-technical-fg/-bg above - same literal Blue, unaffected by Interactive's reassignment to Brand red. */ --accent-inbox-fg: #0E68BE; --accent-inbox-bg: #E7F1FB; /* ── Decorative accent surfaces ─────────────────────────────── Soft pastel panels reserved for emphasis: a quote, a homepage callout, an announcement. Not a status vocabulary - do not give these business meaning. Use sparingly; white remains the dominant canvas. Sand and Light Pink are used near-as-specified (already pastel-level at full strength); Blue is far too saturated in its raw form for a surface, so it's heavily lightened instead - see "The corporate palette" above for why the same "darken for text, lighten for surface" rule applies here too. Green and Red are deliberately excluded from this family even though they're soft at low opacity - both are claimed by Status (success/danger) in this system (Red is now Brand too, as of Issue 45 v2 - one more reason not to also give it a decorative-surface role), and reusing them decoratively is exactly the ambiguity Issue 45 asked to avoid. An Orange member of this family existed briefly for a hero decoration that was removed for v1.0 (see the decision doc's final section); Orange itself was then retired from the primary visual language entirely by Issue 45 v2 - not reintroduced anywhere without a real, currently-approved consumer. */ --surface-sand: #EEC78A; --surface-pink: #FCA6CB; --surface-blue: #CAE0F5; /* ── Code: dark technical surface ───────────────────────────── A fully independent family, outside the six semantic families above: syntax colors for fenced code blocks and their Pygments token classes (see ../components/code.css). Deliberately its own set, not reused from Brand/Interactive/Neutral/Status/ Accent - a keyword or a string must never read as "published" or "danger" just because it happens to share a hue with a badge. Out of scope for the Issue 45 palette migration - this family predates it and answers a different design question (legible syntax-token hues on a technical surface, not corporate identity). Issue 60: the original light sand editor surface didn't work visually - retired in favor of --palette-dark-grey itself (the same primary dark neutral the footer already terminates the page on, not a second, arbitrary dark shade), giving fenced code a deliberate "white editorial page -> dark technical area" hierarchy. --code-text, --code-muted and --code-border are not new derivations - they alias the exact foreground/border scale already computed for --color-footer-bg (see "Footer (dark anchor)" above), which happens to equal this same dark grey: one dark-surface foreground system, reused rather than recomputed. --code-text is a soft off-white (not pure white), --code-border is intentionally low-contrast against the surface (~1.5:1) - a barely-there hairline, not a card outline, since the dark fill already separates the block from the white page on its own. The ten syntax-token hues below are a restrained, muted pastel family tuned for *this* dark surface: moderate lightness (~65-72%) and moderate saturation (~35-55%) - legible without reading as a saturated "colorful IDE theme", and every one individually checked at >=4.5:1 (WCAG AA) against --palette-dark-grey (most land 5-8:1, comment intentionally lowest of the set since it must still read as visually subordinate to the rest). */ --code-surface: var(--palette-dark-grey); --code-border: var(--color-footer-border); --code-text: var(--color-footer-text); --code-muted: var(--color-footer-text-muted); --code-selection: #33495E; /* Token colors, keyed to Pygments' short class names via ../components/code.css (e.g. `.k` -> --code-keyword). */ --code-keyword: #B9A3E3; --code-string: #DDAE81; --code-number: #DE8B8B; --code-comment: #9096A3; --code-function: #8CC29B; --code-class: #CDAB60; --code-variable: #93BEE6; --code-operator: #CE9AC0; --code-punctuation: #A3A9B5; /* Bash-only: a native shell builtin (`cd`, `echo`, `export`, ...) and the `sudo`/`env`/... privilege prefix's command-hierarchy tier - used exclusively via the language-scoped ".language-bash .nb" rule in ../components/code.css, never the shared --code-builtin token (that stays Python's `len`/`self` color, untouched). A richer, more saturated teal than a generic "builtin" needs to be, since in a DevOps snippet this is the word that most needs to catch the eye first. */ --code-bash-command: #67B5C0; --code-builtin: #7BC4CC; --code-error: #E58080; }