/* GENERATED FILE - do not edit by hand. Compiled from resources/scss/themes/hearth.scss by `npm run css`. Edit that source, then rebuild and commit both. */ /* Hearth. The site's only palette today, and the one `App\Site\Theme\Themes` registers as the default. Everything here is a custom property on purpose: a theme has to be swappable at runtime by flipping one attribute on , which a Sass variable cannot do because it is gone before the browser sees the file. Nothing in this tree may resolve a theme colour at compile time. A theme is a palette crossed with a mode, so the selector carries both axes: `html[data-theme="hearth"][data-mode="dark"]`. `_contract.scss` beside this file lists every name a palette owes the site. This file is an entry point rather than a partial, so the directory compile in `npm run css` picks it up on its own. That is what makes a second palette one new file beside this one plus one line in the registry: nothing has to be told the file exists. `_contract.scss` keeps its underscore because it is a checklist with no output of its own. */ /* The hearth palette, ported from the golden mockup (docs/mockups/release-refresh/src/hearth.css). Amber signal on a warm near black, four ink rungs, two rule steps, and the four tier hues the release rail and the table kit colour rows with. Every ink rung and the signal clear 4.5:1 against all three of their own theme's surfaces, which PaletteContrastTest enforces rather than describes. Three of the mockup's values did not and were moved for it, measured here rather than assumed: dark ink-4 #7f7568 read 3.82:1 on --raise and is #8d8376; light ink-4 #6e6559 read 4.33:1 on --raise and is #6a6155; and the light signal is the reason this palette needs two ambers at all. Hearth's #f2a93b is a fill colour on a light page (2.2:1 on --bg), so light --sig is #8f5200, which clears 4.70:1 on the raised surface, while --t-use keeps the brighter amber for the tier dots and bars that are never text. The add/del pair is not hearth's; it is this site's own and stays, because a diff is the one thing a reader arrives already knowing how to read and both hues are contrast-checked on all three surfaces of their theme. */ html[data-theme=hearth][data-mode=dark] { --sig:#f2a93b; --sig-dim:rgba(242,169,59,.32); --sig-ghost:rgba(242,169,59,.10); --bg:#121010; --bg-2:#171413; --raise:#1e1a18; --raise-2:#26211e; --ink:#f3ebdd; --ink-2:#b8ad9c; --ink-3:#9d9283; --ink-4:#8d8376; --rule:#26211e; --rule-2:#35302b; --add:#63c98a; --add-dim:rgba(99,201,138,.30); --add-ghost:rgba(99,201,138,.11); --del:#f2637e; --del-dim:rgba(242,99,126,.30); --del-ghost:rgba(242,99,126,.11); --t-use:#f2a93b; --t-notice:#e0725a; --t-soon:#9a8cff; --t-internal:#5f5850; --notable:#ffcb6b; --off:#a79cff; --d-agents:#7fc8ff; --d-perms:#ff8a7a; --d-settings:#d2b8ff; --d-tools:#8fd39a; --d-extend:#5fd3c4; --d-ui:#f4a3d1; --d-platform:#a9a39a; --d-other:#7f7568; /* What reads on a solid --sig fill: the feedback chips, the send button and the section-feedback button all set the signal as a background and then need an ink for it. It was #0a0a0b written three times in cc-detail.css and it is a theme's decision, not the component's, because a palette whose signal is pale needs light text there and cannot say so from over here. 9.91:1 on this mode's --sig. */ --sig-ink:#0a0a0b; /* The thumbs controls. Both are used as `color:` and nothing else, so both carry the ink floor: --ok 9.13 / 8.82 / 8.31 and --no 6.23 / 6.02 / 5.67 on --bg / --bg-2 / --raise. `-ghost` and `-dim` are the same hue at .10 and .14 for the rest and hover washes behind them; they were written as rgba() literals in cc-detail.css, which is how a themed control ended up with an unthemed background. */ --ok:#7ac74f; --ok-dim:rgba(122,199,79,.14); --ok-ghost:rgba(122,199,79,.10); --no:#ff5b5b; --no-dim:rgba(255,91,91,.14); --no-ghost:rgba(255,91,91,.10); color-scheme: dark; } html[data-theme=hearth][data-mode=light] { --sig:#8f5200; --sig-dim:rgba(143,82,0,.30); --sig-ghost:rgba(143,82,0,.09); --bg:#f6efe2; --bg-2:#f0e7d7; --raise:#e8dfcd; --raise-2:#dfd5c1; --ink:#1b1611; --ink-2:#4f463c; --ink-3:#5f564b; --ink-4:#6a6155; --rule:#ddd3c1; --rule-2:#c9bda6; --add:#11713f; --add-dim:rgba(17,113,63,.26); --add-ghost:rgba(17,113,63,.09); --del:#b8213f; --del-dim:rgba(184,33,63,.24); --del-ghost:rgba(184,33,63,.08); --t-use:#b86b00; --t-notice:#b0432a; --t-soon:#4b3fc4; --t-internal:#8d8478; --notable:#9a5b00; --off:#4b3fc4; --d-agents:#0f6fb5; --d-perms:#b8321f; --d-settings:#5b3fb8; --d-tools:#1f7a3a; --d-extend:#0f7d70; --d-ui:#b03a80; --d-platform:#5d574f; --d-other:#6e6559; /* Deliberately the same #0a0a0b this mode already shipped, so extracting the token changes no pixel. It is 3.18:1 on light --sig #8f5200, which is under the 4.5:1 floor every other pair here clears, and it has been since the light theme was written. Left alone on purpose: fixing it moves a rendered colour, which is out of this wave's scope, and the honest fix is not obvious (#fff reads 6.22:1 and inverts the button, a darker --sig costs the signal its amber). Recorded here rather than quietly corrected, and it is why --sig-ink is a token at all: once it is one, a palette can fix it without touching a component. */ --sig-ink:#0a0a0b; /* Not the light --add/--del pair. A vote is not a diff and a reader should not read one as the other, so these are their own yellower green and redder red, the same relationship the dark mode already had. Measured on --bg / --bg-2 / --raise: --ok #2a6b1f 5.70 / 5.31 / 4.93, --no #b3261e 5.72 / 5.33 / 4.94. The dark mode's light equivalents were rgba() literals in cc-detail.css, so this mode never had a correct wash at all: the controls painted a dark-mode green behind light-mode text. */ --ok:#2a6b1f; --ok-dim:rgba(42,107,31,.14); --ok-ghost:rgba(42,107,31,.10); --no:#b3261e; --no-dim:rgba(179,38,30,.14); --no-ghost:rgba(179,38,30,.10); color-scheme: light; } /* ── the series palette ─────────────────────────────────────────────── */ /* Nine hues, in stack order, read by both halves of the page: `.s0`..`.s8` below and cc-charts.js through getComputedStyle. The signal leads, the add/del pair keep their own meaning, and the last is deliberately the quietest because it is where every tail band lands. The light set is not the dark set: each hue is darkened until it carries a readable edge stroke and a legend swatch against the light page's paper, the same correction cc.css records for its ink rungs. */ /* These moved here from analytics.css, where they were the one other rule in the tree keyed on `html[data-theme]`. They are a palette, so a second palette has to be able to restyle the charts, and leaving them behind would have left one sheet re-keying itself every time a theme was added. `.s0`.. `.s8` stay in analytics.css and still read them through var(); this file is linked on every page, so the root read cc-charts.js does still resolves. */ html[data-theme=hearth][data-mode=dark] { --c0:#ff5b2e; --c1:#e2a03f; --c2:#63c98a; --c3:#4fa3d1; --c4:#b58ce0; --c5:#f2637e; --c6:#cfc39a; --c7:#79a08c; --c8:#8b857c; } html[data-theme=hearth][data-mode=light] { --c0:#b83204; --c1:#8a5c0c; --c2:#11713f; --c3:#1b5b85; --c4:#5f3a92; --c5:#b8213f; --c6:#6f6134; --c7:#356050; --c8:#67624f; }