/*
RetirementCare central brand theme.
This is the single source of truth for brand colours, typography, spacing,
radius and shadow tokens. The public website, the future Admin Portal and the
future Resident Portal must all consume these variables instead of redefining
their own hard-coded values.
The values below currently match the SenoCare template palette exactly, so the
public website renders identically to the source template. Rebranding is done
by changing the values here - public-website.css maps the template's own
variables onto these tokens, so nothing else needs editing.
Do not copy these values into portal-specific or component-isolated CSS.
*/
/*
Minimal global reset.
⚠️ Do not remove. The shells (login, admin, resident) deliberately load NO CSS
framework, which also means they get no framework reset - so the browser's
default `body { margin: 8px }` applies. That 8px is invisible until something is
position:fixed: the admin sidebar then sits at 0 while the content column beside
it starts at 8, which showed up as an unexplained gap down the left AND as the
top bar's bottom border sitting 8px below the sidebar's, making two panels of
identical height look mismatched. Measured and fixed 2026-07-29.
The public website is unaffected - Bootstrap's own reset already zeroes this.
*/
body {
margin: 0;
}
/*
Global border-box.
⚠️ Do not remove, and do not "fix" a width bug by adding box-sizing locally instead.
Content-box has now caused the same bug three times in this shell: an element given
`max-width` or `height` renders WIDER or TALLER than that value, because padding and
border are added on top. It produced a sidebar brand block 1.2rem taller than the top
bar beside it, and a portal hero card 50px wider than the content column it was meant
to line up with. Both looked like careless design; both were this.
Applied globally rather than per-component because the shells deliberately load no CSS
framework and therefore inherit no reset. The public website is unaffected - Bootstrap
already sets exactly this.
*/
*,
*::before,
*::after {
box-sizing: border-box;
}
/* ══════════════════════════════════════════════════════════════════════════════════════════════
THE BRAND FACES, SELF-HOSTED (2026-08-24, RP164 — product owner: "you can download them for use
as assets")
⚠️⚠️⚠️ THIS BLOCK IS WHY EVERY SHELL NOW GETS THE BRAND FACES, AND THAT IS A FIX RATHER THAN A
TIDY-UP. Before it, the webfonts were loaded by exactly TWO shells — `AccountLayout` via a
Google `` and the marketing template via an `@import` — while `--rc-font-family-base`
('Roboto') and `--rc-font-family-heading` ('Ubuntu') are read by 188 declarations across the
product. So `AdminLayout`, `LoginLayout`, `SigningLayout` and the resident portal named families
the browser did not have and FELL THROUGH TO THE SYSTEM SANS: the admin portal, which is most of
this product, had never once rendered in the brand faces. It reads as a styling choice rather
than a fault, which is exactly why it survived.
📌 EVERY ONE OF THE NINE SHELLS ALREADY LINKS THIS STYLESHEET — checked, not assumed — so the
faces arrive everywhere with no per-layout change, and a shell added next year cannot forget.
That property is the whole reason the rules live here rather than in a ``.
⚠️⚠️ AND IT REMOVES A SILENT PRODUCTION DEPENDENCY. Google Fonts needs outbound internet AT THE
OPERATOR'S SITE, and the fallback is silent: no route to fonts.gstatic.com and the page renders
in the system sans, looking merely ordinary rather than broken. Self-hosting makes the faces a
deployed asset like any other.
⚠️ WEIGHTS ARE THE UNION OF WHAT THE PRODUCT ALREADY REQUESTED — Roboto 100/300/400/500/700/900
and Ubuntu 300/400/500/700. The profile area only ever asked for 400/500/700; shipping just
those three would have silently re-weighted the MARKETING site, which requests the rest.
⚠️ Latin and latin-ext only. `unicode-range` is preserved exactly as Google serves it, so a
browser downloads only the faces a page actually needs — 20 files exist, a typical page pulls
two to four.
⚠️⚠️ THESE ARE REDISTRIBUTED BINARIES AND THEIR LICENCES SHIP BESIDE THEM in `theme/fonts/`:
Roboto is Apache-2.0, Ubuntu is the Ubuntu Font Licence 1.0. Both permit self-hosting. Do not
add a face without checking its licence allows it.
⚠️ `font-display: swap` is kept from Google's own CSS: text paints immediately in the fallback
and swaps when the face arrives. The alternative — blocking — trades a flash for invisible text.
══════════════════════════════════════════════════════════════════════════════════════════════ */
@font-face {
font-family: 'Roboto';
font-style: normal;
font-weight: 100;
font-display: swap;
src: url("../fonts/roboto-100-latin-ext.woff2") format("woff2");
unicode-range: U+0100-02BA, U+02BD-02C5, U+02C7-02CC, U+02CE-02D7, U+02DD-02FF, U+0304, U+0308, U+0329, U+1D00-1DBF, U+1E00-1E9F, U+1EF2-1EFF, U+2020, U+20A0-20AB, U+20AD-20C0, U+2113, U+2C60-2C7F, U+A720-A7FF;
}
@font-face {
font-family: 'Roboto';
font-style: normal;
font-weight: 100;
font-display: swap;
src: url("../fonts/roboto-100-latin.woff2") format("woff2");
unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}
@font-face {
font-family: 'Roboto';
font-style: normal;
font-weight: 300;
font-display: swap;
src: url("../fonts/roboto-300-latin-ext.woff2") format("woff2");
unicode-range: U+0100-02BA, U+02BD-02C5, U+02C7-02CC, U+02CE-02D7, U+02DD-02FF, U+0304, U+0308, U+0329, U+1D00-1DBF, U+1E00-1E9F, U+1EF2-1EFF, U+2020, U+20A0-20AB, U+20AD-20C0, U+2113, U+2C60-2C7F, U+A720-A7FF;
}
@font-face {
font-family: 'Roboto';
font-style: normal;
font-weight: 300;
font-display: swap;
src: url("../fonts/roboto-300-latin.woff2") format("woff2");
unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}
@font-face {
font-family: 'Roboto';
font-style: normal;
font-weight: 400;
font-display: swap;
src: url("../fonts/roboto-400-latin-ext.woff2") format("woff2");
unicode-range: U+0100-02BA, U+02BD-02C5, U+02C7-02CC, U+02CE-02D7, U+02DD-02FF, U+0304, U+0308, U+0329, U+1D00-1DBF, U+1E00-1E9F, U+1EF2-1EFF, U+2020, U+20A0-20AB, U+20AD-20C0, U+2113, U+2C60-2C7F, U+A720-A7FF;
}
@font-face {
font-family: 'Roboto';
font-style: normal;
font-weight: 400;
font-display: swap;
src: url("../fonts/roboto-400-latin.woff2") format("woff2");
unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}
@font-face {
font-family: 'Roboto';
font-style: normal;
font-weight: 500;
font-display: swap;
src: url("../fonts/roboto-500-latin-ext.woff2") format("woff2");
unicode-range: U+0100-02BA, U+02BD-02C5, U+02C7-02CC, U+02CE-02D7, U+02DD-02FF, U+0304, U+0308, U+0329, U+1D00-1DBF, U+1E00-1E9F, U+1EF2-1EFF, U+2020, U+20A0-20AB, U+20AD-20C0, U+2113, U+2C60-2C7F, U+A720-A7FF;
}
@font-face {
font-family: 'Roboto';
font-style: normal;
font-weight: 500;
font-display: swap;
src: url("../fonts/roboto-500-latin.woff2") format("woff2");
unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}
@font-face {
font-family: 'Roboto';
font-style: normal;
font-weight: 700;
font-display: swap;
src: url("../fonts/roboto-700-latin-ext.woff2") format("woff2");
unicode-range: U+0100-02BA, U+02BD-02C5, U+02C7-02CC, U+02CE-02D7, U+02DD-02FF, U+0304, U+0308, U+0329, U+1D00-1DBF, U+1E00-1E9F, U+1EF2-1EFF, U+2020, U+20A0-20AB, U+20AD-20C0, U+2113, U+2C60-2C7F, U+A720-A7FF;
}
@font-face {
font-family: 'Roboto';
font-style: normal;
font-weight: 700;
font-display: swap;
src: url("../fonts/roboto-700-latin.woff2") format("woff2");
unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}
@font-face {
font-family: 'Roboto';
font-style: normal;
font-weight: 900;
font-display: swap;
src: url("../fonts/roboto-900-latin-ext.woff2") format("woff2");
unicode-range: U+0100-02BA, U+02BD-02C5, U+02C7-02CC, U+02CE-02D7, U+02DD-02FF, U+0304, U+0308, U+0329, U+1D00-1DBF, U+1E00-1E9F, U+1EF2-1EFF, U+2020, U+20A0-20AB, U+20AD-20C0, U+2113, U+2C60-2C7F, U+A720-A7FF;
}
@font-face {
font-family: 'Roboto';
font-style: normal;
font-weight: 900;
font-display: swap;
src: url("../fonts/roboto-900-latin.woff2") format("woff2");
unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}
@font-face {
font-family: 'Ubuntu';
font-style: normal;
font-weight: 300;
font-display: swap;
src: url("../fonts/ubuntu-300-latin-ext.woff2") format("woff2");
unicode-range: U+0100-02BA, U+02BD-02C5, U+02C7-02CC, U+02CE-02D7, U+02DD-02FF, U+0304, U+0308, U+0329, U+1D00-1DBF, U+1E00-1E9F, U+1EF2-1EFF, U+2020, U+20A0-20AB, U+20AD-20C0, U+2113, U+2C60-2C7F, U+A720-A7FF;
}
@font-face {
font-family: 'Ubuntu';
font-style: normal;
font-weight: 300;
font-display: swap;
src: url("../fonts/ubuntu-300-latin.woff2") format("woff2");
unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}
@font-face {
font-family: 'Ubuntu';
font-style: normal;
font-weight: 400;
font-display: swap;
src: url("../fonts/ubuntu-400-latin-ext.woff2") format("woff2");
unicode-range: U+0100-02BA, U+02BD-02C5, U+02C7-02CC, U+02CE-02D7, U+02DD-02FF, U+0304, U+0308, U+0329, U+1D00-1DBF, U+1E00-1E9F, U+1EF2-1EFF, U+2020, U+20A0-20AB, U+20AD-20C0, U+2113, U+2C60-2C7F, U+A720-A7FF;
}
@font-face {
font-family: 'Ubuntu';
font-style: normal;
font-weight: 400;
font-display: swap;
src: url("../fonts/ubuntu-400-latin.woff2") format("woff2");
unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}
@font-face {
font-family: 'Ubuntu';
font-style: normal;
font-weight: 500;
font-display: swap;
src: url("../fonts/ubuntu-500-latin-ext.woff2") format("woff2");
unicode-range: U+0100-02BA, U+02BD-02C5, U+02C7-02CC, U+02CE-02D7, U+02DD-02FF, U+0304, U+0308, U+0329, U+1D00-1DBF, U+1E00-1E9F, U+1EF2-1EFF, U+2020, U+20A0-20AB, U+20AD-20C0, U+2113, U+2C60-2C7F, U+A720-A7FF;
}
@font-face {
font-family: 'Ubuntu';
font-style: normal;
font-weight: 500;
font-display: swap;
src: url("../fonts/ubuntu-500-latin.woff2") format("woff2");
unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}
@font-face {
font-family: 'Ubuntu';
font-style: normal;
font-weight: 700;
font-display: swap;
src: url("../fonts/ubuntu-700-latin-ext.woff2") format("woff2");
unicode-range: U+0100-02BA, U+02BD-02C5, U+02C7-02CC, U+02CE-02D7, U+02DD-02FF, U+0304, U+0308, U+0329, U+1D00-1DBF, U+1E00-1E9F, U+1EF2-1EFF, U+2020, U+20A0-20AB, U+20AD-20C0, U+2113, U+2C60-2C7F, U+A720-A7FF;
}
@font-face {
font-family: 'Ubuntu';
font-style: normal;
font-weight: 700;
font-display: swap;
src: url("../fonts/ubuntu-700-latin.woff2") format("woff2");
unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}
:root {
/*
Brand palette (product owner, 2026-07-29). Taken from the real logo rather than
inherited from the SenoCare template, and the ROLES WERE SWAPPED at the same time:
primary = the teal (was secondary, #00ADB8)
secondary = the coral (was primary, #FF7A7C)
The swap corrects a long-standing wart: every shell already led with teal, so
"secondary" was doing the primary's job. If you find CSS that reads
--rc-color-secondary expecting teal, it predates this and is a bug.
⚠️ CONTRAST. Both hues sit near 3.5:1 against white:
#0197a1 on white = 3.53:1 #f34d59 on white = 3.49:1
That clears the 3:1 floor for LARGE text, buttons, badges, borders and focus
rings - but NOT the 4.5:1 floor for normal-size text. For coloured text at body
size use --rc-color-primary-dark (5.11:1). Do not put small white text on a
primary/secondary fill.
(Both are still a clear improvement: the old #00ADB8 managed only 2.74:1, which
failed even the large-text floor despite a code comment claiming otherwise.)
*/
--rc-color-primary: #0197a1;
/*
Darker teal. Two jobs: the hover/pressed fill under a primary button, and the
AA-safe colour for coloured TEXT at body size (5.11:1 on white).
⚠️ This used to be #2C374B - a navy, identical to --rc-color-dark and unrelated
to the primary. If you want the navy, name it: `--rc-color-nav-surface` for a SURFACE, or
`--rc-color-dark` for INK. ⚠️ They hold the same navy in the light theme and diverge in the
dark scope, where `--rc-color-dark` is a near-white (RP184) — so "use --rc-color-dark for the
navy", which this line used to say, is now true of ink only.
*/
--rc-color-primary-dark: #017a82;
--rc-color-secondary: #f34d59;
/*
The secondary at a weight that can carry TEXT, and the counterpart of --rc-color-primary-dark
above (added 2026-08-18).
⚠️⚠️ --rc-color-secondary IS 3.49:1 ON WHITE, so it fails the 4.5:1 floor for normal text — the
same trap the primary carries at 3.53:1 and for the same reason. It is a FILL colour: correct
behind white text at large sizes, wrong for a figure somebody has to read. This shade is 4.57:1
and is what the coral should be whenever it is the ink rather than the ground.
📌 It also fixes a live one: `.rc-action--destructive` prints its label in the raw secondary, so
every Delete/Withdraw/Deactivate label in the product currently sits at 3.49:1.
*/
--rc-color-secondary-dark: #D1424D;
/* ══════════════════════════════════════════════════════════════════════════════════════
THE ACTION PALETTE (RP7 / RP10, agreed 2026-08-18) — one colour per ACTION TYPE.
⚠️⚠️ THESE ARE DARKENED VARIANTS OF THE BRAND HUES, NEVER THE RAW ONES, and RP10 is the
reason. Measured on white: primary teal 3.53:1, secondary coral 3.49:1, the accent red
3.44, amber 1.98, green 1.86 — every one below the 4.5:1 floor for normal text. An
action button's label IS normal text, so assigning a brand hue straight to a button
ships labels nobody can read (the P-D81 defect, which measured 1.09:1).
📌 Contrast is symmetric, so each shade works as the ink of an outlined button AND as
the ground of a filled one. That is what lets one token serve both treatments.
⚠️ The ratio beside each is measured, not estimated. Anything changed here must be
re-measured — a hue nudged "to look better" is how a 4.5:1 floor is lost silently.
══════════════════════════════════════════════════════════════════════════════════════ */
/* Primary / confirm — Save · Add · Register now · Confirm. FILLED.
⚠️ Also the ink of the OPEN family below: the map gives the two the same colour and
distinguishes them by treatment, so they share one token deliberately. */
--rc-action-primary: #01828A; /* 4.60:1 */
--rc-action-primary-hover: #016F76; /* 5.94:1 */
--rc-action-primary-pressed: #015C62; /* 7.76:1 */
/* The same teal used as INK rather than as a FILL — a link, not a button (2026-08-23, RP132).
⚠️⚠️⚠️ IT EXISTS BECAUSE THE FILL AND THE INK CANNOT SHARE ONE VALUE ON A DARK GROUND, AND
RE-POINTING `--rc-action-primary` ITSELF WOULD HAVE BROKEN THE BUTTON. Measured on the
published `/account/security`: `Manage your passkeys` renders `--rc-action-primary` as TEXT
on the #171D28 ground at **3.67:1**, under the 4.5:1 floor for body copy. The obvious fix is
to give `--rc-action-primary` a dark variant — and that token is also the BACKGROUND of
`.account-detail__button`, where white-on-teal measures 4.60:1; lightening it to #21A3AB
drops that to roughly 3.05:1. One token, two jobs, opposite directions.
⚠️ On white the two are the same colour, so nothing outside the dark scope changes. */
--rc-action-primary-ink: #01828A; /* 4.60:1 on white */
--rc-action-edit: #0049D0; /* 7.33:1 — Edit · Rename · Correct · Change … */
--rc-action-status: #B5179E; /* 5.86:1 — Change status ONLY (RP8) */
--rc-action-move: #7C5CE0; /* 4.70:1 — Move · Transfer */
--rc-action-record: #0D837D; /* 4.61:1 — Record · Mark · Attach · outcomes */
--rc-action-restore: #A16B04; /* 4.55:1 — Reactivate · Restore · Reopen */
/* WhatsApp — the send-on-WhatsApp control, and the only third-party brand mark in this palette
(WA47, product owner 2026-10-08). FILLED and icon-only, exactly like the download beside it.
⚠️⚠️⚠️ ALL THREE ARE GENUINE WHATSAPP BRAND COLOURS, AND THE COMBINATION WAS MEASURED RATHER THAN
ASSUMED. The familiar #25D366 is kept as the FILL — which is what the product owner asked for —
and it works only because the glyph is WhatsApp's DARK ink rather than white: white on #25D366
is 1.98:1, below even the 3:1 floor for a non-text graphic, while #0B141A on it is 9.38:1.
📌 So the recognisable green survives; what changed is the glyph, not the brand colour.
⚠️⚠️ THE BORDER IS NOT DECORATION. #25D366 against a WHITE card is 1.98:1, so the button's own
edge would fall below WCAG 1.4.11's 3:1 for a component boundary — invisible on every light
screen. #128C7E is 4.14:1 on white and reads as a quiet edge on the green. */
--rc-action-whatsapp: #25D366; /* fill — the brand green */
--rc-action-whatsapp-hover: #1FB457; /* 6.84:1 with the glyph — a shade down on hover */
--rc-action-whatsapp-glyph: #0B141A; /* 9.38:1 on the fill — WhatsApp's own dark ink */
--rc-action-whatsapp-edge: #128C7E; /* 4.14:1 on white — the boundary a light card needs */
/* Document / download — every PDF control in the product (RcPdfButton). FILLED.
⚠️⚠️ IT IS A COLOUR OF ITS OWN, AND THAT IS THE WHOLE POINT (RP27, product owner
2026-08-18). It used to be `--rc-color-primary-dark` (#017a82), which is the same teal
family as --rc-action-primary (#01828A) — so on the invoice row the download button sat
beside an outlined `Open` in a hue 4° away and read as another instance of the same
action rather than as a different kind of control.
⚠️ CHOSEN ON MEASUREMENT, the way RP8's fuchsia was. Green is the one region of the
wheel this palette leaves empty: at hue 126° it is 51° from the record teal (177°),
87° from the restore amber (39°) and further still from everything else — where the
nearest pair anywhere else in the map is 46°. White on it is 5.35:1. */
--rc-action-document: #2A7A32; /* 5.35:1 */
--rc-action-document-hover: #2D8536; /* 4.65:1 — lighter on hover, still over the floor */
/* Surfaces and text */
--rc-color-background: #ffffff;
--rc-color-surface: #F6F6F6;
--rc-color-dark: #2C374B;
/* ⚠️⚠️ A DOCUMENT'S INK IS THEME-INDEPENDENT BY DEFINITION, AND THAT IS WHY IT IS ITS OWN TOKEN
(2026-08-25, RP192). `.terms-body` renders the residency agreement a family is about to sign —
the same content that prints — so it keeps its paper-white ground in both themes. Its ink
therefore cannot be `--rc-color-dark`, which the dark scope re-points to the near-white #E8EBF1
and would put near-white ON that white. ⚠️ Declared at `:root` and DELIBERATELY NOT re-pointed
in the dark scope: a value that must not follow the theme is stated once, here, rather than
written as a literal at the point of use — where the button-treatment guard would read it as a
stray hue and, worse, where nothing would say why it never changes. */
--rc-document-ink: #2C374B;
--rc-color-text: #2C374B;
--rc-color-muted: #757F95;
--rc-color-on-primary: #ffffff;
--rc-color-on-dark: #F5FAFF;
/* ⚠️⚠️⚠️ THE NAVY BRAND SURFACE — THE SIDEBAR AND THE ACCOUNT MENU (2026-08-25, RP184).
IT IS DELIBERATELY *NOT* RE-POINTED IN THE DARK SCOPE, EXACTLY LIKE ITS INK
`--rc-color-on-dark` BELOW, AND THE PAIR ONLY MAKES SENSE TOGETHER.
`--rc-color-dark` holds this same navy in the light theme, which is why four surfaces came to
read it — but that token means *"the strongest ink on this surface"* and therefore resolves to a
near-white `#E8EBF1` inside the dark scope (RP177). So the sidebar painted itself near-white and
kept every ink that had been measured against #2C374B: the labels went to **1.11:1**, the rail
labels to **2.14:1**, and the flyout — `color-mix(… var(--rc-color-dark) 92%, white)` — followed
it. **Measured: 12 light grounds and 123 text failures, the entire remainder of the roll-out.**
📌 The token was doing TWO JOBS, and the counts say which one it is: **78 uses as an ink against
4 as a surface.** So the ink keeps the name and the surface gets its own.
⚠️ It is the SAME VALUE in the light theme, so nothing there moves — verified by measurement, not
by reasoning.
⚠️⚠️ **The avatar disc is NOT one of the four and must not be "made consistent" with them.** RP177
gave it `--rc-color-inset` on purpose: it sits on the top BAR rather than on a navy panel, and a
navy disc on a dark bar is the contrast problem it was fixed for. */
--rc-color-nav-surface: #2C374B;
/* Accents carried over from the template */
--rc-color-green: #15D4C9;
--rc-color-blue: #0049D0;
--rc-color-yellow: #FBA707;
--rc-color-red: #F05454;
--rc-color-border: rgba(0, 0, 0, 0.08);
/* Typography - SenoCare --body-font / --heading-font */
--rc-font-family-base: 'Roboto', sans-serif;
--rc-font-family-heading: 'Ubuntu', sans-serif;
/* ⚠️⚠️ THE ONE SIZE EVERY ALERT / NOTICE / ERROR PANEL READS AT, AND THE FIRST FONT-SIZE TOKEN THIS
PRODUCT HAS HAD (product owner, 2026-08-25). Before it, the family rendered at THREE sizes and the
largest group stated nothing at all: 17 error panels declared no `font-size` and therefore inherited
the BROWSER DEFAULT of 16px — there is no base `font-size` anywhere in this product, `body` sets only
`margin` — while `.account-detail__*` sat at 0.94rem and the page intro at 0.875rem.
📌 The page intro is the reference because it is the panel a reader meets first on every screen.
⚠️ It is a SIZE, so it is deliberately NOT re-pointed in the dark scope: a ground changes what ink
is legible, never how large the words should be. */
--rc-font-size-note: 0.875rem;
/* Radius */
--rc-radius-sm: 0.375rem;
--rc-radius-md: 0.75rem;
--rc-radius-lg: 1.25rem;
/* Elevation */
--rc-shadow-soft: 0 0 40px 5px rgb(0 0 0 / 5%);
--rc-shadow-card: 0 2px 16px rgb(44 55 75 / 8%);
/* ⚠️ The RAISED state of a card you can click (product owner, 2026-08-19: a hover change that reads
as more than a darker border). Same navy hue as `--rc-shadow-card` so the two are one family —
twice the alpha and a slightly deeper offset, because it has to be legible against a card that
rests with NO shadow at all.
⚠️ It is a token rather than a value written into one rule, per this project's styling rule that
shadows are central: any clickable card wants this, and the medication round's is simply the
first. Do NOT re-point `--rc-shadow-card` to it — that is the RESTING elevation of every ordinary
`.card` in both shells, and raising it would lift every panel in the product. */
--rc-shadow-card-hover: 0 4px 20px rgb(44 55 75 / 16%);
/* ------------------------------------------------------------------
Shell layout tokens (Login / Admin / Resident).
CHANGE THE WIDTH AND PADDING HERE AND NOWHERE ELSE. Every shell sizes
its content from these, so adjusting the feel of the whole application
is a one-line edit rather than a hunt through layout files.
The public website is NOT sized from these - it keeps the SenoCare
template's own container widths.
------------------------------------------------------------------ */
/* Maximum width of a shell's content column. */
--rc-shell-content-max-width: 1400px;
/* Gutter between the content column and the viewport edge, so admin and
resident pages never run edge to edge. */
--rc-shell-gutter-x: 2rem;
--rc-shell-gutter-x-sm: 1rem;
/* Vertical breathing room above and below page content. */
--rc-shell-gutter-y: 2rem;
/* Admin/resident chrome. Sidebar width and top bar height are here rather than
in the layouts so the two panels stay aligned with each other by construction. */
--rc-shell-sidebar-width: 16rem;
--rc-shell-topbar-height: 4rem;
/* Spacing scale used by shell chrome. */
--rc-space-xs: 0.25rem;
--rc-space-sm: 0.5rem;
--rc-space-md: 1rem;
--rc-space-lg: 1.5rem;
--rc-space-xl: 2.5rem;
/* ------------------------------------------------------------------
Tabular data.
APPLICATION-WIDE STANDARD (product owner, 2026-07-29): the outer edge
padding for any tabular data anywhere in the product - Syncfusion grids,
plain HTML tables, list rows. Set here so every table in every feature
indents identically and one edit re-spaces all of them.
It equals --rc-space-lg on purpose: that is the card's own padding, so a
grid sitting flush inside a card lines its first column up with the text
of every ordinary card on the page.
------------------------------------------------------------------ */
--rc-table-edge-padding: var(--rc-space-lg);
/* Inner padding between columns. Smaller than the edge, so the outer margin
reads as deliberate rather than as one more column gap. */
--rc-table-cell-padding-x: 0.75rem;
/* ------------------------------------------------------------------
Resident portal.
The portal is read by residents and their family - often elderly, often on a
phone or tablet - whereas the admin portal is read by staff at a desk. It
therefore runs a LARGER type scale and BIGGER tap targets than the admin
shell, deliberately, rather than sharing one scale across the product
(product owner, 2026-07-29).
Change these to re-tune the whole portal; the admin shell does not read them.
------------------------------------------------------------------ */
/* Body text. Admin runs 0.9375rem. */
--rc-portal-font-size: 1.0625rem;
--rc-portal-line-height: 1.65;
/* Minimum height for anything tappable. 44px is the long-standing accessibility
floor for a finger, and it is the reason the nav items are not simply links. */
--rc-portal-tap-target: 2.75rem;
/* The portal is a single centred column, much narrower than the admin content
cap - it is reading material, not a data grid. */
--rc-portal-content-max-width: 60rem;
/* Height of the brand bar. Sized around the logo it contains: the portal runs the
wordmark at 4rem, and this leaves ~0.75rem of air above and below it. Changing
the logo height without changing this makes the bar look crammed. */
--rc-portal-brandbar-height: 5.5rem;
}
/* ══════════════════════════════════════════════════════════════════════════════════════════════
THE DARK SCOPE (2026-08-22, RP118 — supersedes RP103's light ground)
⚠️⚠️⚠️ IT RE-POINTS THE TOKENS ABOVE; IT DOES NOT DEFINE A PARALLEL PALETTE. Every component in
this product already reads `--rc-color-background`, `--rc-color-surface`, `--rc-color-border`,
`--rc-color-dark`, `--rc-color-text` and `--rc-color-muted`, so re-pointing those six inside one
scope turns everything underneath it dark WITHOUT touching a single component stylesheet. A second
set of `--rc-dark-*` names would have to be adopted file by file, and every file that had not
adopted them yet would stay light — which is the same defect as having no dark mode at all, only
harder to see.
⚠️⚠️ HOW THE PRODUCT-WIDE ROLL-OUT HAPPENS (product owner, 2026-08-22: "I might use the dark theme
across the board later"). Today `AccountLayout` puts `data-rc-theme="dark"` on its own root, so the
scope covers the profile area and nothing else. Going product-wide is MOVING THAT ATTRIBUTE TO
`` in `App.razor` — one line, no rewrite, and it is the reason the values live here in the
theme rather than in the two scoped stylesheets that need them today.
⚠️⚠️⚠️ `--rc-color-dark` RESOLVES TO A LIGHT VALUE IN HERE, AND THAT IS CORRECT. The token means
"the strongest ink on this surface", not "the colour dark" — it is the heading/label colour
throughout the product. Reading the name literally and "fixing" it to something dark would make
every heading in this scope invisible against its own card. The same applies to `--rc-color-text`.
⚠️ The ACTION palette above is deliberately NOT re-pointed. Those ten colours are measured against
a 4.5:1 text floor on white and each carries its ratio in a comment; re-pointing them here would
silently invalidate every one of those measurements. A control that needs a dark-ground variant
gets one when somebody measures it — not as a side effect of this block.
══════════════════════════════════════════════════════════════════════════════════════════════ */
/* ⚠️⚠️⚠️ THE SECOND SELECTOR IS NOT A CONVENIENCE — WITHOUT IT THE DARK AREA'S OWN DIALOGS STAY WHITE
(2026-08-22, RP125). `SfDialog` appends its container to `document.body`, so a dialog opened from a
page inside `AccountLayout` is a SIBLING of the shell, not a descendant: measured on the published
site as `div.e-dialog > div.e-dlg-container.rc-modal > body`, with `shell.contains(dialog) === false`
and the nearest `[data-rc-theme]` ancestor NONE. A descendant selector off the shell would therefore
have matched nothing at all, while reading perfectly.
📌 It also means the white dialog reported in review was a SCOPE LEAK rather than a design choice:
its footer and inner note are painted by OUR `--rc-color-surface`, which resolved to the light value
only because the element sits outside the scope. `RcModal` puts the modifier on when the shell above
it cascades a dark theme, so no caller has to remember. */
/* ⚠️⚠️⚠️ AND THE THIRD SELECTOR IS A DATE PICKER'S POPUP, FOR EXACTLY THE SAME REASON (2026-08-23,
RP141). `SfDatePicker` appends its calendar to `document.body` just as `SfDialog` does, so a picker
placed on `/account/payslips` renders its INPUT inside the dark scope and its POPUP outside it — a
white calendar hanging off a dark field, which reads worse than either would alone.
⚠️⚠️ `CssClass` on the component is what puts the class on BOTH elements; there is no way to reach the
popup from the page's own markup, and no selector written against the shell can reach it either.
📌 Named here rather than given a block of its own, for the reason the modal selector already
records: two blocks holding the same tokens is two things to keep in step. */
/* ⚠️⚠️⚠️ THE LIGHT DEFAULTS FOR THE THREE TOKENS THE DARK BLOCK BELOW ALSO SETS, AND THEY MUST STAY
ABOVE IT (2026-08-25, RP178). The light theme needs them or a `.rc-note` outside the dark scope
resolves to nothing and renders with NO bar at all — a silent failure, since the text stays
perfectly readable. **They are declared HERE, before the dark block, because `:root` and
`[data-rc-theme="dark"]` are both (0,1,0):** once the attribute is on `` the two selectors
match the same element and whichever comes LAST wins. Below the dark block, these light values
silently won inside the dark scope. **Do not move them back down, and do not "tidy" them into the
main `:root` at the top of the file** — keeping them adjacent to the dark values is what stops the
pair drifting, and that was always the intent. */
:root {
--rc-note-accent: #01828A;
--rc-note-accent-warn: #D1424D;
--rc-color-inset: #F6F6F6;
/* ⚠️⚠️ A COMPLETED STEP, FOR `RcWorkflowSteps` (RP241) — AND THE PRODUCT HAD NO SUCCESS COLOUR AT ALL
BEFORE THIS. `--rc-color-green` is #15D4C9, which is cyan despite its name, and `--rc-action-record`
is the teal-green of an action family rather than a statement that something is finished. Declared
as a PAIR in both themes so the rail follows the shell; the first draft used a literal behind a
`var(…, #0F7F55)` fallback, which always applied and therefore never followed the theme at all.
📌 #0F7F55 carries white at 4.86:1, which clears the 3:1 floor for the tick it holds.
⚠️ The INK differs between themes and the fill does not: #1B6B43 is 6.2:1 on white, while the dark
scope needs a pale ink on a dark card. */
--rc-color-success: #0F7F55;
--rc-color-success-ink: #1B6B43;
/* ⚠️ The dashed ring on a step not yet reached. `--rc-color-border` is rgba(0,0,0,0.08) here — right
for a hairline between rows, far too faint to read as a dashed placeholder. */
--rc-color-border-strong: rgba(0, 0, 0, 0.26);
/* ⚠️ PC61 — "saved but not published" (the approved mock, 2026-09-22): the page editor's banner, the side
menu's count and dot, and the leave dialog's icon. Its OWN family, not --rc-warning-ink: that one is
an ink for text with no ground, and this is a filled amber with a dark label (8.4:1) plus a tinted
panel. Declared HERE, before the dark block, for the source-order reason stated above. The amber and
its ink are the same in both themes; the panel's ground, rule and text are what the dark block moves. */
--rc-pending: #F0A33A;
--rc-pending-on: #231A07;
--rc-pending-ground: #FFF4E0;
--rc-pending-line: #E8C07A;
--rc-pending-title: #6B4400;
--rc-pending-text: #5C4410;
}
[data-rc-theme="dark"],
.rc-modal--dark,
.rc-datepicker--dark {
/* The page ground. The example's `--page-bg`. */
--rc-color-surface: #171D28;
/* Anything raised off the ground: a card, a tile, a panel, the bar. The example's `--card`. */
--rc-color-background: #1F2635;
/* ⚠️ AN OPAQUE HAIRLINE, NEVER THE LIGHT THEME'S `rgba(0, 0, 0, .08)`. A translucent black edge
over a #1F2635 card computes to something DARKER than the card it is meant to outline, so the
border disappears and every tile loses the edge the design is built on. */
--rc-color-border: #2E3849;
/* The strongest ink — headings, labels, figures. See the warning above before "correcting" it. */
--rc-color-dark: #E8EBF1;
--rc-color-text: #E8EBF1;
/* Secondary ink: facts, leads, captions. */
--rc-color-muted: #8B94A8;
/* ⚠️ `--rc-color-on-dark` is the ink used ON a navy surface (the sidebar, the account menu).
Those surfaces do not change here, so neither does it. Stated so its absence reads as a
decision rather than as an omission. */
/* ⚠️ Elevation is carried by BLACK here, not by the navy of the light theme. A navy shadow on a
navy-black ground is invisible, so a tile would lose its lift entirely and read as flat. */
--rc-shadow-card: 0 1px 2px rgb(0 0 0 / 40%), 0 8px 24px rgb(0 0 0 / 38%);
--rc-shadow-card-hover: 0 2px 4px rgb(0 0 0 / 46%), 0 14px 32px rgb(0 0 0 / 44%);
--rc-shadow-soft: 0 0 40px 5px rgb(0 0 0 / 35%);
/* ── Ink for the note bars ──────────────────────────────────────────────────────────────────
⚠️⚠️ THE BRAND TEAL AND CORAL ARE LIGHTENED FOR THIS GROUND, and the two are NOT
interchangeable with the action tokens. `--rc-action-primary` (#01828A) is measured for white
and drops to roughly 2.6:1 against #171D28 — a bar nobody can see. These are the example's own
dark-mode values. */
--rc-note-accent: #21A3AB;
--rc-note-accent-warn: #D1424D;
/* A chip / inset ground: one step up from a card, never down. */
--rc-color-inset: #262F40;
/* ⚠️⚠️ THE DARK HALF OF THE SUCCESS PAIR (RP241). The FILL is the same #0F7F55 as the light theme —
it carries white at 4.86:1 on either ground — while the INK must be pale here: #1B6B43 on the
#1F2635 card would be 1.6:1 and effectively invisible. 📌 That asymmetry is the reason this is a
pair rather than one token: a single value cannot serve a fill and a label on opposite grounds. */
--rc-color-success: #0F7F55;
--rc-color-success-ink: #8FDCA8;
/* ⚠️ The dashed ring on a step not yet reached, one step clear of `--rc-color-border` (#2E3849). */
--rc-color-border-strong: #46536A;
/* ⚠️⚠️ DECLARED FOR THE FIRST TIME HERE, AND THAT IS THE POINT (product owner, 2026-08-25 — the
Residency terms *Draft* badge was near-white on near-white). `--rc-color-surface-muted` is read
by six rules and was DECLARED NOWHERE, so every one of them fell through to a light literal
(#F1F5F7 / #F7F8FA) — while `--rc-color-dark`, which several of them use as their ink, IS
re-pointed here to the near-white #E8EBF1 (RP184). Light ground, light ink, invisible content.
📌 Defining it in this scope fixes all six at once BECAUSE they already read it with a fallback:
the token was a contract nobody had honoured on dark. ⚠️ It matches `--rc-color-inset` today and
is kept separate because the two say different things — "a quieter surface" and "a well sunk
into one" — and a token doing two jobs is exactly what RP184 had to unpick. */
--rc-color-surface-muted: #262F40;
/* ⚠️⚠️⚠️ THE DARK SCOPE HAS A SECOND HALF, AND IT IS IN `syncfusion-brand.css` (2026-08-25,
RP179). Twelve `--color-sf-*` re-points — the dialog ground, the calendar and dropdown
flyout, the input groups, the placeholders, the icons and the secondary inks — used to sit
HERE, and every one of them silently reverted to Syncfusion's light default the moment the
attribute moved to ``: the vendor declares them all at `:root` in `bootstrap5.3.css`,
which loads AFTER this file, and `:root` and `[data-rc-theme="dark"]` are both (0,1,0).
⚠️⚠️ THE SELECTOR LIST ABOVE AND THE ONE OVER THERE MUST STAY IDENTICAL, or a dialog resolves
our surfaces from one scope and Syncfusion's from the other — the half-dark state RP125
exists to prevent. `DarkScopeSelectorListGuardTests` fails if they drift.
📌 Anything reading a `--rc-*` token belongs here; anything re-pointing a VENDOR token
belongs in the file that loads after the vendor. That is the whole rule. */
/* ══ THE LIFTED INKS — ONE PER ACTION FAMILY (2026-08-24, RP160) ═══════════════════════════
⚠️⚠️⚠️ EVERY ACTION COLOUR IN THIS PRODUCT FAILS THE 4.5:1 TEXT FLOOR ON THE DARK CARD, AND
OUTLINED IS THE DEFAULT BUTTON SHAPE (RP9) — an outlined button draws its LABEL in the family
colour, so without this table every action button on a dark screen is under the readability
floor. Measured against #1F2635, where buttons actually sit:
family fill on dark lifted ink on dark
primary/open #01828A ⛔ 3.29:1 #21A3AB ✅ 4.97:1
edit #0049D0 ⛔ 2.06:1 #5B8DEF ✅ 4.69:1
status #B5179E ⛔ 2.58:1 #CF68C0 ✅ 4.61:1
move #7C5CE0 ⛔ 3.22:1 #967DE6 ✅ 4.60:1
record #0D837D ⛔ 3.29:1 #3D9C97 ✅ 4.62:1
restore #A16B04 ⛔ 3.33:1 #B48936 ✅ 4.74:1
document #2A7A32 ⛔ 2.83:1 #5F9B65 ✅ 4.59:1
destructive #D1424D ⛔ 3.31:1 #DD717A ✅ 4.84:1
⚠️⚠️⚠️ THIS SUPERSEDES RP126's NARROWNESS, AND *ONLY* ITS NARROWNESS. That decision said a
family gets a dark variant "when somebody measures it" and warned that converting nine on the
strength of one is how a known-good ratio is replaced by an unknown one. All eight are measured
now, so the condition it set is met rather than waived.
⚠️⚠️ AN INK TOKEN, NEVER A RE-POINT OF THE FILL — AND RP126 DID THE LATTER, WHICH WAS A LIVE
DEFECT. `--rc-action-edit` was re-pointed to #5B8DEF here, and the family rule uses that same
token as the HOVER BACKGROUND with #FFF text: white on #5B8DEF is 3.23:1, so hovering
`Edit contact details` on this page produced an unreadable label. Splitting ink from fill is
what fixes it — the resting label keeps #5B8DEF, the hover fill goes back to the saturated
#0049D0, where white is 7.33:1. RP132 already had this shape for the teal; it is now the rule
for all eight rather than an exception for one.
⚠️⚠️ PRIMARY/OPEN KEEPS #21A3AB (product owner, 2026-08-24). The RP160 table computed #349BA1
for this slot; #21A3AB was already SHIPPED and browser-measured under RP132, and a second teal
for one job is exactly the drift these tokens exist to prevent — the same call RP160 made for
Edit. It is also the BETTER value, not a compromise: 4.97:1 against #349BA1's 4.58:1.
⚠️ It is the value the note bars above use on this ground, so the profile area's teal ink is
ONE colour rather than two near-misses.
⚠️ And it is deliberately NOT a re-point of `--rc-action-primary`: that token is the FILL of
`.account-detail__button`, where white on it is 4.60:1, so re-pointing it would fix the link
and break the button in one edit.
⚠️ THE PASTEL EDGE IS NOT TABLED — it is derived with `color-mix` from the fill it borders, in
`syncfusion-brand.css`. See RP159: derive a decoration's colour from the colour being painted,
never from a copy of it. */
--rc-action-primary-ink: #21A3AB;
--rc-action-edit-ink: #5B8DEF;
--rc-action-status-ink: #CF68C0;
--rc-action-move-ink: #967DE6;
--rc-action-record-ink: #3D9C97;
--rc-action-restore-ink: #B48936;
--rc-action-document-ink: #5F9B65;
--rc-action-destructive-ink: #DD717A;
/* ⚠️⚠️ WHATSAPP IS DELIBERATELY ABSENT FROM THIS BLOCK, AND THE ABSENCE IS THE DECISION. Every
family above is OUTLINED, so its ink is text on a dark card and has to be lifted. WhatsApp is
FILLED — brand green with a dark glyph — so both halves travel with the button: the glyph is
9.38:1 on the fill whatever is behind it, and the fill is 7.63:1 on this #1F2635 panel.
⛔ An override here would repaint the glyph #25D366 on a #25D366 fill. */
/* ⚠️⚠️ THE ALERT RED, LIFTED FOR A DARK GROUND (product owner, 2026-08-25). #A11B1B is the right
red on white and measures 1.94:1 on the #1F2635 card — dark-on-dark, which reads as absent
rather than as urgent. #fe6868 measures 5.33:1 there and 4.70:1 on the 12%-coral chip tint.
⚠️ Declared ONLY here, and every rule keeps #A11B1B as its `var()` FALLBACK, so the light theme
is unchanged BY CONSTRUCTION rather than by two values happening to agree — RP160's shape.
⚠️⚠️ IT IS AN **INK**, NEVER A FILL (RP171). Two rules paint an appointment with #A11B1B as a
BACKGROUND and put white on it — the diary's outstanding event and the roster's unfilled gap —
and lifting those would drop white-on-red to about 2.8:1. They keep the strong red.
⚠️⚠️ AND IT IS NOT APPLIED WHERE THE PANEL ITSELF STAYS LIGHT. The error toast, the wizard's
error note, the invoice "late" chip and the billing-run error all paint an opaque #FBDCDC-family
ground that the dark theme does not override, so #A11B1B is still the readable ink on them —
lifting it there would put #fe6868 on pale pink. ⬜ **Those panels being light on a dark page is
its own gap, raised with the product owner and deliberately not fixed here.**
📌 The badges and the maintenance room chip already carry their own dark overrides and are
untouched, so this token does not give them a second opinion. */
--rc-danger-ink: #fe6868;
/* ⚠️⚠️ THE WARNING INK, THE OTHER HALF OF THE PAIR (product owner, 2026-08-25 — "all three should
change together"). `#7A5300` is the right amber on white and measures ~2.2:1 on the #1F2635 card.
Three rules ink text with it and set NO ground of their own — `.wizard-field__hint--warning`,
`.wizard-actions__reason` and `.rc-invoice-totals__warning` — so all three were dark-on-dark.
⚠️⚠️ IT REUSES THE DARK THEME'S EXISTING AMBER (`--rc-action-restore-ink`) RATHER THAN ADDING A
FOURTH COLOUR. The workstream already carries three reds by role and that is recorded as a cost;
repeating it in amber would be doing it on purpose. **One amber on dark, two names for it — the
role that needs it and the action family that already had it.**
⚠️ Declared ONLY here, with `#7A5300` kept as each rule's `var()` fallback, so the light theme is
unchanged BY CONSTRUCTION — the same shape as `--rc-danger-ink`. */
--rc-warning-ink: #B48936;
/* PC61 — the mock's own values, exactly: ground #3A2D14, rule #7A5A1F, title #FFD592, text #E7CFA3. */
--rc-pending-ground: #3A2D14;
--rc-pending-line: #7A5A1F;
--rc-pending-title: #FFD592;
--rc-pending-text: #E7CFA3;
color-scheme: dark;
}
/* ⚠️⚠️⚠️ THESE THREE LIGHT DEFAULTS USED TO SIT HERE, AFTER THE DARK BLOCK, AND THAT BROKE ALL THREE
TOKENS THE MOMENT THE THEME WENT PRODUCT-WIDE (found and fixed 2026-08-25, RP178).
`:root` and `[data-rc-theme="dark"]` are BOTH specificity (0,1,0). While the attribute lives on a
`
` — `AccountLayout`'s shell — the two match DIFFERENT elements and the nearer one wins, so the
dark values applied and everything looked correct. Move the attribute to ``, which is what §4
calls "one line, no rewrite", and both selectors match the SAME element: the tie falls to source
order and the LIGHT values win INSIDE THE DARK SCOPE.
✅ Measured on the published site with the attribute flipped onto ``:
`--rc-color-inset` resolved to **#F6F6F6** on a dark page, and `--rc-note-accent` — which is what
`RcAlert` paints its bar with — resolved to the light **#01828A**.
📌 They have been moved ABOVE the dark block, which fixes the cascade and keeps the pair adjacent,
which is what the original note wanted. See the block below. */
/* ======================================================================
The page heading's focus ring.
`Routes.razor` uses , which stamps tabindex="-1"
on the page's
and focuses it after every navigation so a screen-reader user
lands on the heading rather than at the top of the chrome. That is worth keeping.
The side effect is that the browser then paints its DEFAULT focus ring around the
heading — a black box across the full content width, on every page, after every
navigation. It looks like a rendering fault and was reported as one.
⚠️ Removing the ring here is safe, and ONLY here. tabindex="-1" means the element
cannot be reached by tabbing, so this focus is always programmatic — there is no
keyboard user whose position is being hidden. Do NOT generalise this rule to
:focus on other elements; every genuinely tabbable control must keep a visible
focus indicator.
====================================================================== */
h1[tabindex="-1"]:focus,
h1[tabindex="-1"]:focus-visible {
outline: none;
}
/* ════════════════════════════════════════════════════════════════════════
THE FAMILY PORTAL'S OWN SCREENS.
⚠️⚠️ THIS IS THE PORTAL'S HOME SHEET, AND IT IS NO LONGER THE ONLY ONE IT
LOADS. This block used to say "ResidentPortalLayout links this file and
nothing else"; that stopped being true at TS14, when the shell took the
Syncfusion theme for the testimonials rating — and syncfusion-brand.css
came with it, because the three are a cascade contract rather than a menu.
⚠️ CORRECTED 2026-09-05, having been relied on while false: it is what
makes `rc-num` and `rc-table--stacked` (both declared in
syncfusion-brand.css) work on the portal's own tables. Read
ResidentPortalLayout's own HeadContent before believing either version.
⚠️⚠️ WHAT IS STILL TRUE, AND IS THE REASON RULES BELONG HERE: a rule this
shell needs is written in THIS file. syncfusion-brand.css scopes much of
its own furniture to `.account-shell__body` or keys it on `.e-btn`, so a
portal rule dropped in there can silently reach nothing.
⚠️⚠️ AND `.btn` IS NOT AVAILABLE TO THIS SHELL AT ALL. It is declared once,
as `.login-shell__body ::deep .btn` in LoginLayout's SCOPED sheet (P-D153),
so `class="btn btn-primary"` on a portal page is a raw browser button. Use
`.rc-portal-btn` below. It fails in complete silence — no build error, no
console warning, no failing test — and merely looks like markup nobody
finished, which is how the invoices list's own "Pay now" shipped unstyled.
════════════════════════════════════════════════════════════════════════ */
/* ---- The family portal's invoices screen (stage 10). ---- */
.rc-portal-invoices {
width: 100%;
border-collapse: collapse;
}
.rc-portal-invoices th,
.rc-portal-invoices td {
padding: 0.6rem var(--rc-table-cell-padding-x, 0.75rem);
border-bottom: 1px solid var(--rc-color-border);
text-align: left;
}
.rc-portal-invoices th {
font-size: 0.75rem;
text-transform: uppercase;
letter-spacing: 0.04em;
color: var(--rc-color-muted);
}
.rc-portal-balance {
font-size: 1.05rem;
}
/* ⚠️ The word "overdue" is IN THE TEXT, not conveyed by this colour — a colour-blind
reader must get the same information. The panel only ever renders for an invoice
where payment is actually required, which is what keeps a fee-free resident off it. */
.rc-portal-overdue {
padding: 0.75rem 1rem;
border-radius: var(--rc-radius, 0.5rem);
background-color: #FBDCDC;
color: #A11B1B;
}
.rc-portal-pay {
display: grid;
gap: 0.5rem 1.5rem;
margin: 0 0 0.75rem;
}
.rc-portal-pay div {
display: flex;
flex-wrap: wrap;
gap: 0.5rem;
}
.rc-portal-pay dt {
min-width: 9rem;
color: var(--rc-color-muted);
}
.rc-portal-pay dd {
margin: 0;
}
.rc-portal-pay__note {
font-size: 0.875rem;
color: var(--rc-color-muted);
}
/* ---- The family portal's SECTION TILES (feature 5, PS9 / PS10). ----
⚠️⚠️⚠️ THIS IS THE THIRD COPY OF THIS TILE TREATMENT, AND THAT IS A KNOWN COST
RATHER THAN AN OVERSIGHT. `ResidentProfile.razor.css` and
`AccountDashboard.razor.css` each carry their own, because BOTH ARE SCOPED
stylesheets and scoped CSS is never shared between components (P-D20). Writing
`rc-profile-tile` here would compile to a selector that matches nothing — the
class would be plainly present in the markup and do absolutely nothing, which is
the P-D153 trap.
⚠️ PROMOTION IS OWED AND IS ITS OWN SLICE. Merging the three means editing two
accepted, published screens, which is not this feature's scope. The five accent
hues below are COPIED FROM `ResidentProfile.razor.css` — its comment carries the
measured contrast ratios (blue 5.17/6.70, teal 3.74/5.47, violet 5.70/7.10,
red 4.83/6.47, green 3.30/5.02, white-on-badge / ink-on-white). **Change them
together or the two sides of the product drift.**
──────────────────────────────────────────────────────────────────────── */
.rc-portal-tiles {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(13rem, 1fr));
gap: 0.75rem;
/* ⚠️ RP35: every card in a row takes the height of the tallest. `stretch` is
already the default — it is stated so the next person does not "tidy" it
into `start` and give the row several bottom edges. */
align-items: stretch;
}
.rc-portal-tile {
display: flex;
flex-direction: column;
gap: 0.375rem;
padding: 0.875rem;
background-color: var(--rc-color-background);
border: 1px solid var(--rc-color-border);
border-radius: var(--rc-radius-md);
/* ⚠️ The portal shell underlines every non-button anchor (see its layout's scoped
sheet). A tile is a card, not a sentence, so it opts out — and it must opt the
LABEL out too, because text-decoration propagates from the anchor to its
in-flow descendants. */
text-decoration: none;
}
/* ⚠️ 38px at a 10px radius — the admin tile's own metrics, so a reader meets ONE
tile in this product rather than three. Deliberately not `--rc-radius-sm`, which
is the control radius and would read as a button rather than as a mark. */
.rc-portal-tile__icon {
display: inline-flex;
align-items: center;
justify-content: center;
flex: 0 0 auto;
width: 38px;
height: 38px;
background-color: var(--rc-tile-badge, var(--rc-color-primary-dark));
border-radius: 10px;
color: #ffffff;
}
.rc-portal-tile__label {
font-weight: 500;
color: var(--rc-tile-ink, var(--rc-color-text));
/* ⚠️ Stated again on the label, not only on the anchor: the shell's underline rule
is a descendant selector and propagation is what actually draws the line. */
text-decoration: none;
}
/* The plain fact line — what the section shows. Muted, because the CHIP below is the
thing that changes and should catch the eye first. Mirrors `rc-profile-tile__fact`. */
.rc-portal-tile__fact {
font-size: 0.85rem;
line-height: 1.5;
color: var(--rc-color-muted);
overflow-wrap: anywhere;
}
/* The chip: the count or status, as a pill (product owner, 2026-09-06).
⚠️⚠️ `margin-block-start: auto` IS WHAT PINS IT TO THE BOTTOM of a tile that RP35 has
stretched to its tallest neighbour — without it the chips sit at five different
heights across the grid, which is exactly the ragged edge RP35 exists to remove. It
needs the tile to be a flex COLUMN; the two rules are one mechanism and deleting
either leaves the other doing nothing visible.
⚠️ `align-self: flex-start` so it hugs its own text rather than stretching the width
of the tile — a full-width pill reads as a banner, a different weight of statement.
📌 Copied part for part from `rc-profile-tile__chip`. The two are one design; change
them together. */
.rc-portal-tile__chip {
align-self: flex-start;
margin-block-start: auto;
padding: 0.16rem 0.5rem;
background-color: var(--rc-color-inset);
border-radius: 999px;
font-size: 0.69rem;
font-weight: 400;
letter-spacing: 0.06em;
text-transform: uppercase;
line-height: 1.5;
color: var(--rc-tile-ink, var(--rc-color-muted));
}
/* ⚠️⚠️ ONLY A CHIP SOMEBODY SHOULD ACT ON TAKES THIS — an overdue balance, an unread
message. Colouring every chip makes none of them mean anything.
⚠️ `--rc-color-secondary-dark` is the DARKENED coral (4.57:1); the raw brand coral is
3.49:1 and under the text floor.
⚠️ The chip's WORDS already say "overdue" or "unread", so the colour is a second
signal and never the only one. */
.rc-portal-tile__chip--alert {
background-color: rgb(243 77 89 / 12%);
color: var(--rc-color-secondary-dark, #D1424D);
}
/* The third tone: SETTLED. Added 2026-09-25 for the Photographs & marketing tile (product
owner), and it mirrors the admin profile tile's `--settled` exactly — the same record seen
from the other side should not read as two different badges.
⚠️⚠️ IT IS NOT "GOOD NEWS". The rule it states is "nothing is outstanding here", which is
why a family who was asked and DECLINED gets this tone: they have given a real answer.
⚠️ Same caution as the alert above — the chip's WORDS already say what it means, so the
colour is a second signal and never the only one.
📌 Computed: #1F7A34 on the resulting wash is 5.6:1, clear of the 4.5:1 text floor. */
.rc-portal-tile__chip--settled {
background-color: rgb(42 122 50 / 12%);
color: #1F7A34;
}
/* ⚠️ No `::deep` — unlike the admin tile's rule, these live in a GLOBAL stylesheet, so a
plain descendant selector reaches NavIcon's