/* RBMG Core v0.4.1-draft — stylesheet
* GENERATED by tools/build-dist.py. Do not edit this file: an edit here
* is invisible to every check the core ships, and is a defect rather than
* a fork. Change the source and rebuild.
*
* Load order (the three-layer rule, and nothing else to remember):
* core → brand → site
*
* Concatenated, in this order:
* core.layers.css
* core.tokens.css
* core.foundation.css
* core.typography.css
* core.surfaces.css
* core.components.css
* core.forms.css
* core.overlays.css
*/
/* ---------- core.layers.css ---------- */
/* ==========================================================================
RBMG Core — layer order
css/core.layers.css · v0.2.0-draft
THIS FILE MUST LOAD FIRST. Nothing else.
Why it exists as a separate file: CSS registers a layer's position at
the point its NAME is first seen. The order statement was originally
inside core.foundation.css, which works only if foundation happens to
load before the token sheet — otherwise `tokens` gets registered ahead
of `reset` and the whole cascade inverts, silently. Splitting the
declaration out makes the correct order independent of file order, so
the failure is no longer possible to cause by reordering tags.
Everything downstream depends on this one line:
· utilities beat components by cascade POSITION, which is what
retires `!important` across the shop
· a brand sheet cannot outrank a component's structure, because it
only ever writes into `tokens`
THE SIXTH LAYER — `a11y`, added v0.4.1 (Pilot 04, E-106).
`site.css` loads into `utilities` and loads LAST, so until now there was no
position from which a core guarantee could outrank site composition without
`!important`, which this project bans. That made "accessibility is a core
property, not a per-project install" true of everything the core DRAWS and
false of anything a site adds.
E-106 is what that costs. The reduced-motion block was headed "one place,
covering every component above" and was an enumerated list of eight
selectors in one file — so a site composing a transition shipped it to a
user who asked for no motion, and nothing anywhere said so. It is the
TAP_RULES shape: the blind spot is the list, not the thing it forgot. (It
also missed nine CORE rules in three other files, which is how far a list
drifts from its own heading in three versions.)
`a11y` is the one place a core guarantee is allowed to win, and the bar for
putting something in it is deliberately high: it must be a WCAG obligation
the USER has expressed, not a preference the core holds. Reduced motion is
the only thing in it. A colour, a size or a spacing decision does NOT belong
here — those are the site's to compose, and a layer that grew past its one
purpose would just be `!important` with better manners.
========================================================================== */
@layer reset, tokens, base, components, utilities, a11y;
/* ---------- core.tokens.css ---------- */
/* ==========================================================================
RBMG Core — tokens layer (Tier 0B semantic roles)
core.tokens.css · v0.2.0-draft · 2026-08-07
THE CONTRACT
--------------------------------------------------------------------------
Components read ONLY the roles in this file. A component never references
a Tier 0A brand primitive; a brand sheet never defines a new role; a site
sheet touches neither. (Precedence: CORE > BRAND > SITE — see
rbmg-phase0-tier-map.md, "Precedence" block.)
A brand sheet's entire job is answering this file's role list.
Roles are marked one of three ways:
[REQUIRED] No core default exists. The brand sheet MUST answer it.
A role the Figma file doesn't answer is a blocking question
for the designer — never an invented value, never a snap to
a neighboring hex.
[DEFAULT] A core default ships below. A brand may override it; a brand
taking the default LISTS it in the role-satisfaction
confirmation ("--surface: core default, white page ground")
rather than re-declaring it.
[DERIVED] Computed by the core. NEVER authored in a brand sheet — an
authored -hover is a lint error. This is what makes the
stale-hover failure found in the audit inexpressible.
LOAD ORDER
--------------------------------------------------------------------------
@layer reset, tokens, base, components, utilities, a11y;
core.tokens.css loads first inside `tokens`, brand.css second (same
layer) — the brand's :root re-declarations win by source order, and no
file outside the tokens layer may declare a token.
========================================================================== */
@layer tokens {
:root {
/* ----------------------------------------------------------------------
BRAND ACTION COLORS
The brand sheet points these at Tier 0A primitives:
--brand-primary [REQUIRED] the lead action/identity color
--brand-secondary [REQUIRED] the supporting brand color
--brand-accent [DEFAULT] the highlight/CTA-contrast color
primary and secondary have no usable default, so none is shipped;
they are declared here as documentation only.
--brand-accent IS defaulted, as of v0.3.0 (Pilot 01, F-013). It was
[REQUIRED], on the reasoning that no default is usable — but the
first real brand had exactly TWO action hues. No third colour
appeared anywhere in a 10,596px comp, and none in its Figma
variables. The role is not decorative (it feeds the icon roles,
.btn-accent, .bg-accent and the gated --on-accent), so leaving it
unanswered left those UNRESOLVED, and a two-hue brand was forced to
either alias a hue it already had or invent one.
The wrong version this prevents is the one that actually happens on
a deadline: somebody picks a plausible third hue no designer chose,
and it ships as brand. Falling back to --brand-primary keeps the
"no hex-named one-off" guarantee — the variant list is still
generated from roles — while letting a two-hue brand answer
honestly by answering nothing.
---------------------------------------------------------------------- */
--brand-accent: var(--brand-primary);
/* ----------------------------------------------------------------------
CONTRAST DIRECTION — [DERIVED] · the primitive everything else uses
v0.2.0
`--contrast-toward` resolves to white on a dark fill and black on a
light fill, computed from the fill's OWN lightness via relative
color syntax. Every publisher re-declares it from its own fill (see
core.surfaces.css), so "which way is more contrast?" is answered by
measured luminance rather than by selector-list membership.
Pilot 01 is why this exists. Direction used to be hardcoded —
`.bg-surface` lived in the "light" list and always darkened. On a
dark-ground brand that made every hover LESS legible
(--link 16.30:1 → --link-hover 10.15:1) while still clearing 4.5:1,
so no threshold gate could see it. A threshold cannot detect a
guarantee being violated; direction has to be computed, not listed.
IT DECIDES ON MEASURED LUMINANCE NOW, NOT ON A PROXY FOR IT —
v0.4.1, Pilot 04 (E-035). See --contrast-pick below, which is the whole
mechanism and the whole story.
---------------------------------------------------------------------- */
--contrast-toward: color(from var(--surface) srgb-linear var(--contrast-pick) var(--contrast-pick) var(--contrast-pick));
/* ----------------------------------------------------------------------
--contrast-pick — [DERIVED] · THE AUTO-CONTRAST SWITCH ITSELF
v0.4.1, Pilot 04 (E-035). Never authored, never overridden; it is not a
colour and a brand has no opinion about it.
This is not a value. It is the EXPRESSION every auto-contrast
derivation in the core substitutes into a relative colour function:
color(from srgb-linear
var(--contrast-pick) var(--contrast-pick) var(--contrast-pick))
In srgb-linear, `r`, `g` and `b` are the fill's LINEAR-LIGHT channels,
so 0.2126r + 0.7152g + 0.0722b IS the WCAG relative luminance — exactly,
with no gamma maths and no pow(). White is (1 1 1) in that space and
black is (0 0 0), so driving all three channels with one 0-or-1 switch
yields one or the other. The switch is 1 while luminance is below the
point where white and black TIE:
Y_tie = √0.0525 − 0.05 = 0.17913, where both measure 4.58:1
WHAT THIS REPLACES, AND WHY THE REPLACEMENT IS A DIFFERENT KIND OF
CLAIM. Every derivation used to read
`oklch(from clamp(0, (l / 0.623 - 1) * -infinity, 1) 0 0)`:
OKLCH lightness compared against the OKLCH perceptual midpoint. Two
separate errors compounded there.
The pivot was the wrong number. L = Y^⅓ for a neutral, so the tie sits
at L = 0.5637 and everything in [0.5637, 0.623] got the label that
measures WORSE — bottoming out at 3.60:1, an AA failure chosen
automatically by the mechanism whose whole job is to make an illegible
label inexpressible. Pilot 04's AC blue sits at L = 0.607, dead centre:
white 3.83:1 where black would have been 5.49:1, and the brand darkened
its own hue to work around it. Plain #808080 got white at 3.95:1.
And OKLCH LIGHTNESS IS NOT LUMINANCE. Chroma shifts L away from Y^⅓ by
up to ~0.05, so no pivot on L can be right everywhere. Swept over the
whole sRGB gamut (140,608 fills), the best possible pivot is ≈0.575 and
it still leaves 2,800 fills with a sub-4.5:1 label, worst case 4.07:1 on
a saturated violet. The tie point 0.5637 leaves 3,459. The shipped 0.623
left 11,668, worst case 3.40:1. THE FIRST VERSION OF THIS FIX MOVED THE
PIVOT TO 0.5637 AND THE GAMUT SWEEP CAUGHT IT AT 3.93:1 — a better
constant, still a proxy, still wrong on 2% of the gamut.
Measuring the thing itself removes the class: a label derived this way
cannot measure below 4.58:1 for ANY fill in the gamut, and the sweep in
roles.test.mjs asserts exactly that rather than reporting how bad it is.
ONE PLACE, BY CONSTRUCTION. The old form repeated its constant 22 times
and the only defence was a test that they all agreed. Here the constant
exists once and every derivation reads it, so drift is not a thing that
can happen.
BROWSER FLOOR IS UNCHANGED, and it is MEASURED rather than assumed.
Relative colour syntax was already a hard requirement — every derivation
in this file used `oklch(from …)` — and `srgb-linear` in color() predates
it in all three engines. `npm run gate:browsers` resolves this expression
in Chrome, WebKit and Firefox against ten fills chosen to cover every way
the decision can be made, and asserts the PAINTED label plus its measured
ratio. All three agree, identically, on all ten.
That gate is separate from gate:rendered on purpose. Geometry is a
question one engine can stand in for; colour-syntax support is per-engine
by definition, and this expression is the one thing in the core with no
fallback — an engine that cannot parse it makes the declaration invalid
at computed-value time, and a button label INHERITS THE PAGE INK. Run it
whenever this expression changes.
---------------------------------------------------------------------- */
--contrast-pick: clamp(0, (0.17913 - (0.2126 * r + 0.7152 * g + 0.0722 * b)) * infinity, 1);
/* ----------------------------------------------------------------------
HOVER TINTS — [DERIVED]
A hover state must always move AWAY from its own surface. Mixing
toward --contrast-toward does that at either polarity; the legacy
"+20% white" rule only did it on light grounds.
The original derivation was verified byte-exact against every
authored hover pair in the 2026-08 audit — but that estate was
entirely light-ground, so "mix with white" and "mix away from the
surface" were indistinguishable in the evidence. Pilot 01
separated them. Recorded because the same conflation is likely
elsewhere: see the gradient premise in the pilot report.
---------------------------------------------------------------------- */
--brand-primary-hover: color-mix(in srgb, var(--brand-primary), var(--contrast-toward) 20%);
--brand-secondary-hover: color-mix(in srgb, var(--brand-secondary), var(--contrast-toward) 20%);
--brand-accent-hover: color-mix(in srgb, var(--brand-accent), var(--contrast-toward) 20%);
/* ----------------------------------------------------------------------
SURFACES — [DEFAULT]
The publisher side of the surface-aware system. Every surface utility
in the core publishes --link/--link-hover/--icon-accent values legible
against itself; these are the page-level defaults.
---------------------------------------------------------------------- */
--surface: #ffffff;
--surface-hover: color-mix(in srgb, var(--surface), black 6%); /* the #f0f0f0 pattern, derived */
--surface-raised: #ffffff; /* + --shadow-sm; distinct role so a brand can tint cards */
--surface-sunken: #eef0f5; /* wells, alternating bands */
--surface-inverse: #121212; /* dark bands; brands usually point this at a deep brand hue */
/* THE SECOND SUNKEN STEP — [DEFAULT], v0.4.1, Pilot 04 (E-114).
The surface vocabulary was surface / raised / sunken / inverse: exactly
ONE step below the page ground. Pilot 04's comp paints two greys —
#EEF0F5 in three sections and #E5E7EA in two more, the pair that brackets
the page's lower half — and the second one had no role to land on.
There is no site-tier workaround and that is the whole ticket: a brand
may answer roles and may not define one, a site may not reference a
Tier 0A primitive, and scoping --surface-sunken on a section needs a
value that could only be a hex. The build shipped both bands on
--surface-sunken as a stated deviation.
DERIVED, not typed, and mixed toward the page ground's OWN contrast
direction so it darkens on a light brand and lightens on a dark one. 4%
is the number the comp validates rather than a taste: #EEF0F5 mixed 4%
toward black is #E4E6EB against the comp's #E5E7EA — one bit per
channel. Derive it, then check it lands on the value someone already
picked by eye, which is how the hover tints and the border ramp were
each settled.
It publishes like any other surface (.bg-surface-sunken-strong is in the
neutral publisher list) and it has gate rows, because a surface with no
gate row is the TAP_RULES shape — a list that measured seven selectors
and said nothing whatever about the eighth.
The direction is derived from --surface INLINE rather than by reading
var(--contrast-toward), and that is deliberate twice over. "Sunken" is
a relationship to the PAGE GROUND, not to whatever band you happen to be
inside, so reading a published --contrast-toward would make the role mean
different things in different places. And a :root role whose value
mentions --contrast-toward is one every publisher must re-declare — the
rule roles.test.mjs enforces — which would be true of a link colour and
is nonsense for a surface. */
--surface-sunken-strong:
color-mix(in srgb, var(--surface-sunken),
color(from var(--surface) srgb-linear var(--contrast-pick) var(--contrast-pick) var(--contrast-pick)) 4%);
--on-surface: #121212;
--on-inverse: #ffffff;
/* MUTED INK — [DERIVED from the surface it is gated against], v0.4.0.
These were two hardcoded values, and --on-inverse-muted was
rgba(255,255,255,.8): a role meaning "muted text on the inverse
surface" whose default ASSUMED that surface is dark. On a light inverse
island it measures 1.26:1 composited — invisible — which is the
--on-inverse failure exactly, in the role sitting next to it.
BOTH REFERENCE BRANDS MASKED IT by answering the role, which is the same
masking that hid the original. Pilot 02 hit it, said so in a comment
("invisible on a #DCDFE7 card"), overrode it with a ramp stop, and that
stop measured 4.09:1 — so the workaround failed too, and nothing caught
either one until the muted rows landed.
Deriving from the ink and mixing 35% toward the surface makes it correct
at any polarity by construction. THE CHAIN IS SAFE, and it is worth
being explicit about why, because the house rule forbids chaining a
gated [DEFAULT] to a role a brand overrides: --on-inverse-muted is gated
against --surface-inverse, and it derives from --on-inverse, which is
gated against that same surface. A brand that answers the parent
correctly gets a correct child; a brand that answers it wrongly fails on
the parent's own gate row first. Same shape as --on-btn-* following its
seam rather than the base role.
30%, NOT 35% — v0.4.1, Pilot 04 (E-036). 35% was measured against a
near-black ink (#121212 → 5.83:1 on white, next to the 5.57:1 of the
#656870 it replaced: derive it, then check it lands on the value someone
already picked by eye). It does not survive a CHROMATIC ink. Pilot 04's
page ink is a navy #0F2848, so the default resolves to #637388 and
measures 4.84:1 on white and 4.25:1 on the sunken band — a FAIL, and
Pilot 02's real brand measured 4.30:1 on the same row. Two of two real
brands, while both references passed.
The core has already learned that retuning a muted constant "only moves
which brand fails", so this was measured before it moved — four brands
(both references, Pilot 02's, Pilot 04's) × four neutral grounds, with
each brand's own answer stripped so the DEFAULT is what is under test:
toward --surface 35% (was) Pilot 04 sunken 4.25 FAIL
toward --surface-sunken 35% Ironwood raised 4.45 FAIL — a NEW one
toward --surface 30% nothing fails
The middle row is the intuitive fix and it is wrong, which is the second
polarity earning its keep before a line was written: on a dark-ground
brand the RAISED surface is lighter than the page ground, so fading the
ink toward the sunken band moves it the wrong way.
What forces the decision rather than leaving it a brand's problem is
--surface-sunken-strong above: adding a fourth neutral ground makes the
35% default fail on two brands instead of one. Blast radius is zero —
all four brands answer --on-surface-muted themselves, so this governs
only brands not yet written. */
--on-surface-muted: color-mix(in srgb, var(--on-surface), var(--surface) 30%);
--on-inverse-muted: color-mix(in srgb, var(--on-inverse), var(--surface-inverse) 30%);
/* ----------------------------------------------------------------------
ON-COLORS — [DEFAULT, contrast-gated] · COMPUTED, not chained
v0.2.0 — CHANGED. These used to default to `var(--on-inverse)`.
That was the single root cause of Pilot 01's colour failures.
`--on-inverse` means "text on the inverse surface." A dark-ground
brand must set it DARK, because its inverse surface is the page's
one light island. One correct edit to one surface role then
silently broke three unrelated roles:
--on-primary 6.05:1 → 2.69:1
--on-secondary 10.62:1 → 1.53:1
--on-accent 6.05:1 → 2.69:1
All six declared gates still reported PASS.
THE RULE THIS ESTABLISHES: never var()-chain a gated [DEFAULT] to
another role a brand is expected to override. A gated role must
resolve from the thing it is gated AGAINST — so each on-colour is
now computed from its own brand hue's lightness and is correct at
any polarity by construction. Verified by pixel sampling: white on
#C02021 (16.3:1), black on #F2A54A (10.3:1), black on #2BC4A8
(8.4:1) — all chosen automatically.
A brand may still override with a literal (e.g. an off-white that
matches its palette); the gate then checks the literal.
---------------------------------------------------------------------- */
--on-primary: color(from var(--brand-primary) srgb-linear var(--contrast-pick) var(--contrast-pick) var(--contrast-pick));
--on-secondary: color(from var(--brand-secondary) srgb-linear var(--contrast-pick) var(--contrast-pick) var(--contrast-pick));
--on-accent: color(from var(--brand-accent) srgb-linear var(--contrast-pick) var(--contrast-pick) var(--contrast-pick));
/* ----------------------------------------------------------------------
BUTTON FILL SEAMS — [DEFAULT] value-only, component-scoped
v0.3.0 — NEW (Pilot 01, F-010).
--brand-secondary is documented as the deep hue behind BANDS and
also generates .btn-secondary. The pilot's brand gave those jobs
different values (#2E414C for bands, #5E6B78 for the button), so
answering the role correctly for one made the other wrong — and the
build shipped with no secondary button rather than a wrong one.
A brand using one value for both answers nothing here. One that
splits them answers a line. The variant list is still generated
from roles, so the "no hex-named one-off" guarantee is intact.
The LABELS are [DERIVED] from the seam, not from the base role. If
they chained to --on-primary, a brand overriding the fill would keep
the base hue's label — which is the stale-hover failure that
commissioned this project, and the var()-chain rule from v0.2.0,
arriving together. Deriving from the seam means answering the fill
is enough; the label follows and the gate measures the pair.
Scope note: these are BRAND-tier (:root) seams, so deriving the
labels at :root is correct. Compare --on-gradient, which is
re-declared by its surface publisher because gradients are selected
PER SECTION — a derived role resolves on the element that declares
it, so anything a descendant can rebind must be re-derived where it
is rebound.
---------------------------------------------------------------------- */
--on-btn-primary: color(from var(--btn-primary, var(--brand-primary)) srgb-linear var(--contrast-pick) var(--contrast-pick) var(--contrast-pick));
--on-btn-secondary: color(from var(--btn-secondary, var(--brand-secondary)) srgb-linear var(--contrast-pick) var(--contrast-pick) var(--contrast-pick));
--on-btn-accent: color(from var(--btn-accent, var(--brand-accent)) srgb-linear var(--contrast-pick) var(--contrast-pick) var(--contrast-pick));
/* ----------------------------------------------------------------------
THE FILLED ACTIVE TAB — v0.4.0, Pilot 03.
`rbmg-tabs[active="fill"]`, the seam and its derived label.
--tab-active says "active" with a COLOUR: one role drives the label
and the 3px indicator together, deliberately, so answering it cannot
leave a stale indicator behind. Pilot 03's comp says "active" with a
SURFACE — a filled pill lifted off a brand band, carrying an icon and
a label in a second hue. That is not a value --tab-active can answer,
because it is not a colour change: it is a fill, and a fill needs a
PAIR.
This is the .btn lesson arriving at a component that had learned only
half of it. A single role painting a fill AND its label is the
.btn-outline-inverse failure written down — `currentColor` on its own
background, 1.00:1, invisible. So the fill is a seam and the label is
[DERIVED] FROM THE SEAM, never from --tab-active:
--tab-active is the colour treatment (undeclared seam)
--tab-active-fill is the surface treatment (undeclared seam)
They are independent on purpose. A brand answering one says nothing
about the other, and a site choosing `active="fill"` gets a label that
already tracks whatever fill it lands on.
WHY --surface IS THE FALLBACK, not a brand hue. Publishers re-declare
--contrast-toward, --link, --icon-accent and --border from their own
fill; they do NOT re-declare --surface. So inside a .bg-primary band
var(--surface) still resolves to the PAGE GROUND — which is exactly
what a filled active tab means: the tab lifts out of the band to the
page's own surface. It reads correctly at either polarity for free,
and a brand that wants a different pill answers the seam.
The seam stays UNDECLARED with its fallback at the point of use. A
[DEFAULT] declared here and chained to a role a brand overrides is the
--on-inverse failure, and this file is not going to commit it twice.
---------------------------------------------------------------------- */
--on-tab-active-fill: color(from var(--tab-active-fill, var(--surface)) srgb-linear var(--contrast-pick) var(--contrast-pick) var(--contrast-pick));
/* ----------------------------------------------------------------------
LINK & ICON — the surface-aware system
v0.2.0 — RENAMED. `-on-light` / `-on-dark` became
`-on-surface` / `-on-inverse`.
The old names encoded a brand's BRIGHTNESS into the role name. On a
dark-ground brand a correct brand sheet had to read
`--link-on-light: white`, which reads like a bug and invites the
next person to "fix" it straight back into a white-on-white
failure. A role should name WHICH SURFACE it sits on — invariant —
not how bright that surface happens to be.
Old names still resolve as a fallback; they are deprecated and the
linter should flag them.
--link / --link-hover / --icon-accent are PUBLISHED CONTEXT VALUES:
set only by surface publishers (core.surfaces.css), read by
consumers, never authored by a brand or site sheet.
---------------------------------------------------------------------- */
--link-on-surface: var(--link-on-light, var(--brand-primary));
--link-on-inverse: var(--link-on-dark, var(--on-inverse));
--icon-on-surface: var(--icon-on-light, var(--brand-accent));
--icon-on-inverse: var(--icon-on-dark, var(--on-inverse));
/* --muted is the PUBLISHED muted-text value, and it is the same split
--link already uses: the brand answers --on-surface-muted (what muted
copy looks like on the page ground), and every surface publisher
re-declares --muted from its OWN fill.
v0.4.0 — NEW (Pilot 02, tickets 19 and 25). --on-surface-muted was
consumed directly by .text-muted, the placeholder, the drawer/tab
secondary text and .breadcrumb-item.active, so on .bg-primary,
.bg-secondary, .bg-accent and any gradient it resolved to the PAGE
GROUND's muted grey and was inherited already-resolved. Nothing
republished it, exactly as nothing republished --on-gradient and then
--focus-ring. Third time for the same shape, in a third role.
Consumers read --muted. A brand still answers --on-surface-muted and
nothing changes for it. */
--muted: var(--on-surface-muted);
/* root-level published defaults (double as the page-ground fallback): */
--link: var(--link-on-surface);
--link-hover: color-mix(in srgb, var(--link-on-surface), var(--contrast-toward) 20%);
--icon-accent: var(--icon-on-surface);
/* ----------------------------------------------------------------------
LINK UNDERLINE — [DEFAULT] · the affordance, not decoration
v0.4.0 — NEW (Pilot 02, ticket 20).
These two exist so that "our links look like this" is a brand answer
instead of a reason to write `text-decoration` in site.css. What a
brand may NOT do is remove the underline by answering a role: zeroing
the thickness kills the hover thickening too (it derives by
multiplication), and the rendered gate then fails every link in running
text. The knob tunes the affordance; it cannot delete it.
0.0625em is 1px at body size and scales with the type, so a link inside
a display heading gets a rule proportional to its own letterforms
rather than a hairline. Offset is a role because the right value
depends on the brand's descenders.
---------------------------------------------------------------------- */
--link-underline-thickness: 0.0625em;
--link-underline-offset: 0.15em;
/* ----------------------------------------------------------------------
FOCUS RING — [DEFAULT, contrast-gated at 3:1]
v0.2.0 — NEW.
Pilot 01: :focus-visible was styled only on .btn, form controls and
two overlay internals. Everything else — nav toggles, tabs,
accordion toggles, footer links — fell back to the browser default
(#005FCC), which measured 2.72:1 on a dark-ground brand, under
WCAG 2.4.11's 3:1. A site-authored focus ring is exactly the
per-project accessibility install this core exists to retire, so
the ring is now global (see core.foundation.css) and follows the
surface's own contrast direction.
---------------------------------------------------------------------- */
--focus-ring: var(--contrast-toward);
/* ----------------------------------------------------------------------
SCRIM — [DEFAULT] · text over imagery
v0.2.0 — NEW.
Pilot 01 put text over photography in four of fourteen sections and
found NO compliant path: every core surface is opaque, so the only
expressible option was an rgba() in site.css — a raw colour outside
the brand sheet, i.e. a Tier-2 violation. The most common
composition pattern in the comp had no legal expression, and the
mechanism keeping text legible over images was un-tokenized and
unmeasurable.
--scrim is a translucent veil of the page ground. The .bg-scrim
utilities publish link and icon colours like any other surface, so
text over a photo is governed by the same system as text anywhere
else.
v0.4.0 — THE RAMP IS ANSWERABLE TOO (Pilot 02, ticket 6). Only the
scrim's SOURCE COLOUR was a role; its weight was baked in at 72% and 88%
opaque. That is 3-9x heavier than the pilot's comp wanted, so three
sections hand-composed their own color-mix() in site.css — a raw
composite outside the brand sheet, which is the Tier-2 violation the
scrim was introduced to end. A knob nobody can reach is a knob that gets
rebuilt locally.
Stated as "how much of the image shows through", because that is the
decision a designer is actually making when they look at a comp.
⚠️ WHAT THE GATE CANNOT DO WITH THIS, stated because loosening the knob
makes it matter more: the role gate resolves `transparent` as the colour
it is mixed with, so it measures text on a FULLY OPAQUE scrim. That is
an upper bound, and the lighter a brand sets the ramp the looser it
gets. Text over imagery is not gate-measurable in general — that is the
whole reason --gradient-ref exists for gradients. The gate now PRINTS
the alpha beside the ratio so the assumption is on screen rather than
implied.
---------------------------------------------------------------------- */
--scrim-alpha: 28%; /* how much of the image shows through */
--scrim-strong-alpha: 12%;
--scrim: color-mix(in srgb, var(--surface), transparent var(--scrim-alpha));
--scrim-strong: color-mix(in srgb, var(--surface), transparent var(--scrim-strong-alpha));
/* ----------------------------------------------------------------------
GRADIENT — [DEFAULT]
v0.3.0 — REBUILT. Pilot 01, F-009.
v0.1.0 modelled a gradient as ONE endpoint pair rendered at six fixed
LINEAR angles, on the audit finding that "every audited gradient
family is deep-hue → lead-hue at an angle." Two things went wrong.
First, the premise was true of the LEGACY ESTATE, not of RBMG
brands. The first new brand shipped SIX separately named gradients
(Hero, Steel, Brands Block, Our Story, Maint Plans, Footer), one of
which is a 16-stop conic sweep at irregular stops — not two-stop,
not linear, not one of six angles, and six different ones. The six
angle utilities were used ZERO times on that build; both gradient
sections were flattened and logged as deviations.
Second — the part not to repeat — the fix is NOT a richer parametric
model (shape + position + stops as roles). That is the same mistake
one level more general: inventing a universal shape from a sample of
brands, which the next brand's weirdness breaks again. Someone will
ship a mesh gradient, an SVG fill, or two blend-mode layers.
SO: the core stops modelling the IMAGE, and models only the thing it
actually needs — the colour text has to survive.
--gradient the background-image, whatever CSS can express. A
brand may declare as many named ones as it has
(--gradient-hero, --gradient-footer, …); site
composition selects one per section.
--gradient-ref [GATED] the flat colour the core reasons about:
the stop where text has the LEAST contrast. Every
legibility decision — text colour, the link and
icon publishers, hover direction — derives from
this, and the role gate measures it.
That split is what makes the wrong version inexpressible. The wrong
version is six hand-authored background-image blobs in site.css:
raw colour outside the brand sheet, the Tier-2 violation this
project exists to stop, and unmeasurable besides. A gradient now
cannot enter the system without declaring the surface the core is to
reason about — a named gradient with no --ref is a gate failure, not
a silent fallback.
FIGMA TRAP, recorded because it costs an hour every time:
`get_variable_defs` returns gradient variables as EMPTY STRINGS —
the API does not serialise gradient values. A brand sheet built from
Figma variables alone silently has no gradients at all. Read them
off the node's fills instead.
---------------------------------------------------------------------- */
--gradient-from: var(--brand-secondary);
--gradient-to: var(--brand-primary);
/* the angle is its own role so .bg-gradient- can re-angle a brand's
named gradient rather than replacing it — ticket 11 */
--gradient-angle: 135deg;
--gradient: linear-gradient(var(--gradient-angle, 135deg), var(--gradient-from), var(--gradient-to));
--gradient-ref: var(--gradient-from);
/* [DERIVED] Text on a gradient, computed from the reference stop's own
lightness — never chained to another role. Chaining is what produced
Pilot 01's invisible button, and v0.1.0's gradient publisher had the
same shape: it set --link to --on-secondary, which is only correct
for as long as --gradient-from happens to be the secondary hue. */
--on-gradient: color(from var(--gradient-ref) srgb-linear var(--contrast-pick) var(--contrast-pick) var(--contrast-pick));
/* ----------------------------------------------------------------------
STATUS — [DEFAULT]
Validation/feedback roles. Defaults chosen to clear AA on both
--surface and --surface-sunken (demo: danger 6.54 / 6.04,
success 5.34 / 4.94).
STATUS IS BINARY — BY DECISION, NOT OMISSION (Sept 2026).
--warning and --info will not be added. The core consumes status in
exactly one place (form validation), which is a pass/fail signal;
nothing in the core paints a warning yellow or an info blue, and a
role with zero consumers is a bug factory. Where a site design
calls for a yellow/highlight treatment, that is a brand accent or a
site-sheet addition, appropriate to that design — never a status
role. (Also: gate-passing "warning yellow" is a dark ochre that no
longer reads as yellow, and info-blue collides with link colour.)
---------------------------------------------------------------------- */
--danger: #B3261E;
--success: #1B7A4B;
--on-danger: #ffffff;
--on-success: #ffffff;
/* ----------------------------------------------------------------------
BORDERS — [DEFAULT]
NOTE the third role. --border and --border-strong are DECORATIVE
(dividers, card edges) and may be low-contrast by design.
--border-control is FUNCTIONAL: it draws the edge of an interactive
control, so WCAG 1.4.11 requires 3:1 against the adjacent surface.
They must be separate roles — the audited neutral border ramps
measure ~1.5:1 on white, so a control edge drawn with --border-
strong would fail while looking correct. Gated by the role check.
v0.4.0 — DERIVED, and re-declared by every publisher (Pilot 02,
ticket 19). These were two hand-picked greys declared once at :root, so
a band with any other fill drew a light-grey divider on it: Pilot 02's
rbmg-accordion separator measured 1.46:1 worst / 1.54:1 median on its
red band. Not a contrast failure exactly — --border is decorative on
purpose — but a divider nobody can see is a divider that is not there,
and the colour had no relationship to the band at all.
Deriving from --contrast-toward means the edge is always the band's own
ink, faded. The percentages were chosen so the derivation reproduces the
hexes it replaces on a white ground: mix(black, white 90%) is #e6e6e6
against the old #e5e7ea, and 80% is #cccccc against #ccced6. Same
validation the hover derivation got in the audit — derive it, then check
it lands on the value someone had already picked by eye.
They mix toward --surface rather than toward `transparent` on purpose.
A translucent border would look identical, and would be UNMEASURABLE:
the role gate resolves `transparent` as white, so every gate row about a
translucent colour would report a number the browser never paints.
THE SEAMS ARE NEW IN v0.4.1 — Pilot 04, E-118, and the ticket was
smaller than what verifying it found.
As filed: the inverse publisher hard-codes its border derivation with no
--border-on-inverse to answer, so a comp wanting a visible rule on a dark
band (Pilot 04's FAQ draws #DCDFE7, 11.12:1 on its navy) gets the core's
1.36:1 and has no legal way to say otherwise. `.border-strong` is not the
escape hatch either — same shape at 80%, ~1.89:1.
What the grep found: **a brand's answer to --border was already dead.**
These are documented [DEFAULT] roles a brand may override, and every
publisher re-declares them — including the one that matches `body`. A
declaration on body beats an inherited :root value, so a brand answering
--border at :root has it overridden on the whole document. Pilot 04's
brand sheet answers #DCDFE7, its read-back lists it as overridden, and
the page paints the derived #E6E6E6. Nobody noticed, because a decorative
border being slightly the wrong grey looks like nothing at all.
So both halves close the same way, and the naming is not invented: the
core already splits exactly this way for the two other roles a publisher
owns — --link-on-surface / --link-on-inverse and --icon-on-surface /
--icon-on-inverse. Borders join that family. A brand answers the SEAM,
every publisher reads it, and the answer actually paints.
They stay UNDECLARED, with the fallback at each point of use, because a
[DEFAULT] declared here and chained to --surface or --surface-inverse
(both of which a brand overrides) is the --on-inverse failure. The bands
and gradients keep their own derivation: no build has needed a seam
there, and this file seeds from measured violations rather than a
theoretical complete set.
--border-control IS THE THIRD, and it is the one that mattered most to
find, because it is the FUNCTIONAL role. Every publisher sets it to
var(--muted), so a brand answering --border-control at :root had that
answer overridden too — and unlike the decorative pair, THE GATE WAS
READING THE DEAD VALUE. Its two rows resolved the brand's :root answer
while the browser painted --muted: a gate measuring the intent while the
cascade did something else, which is the failure this whole file exists
to end, sitting inside the file.
Note the publisher's override was PROTECTIVE, not merely wrong, and that
is why the seam splits by ground rather than passing one answer through.
The dark reference brand answers --border-control with a light grey,
correct on its dark page ground and about 1.5:1 on its LIGHT inverse
island — a 1.4.11 failure. One brand-wide answer cannot be right on both
polarities, which is the same argument that renamed --link-on-light to
--link-on-surface in v0.2.0.
MIGRATION, one line per answer: a brand answering --border,
--border-strong or --border-control renames it to the -on-surface form
(or -on-inverse, if the answer was ever meant for the dark island).
Nothing renders differently for the decorative pair — those answers were
not being painted. --border-control now paints what the brand asked for
instead of --muted, so its gate rows finally measure the rendered edge;
both reference brands were re-measured on the seam before this shipped.
---------------------------------------------------------------------- */
--border: var(--border-on-surface, color-mix(in srgb, var(--contrast-toward), var(--surface) 90%));
--border-strong: var(--border-strong-on-surface, color-mix(in srgb, var(--contrast-toward), var(--surface) 80%));
--border-control: var(--border-control-on-surface, var(--muted)); /* functional, 3:1-gated */
/* ----------------------------------------------------------------------
RADIUS — [DEFAULT]
Seeded from the reference brand's three-stop scale. A fully square
brand zeroes ALL of these in its brand sheet —
that is the entire mechanism for the square look; no component knows.
---------------------------------------------------------------------- */
--radius-xs: 0.25rem; /* v0.2.0 — added; pilot needed a 4px stop (chips, small controls) */
--radius-sm: 0.5rem;
--radius-md: 0.75rem; /* was --border-radius-standard */
--radius-lg: 1rem; /* was --border-radius-card */
--radius-xl: 1.25rem; /* was --border-radius-large */
--radius-pill: 50rem;
/* ----------------------------------------------------------------------
ELEVATION — [DEFAULT]
---------------------------------------------------------------------- */
--shadow-sm: 0 0 8px rgba(0, 0, 0, 0.05);
--shadow-md: 0 0.5rem 1rem rgba(0, 0, 0, 0.15);
--shadow-dropdown: 0 3rem 3rem rgba(0, 0, 0, 0.175);
/* ----------------------------------------------------------------------
MOTION — [DEFAULT]
Already universal at 0.25s across all seven sites.
The CURVE was the missing half. Duration was a role; easing was a
literal — `ease-out` typed into the three rules someone happened to
notice and omitted from the other ten, which therefore ran the CSS
default `ease`. Motion was the one value a brand could not answer,
so "make it feel like us" had nowhere to land.
Three roles, not one: a thing arriving and a thing leaving want
different curves, and a single symmetric curve makes one of them feel
wrong. That is precisely why `ease-out` got hand-written in the first
place — the split is the generalization of that patch. Duration stays
single: 0.25s was universal across the estate, and inventing an exit
duration would be inventing variance no brand has asked for. The exit
reads quicker because of its curve, not because of a second number.
---------------------------------------------------------------------- */
--transition-standard: 0.25s;
--ease-standard: cubic-bezier(0.4, 0, 0.2, 1); /* symmetric — hover, colour, border */
--ease-enter: cubic-bezier(0, 0, 0.2, 1); /* decelerate — arriving, settles into place */
--ease-exit: cubic-bezier(0.4, 0, 1, 1); /* accelerate — leaving, gets out of the way */
/* ----------------------------------------------------------------------
STRUCTURE KNOBS — [DEFAULT]
Value-shaped levers into core structural defaults, so brands adjust
them without touching structure (per the precedence block).
---------------------------------------------------------------------- */
--heading-transform: uppercase; /* near-universal treatment; a brand may set none */
--scroll-offset: 120px; /* anchor scroll-margin under the fixed header */
/* ----------------------------------------------------------------------
NAVBAR KNOBS — [DEFAULT]
v0.4.0 — NEW, with the navbar shell (Pilot 02, ticket 2).
Geometry a brand answers so the shell's STRUCTURE never has to be
rewritten in site.css. --navbar-fit is the width the header's content
must not be squeezed below: Pilot 02's needed 1420px and a .container
capped it at 1320 at every width, which crushed the brand mark 46.5% on
every desktop. Leave slack in it — a header that fits to the pixel
breaks on a longer phone number.
--z-navbar exists because a third-party chat widget is the one thing
that genuinely has to be layered against a site's header, and the
alternative is an !important in site.css. It sits under the drawer
(1050) and the modal (1060) on purpose.
THREE MORE SEAMS IN v0.4.1, all Pilot 04, and all UNDECLARED with their
fallback at the point of use — see core.components.css for each:
--navbar-shadow E-076. The core supports a TRANSPARENT
header in JS (core.behaviors.js grew
data-hero-pad for exactly that case and
documents it at length) and .navbar
hard-coded box-shadow: var(--shadow-md), so
the only way to build the thing the
behaviour exists to serve was to override a
core declaration. Half that ticket
dissolved on reading the rule: .navbar sets
NO background-color at all, so a
transparent header is already expressible
by simply not composing a .bg-* utility
onto the shell. Only the shadow was stuck.
--navbar-utility-display E-077. See the shrink hook.
--navbar-pad-x E-082. The full-bleed inset existed only as
an inline clamp() on .navbar-inner, so
rbmg-dropdown[mega] — which sets itself
position: static and therefore cannot
inherit that padding — had no way to align
its panel with the nav links above it.
Pilot 04 restated the clamp verbatim in
site.css and labelled it as duplication.
It is declared ON .navbar rather than here,
because it is per-header geometry a section
may rebind, not a page-level value.
---------------------------------------------------------------------- */
--navbar-fit: 1460px;
--navbar-inset: 5rem;
--navbar-brand-width: 12rem;
--navbar-brand-width-shrunk: 7rem;
--z-navbar: 1040;
/* ----------------------------------------------------------------------
FONT ROLES
[REQUIRED] the brand sheet answers: --font-heading --font-body
--font-label
[DEFAULT] --font-overline falls back to --font-label (v0.3.0,
Pilot 01 F-008). A brand whose eyebrow is the label
family answers nothing. A brand whose eyebrow is a
different voice — the pilot's was a black extended
italic SERIF against a black SANS label, in every
section — answers one line instead of logging the
section unbuildable.
The overline style knobs are value-shaped levers into core
structure, the same device as --heading-transform. They live here
rather than in a site sheet because "the eyebrow is italic" is a
brand fact, and site.css restyling a core utility is the failure
mode this project exists to prevent:
--overline-weight default --font-weight-black
--overline-style default normal (a brand may set italic)
--overline-tracking default normal
--overline-transform default uppercase
---------------------------------------------------------------------- */
/* ----------------------------------------------------------------------
WEIGHTS — [DEFAULT]
---------------------------------------------------------------------- */
--font-weight-black: 900;
--font-weight-bold: 700;
--font-weight-semibold: 600;
--font-weight-medium: 500;
--font-weight-regular: 400;
/* ----------------------------------------------------------------------
TYPE SCALE — [DEFAULT] (locked decision: the audited fluid model is
the core scale, so it moves OUT of brand sheets entirely — ~35
lines leave every brand.css)
Sizes calibrated at a 1600px viewport (Figma reference); clamp()
floor = mobile minimum; slope scales linearly 375px → 1600px.
---------------------------------------------------------------------- */
--fs-display-lg: clamp(2rem, calc(1.541rem + 1.959vw), 3.5rem); /* 32 → 56 */
--lh-display-lg: 1.143;
--fs-display-sm: clamp(1.75rem, calc(1.367rem + 1.633vw), 3rem); /* 28 → 48 */
--lh-display-sm: 1.167;
--fs-h1: clamp(1.625rem, calc(1.319rem + 1.306vw), 2.625rem); /* 26 → 42 */
--lh-h1: 1.190;
--fs-h2: clamp(1.375rem, calc(1.146rem + 0.98vw), 2.125rem); /* 22 → 34 */
--lh-h2: 1.235;
--fs-h3: clamp(1.25rem, calc(1.097rem + 0.653vw), 1.75rem); /* 20 → 28 */
--lh-h3: 1.286;
--fs-h4: clamp(1.125rem, calc(1.049rem + 0.327vw), 1.375rem); /* 18 → 22 */
--lh-h4: 1.364;
--fs-h5: clamp(1.125rem, calc(1.087rem + 0.163vw), 1.25rem); /* 18 → 20 */
--lh-h5: 1.4;
--fs-p-lg: clamp(1rem, calc(0.962rem + 0.163vw), 1.125rem); /* 16 → 18 */
--lh-p-lg: 1.25;
--fs-p-md: 1rem; --lh-p-md: 1.5;
--fs-p-sm: 0.875rem; --lh-p-sm: 1.571;
--fs-p-xs: 0.75rem; --lh-p-xs: 1.667;
--fs-label-lg: 1rem; --lh-label-lg: 1.125;
--fs-label-md: 0.875rem; --lh-label-md: 1.143;
--fs-label-sm: 0.75rem; --lh-label-sm: 1.167;
--fs-label-xs: 0.625rem; --lh-label-xs: 1.2;
--fs-overline-lg: 0.875rem; --lh-overline-lg: 1.429;
--fs-overline-sm: 0.75rem; --lh-overline-sm: 1.667;
/* ----------------------------------------------------------------------
ICON SIZE — [DEFAULT]
v0.4.0 — NEW (Pilot 02, ticket 8). TEN live instances, and every one
was a `raw-token-value` linter finding that got JUSTIFIED rather than
fixed — which is the tell that the vocabulary was missing rather than
the build being sloppy.
Every --fs-* above is a TEXT role. Binding a decorative glyph to
--fs-h3 because the numbers happen to match is the --on-inverse-as-a-
fill mistake one level over: it asserts a relationship the design never
made, and it breaks the moment a brand retunes its heading scale — the
glyph moves with a heading it has nothing to do with.
So an icon gets its own scale. This is a SEPARATE ladder from
.icon-stacked's size modifiers, which size the backdrop BOX; this sizes
the glyph itself.
The defaults cover what the pilot's comp actually used (16, 20, 24, 36).
A brand whose comp draws a 36px glyph answers --icon-xl and stops
writing a literal in site.css, which is the whole point.
v0.4.1 — A SIXTH STOP (Pilot 04, E-110), and the note above is the thing
it corrects. "A brand answers --icon-xl and stops" holds only while a
comp uses one size above 24. Pilot 04 uses two: 36 on the About chips and
the Opener pennants (measured off the comp's own raster as a red-pixel
bounding box, not read off a declared value) and 47–48 on the Financing
benefits. --icon-xl was already answered at 36 because two sections need
it there, so the fifth benefit's glyph shipped 12px small.
A brand may ANSWER a role and may not INVENT one, so --icon-2xl in a
brand sheet would be introducing structure at the value tier and there
was no compliant workaround at all. This is not a wrong default: it is a
scale one stop short, which only shows on a brand using more of the range
than the reference brands do. */
--icon-xs: 0.875rem; /* 14 */
--icon-sm: 1rem; /* 16 */
--icon-md: 1.25rem; /* 20 */
--icon-lg: 1.5rem; /* 24 */
--icon-xl: 2.25rem; /* 36 — the pilot's recurring glyph size */
--icon-2xl: 3rem; /* 48 */
}
}
/* ==========================================================================
ROLE-SATISFACTION CHECK (run at brand-sheet time; see tier map §handoff)
--------------------------------------------------------------------------
Walk the roles above. Every [REQUIRED] role resolves to a Tier 0A
primitive. Every [DEFAULT] role is either overridden or listed as taken.
No [DERIVED] role appears in the brand sheet at all.
Confirm back in ≤10 lines: the brand, and every role taking a core
default, with what that means visually.
========================================================================== */
/* ---------- core.foundation.css ---------- */
/* ==========================================================================
RBMG Core — foundation (layer order, reset, base, grid, utilities)
core.foundation.css · v0.1.0-draft · GENERATED by tools/build-foundation.py
DO NOT EDIT BY HAND — a local edit to this file is a defect, not a fork.
Public API contract (locked, tier map §Layout): Bootstrap's exact
breakpoints (576/768/992/1200/1400), container max-widths
(540/720/960/1140/1320), 12-column math, and unprefixed Bootstrap-
compatible class names, so figma-build's Appendix A, the srcset
pipeline, patterns.md, and the team's habits transfer unedited.
Internal implementation is free — and differs where Bootstrap's had a
known failure (see the .row gutter clamp).
Deliberately not carried in this draft (flagged, not silent):
`.container-{bp}` responsive-container variants — pending a usage check
across the seven sites before they earn generation.
========================================================================== */
/* The layer order lives in css/core.layers.css, which MUST load first.
It is NOT declared here: a layer's position is fixed when its name is
first seen, so declaring the order in this file would make the cascade
depend on whether foundation happens to load before the token sheet. */
@layer reset {
*, *::before, *::after { box-sizing: border-box; }
body { margin: 0; }
h1, h2, h3, h4, h5, h6, p, figure, blockquote { margin: 0 0 1rem; }
ul, ol { margin: 0 0 1rem; padding-left: 2rem; }
img, svg, video { vertical-align: middle; max-width: 100%; }
/* TICKET 13 — the reset half-implemented fluid images for three versions.
`max-width: 100%` with no `height: auto` distorts any carrying the
width and height ATTRIBUTES the SOP requires for CLS: the attributes set a
used height, max-width clamps the width below its attribute value, and
nothing recomputes the height. Pilot 02 hit it 3+ times and worked around
it locally each time; its brand mark was squashed 46.5% by the same shape
one component over. `height: auto` restores the intrinsic ratio, and a
component that genuinely wants a fixed height sets one in a later layer.
img ONLY — an