/* ═══════════════════════════════════════════════════════════════════════
Tempus — rebuild stylesheet
Brand tokens are the repo's real values. They were read off style.css, the
stylesheet the pre-rebuild site used — DELETED on 2026-09-09, once the last
three hand-written pages moved onto this one and nothing loaded it any more.
The values are unchanged by that; this line records where they came from, so
nobody goes looking for a file that is now only in the git history.
Typography follows Font Lab preset 1, "Keep, but tune": the existing
faces (League Spartan + Inter) with the measure, size and line height
corrected — the lab found the fonts were never the problem, the
~95 characters-per-line measure was.
═══════════════════════════════════════════════════════════════════════ */
:root{
/* ── Brand colours — the single source of truth (button/colour spec §2) ──
Four values, defined once, never written as a literal hex again anywhere
below this block. The spec exists because the sibling support site has
#091464 written out 96 times and #E6007E 92 times, which is exactly how a
second, undocumented pink hover crept in there. Same drift had started
here: .btn-primary:hover was #c80070, a third pink nobody had approved.
It is now var(--brand-pink-hover).
2026-09-08 — the approved palette lands, and it names two of these colours
differently: the navy is --tile, the pink is --action, the pink hover is
--action-press. Those names are added below as ALIASES pointing back here,
NOT as fresh hex. Writing #091464 out a second time under a new name would
leave the site running two colour systems side by side, which is precisely
the drift this block exists to stop. One declaration, many names.
DELETED 2026-09-08: --brand-blue-hover:#0A1880. It had zero consumers from
the day it was written — nothing on this site ever hovered to a second
navy. The approved palette's second navy (--tile-2:#0b1878) is deliberately
NOT declared in its place, because it would have zero consumers too: the
CTA band's middle gradient stop is #1a2a8a, and changing that is a visible
change nobody has approved. Declare --tile-2 at the point something
actually uses it, not before.
──────────────────────────────────────────────────────────────────────── */
--brand-blue:#091464;
--brand-pink:#E6007E;
--brand-pink-hover:#C9006E;
/* ── The approved palette (operator sign-off, 2026-09-08) ────────────────
Surfaces, ink and action. Three entries are the brand colours above under
their palette names; the rest are new. Every ratio quoted here was
measured, not estimated, and the measurements are the reason several of
these values are not the obvious ones:
--ink #14161f 18.04:1 on canvas, 16.42:1 on parchment.
--ink-muted #5b6070 6.27:1 on canvas, 5.70:1 on parchment. It
replaces #6b7280, which was 4.83:1 / 4.40:1 —
i.e. the OLD muted grey fails AA on the NEW
parchment. The two changes must never be
separated, or the retrofit ships a contrast
regression in text it never meant to touch.
--ink-faint #8a8fa3 3.21:1 on canvas, 2.92:1 on parchment. This is a
DECORATIVE tier: illegal for normal-size text on
canvas, and illegal for text of ANY size on
parchment, because 2.92 misses even the 3:1
large-text bar. "Just use it at 24px" does not
rescue it on parchment.
--action #e6007e 4.50:1 on canvas — it clears AA by 0.0008 — and
4.10:1 on parchment, which FAILS. Fills and
large text only, and never at reduced opacity.
--action-press #c9006e 5.66:1 on canvas, 5.16:1 on parchment. The only
pink that is legal as normal-size text on both
grounds, which is why D2 makes it the inline
link colour. On navy it is 2.86:1 — never put it
on a dark surface.
--action-on-dark #ff5cae 5.71:1 on the navy. Use it wherever pink meets a
dark surface; #e6007e there is 3.60:1 and fails.
--on-dark-muted #b9bed6 8.80:1 on the navy, 10.43:1 on the footer.
--hairline #e3e5ee 1.26:1 on canvas. Fine for a decorative card
edge (WCAG 1.4.11 exempts decoration) and NOT
fine as the only visible edge of a control — see
--form-border below.
--hairline-hover #7b8093 The edge a card, tile or post card takes when
the pointer is over it. THREE numbers have to
clear 3:1 here, not one, and this value clears
all three:
3.12:1 the STEP — resting edge (--hairline
#e3e5ee) to hovered edge. This is the
change a visitor actually perceives as
the hover happening, and it is the
hardest of the three to clear.
3.92:1 the hovered edge on canvas
3.57:1 the hovered edge on parchment
Both grounds are measured because cards sit on
BOTH surfaces; a value that passed on white
while failing on parchment would drop the cue on
half the site.
TWO VALUES THAT LOOK RIGHT AND ARE NOT, so
nobody re-derives them:
--ink-faint #8a8fa3 — 2.92:1 on parchment. It
fails outright, and being an existing token
is not a reason to reach for it.
#858a9e — 3.43 canvas / 3.12 parchment, so it
clears the EDGE bar and looks like a pass.
Its step is only 2.73:1. It was the
front-runner until the step was measured.
For scale: the old #d8dbe2 was a step of 1.10:1
— roughly a tenth of what the guideline asks.
--form-border #7b8093 The edge of an input, a select or a textarea.
Deliberately the SAME value as --hairline-hover
and measured the same four ways — 3.92:1 on
canvas, 3.57:1 on parchment, 3.79:1 on the
Ask-an-AI box's own #FAFBFD fill, and a 3.12:1
step away from --hairline so a field's edge
cannot be mistaken for a card's. Raised from
#d4d7de (1.44:1) on 2026-09-08; the full note is
on the token itself.
Naming note: --tile is a COLOUR and .tile (~line 371) is a card class. They
are unrelated — CSS keeps custom properties and class names in separate
namespaces — but a grep for "tile" returns both.
──────────────────────────────────────────────────────────────────────── */
--canvas:#ffffff;
--parchment:#f3f4f9;
--tile:var(--brand-blue);
--ink:#14161f;
--ink-muted:#5b6070;
--ink-faint:#8a8fa3;
--on-dark:var(--canvas);
--on-dark-muted:#b9bed6;
--action:var(--brand-pink);
--action-press:var(--brand-pink-hover);
--action-on-dark:#ff5cae;
--hairline:#e3e5ee;
/* Approved by the operator 2026-09-08: the card hover edge must clear 3:1.
It is a NAMED token and not a fourth loose hex because three separate rules
(.card, a.tile, .postcard) have to move together — when they were three
literals, one of them was always going to be missed.
If you change this value, the number to check FIRST is its contrast against
--hairline directly above, not against the page background. That step is
the binding constraint and it is the one that is easy to forget. */
--hairline-hover:#7b8093;
/* HOW A CARD ANSWERS THE POINTER. Requested by the operator 2026-09-09: the
card should GROW slightly rather than slide upwards, which is what it did
before ("I think that we should have the card actually increase in size a
little bit").
Named for exactly the reason --hairline-hover above is named — .card,
a.tile and .postcard are one hover language and must move together. They
used to lift by three different literals (-4px, -3px, -3px), which is how
you end up with a row of cards that answer the pointer three ways.
1.02 and not more. On the widest card on the site (~381px) it is 3.8px of
growth per side; anything larger starts to overlap the neighbouring card
rather than nudge it, and a marketing card that leaps reads as a bug.
If you raise it, the two numbers to re-check are the grid gaps it has to
stay inside (.cards 20px, .grid3 18px, .postgrid 22px) and whether the
card's 1px border still rasterises sharply — see the note on .card:hover. */
--card-hover-grow:1.02;
/* Legacy names, kept as aliases so every existing rule in this file — and
anything outside it that reads these — keeps working untouched. That
"anything outside" is not hypothetical: _source/build.py's review-file
chrome reads --font-display, --border-gray, --text-dark, --tempus-pink,
--text-gray, --pad and --dark-blue directly. Delete one of these aliases
and the review file silently loses its styling — no error, no build abort,
because CSS just drops a declaration it cannot resolve. New rules should
reference the palette names above. */
--tempus-pink:var(--action);
--dark-blue:var(--tile);
--text-dark:var(--ink);
--text-gray:var(--ink-muted);
--light-gray:var(--parchment);
--border-gray:var(--hairline);
/* DELETED 2026-09-08: --white:#fff. It had exactly one consumer (the page
background) while 45 literal #fff sat beside it doing the same job under no
name at all. Those literals are now split between --canvas (a white
SURFACE: the page, a card, a panel) and --on-dark (white INK sitting on a
dark surface: the navy bar, the CTA band, the footer, a filled pink
button). Same colour, two different jobs, and the job is what a future
dark-surface pass will need to be able to tell apart. */
--accent-blue:#3b82f6;
--quote-teal:#2BB3A3;
/* Control borders are deliberately DARKER than --hairline, and must stay that
way. A hairline round a card is decoration and WCAG 1.4.11 exempts it; the
border of an input is the only thing telling a user where the field is, so
it has to carry its own weight. Declared here on 2026-09-08 because
.askai-prompt-box has read var(--form-border,#D4D7DE) since the day it was
written while --form-border was declared NOWHERE in the repo — it rendered
only because of that inline fallback, so nobody ever noticed.
DARKENED 2026-09-08 from #d4d7de, which measured 1.44:1 on canvas and
1.31:1 on parchment against the 3:1 WCAG 1.4.11 asks of a control's
boundary. The comment above already said control borders had to be darker
than a hairline; the value did not do it — #d4d7de is only 1.15:1 away from
--hairline itself, so in practice every input on the site was outlined in
decoration.
WHY THIS EXACT VALUE, and it is not a taste call. FOUR numbers have to
clear 3:1, not one, and the fourth is the one that is easy to miss:
3.92:1 on canvas — the field's own white fill, and the white page
behind it.
3.57:1 on parchment — the same edge where the page under it is grey.
3.79:1 on #FAFBFD — the Ask-an-AI prompt box's own off-white fill.
3.12:1 the STEP from --hairline #e3e5ee. A form sits among cards edged
in --hairline, and if a field's edge is not distinguishable from
a decorative one then it is not doing the job this token exists
for. #868b9f clears the three grounds (3.38 / 3.08 / 3.27) and
fails this at 2.69:1 — the same trap that #858a9e fell into on
--hairline-hover, recorded there.
It is the SAME measured value as --hairline-hover and that is deliberate:
the site already owns a blue-grey that clears 3:1 everywhere, and inventing
a second one a shade away is how a palette doubles. Written as a literal
rather than var(--hairline-hover) because the two mean different things — a
hover state and a control edge — and either should be able to move without
dragging the other with it. */
--form-border:#7b8093;
/* typography — the tuned values.
Body/UI face is DM Sans (spec §7): headings stay League Spartan, everything
else — body copy, ALL buttons, labels, table headers — is DM Sans.
CORRECTION 2026-09-08 to what this comment used to claim. It said Inter was
kept in the fallback stack only to cover "the window between this file
shipping and the Google Fonts in build.py being updated". That
window closed long ago: build.py requests DM Sans, so DM Sans always loads
and the Inter entry in --font-body is inert. Inter is still REQUESTED, for
a completely different reason — lead-overlay.css hard-codes
'Inter', sans-serif on six rules with no DM Sans in the stack, and build.py
links that stylesheet on every built page. Drop Inter from the font request
and the lead-capture overlay, the site's only conversion path, falls back
to the system sans on all 18 pages — and it will never show up in a
screenshot, because the overlay is closed by default.
Leading 1.47 and the slight negative tracking are the approved Apple ladder
(2026-09-08), replacing 1.62 and no tracking at all. The tracking is a
token rather than a bare letter-spacing literal on body, so the next person
can find it. */
--font-display:'League Spartan',system-ui,sans-serif;
--font-body:'DM Sans','Inter',system-ui,-apple-system,sans-serif;
--body-size:17px;
--body-leading:1.47;
--body-tracking:-.011em;
/* DELETED 2026-09-08: --measure:34em and --measure-wide:52em. Both had zero
consumers. Rule 2.4 ("no measure cap anywhere") put max-width:none on
.article and on every p, which deleted every consumer they had ever had and
left the two tokens sitting in :root looking load-bearing. If a measure cap
is ever wanted again, the rule and the token come back together. */
--ink-h:var(--ink);
--ink-body:#3c4250;
/* --ink-body is a THIRD grey, sitting between --ink and --ink-muted, and the
approved four-step ink ladder has no slot for it. It is deliberately left
alone rather than folded into --ink: it sets the text colour of the whole
document (see body{} below), so re-pointing it would darken every paragraph
on the site — a visible change the operator has not signed off. Recorded
here so it reads as a decision rather than as something that was missed. */
--pad:clamp(20px,5vw,64px);
/* ── The vertical rhythm of the whole site (approved 2026-09-08) ─────────
--section is the padding a surface block keeps inside its own top and
bottom edges: 80px on a desktop, 56px on a narrow screen (the step-down is
the single @media rule in the sections block below). It replaces a
clamp(22px,1.9vw,32px) scale that predates the surface model — roughly a
2.5x increase, so every page is noticeably longer than it was.
ONE KNOB ON PURPOSE. Every section-padding override in this file is
derived from this token rather than written as its own number, so moving
the rhythm moves all of it together. Do not reintroduce a hard-coded
section padding anywhere; that is exactly how the five different
hand-tuned clamps this replaces came about.
--section-top is the shorter padding the FIRST section on a page gets. It
exists because the header is fixed and does not occupy flow, so
body{padding-top:58px} holds its space and the first section's own top
padding lands on top of that. At the full 80px that is 138px of empty
screen above every page's first word. .45 lands it on 36px, which is
within a couple of pixels of what .hero and .page-hero were already doing
by hand before this token existed. */
--section:80px;
--section-top:calc(var(--section) * .45);
/* THE SITE IS LIGHT-ONLY, AND SAYS SO. Operator decision, 2026-09-09, after
opening the dev site on an iPhone 15 with the system in dark mode.
There is no `prefers-color-scheme` rule anywhere in this file and there is
not meant to be: every surface here is a deliberate choice against a fixed
palette, and a half-honoured dark mode - navy bars that adapt, white cards
that do not - is worse than none. Declaring `light` stops the browser
auto-darkening the things it decides for itself (form controls, scrollbars,
the canvas behind a short page) on a device set to dark. Without it those
drift while everything painted by this file stays put, which is exactly
the mismatch the operator saw.
If a real dark mode is ever wanted, it is a design project with its own
token set, not a media query bolted on here. */
color-scheme:light;
/* Operator decision: cards, tiles, panels and CTA blocks are perfectly square,
so the colour band across the top of a card has no rounding to fight.
This token is used ONLY by card/tile/panel containers. The spec's 12px card
tier is deliberately NOT followed — the operator's zero overrides it.
STILL STANDING as of 2026-09-08. The pill reversal recorded below covers
BUTTONS ONLY; cards, tiles and panels stay square. */
--radius:0;
/* ── Radius scale (spec §5, as amended twice) ────────────────────────────
Spec scale: 4 small · 6 control · 8 overlay · 12 card · 9999 pill.
AMENDMENT 1 (operator, original — kept here rather than deleted, so nobody
re-derives it from scratch). Two parts: cards/panels are 0 rather than 12px
(--radius above), and buttons were "very square, minimal corner rounding",
so the primary CTA was NOT a pill and every button on the site sat at the
6px control tier. The consequence was stated plainly at the time, because
spec §9.1 warns about it: rank could no longer be encoded by SHAPE, so it
was carried by size, weight and shadow instead.
AMENDMENT 2 (operator, 2026-09-08) — REVERSES the button half of that, and
only the button half. Pills are back on every .btn variant: primary, ghost,
outline, bare, small and the header pair, plus the footer's mobile buttons
and the Ask AI row. Rank is now carried by FILL, SIZE and WEIGHT. Shape no
longer separates one button from another, because they all share it — and
the CTA's drop shadow has gone too (see the note where --btn-shadow used to
be), so what was a three-lever hierarchy is now a two-lever one and both
remaining levers have to be got right.
What amendment 2 does NOT touch, stated because "pills are back" is exactly
the sentence that gets over-applied: --radius stays 0, so cards, tiles,
panels, quotes and FAQ blocks are still square; and --r-control keeps
inputs, selects and textareas, because a pill-shaped text field is wrong.
──────────────────────────────────────────────────────────────────────── */
--r-control:6px; /* inputs, selects, textareas, and menu/panel chrome */
--r-overlay:8px; /* modals and dialogs, >=768px only */
--pill:9999px; /* every button, plus badges and status pills */
/* DELETED 2026-09-08: --r-small:4px ("checkboxes, inline chrome"). Zero
consumers — the generated pages contain no checkboxes at all.
RENAMED 2026-09-08: --r-pill:999px became --pill:9999px, which is the
approved palette's name and value. Renamed rather than added alongside,
because two pill tokens holding two different values in one :root is how
the next person picks the wrong one. Its old trailing comment read "NOT
buttons" — that was amendment 1 talking, and it is now exactly backwards.
--r-overlay was itself dead until 2026-09-08: .askai-modal hard-coded its
own 8px corner instead of reading the token. It now reads the token. */
/* ── One control height (spec §9.5) ──────────────────────────────────────
The source site renders a button at 38px, a text input at 36px and a select
at 40px — three heights in one form row. We pick ONE and apply it to
button + input + select together: 44px, which is also the minimum touch
target, so a thumb-driven marketing site gets it for free.
The 32px small tier below is a deliberate, explicitly opted-into second
size for repeatable in-page actions (the Ask AI row), not drift. */
--control-h:44px;
--control-h-sm:32px;
/* REMOVED 2026-09-08: --btn-shadow, the primary CTA's drop shadow, taken
verbatim from spec §4b. It existed because the operator had ruled the pill
shape out, so rank had to be carried by size, weight and shadow instead.
Pills are back (amendment 2 above), so shape carries rank again and the
shadow is no longer earning its place. Apple's method allows essentially
one decorative shadow tier, and it is reserved for product imagery — see
--shadow below. Do not reintroduce a button shadow to "make the CTA pop":
make it pink, filled, 700 and 44px tall instead.
Both of its references went with it. The second one mattered far more than
it looked: .btn-primary:focus-visible composed --btn-shadow INTO the focus
ring, so deleting the token alone would have made that whole box-shadow
declaration invalid and computed it to none — silently deleting the focus
ring on the most important button on every page. See the focus-ring block
below for why the rule was deleted rather than edited. */
/* The one surviving decorative elevation, and it does not get a new user
without a conversation. It is reserved for PRODUCT IMAGERY — .videowrap,
.visual, .uiframe and .shot, the four places real screenshots and video
land — plus exactly one piece of chrome: the desktop nav popover
(.mainnav .grp .menu), where elevation is information rather than
decoration because it says "this layer floats above the page". The three
card hover shadows and the two button shadows that used to read this token
were culled on 2026-09-08.
.shot WAS the fourth user, added 2026-09-08 for the home hero's product
screenshot. It is inside the policy rather than an exception to it — a
screenshot of the product is exactly what "product imagery" means — and it
is recorded here rather than added quietly, because the previous sentence
of this comment said a FIFTH user is how the shadow tier grows back, and
that sentence is still true. It now means a sixth. */
--shadow:0 1px 3px rgba(16,24,40,.08),0 12px 32px -12px rgba(16,24,40,.14);
/* Card colour band. Base height, and the doubled height it grows to on a
desktop hover. Both live here so the "doubles" relationship is visible.
Naming note: "band" means two unrelated things in this file. These two
tokens are the 6px colour rule across the top of a CARD. The OTHER meaning
is gone as of 2026-09-08: the navy CTA section's class .band was renamed
.surface-tile, so "band" now means one thing in this file again. That
resolved an ambiguity rather than creating one, and it is the reason the
surface classes are not called .band-navy or similar. */
--band-h:6px;
--band-h-hover:12px;
}
*{box-sizing:border-box;margin:0;padding:0}
html{scroll-behavior:auto} /* smooth scrolling fights the hide-on-scroll bar */
html:focus-within{scroll-behavior:smooth}
body{
font-family:var(--font-body);font-size:var(--body-size);line-height:var(--body-leading);
letter-spacing:var(--body-tracking);
color:var(--ink-body);background:var(--canvas);-webkit-font-smoothing:antialiased;
}
img{max-width:100%;display:block}
a{color:inherit}
/* ── Inline links in body copy (D2, operator 2026-09-08) ──────────────────
`a{color:inherit}` above is the whole of this stylesheet's link policy, and
it means an inline link inside a paragraph renders in the surrounding body
colour with no underline — i.e. it is not identifiable as a link at all.
Every other link on the site (nav, footer, cards, buttons) is styled by its
own component rule and is unaffected by this; PROSE was the gap.
The colour is --action-press #c9006e and NOT the brand pink #e6007e. That is
a measured call, not a taste one: #e6007e is 4.10:1 on the parchment sections
and fails AA outright, and 4.50:1 on white, which clears AA by 0.0008 and is
therefore not a number to build on. #c9006e is 5.66:1 and 5.16:1. The brand
pink stays where it earns its keep — filled buttons, where the white label
sits ON it rather than beside it.
Colour alone is never the only signal (WCAG 1.4.1), hence the underline. It
thickens rather than appears on hover, so the line does not shift.
THIS RULE HAS REAL CONSUMERS AS OF 2026-09-09, and it did not before. The
note here used to say no section in _source/content.py contained an inline
link, so the rule matched nothing. Bringing the contact page and the privacy
policy onto the generator brought seven links with them: three mailto: links,
one per contact card, and four outbound links in the policy — three in §14
and one in §19. Those two shapes are added to the selector list below. Leave
them there: a policy link that renders as plain black text is a link nobody
can see, on the one page where "where does this go?" is the whole question.
─────────────────────────────────────────────────────────────────────────── */
.article p a,.article li a,.article blockquote a,
.prose p a,.prose li a,.callout p a,.lede a,
.card p a,.accordion-content p a,.accordion-content li a{
color:var(--action-press);text-decoration:underline;
text-underline-offset:3px;text-decoration-thickness:1px}
.article p a:hover,.article li a:hover,.article blockquote a:hover,
.prose p a:hover,.prose li a:hover,.callout p a:hover,.lede a:hover,
.card p a:hover,.accordion-content p a:hover,.accordion-content li a:hover{
text-decoration-thickness:2px}
/* 600, not 700 (approved weight ladder, 2026-09-08). The ladder is
300/400/600/700 with 500 deliberately absent, and headings sit at 600. Two
s carry their own font-weight and are therefore NOT reached by this rule
— .hero h2.sub-head (300) and .askai-modal-title (600) — and two
s take
their weight from here while overriding the family: .site-footer h4 and
.aside h4. Those two are now pinned to 700 explicitly, because they are
11.5px uppercase micro-labels whose peers (.eyebrow, .postcard .cat,
.cmp-label) are all 700, and letting them drift to 600 would split one label
role across two weights for no reason. */
h1,h2,h3,h4{font-family:var(--font-display);color:var(--ink-h);line-height:1.12;font-weight:600}
h1{font-size:clamp(34px,5.2vw,54px);letter-spacing:-.02em}
h2{font-size:clamp(26px,3.4vw,36px);letter-spacing:-.015em;line-height:1.18}
h3{font-size:clamp(19px,2vw,22px);line-height:1.3;letter-spacing:-.01em}
p{max-width:none} /* measure is applied to .article only, never globally */
strong{color:var(--ink-h);font-weight:600}
.wrap{max-width:1180px;margin:0 auto;padding:0 var(--pad)}
.eyebrow{font-size:12px;letter-spacing:2.4px;text-transform:uppercase;font-weight:700;
color:var(--action-press);font-family:var(--font-body)}
/* ── buttons ─────────────────────────────────────────────────────────────
Built to the button & colour spec, with ONE deliberate departure.
HISTORY, kept because it explains why the rest of this block is shaped the
way it is. The spec (§3) encodes rank in SHAPE: the single page CTA is a
9999px pill, every other affirmative button is 6px and square-ish. The
operator ruled that out — "drop the entire sentiment of these rounded
buttons, very square buttons with very minimal corner rounding" — so for a
time every button here was 6px. That removed the spec's rank signal, which
§9.1 explicitly warns is the thing that most often breaks this design
language, and rank was carried by three levers instead: size, weight and a
drop shadow on the CTA alone.
REVERSED 2026-09-08 (operator). Pills are back on every .btn variant, so the
shape lever is live again — and because every button now shares it, shape
says "this is a button", not "this button outranks that one". The CTA's drop
shadow has been culled in the same pass (Apple's method keeps one decorative
shadow tier and reserves it for product imagery), so the three levers are now
two, and both have to be got right:
1. FILL — the CTA is the only SOLID pink button in a view. Everything
else is transparent with a hairline border.
2. SIZE — CTA 44px tall with 32px side padding; secondary 32px/12px.
3. WEIGHT — CTA 700; everything else 600. Weight 500 was removed from
the ladder entirely on 2026-09-08, so the old three-step
700/600/500 is now a two-step 700/600.
One CTA per view, same as before. A second one and none of the levers mean
anything.
Hover is a flat colour swap, not the source site's translucent overlay film.
The spec recommends this for a site with a handful of known button colours
(§8, §9.3) and it sidesteps the overlay's position:relative trap entirely.
The old translateY(-1px) lift is gone with it: a button that jumps reads as
soft, which is the opposite of what the operator asked for.
─────────────────────────────────────────────────────────────────────────── */
.btn{display:inline-flex;align-items:center;justify-content:center;gap:8px;
font-family:var(--font-body);font-weight:600;font-size:14px;line-height:20px;
min-height:var(--control-h);padding:10px 16px;border-radius:var(--pill);
border:1.5px solid transparent;cursor:pointer;text-decoration:none;
white-space:nowrap;transition:background-color .15s ease,border-color .15s ease}
.btn svg,.btn .ico{width:16px;height:16px;flex:none}
.btn[disabled],.btn:disabled,.btn.is-disabled{opacity:.5;pointer-events:none}
/* Primary CTA. Pink is the action colour and is never a background band.
White on #E6007E is 4.50:1 — it clears AA by 0.0008, so it must stay at full
opacity and must never be tinted or faded. Hover #C9006E is 5.66:1. */
.btn-primary{background:var(--action);color:var(--on-dark);border-color:transparent;
font-weight:700;padding:10px 32px}
.btn-primary:hover{background:var(--action-press)}
/* Secondary pink — the repeatable, in-page affirmative action. Same pink, so it
still reads as the yes-choice, but small and shadowless so it cannot compete
with the page CTA. This is the rank the Ask AI buttons use. */
.btn-sm{min-height:var(--control-h-sm);padding:6px 12px;font-size:12px;line-height:16px;
font-weight:600}
/* Neutral. Transparent, hairline border, and it INHERITS its text colour —
that is how the white-on-navy buttons in the header and the CTA band work:
the parent sets the colour and the button follows. .btn-ghost is the name the
existing markup already uses for this, so it keeps the visible border; the
spec's true border-less ghost is .btn-bare, which keeps the same 1.5px
transparent border so its height matches an outline button beside it. */
/* The 5%-black 1px shadow this pair used to carry was culled on 2026-09-08.
It was invisible under a transparent button on white, and actively wrong on
the navy header, where a BLACK shadow under a white-on-navy ghost button
contributes nothing at all. */
.btn-outline,.btn-ghost{background:transparent;color:inherit;
border-color:rgba(0,0,0,.1)}
.btn-outline:hover,.btn-ghost:hover{border-color:rgba(0,0,0,.28)}
.btn-bare{background:transparent;color:inherit;border-color:transparent;box-shadow:none}
.btn-bare:hover{background:rgba(0,0,0,.04)}
.btn-row{display:flex;gap:12px;flex-wrap:wrap;margin-top:22px;align-items:center}
/* ── one control height, and one focus ring (spec §4a, §8, §9.5) ──────────
Buttons take a 2px ring flush to the edge. Inputs take a 2px gap in the page
colour first, then the ring, so the ring does not touch the field border.
On navy — the header bar and the CTA band — a navy ring is invisible, so it
flips to white there. Focus that cannot be seen is not focus.
DELETED 2026-09-08, and the reason is worth reading before anyone writes
anything like it again. There used to be a fourth rule here:
.btn-primary:focus-visible{box-shadow:0 0 0 2px var(--brand-blue),var(--btn-shadow)}
Its job was to keep the CTA's drop shadow underneath the ring instead of
having it blown away by the focus rule. The shadow is gone, so the rule had
nothing left to preserve — but it could not simply have its token stripped
out and be left in place, and it could NOT be left behind when --btn-shadow
was deleted. An undefined custom property with no fallback makes the WHOLE
box-shadow declaration invalid at computed-value time; box-shadow is not
inherited, so it computes to none. And because that rule had already beaten
the generic .btn:focus-visible rule on the cascade (both are (0,2,0), it came
later), the browser would NOT have fallen back — the most important button on
every page would have rendered with no visible focus ring at all, with
nothing in the build or the tests to catch it. Deleting the rule lets the
generic one win, which is safe here because build.py never emits btn-primary
without btn. Never reintroduce a .btn-primary:focus-visible rule that
composes a var() without a fallback. */
button:focus-visible,.btn:focus-visible,a.btn:focus-visible,summary:focus-visible{
outline:none;box-shadow:0 0 0 2px var(--brand-blue)}
.hdr button:focus-visible,.hdr .btn:focus-visible,.hdr a:focus-visible,
.surface-tile .btn:focus-visible,.site-footer a:focus-visible{box-shadow:0 0 0 2px var(--on-dark)}
input:focus-visible,select:focus-visible,textarea:focus-visible{
outline:none;box-shadow:0 0 0 2px var(--canvas),0 0 0 4px var(--brand-blue)}
/* Button, input and select are the SAME height. This is spec §9.5's one fix and
the reason it exists — three heights in one form row is the tell that nobody
set a control height on purpose. Scoped to bare elements so the lead-capture
overlay, whose stylesheet loads after this one and styles its own fields by
class, is untouched. */
input:not([type=checkbox]):not([type=radio]):not([type=hidden]),select,textarea{
font-family:var(--font-body);font-size:14px;line-height:20px;
min-height:var(--control-h);padding:10px 12px;border-radius:var(--r-control);
border:1px solid var(--form-border);background:var(--canvas);color:var(--ink-h)}
textarea{min-height:calc(var(--control-h) * 2)}
/* ── header: full-bleed navy strip, flush to the top ───────────────────
This WAS a floating pill: .hdr was itself the width wrapper (`class="wrap
hdr"`), so it inherited the 1180px cap, sat 14px down from the top and was
ringed in 3px of white. Now .hdr is the full-bleed navy band and .hdr-inner
— which carries .wrap — holds the content on the normal 1180px grid.
A full-width bar and a centred content column cannot be the same element;
if you find yourself collapsing these two divs you are rebuilding the pill.
THE BOTTOM EDGE IS LOAD-BEARING, NOT DECORATION — do not "tidy it away".
The 3px white ring it replaces existed for exactly one reason, recorded
here before it was removed: on a white section the ring merged into the
background and read as nothing, but the moment the hide-on-scroll bar
revealed over a NAVY background it became a crisp outline, so navy-on-navy
never happened. Both the CTA band and the footer are navy, and an invisible
header is a lost navigation. Flush to the top there is no gap left to draw
a ring in — it would render off-screen — so the same job is done by the
bar's bottom edge instead:
• 0 1px 0 rgba(255,255,255,.36) the hairline. This is the half that
does the navy-on-navy job, and .36 is a MEASURED value, not a taste
call. .surface-tile (renamed from .band on 2026-09-08) is painted
in var(--tile) — the identical rgb(9,20,100) the bar is painted in —
so the hairline is the only thing separating them.
RE-CHECKED 2026-09-08, when .surface-tile went from a three-stop
gradient to that flat navy. The number does not move, and the worst
case gets BETTER rather than worse. Under the gradient only the band's
top-left corner was #091464; across and down it ran to #1a2a8a and then
#3a1a6a, and the hairline had never been measured against either of
those. Flat, the measured 3.09:1 is true across the whole band for the
first time. The one arrangement that would void it is unchanged and is
spelled out three paragraphs down: do not flatten to #0b1878.
Resolved over that navy it is rgb(98,105,156), which is 3.09:1
against #091464 (WCAG 1.4.11 wants 3:1 for a non-text boundary).
The .14 it replaces resolved to 1.44:1, which is why the bar read as
nothing when it revealed over the CTA band.
THIS NUMBER IS MEASURED AGAINST #091464 AND ONLY HOLDS THERE. It stays
true only while the navy surface's TOPMOST gradient stop is that exact
colour. Anyone who "simplifies" .surface-tile to the palette's second
navy #0b1878 voids it: #0b1878 against #091464 is 1.09:1, i.e. the
fixed bar would disappear into a navy section scrolling behind it,
which is the precise failure this hairline exists to prevent.
Do not lower it back towards .2 "because it looks strong on white" —
over white it is white, i.e. invisible, which is the whole point.
• 0 6px 16px -8px rgba(0,0,0,.34) the soft drop. The hairline cannot
be seen on a WHITE section, so this is the half that draws the edge
there; the pair is what makes one bar work over both backdrops.
Deeper and less negatively-spread than the 0 8px 24px -14px rgba(0,0,0,.55)
it replaces, which resolved to almost nothing on white and, being
black-on-navy, contributed literally nothing over the band.
Delete either half and the bar loses its edge on one of the two backdrops.
─────────────────────────────────────────────────────────────────── */
.site-header{position:fixed;top:0;left:0;right:0;z-index:90;padding:0;
transition:transform .32s cubic-bezier(.4,0,.2,1)}
/* Plain -100%. The old calc(-100% - 18px) was buying clearance for the 14px
top inset plus the ring and its shadow; with the bar flush to the viewport
edge there is nothing left above it, so the extra 18px is pure over-travel.
One of THREE coupled numbers — see the note on .mainnav.open below. */
.site-header.hidden{transform:translateY(-100%)}
/* Full width on purpose: no max-width, no auto margins, no radius, and none
of the old `padding:0 10px 0 20px`. That padding belonged to a bar that was
also the wrapper; re-adding it here would inset the strip's background from
nothing and shove .hdr-inner off the site's own grid.
The box-shadow is the LOAD-BEARING EDGE — read the block comment above
before touching either half. Hairline resolves to 3.09:1 on #091464, which
is the navy the CTA band starts on; the drop is what draws the edge on a
white section. Both are needed; neither is decoration. */
.hdr{background:var(--dark-blue);border-radius:0;
box-shadow:0 1px 0 rgba(255,255,255,.36), 0 6px 16px -8px rgba(0,0,0,.34)}
/* .hdr-inner also carries .wrap, so max-width:1180px, the auto margins and the
horizontal --pad all arrive from there. Do NOT re-declare them here — a
second max-width on the same element is how the pill crept back last time.
58px is the bar height and is quoted in two other places; keep them in step. */
.hdr-inner{display:flex;align-items:center;gap:22px;height:58px}
.brand{display:flex;align-items:center;gap:9px;text-decoration:none;font-family:var(--font-display);
font-weight:700;font-size:19px;color:var(--on-dark);letter-spacing:-.01em}
/* The real Tempus logo. What shipped here was a conic-gradient swirl standing in for it —
a placeholder that read as the brand mark. object-fit:contain so a non-square source is
never distorted; alt is empty because the adjacent text already says "Tempus". */
.brand .brandmark{width:26px;height:26px;flex:0 0 26px;object-fit:contain;display:block}
.mainnav{display:flex;gap:20px;align-items:center;margin-left:6px;flex:1}
.mainnav a{text-decoration:none;font-size:14px;font-weight:400;color:rgba(255,255,255,.82);
padding:5px 0;border-bottom:2px solid transparent;transition:color .15s ease}
.mainnav a:hover{color:var(--on-dark);border-bottom-color:var(--action-on-dark)}
/* --nav-menu-gap is the visible breathing space between the nav button and the
dropdown it opens. It is a variable rather than a repeated 14px because TWO
rules below have to agree about it — the menu's own offset, and the invisible
bridge that spans it. They drifted apart once already and the menu became
unreachable; see the bridge comment. Change the gap here and both follow. */
.mainnav .grp{position:relative;--nav-menu-gap:14px}
.mainnav .grp>button{background:none;border:0;font:400 14px var(--font-body);
color:rgba(255,255,255,.82);cursor:pointer;display:flex;align-items:center;gap:5px;padding:5px 0}
.mainnav .grp>button:hover{color:var(--on-dark)}
.mainnav .grp .menu{position:absolute;top:calc(100% + var(--nav-menu-gap));left:-14px;background:var(--canvas);
/* Squared with the bar it hangs off. A 14px popover under a 6px header bar was
the same two-design-languages problem the .hdr fix above solved. */
border:1px solid var(--border-gray);border-radius:var(--r-control);box-shadow:var(--shadow);padding:8px;
min-width:260px;display:none}
/* THE HOVER BRIDGE — without it the menu cannot be reached with a mouse.
The menu is shown by `.grp:hover`, and it hangs --nav-menu-gap below the
button. That gap was empty, so the instant the pointer left the button it
was over the header bar instead of over anything inside .grp, :hover was
lost, and the menu closed before the pointer had travelled the 14px to it.
Measured on a 1470px viewport: button bottom y=43.3, menu top y=57.3, and
the menu went display:none at every y in between.
This is an invisible strip that belongs to the menu and fills that gap, so
the pointer never leaves .grp on the way down. It paints nothing — no
background, no border — it only takes pointer events.
Deliberately NOT a close-delay: a delay leaves the menu hanging after the
pointer has genuinely gone, and still feels laggy on the way in. And
deliberately not "move the menu flush to the button" either — the gap is
the visual separation between the bar and the popover, and is wanted.
bottom:100% parks it directly on top of the menu's padding box; the +1px is
the menu's own 1px border, which sits between that padding box and the gap.
left/right:0 give it the menu's full width, which covers the button and then
some, so there is no diagonal the pointer can slip through.
It exists ONLY while the menu is displayed, because it is the menu's own
pseudo-element. That is what keeps it from swallowing clicks: with the menu
closed there is nothing there at all. Verified with the menu open that the
brand mark and all five sibling nav links still hit-test to themselves.
Killed at <=960px in the responsive block below — the mobile panel lays the
menu out static, where an absolutely-positioned strip would float loose over
the nav and block taps. */
.mainnav .grp .menu::before{content:"";position:absolute;left:0;right:0;bottom:100%;
height:calc(var(--nav-menu-gap) + 1px)}
.mainnav .grp:hover .menu,.mainnav .grp:focus-within .menu{display:block}
.mainnav .grp .menu a{display:block;padding:9px 12px;border-radius:0;border:0;
color:var(--text-dark)}
.mainnav .grp .menu a:hover{background:var(--light-gray);border:0;color:var(--text-dark)}
.hdr-cta{display:flex;gap:8px;align-items:center}
.hdr-cta .btn{padding:9px 17px;font-size:13.5px}
.hdr-cta .btn-ghost{color:rgba(255,255,255,.9);border-color:rgba(255,255,255,.28)}
.hdr-cta .btn-ghost:hover{border-color:var(--on-dark);color:var(--on-dark)}
/* A pill, like every other button (operator, 2026-09-08 - it was 6px while
buttons were square).
font-family too: a