/* ============================================================================ Cordis Design System — legacy compatibility shim (--cordis-* -> --cordis-*) ---------------------------------------------------------------------------- WHAT THIS IS The Cordis IDE ("Studio", Cordis.IDE.UI/wwwroot/app.css) declares its own token block under the legacy `--cordis-*` prefix. The canonical prefix of this design system is `--cordis-*`. This file aliases every legacy token onto its canonical counterpart so that existing IDE CSS keeps working unchanged while already resolving to the new canonical values wherever the two systems agree. THIS FILE IS TEMPORARY. It exists only to make the IDE migration incremental. It is deleted once the last `--cordis-*` / `--cdg-*` reference is gone from application code. NEW CODE MUST USE `--cordis-*` DIRECTLY. Never add a token here to serve new code; promote it into tokens.css instead. LOAD ORDER (this file always last) 1. css/tokens.css — canonical --cordis-* tokens 2. css/cordis.css — components 3. css/cordis-studio.css — Studio/IDE layer 4. css/compat/cordis-legacy.css — this shim The IDE must then DELETE its own `:root` + `.cordis-shell.cordis-dark` token blocks from app.css. Leaving them in place would win by source order and the shim would have no effect. DARK MODE Canonical dark is the ATTRIBUTE `[data-theme="dark"]`, set on . The IDE drives dark through the CLASS `.cordis-shell.cordis-dark`. Both mechanisms are bridged below, so either one works. The page's theme goes on . A scoped theme (`data-theme` on an element inside the page, see tokens.css rule 5) works because the alias block below is declared on `[data-theme]` as well as `:root`: a var() inside a custom property resolves where it is DECLARED, so aliases declared on `:root` only would keep the page's values inside that subtree. BRAND DECISIONS D1-D5 — ALL DECIDED (2026-08) Five values used to differ between the two systems, and each kept its LEGACY LITERAL here while the decision was open. None does now: D1/D2/D3 went to the canonical palette (the hexes reference/index.html shows), D4 became a per-profile token, and D5 was deleted because nothing read it. There is no `PENDING D#` marker left in this file. If you are adding one, you are adding a held brand value, and it needs a page in the showcase saying so. ST SYNTAX TOKENS — HARD CONSTRAINT Every `--cordis-st-*` token MUST resolve to a literal 6-digit #rrggbb hex. The Monaco shim (cordisMonaco._stTokenColors) parses the COMPUTED value as a string and silently drops anything it cannot read as a hex — a `var()` there breaks Structured-Text syntax highlighting. They are therefore written as literals, never as aliases. ========================================================================== */ :root, [data-theme] { /* ------------------------------------------------------------------ Brand palette ------------------------------------------------------------------ */ --cordis-blue: var(--cordis-blue-500); /* #1F9CD8 — exact match */ --cordis-green: var(--cordis-green-500); /* #3BAA35 — exact match */ --cordis-red: var(--cordis-red-500); /* #E20717 — exact match */ --cordis-violet: var(--cordis-type-violet); /* #8B5CF6 — exact match. User-defined data types (enumerations, complex types). */ /* D1, D2, D3 — DECIDED 2026-08: the canonical palette wins, in all three cases. The brand is what the specification document (reference/index.html) shows, and it shows exactly these hexes; a legacy literal one step away from the brand is a value that drifted, not a value anyone chose. Studio therefore moves: blue-dark #1A83B8 → #0F6A97 (visible), blue-light #90D3F5 → #8FD3F5 (one step in the green channel, invisible), amber #D8941F → #C97A0E (visible, and the canonical one is the one that clears 4.5:1 as text). */ --cordis-blue-dark: var(--cordis-blue-700); --cordis-blue-light: var(--cordis-blue-300); --cordis-amber: var(--cordis-amber-500); /* D5 — DECIDED 2026-08: deleted, not resolved. --cordis-grey #575756 was a warm grey with no rung in the cool --cordis-n-* ramp, and the question "which rung should it map to" had no answer because NOTHING READ IT. It is declared in app.css and in this shim and referenced nowhere in either repository; the one place in cordis-ide that considered it — StateNodeWidget.razor.css — rejected it in a comment as a near-invisible fixed dark grey and used a theme-aware one instead. A token no rule consumes is not a colour decision, it is a leftover. Anything that wants a neutral grey takes --cordis-text-muted or a --cordis-n-* rung. */ /* ------------------------------------------------------------------ State colours (diagram box accent + tree/palette/SPECIFY glyph) IDE-specific — not promoted to the design system. ------------------------------------------------------------------ */ --cordis-state-normal: #98A1AD; --cordis-state-flat: #565F6B; /* ------------------------------------------------------------------ Structured-Text syntax tokens — LITERAL HEX ONLY (see header) Values mirror the brand palette by hand: keyword = brand blue, call/true = brand green, type = type violet, false = brand red, number/string = canonical amber (D3 decided), variable/comment = dimmed text. If a brand value changes, update these literals in the same commit. ------------------------------------------------------------------ */ --cordis-st-keyword: #1F9CD8; /* = --cordis-blue-500 */ --cordis-st-call: #3BAA35; /* = --cordis-green-500 */ --cordis-st-type: #8B5CF6; /* = --cordis-type-violet */ --cordis-st-true: #3BAA35; /* = --cordis-green-500 */ --cordis-st-false: #E20717; /* = --cordis-red-500 */ --cordis-st-number: #C97A0E; /* = --cordis-amber-500 (D3 decided) */ --cordis-st-string: #C97A0E; /* = --cordis-amber-500 (D3 decided) */ /* Variables carry the line and the punctuation around them recedes (issue #183): a macro's target path and its argument are what a reader is after, so they take the full body text and the delimiters take the dim. Shipped the other way round at first, which made the dots and brackets out-read the names on both themes. */ --cordis-st-variable: #212B36; /* = light --cordis-text; re-declared per theme below */ --cordis-st-punctuation: #6B7280; /* light dimmed text; re-declared per theme below */ --cordis-st-comment: #6B7280; /* light dimmed text; re-declared per theme below */ /* ------------------------------------------------------------------ IDE chrome (deliberately dark in BOTH themes — VS Code style) IDE-specific, not promoted to the design system. These must stay literal: aliasing them to a semantic --cordis-* surface would make the chrome follow the body theme and turn the title bar white in light mode. Note --cordis-rail-bg equals the dark --cordis-surface-sunken (#171716) but must NOT alias it, because in light mode that token resolves to #F7F9FB. ------------------------------------------------------------------ */ --cordis-chrome-bg: #1F1F1E; --cordis-rail-bg: #171716; --cordis-chrome-fg: #CFCDC8; --cordis-chrome-fg-dim: #85837E; --cordis-chrome-active: #FFFFFF; --cordis-chrome-border: #2C2C2A; /* The rules that separate GROUPS INSIDE the chrome, as opposed to the chrome's own outline. Not the same job, and they cannot share a value: --cordis-chrome-border draws the seam between two chrome surfaces that already differ, so it is deliberately almost invisible, while a divider has to be seen against ONE surface with nothing else marking it. At --cordis-chrome-border the activity rail's cluster hairlines sat at 1.3:1 on --cordis-rail-bg and could not be made out. The body's --cordis-border is not the answer either: it steps with the theme (#E5EAF0 in light) and the chrome stays dark in both, so in light mode it would draw a white line across the rail. A white FILM rather than a literal, matching --cordis-chrome-hover's idiom just below: the chrome has two grounds (--cordis-chrome-bg and the darker --cordis-rail-bg) and a film lands at the same weight on each - 1.79:1 and 1.76:1 - where one fixed colour drifts apart. */ --cordis-chrome-divider: rgba(255, 255, 255, 0.18); --cordis-chrome-hover: rgba(255, 255, 255, 0.07); /* ------------------------------------------------------------------ Custom tooltip chip — PROMOTED to css/tokens.css by D10 family merge #6, so it is no longer declared here. It was never IDE-specific: nothing about a dark chip over a `title` attribute is Blazor's or Studio's, and while the four tokens lived here an HMI panel loading only tokens.css + cordis.css got the class and never the colours. Token ownership is exactly one file per token (TokenOwnershipTests), so promoting them meant deleting them here rather than aliasing them. ------------------------------------------------------------------ */ /* ------------------------------------------------------------------ Status bar ------------------------------------------------------------------ */ /* D4 — DECIDED 2026-08, and the legacy value turned out to be the right one FOR STUDIO: white on brand blue, 3.1:1, because Studio's bar is IDE window chrome that is glanced at rather than read. This alias is therefore no longer a held literal — cordis-studio.css sets --cordis-statusbar-text to white, and Shell keeps the dark blue-950 (5.3:1) for a bar that carries information to be parsed. One token, two profiles, and this shim just follows it. */ --cordis-statusbar-fg: var(--cordis-statusbar-text); /* ------------------------------------------------------------------ Work area surfaces (follow the body theme) ------------------------------------------------------------------ */ --cordis-body-bg: var(--cordis-surface); /* #FFFFFF — exact match in light */ --cordis-panel-bg: var(--cordis-surface); /* #FFFFFF — exact match in light */ /* The workbench chrome surface (explorer / inspector / bottom & terminal pane), promoted to tokens.css as --cordis-surface-chrome (cordis-studio #1889). */ --cordis-sidebar-bg: var(--cordis-surface-chrome); --cordis-panel-header-fg: #6B7280; /* IDE-specific */ /* Renames per MIGRATION.md ("Studio and MachineControlServer"). The legacy literals were #1f2430 / #6b7280 / #e6e8eb; the canonical tokens are the norm and carry the (sub-perceptual) numeric drift. */ --cordis-text-dim: var(--cordis-text-muted); /* The focus ring, aliased so a .cordis-* sheet can hang the suite's one ring on the element the user perceives as the control. Needed because the universal :focus-visible rule in cordis.css can only ring whatever holds DOM focus, and a composite control (CordisFilterBox = bordered