/* * tokens.css — the single :root token set for every Fiery Void page. * * Roadmap item 6 (visual unification), Stage 1. See VISUAL_UNIFICATION_PLAN.md. * * WHY THIS FILE EXISTS * -------------------- * The games.php redesign introduced the --fv-* scheme and proved it works, but it * declared the tokens inside gamesPanel.css and then had to declare a SECOND copy in * ladder.css (creategame.php includes ladder.php without linking gamesPanel.css). Two * copies that "have to be retuned together" is a bug waiting to happen, and a third copy * would have been a trend. Both copies are now gone: this file is the only :root block. * * It is also what makes Stage 4 cheap. Per the plan's audit the palette across the 16 * stylesheets is already ~90% coherent — the visible mismatch between the legacy chrome * and the item-5 SCS ship windows is GEOMETRY and TYPE, not colour. Naming the four * corner radii below means the eventual "square everything" retune is a four-line change * instead of a search-and-replace across 10,000 lines of CSS. * * HOW TO USE IT * ------------- * Linked FIRST on every page, ahead of every other stylesheet, and versioned through * AssetLoader::getAssetUrl() like all the others (Stage 0) — .htaccess caches text/css * for a month, so an unversioned token edit would reach returning players as a half- * retuned screen for up to that long. * * Nothing in here paints anything. It only declares values. Adding a token is cheap; * changing one repaints every page at once, which is the point. * * SYNC CONTRACT WITH theme.js * --------------------------- * client/UI/reactJs/styled/theme.js is the styled-components half of the same palette. * The two are deliberately kept as two files — a build step that generated one from the * other is not worth a new pipeline dependency for ~30 values — and are kept honest by * the cross-reference comments below. If you retune a value here that names a theme.js * key, retune it there too (and vice versa), then `yarn build`. */ :root { /* ── Surfaces ────────────────────────────────────────────────────────────── Panels and window fills, darkest first. --fv-chrome and --fv-chrome-scs are the two competing window bodies item 6 exists to reconcile: the 2011 legacy teal and the item-5 desaturated SCS blue-grey. */ --fv-well: #04161c; /* theme.colors.panelBg */ --fv-card: #0a1c26; --fv-card-hover: #102a36; --fv-panel: rgba(23, 39, 54, 0.92); /* base.css .panel — the site-wide page panel */ --fv-chrome-scs: #152029de; /* theme.colors.windowBg */ --fv-overlay: black; /* map tooltips + shadows */ /* The SAME overlay, see-through as a FILL rather than via element `opacity`. Element opacity fades a surface's TEXT along with its panel, so the hover tooltips were rendering the shared allegiance tints at 65% strength — visibly duller than the same token in the opaque hex picker sitting right beside them. Moving the translucency into the background colour keeps the panel exactly as see-through as it was (65% black over the map, unchanged) while the text returns to full strength. ⚠️ Do NOT combine this with element opacity — see the alpha-compounding note in VISUAL_UNIFICATION_PLAN.md. theme.colors.overlayBgSoft is its twin. */ --fv-overlay-soft: rgba(0, 0, 0, 0.65); /* The LOG PANEL's fill (#logcontainer, LOG_PANEL_REDESIGN_PLAN.md section 1). Same job as --fv-overlay-soft above and added for exactly the same reason: the panel carried `opacity: 0.85` as an ELEMENT opacity, so every log line, fleet row and declaration inside it rendered at 85% strength too. This is --fv-well (#04161c) with the translucency moved into the FILL, so the panel stays as see-through as it was while the text returns to full strength. WARNING: never combine with element opacity - see the alpha-compounding note above. */ --fv-well-soft: rgba(4, 22, 28, 0.86); /* HISTORICAL — the 2011 chrome. Nothing paints with these any more; every surface that did was converged in Stage 4. They are kept, rather than deleted, because they are the documented revert path: putting the old look back means pointing the converted rules at these two (and their theme.js twins, colors.chromeBg / colors.chromeLine) rather than re-deriving the values from git history. Do not reach for them in new code. */ --fv-chrome: #0a3340; --fv-line-chrome: #587e8d; /* ── Lines ───────────────────────────────────────────────────────────────── Three borders for the same job, one per world. Stage 4 converges the chrome surfaces onto --fv-line-scs; --fv-line stays the landing page's own. */ --fv-line: #215a7a; /* the landing page's own border, unchanged */ --fv-line-soft: #1a3f55; --fv-line-scs: #496791; /* theme.colors.line — THE border now */ --fv-line-accent: #8bcaf2; --fv-rule: #1e3a4a; /* the divider under a modal's control bar */ /* ── Text ────────────────────────────────────────────────────────────────── --fv-text-dim is NOT theme.colors.textDim (#7f9bb8): the landing page runs a lighter dim for contrast over its nebula backdrop. Two deliberate values, so don't "fix" either to match the other. */ --fv-text: #deebff; --fv-text-bright: #ffffff; /* theme.colors.text — text on the black overlay */ --fv-text-accent: #C6E2FF; /* theme.colors.textAccent — bluish-white values */ --fv-text-dim: #8ca5c0; --fv-accent: #8bcaf2; --fv-warning: #ffd84d; /* ── Type ────────────────────────────────────────────────────────────────── Body text is Arial everywhere and is not tokenised — gamesNew.css enforces it with `* { font-family: Arial }`, and a universal selector matches every element DIRECTLY, which beats an inherited face regardless of specificity. Anything below has to be applied to the element itself, not to an ancestor. */ --fv-mono: Consolas, "Lucida Console", monospace; /* theme.fonts.mono */ --fv-display: "Orbitron", sans-serif; /* @imported by gamesNew.css */ --fv-hero: "Bruno Ace SC", sans-serif; /* @imported by gamesNew.css */ /* ── Geometry ────────────────────────────────────────────────────────────── THE corner radius is the single most visible tell that a surface belongs to the old world or the new one, so each of the four in play gets a name. Stage 4 retunes these and (mostly) nothing else. Stage 4 has squared the React overlays (--fv-radius-pill, mirroring theme.radii.pill). The two still at their 2011 values are simply not converted yet — the jQuery surfaces that consume them hold literal hex to this day and have to be pointed at the tokens first. */ --fv-radius-chrome: 0px; /* #phaseheader + log tabs — squared, was 8px/5px */ --fv-radius-modal: 0px; /* .confirm — squared, was 5px */ --fv-radius-tooltip: 7px; /* both map tooltips — rounded ON PURPOSE */ /* The state/allegiance rail down the left edge of a row - the .fv-card grammar's signature mark, shared by the log panel's four row types (combat-log entry, fleet row, fleet header, declaration card). One token so the four cannot drift apart. */ --fv-log-rail: 3px; /* ── Top-bar HUD geometry ────────────────────────────────────────────────── The strip along the top of game.php is FOUR boxes that have to read as one row: #phaseheader and #replayUI on the left (tactical.css / replay.css), and the Surrender / FullScreen / PlayerSettings buttons on the right (React, sized from theme.hud). They were three independent height calculations and came out 35 / 35 / 46 (user report 2026-08-04). --fv-hud-bar / --fv-hud-bar-small are the shared OUTER height — border-box, top border dropped on every box because the row is flush into the screen edge — so matching them is now one value rather than three sums. Derived from theme.hud.btn / btnSmall + the 1px bottom border those buttons keep. Retune theme.hud and these follow, not the other way round. --fv-hud-strip is how much of the right-hand edge the button row occupies: 3 boxes + the two 10px gaps between them (see the `right:` arithmetic in Surrender.js / FullScreen.js). #topcontainer subtracts it so the phase header cannot grow underneath the buttons — it is deliberately the width of ALL THREE even though Surrender hides itself outside a live game, because a reservation that changed with the button count would make the bar jump. */ --fv-hud-bar: 36px; /* theme.hud.btn 45px + 1px bottom border */ --fv-hud-bar-small: 25px; /* theme.hud.btnSmall 30px + 1px */ --fv-hud-strip: 155px; /* (45 x 3) + (10 x 2) */ --fv-hud-strip-small: 110px; /* (30 x 3) + (10 x 2) */ /* STANDING EXCEPTION — do NOT square this one when the chrome converges. The initiative panel (#iniGui) and its pull-tab (#backDiv) are a DRAWER and its HANDLE, anchored to the left screen edge: the rounding is only on the right-hand corners, and that curve is what makes them read as sliding out rather than as docked chrome. User decision 2026-07-30. It is deliberately its own token so a future retune of --fv-radius-chrome cannot sweep it up by accident. */ --fv-radius-drawer: 10px; /* #iniGui + #backDiv, right-hand corners */ /* ── Scrollbars ──────────────────────────────────────────────────────────── The "site-standard scrollbar" is currently copy-pasted six times with four different thumb colours. These are the games.php/ladder pair — the SCS-facing ones — and are what the other copies converge on when they are rewired. Rewiring is a visible change, so it belongs to Stage 4, not here. */ --fv-scroll-track: #0c151a; --fv-scroll-thumb: #2a4a66; --fv-scroll-thumb-hover: #3a6a96; /* ── Status ──────────────────────────────────────────────────────────────── Signals, not chrome: these carry meaning and must survive any reskin intact. The first three already agree across both stacks. */ --fv-ok: #427231; /* theme.colors.healthOk */ --fv-warn: #e1b000; /* theme.colors.warning */ --fv-crit: #ed6738; /* theme.colors.healthCrit */ --fv-custom: #cccc00; /* ── Allegiance ──────────────────────────────────────────────────────────── Whose unit is this? Signals, not chrome — same category as Status above, and they must survive any reskin intact. SEVERAL renderings per allegiance, which is the whole point of the set. The -signal twin is the full-chroma value and belongs ONLY on small marks: a 3px bar, a rule, a dot. A strong colour reads as a signal precisely because there is so little of it. The plain value is tone-mapped — same hue, lower chroma, lightness normalised to roughly 0.65 — so all four allegiances sit at the same perceived brightness instead of red shouting and blue sinking. See the tier table below for which one a given surface should take. Introduced by the hex picker (SELECT_FROM_SHIPS_PLAN.md §2.5, Stage 6), which is where the reasoning is written up. gamedata.getMutedTeamColorRGB() is the runtime equivalent for arbitrary per-team colours in 3+-team games and observer views — it lands them in this same brightness band. FOUR TIERS as of 2026-08-20, not two. Pick by how much of the colour there is and how dense its surroundings, NOT by what kind of element it is: -bright raw palette one large heading standing alone — the ShipTooltip ship name, the fleetList TEAM label, the combat log -mid 55% toward raw allegiance text inside a DENSE list — the hex picker's rows, the ShipTooltip stack grid (plain) tone-mapped supporting/secondary text, and any surface where allegiance is context rather than the point -signal full chroma small marks ONLY: a 3px bar, a rule, a dot Every tier has a runtime twin for arbitrary team numbers, so the observer and 3+-team arms can follow the same tier the CSS classes do: getTeamColorRGB (bright), getMidTeamColorRGB (mid), getMutedTeamColorRGB (plain). NO theme.js TWINS: nothing in the React stack paints allegiance yet. If that changes, add them there and re-declare the sync contract above. ⚠️ THE TRAP THIS SET KEEPS SPRINGING — a rule here paints ONE ARM of a two-arm gate. Every allegiance surface splits: 2-team participants take these CSS classes, while observers and 3+-team participants take an inline colour from JS. Retuning a token therefore changes what a 2-player game looks like and leaves a 4-player game exactly as it was. That is precisely how the ShipTooltip ended up bright for observers and pastel for participants between 2026-08-14 and 2026-08-20. Before changing any value below, find the JS twin (gamedata.js and the getTeamColorVars / getNameStyle pair) and move it to the matching tier in the same commit. gamedata.getShipLogColorCss (the combat log) holds its own bright literals rather than referencing --fv-*-bright, because it builds a canvas/inline colour string and cannot read a custom property. Same values, different delivery — keep in step. */ /* Text tints — equal perceived lightness, for NAMES and labels on a dark ground. */ --fv-own: #7dbf88; --fv-ally: #79aed4; --fv-enemy: #ea6a5e; --fv-neutral: #b4c2cf; /* Full-chroma twins — for BARS, rules and other small marks only. */ --fv-own-signal: #52b352; --fv-ally-signal: #33adff; --fv-enemy-signal: #e0483f; --fv-neutral-signal: #8ca5c0; /* BRIGHT tier — the raw team palette (gamedata.teamBaseColors 1-3) as tokens, for the surfaces that carry allegiance as their PRIMARY signal on a large, uncrowded piece of text: the hover ShipTooltip's ship name and the fleetList's TEAM header. Added 2026-08-20 on user request — those two read as washed out beside the combat log, which had kept the full-strength values all along, and the ShipTooltip in particular CONTRADICTED ITSELF: 2-team participants got the muted tints while observers and 3+-team participants got the raw palette inline off getTeamColorRGB. These tokens are that raw palette, so both arms of the gate now land on the same brightness. ⚠️ MUST stay byte-equal to gamedata.teamBaseColors[0..2] — the JS side hands the same colours in as inline rgb() on the observer / 3+-team arm, and a drift shows up as a 2-team game and a 4-team game disagreeing about what "green" is. */ --fv-own-bright: #32cd32; --fv-ally-bright: #33adff; --fv-enemy-bright: #ff5050; /* MID tier — deliberately between the two above, for allegiance text that sits in a DENSE list rather than alone: the SelectFromShips picker's row names and the ShipTooltip stack-grid cells (the picker opens that tooltip beside itself, so those two must move together — see shipTooltip.css). At full chroma a column of twenty rows stops reading as a list and starts reading as a warning; muted, it disappeared. Each value is a 55% sRGB blend from the tone-mapped tint toward its -bright twin, which is exactly what gamedata.getMidTeamColorRGB does at runtime for arbitrary team colours. Terrain has no bright counterpart and stays on --fv-neutral in this tier. */ --fv-own-mid: #54c759; --fv-ally-mid: #53adec; --fv-enemy-mid: #f65c56; /* Landing-page game states. --fv-mine is --fv-lobby's green under a second name: "you are in this one" is a different statement from "this is a lobby", and naming them apart means either can be retuned without disturbing the other. --fv-mine-soft is a pastel of it for TEXT — #52b352 on the card fill is about 3.4:1, the pastel is ~9:1. --fv-ended is muted rather than a signal red: an ended game is over, not a problem. */ --fv-turn: #84a5ce; --fv-turn-bg: #254d82d0; --fv-lobby: #52b352; --fv-ladder: #e6ac00; --fv-fleet: #0d7ea3; --fv-done: #2f4a52; --fv-idle: #3a5a72; --fv-mine: #52b352; --fv-mine-soft: #7ed576; --fv-ended: #b76662; }