/* ============================================================
babah3d.com — the whole stylesheet. There is only one.
No build step, no framework, no fonts to download, no npm. A page
here is an HTML file and this file, and that is the entire stack.
It is meant to stay that way: the site will be edited far more often
than it is engineered, usually to change a sentence or swap a photo,
and a toolchain is a thing that breaks between those visits.
THE RULE THIS DESIGN IS BUILT ON: one idea per screen, and the
picture does the talking. Big type, a lot of empty space, almost no
chrome, and never two paragraphs where one line will do. If a
section needs explaining, the photograph in it is the wrong
photograph. Adding copy is how this design dies.
============================================================ */
:root {
/* Surfaces. Near-white rather than white: a page of pure #fff with
#fff cards has no depth at all, and the soft grey is what makes a
full-bleed photograph look placed rather than pasted. */
--bg: #ffffff;
--bg-soft: #f5f5f7;
--ink: #1d1d1f;
--ink-2: #6e6e73;
--hairline: rgba(0, 0, 0, 0.12);
--hairline-soft: rgba(0, 0, 0, 0.06);
/* The pink is Babah3D's, carried over from the app's stylesheet so
the site and the tool are visibly the same shop.
THE RULE, IN BOTH DIRECTIONS — the first version of this comment
only stated the first half, and the second half shipped broken for
weeks behind it:
1. --pink must never be a `color:`. #ff7aa8 on #ffffff = 2.44:1.
2. --pink must never be a fill that carries white `color:`.
#ffffff on #ff7aa8 = 2.44:1 — THE SAME TWO COLOURS AND THE
SAME RATIO. Contrast is symmetric: which of the pair is the
ink makes no difference whatsoever to the number.
So --pink is decorative only: a wash, never a boundary and never
under type. It is also under the 3:1 that WCAG 1.4.11 asks of a
border or a control's edge, which is why the .todo outline and the
.ph border are --pink-text and not this.
Four tokens, and each one has exactly one job:
--pink #ff7aa8 decorative wash. Never ink. Never under ink.
--pink-text #b3275d ink ON the page background, 6.24:1 on #ffffff
and 5.73:1 on #f5f5f7. It used to be
scheme-aware, with a #de6896 value for the
dark page — same hue, same saturation, lifted
in lightness. That second value went with the
dark palette on 2026-08-13 and this token is
now a single pigment.
--pink-btn #90194c a fill that carries WHITE ink, 8.64:1. It
stays a SEPARATE token from --pink-text even
though only one theme ships, and the reason
outlives the dark palette. It is NOT that
--pink-text fails under white — measured,
#ffffff on #b3275d is 6.24:1 and clears 4.5,
so a merge would be legible. It is that the
two do different jobs: #90194c is the logo's
own magenta, the pigment the owner picked, and
holding it apart from the link colour is what
makes the primary out-contrast its own
secondary (8.64 against 6.24) instead of
tying with it. Merging would be legible and
flat.
--pink-btn-ring #bb2163 UNUSED TODAY. It was the button's edge in
dark mode only, and that rule was deleted on
2026-08-13 because the fill measures 8.64:1 on
a light page and needs no edge — the argument
is at .btn further down. The token is kept
because it is a correct tint of --pink-btn's
own hue and costs one line, but nothing paints
it, and a reader should not go looking for
where it is spent.
WHY #90194c AND NOT #b3275d. #b3275d was a colour chosen to clear a
bar. #90194c is the logo's own magenta — the value in the mesh
markup on services.html, alongside orange #ed5f2f and teal #207a64.
The owner picked it. It is the brand's colour rather than a
near-miss of it, and it is also the better number in light mode.
The site now has THREE pinks, not two: --pink-text is still
#b3275d, so the filled pill and the plain text link beside it are
no longer the same pigment. In light mode that is an improvement
and it is measured below — the primary now out-contrasts its own
secondary, which it did not when they were the same value.
Measured this session in a real headless Chrome, from the computed
style of an actual .btn against the backdrop resolved by walking
its ancestors — not from the token (fleet/STATUS-A53.md §3):
#ffffff on --pink-btn #90194c ........ 8.64:1 (bar 4.5) was 6.24
#ffffff on hover #c2185b ........ 5.87:1 (bar 4.5)
--pink-btn vs #ffffff page ........... 8.64:1 (bar 3) was 6.24
--pink-btn vs #f5f5f7 --bg-soft ...... 7.94:1 (bar 3) was 5.73
TWO MORE LINES USED TO SIT UNDER THOSE — --pink-btn against the dark
page's #000000 at 2.43:1 and against its #0e0e10 at 2.23:1, both
under WCAG 1.4.11's 3:1, and both the reason a dark-mode edge ring
existed. The dark palette went on 2026-08-13 and those two surfaces
no longer exist, so the figures are gone with them rather than kept
as measurements of nothing. #90194c is darker than the #b3275d it
replaced, which is why every light figure above got BETTER — the
owner's pigment and the accessible choice were the same choice here.
Hover goes BRIGHTER, not deeper. Deeper was measured first and
rejected: the obvious hover #a22354 is 7.23:1 with white but the
reason it lost was its 2.90:1 against the black page, which no
longer applies. It is left as chosen because #c2185b is 5.87:1 with
white and 5.87:1 against the page, both comfortable, and re-opening
a settled colour decision is not what removing a theme is for.
#c2185b is now 9.7 points of lightness above the base rather than
0, so the hover reads as a bigger step than it used to. That is a
second colour decision and the owner made one, so it is left alone
and written up in fleet/STATUS-A53.md §5 instead of adjusted here. */
--pink: #ff7aa8;
--pink-text: #b3275d;
--pink-btn: #90194c;
--pink-btn-hover: #c2185b;
--pink-btn-ring: #bb2163;
--radius: 14px;
--nav-h: 48px;
/* THE FACET. Added 2026-08-01.
The owner asked for "some slight pixelated theme ... just like the
logo". The logo is not pixelated — it is LOW-POLY: triangular facets
with the gradient running across them. The distinction is the whole
design, because a low-poly mesh is not a decoration here. An STL file
IS a triangulated surface. The brand mark is a mesh and so is every
object this shop prints, so the motif is the craft rather than a
texture laid over it.
Three placements and no more — see the FACET MOTIF block near the end
of this file for what they are and what was tried and dropped. The
rule at the top of this file has not moved: one idea per screen, and
the picture does the talking. A faceted texture that competes with a
product photograph has failed, so none of these three sit ON a
photograph — they sit on its frame, on a label, or behind the logo.
--facet is the corner a picture frame loses.
IT USED TO BE clamp(11px, 1.9vw, 20px) — fluid, so a 300px card and a
980px hero read as the same shape. 2026-08-02 it became a fixed
multiple of --px, and that is not a regression, it is the point.
THE OWNER ASKED FOR A PIXELATED THEME, SUBTLY, WITH THE LAYOUT KEPT.
A pixel grid that scales with the viewport is not a pixel grid: the
whole idea is one unit that never changes, so a step is a step is a
step. --px is that unit. Everything the motif draws is an integer
multiple of it, which is also the only way the staircases stay crisp
— 4px and 8px are whole device pixels at DPR 1 and at DPR 2, and a
stepped edge on a fractional boundary is just a blurry diagonal.
WHAT IT COSTS THE LAYOUT, measured rather than asserted. I wrote
"nothing moves" here first and it was wrong; a53-layoutdiff.mjs
records the bounding rect of every element on all five pages at 375
and 1280, injects the pre-pixel rules back, and diffs:
every page's total scrollHeight IDENTICAL, to the pixel
every element's width and height IDENTICAL
154 elements shifted VERTICALLY by 0.63px to 1.65px
404.html and guide.html 0 elements moved
All of it is one cause: the .eyebrow mark is 9px tall where the
triangle was 8px, which grows that one line box, so whatever follows
an eyebrow sits about a pixel lower. Nothing reflows, nothing
rewraps, nothing overflows, no page gets longer. Keeping it at 8px
would put the three steps on 2.67px boundaries, which is a blurred
diagonal — the exact thing this pass exists to avoid. A pixel of
baseline for a crisp staircase is the trade, and it is stated here
rather than glossed. */
--px: 4px;
--facet: calc(var(--px) * 4);
--facet-lg: calc(var(--px) * 8);
/* The monospace stack was already in this file, on .ph__path. It is now
a token because it does a second job: the small technical labels.
Every one of these ships with the OS — ui-monospace resolves to SF
Mono on Apple, and Consolas is on every Windows since Vista — so this
costs nothing to fetch, exactly like the body stack below. */
--mono: ui-monospace, SFMono-Regular, "SF Mono", Menlo, Consolas,
"Liberation Mono", monospace;
/* THE DISPLAY FACE. Added 2026-08-02. The full argument, the licence,
the provenance and the measured legibility floor are in the DISPLAY
FACE block below — this is only the stack.
The fallback behind it is the body stack verbatim, and it is not
decoration: font-display is `optional`, so on a cold visit that
loses the 100ms race THIS is what paints the headings, for the whole
of that page load. It has to be a face somebody would have chosen. */
--display-face: "Pixelify Sans", -apple-system, BlinkMacSystemFont,
"Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif;
/* One measure for body copy. 34em is about 68 characters, which is
the width text stops being tiring to read at. */
--measure: 34em;
--page: 1120px;
--gutter: clamp(20px, 5vw, 40px);
/* Vertical rhythm. A "chapter" gets a lot of air — this number is
the single biggest reason the page reads as calm. */
--chapter-y: clamp(72px, 13vh, 168px);
/* THIS SITE IS LIGHT, FULL STOP. Owner's decision, 2026-08-13, in
their own words: 'i dont think i want dark hue in any of future
development', then 'remove dark mode from everything'. It is a
standing rule across the whole family of apps, recorded as P0003 in
product-app-playbook/references/portfolio-decisions.md and argued in
launch-playbook/SKILL.md §3.5. It supersedes the 2026-08-03 decision
this comment used to quote, which said the same thing about this one
site: 'in dark mode is not nice. like apple website it does not
affected by dark mode... to preserve the coolness of the UI.'
THE DARK PALETTE IS DELETED, NOT DISARMED. It used to live here as
an @media block whose query was made unmatchable with a bogus
`and (min-width: 999999px)`, on the reasoning that restoring dark
would then be re-enabling one query rather than re-deriving a
palette. That is exactly the half-removed state the playbook forbids:
a disarmed block is one specificity accident or one careless edit of
the query away from applying, and it re-enables a theme nobody has
measured since. Four such blocks and four dead `[data-theme]` rules
came out on 2026-08-13. Restoring dark now means writing a block and
re-measuring every ratio against the new surfaces — which is the
honest price, and the token layer below is what keeps it cheap.
`color-scheme: light` is the half that deletion alone does not do.
Without it a dark-mode machine still paints the UA's own surfaces
dark — the scrollbar, form controls, the caret, the canvas before
first paint — so a light page ends up in a dark frame. Every page
also carries so this is
true before this stylesheet has even loaded. Both are asserted by
tools/check-light-theme.mjs. */
color-scheme: light;
}
*,
*::before,
*::after {
box-sizing: border-box;
margin: 0;
padding: 0;
}
html {
scroll-behavior: smooth;
-webkit-text-size-adjust: 100%;
}
@media (prefers-reduced-motion: reduce) {
html {
scroll-behavior: auto;
}
*,
*::before,
*::after {
animation-duration: 0.01ms !important;
transition-duration: 0.01ms !important;
}
}
body {
/* THE BODY STACK, AND IT IS STILL THE SYSTEM STACK. On a Mac or an
iPhone this is SF Pro, on Windows Segoe, on Android Roboto — every
one of them already installed, so there is no font file to fetch for
the text somebody actually reads, and no flash of the wrong typeface
on a paragraph.
THIS PARAGRAPH USED TO SAY THERE WAS NO WEBFONT ON THIS SITE. There
is one now, and leaving the old text here would have made this
comment a description of a stylesheet that no longer exists — the
failure this file keeps finding in itself. What was rejected on
2026-08-01 (fleet/STATUS-A36.md) was a geometric display sans, and
the reason was that a geometric sans reads ROUNDER than the logo's
wordmark while costing a font file: it moved away from the brand and
charged for the privilege. That judgement still stands and the face
that landed is not that face — see the DISPLAY FACE block below.
The bar that block had to clear is the one this comment set, and it
was set deliberately high: not "does it look nice" but "is it worth
the site's only external-shaped request", with a real fallback and
no flash. It is answered there with measurements rather than with an
opinion, and the answer includes a floor size below which the face
is NOT used — which is why you are reading the system stack here and
will keep reading it on every paragraph, every link in prose, every
form label and all the legal copy.
The third face is --mono, for the small technical labels. Unchanged,
still zero bytes, and still the part that echoes the engineering
half of the logo. */
font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto,
"Helvetica Neue", Arial, sans-serif;
font-size: 17px;
line-height: 1.5;
letter-spacing: -0.01em;
color: var(--ink);
background: var(--bg);
-webkit-font-smoothing: antialiased;
}
img,
svg,
video {
display: block;
max-width: 100%;
height: auto;
}
a {
color: inherit;
}
/* One global focus ring, so a control added next year is visible to the
keyboard the moment it exists rather than when somebody remembers. */
:focus-visible {
outline: 2px solid var(--pink-text);
outline-offset: 3px;
border-radius: 4px;
}
.skip-link {
position: absolute;
left: -9999px;
top: 0;
z-index: 100;
padding: 12px 18px;
background: var(--bg);
border: 1px solid var(--hairline);
border-radius: 0 0 var(--radius) 0;
}
/* 6px and not 0, and the reason is the focus ring rather than the box.
:focus-visible above draws `outline: 2px` at `outline-offset: 3px`, and an
outline paints OUTSIDE the border box — so with the link flush at 0,0 the
top and left of the ring land 3px outside the VIEWPORT and are clipped
away. What a keyboard user actually saw was a pink arc down the right-hand
side and along the bottom, cut flat at the corner: it reads as a rendering
fault rather than as "you are here", on the first control on every page.
Nothing a test asserts was wrong — the ring was present, 2px, and the
right colour in both schemes. It had to be looked at. See
fleet/STATUS-A51.md §2.1 for the before and after rasters.
Inset the BOX, not the ring: 6px clears the 3px offset plus the 2px stroke
with a pixel to spare, and the link still arrives in the top-left corner
where a skip link belongs. The radius goes to the full --radius because
the `0 0 var(--radius) 0` above is shaped for a box that meets the corner
of the window, and this one no longer does. */
.skip-link:focus {
left: 6px;
top: 6px;
border-radius: var(--radius);
}
.sr-only {
position: absolute;
width: 1px;
height: 1px;
overflow: hidden;
clip: rect(0 0 0 0);
clip-path: inset(50%);
white-space: nowrap;
}
/* ============================================================
LAYOUT
============================================================ */
.wrap {
width: 100%;
max-width: var(--page);
margin-inline: auto;
padding-inline: var(--gutter);
}
.wrap--narrow {
max-width: 760px;
}
/* A chapter is one idea. Headline, at most one sentence, one picture.
If you find yourself adding a third element, it is two chapters. */
.chapter {
padding-block: var(--chapter-y);
}
.chapter--soft {
background: var(--bg-soft);
}
.chapter__head {
max-width: var(--measure);
margin-inline: auto;
text-align: center;
margin-bottom: clamp(32px, 6vh, 64px);
}
/* ============================================================
THE DISPLAY FACE — Pixelify Sans, self-hosted. Added 2026-08-02.
The owner, having seen the 4px staircase this file already draws on the
picture frames and the eyebrows: "the website is not redesign with
pixelated font". The staircase was too quiet to read as a decision. So
the pixel goes into the type, which is the loudest thing on every page.
PROVENANCE, so nobody has to guess later:
face Pixelify Sans, variable, weight axis 400-700
designer Stefie Justprince
copyright Copyright 2021 The Pixelify Sans Project Authors
licence SIL Open Font License 1.1 — verbatim at fonts/OFL.txt,
which is not documentation: OFL §2 requires the notice and
the licence to travel WITH the font. No Reserved Font Name,
which is why the family below is the designer's own name
rather than an alias that would hide where it came from.
upstream https://github.com/eifetx/Pixelify-Sans
source Google Fonts, css2?family=Pixelify+Sans:wght@400..700,
the `latin` subset, v3, from fonts.gstatic.com
obtained 2026-08-02
file fonts/pixelify-sans-v3-latin-wght.woff2, 12,016 bytes
SELF-HOSTED, AND THAT IS NOT A PREFERENCE. This site makes no external
request at all and the deploy gate follows what the pages reference, so
a to fonts.googleapis.com would be a new third-party origin on
every page — and it is also two round trips before a heading paints.
12 KB from our own origin is one, and it is preloaded.
WHY THIS FACE AND NOT THE OBVIOUS ONES. Five OFL pixel faces were
rendered on this actual page rather than on a specimen sheet
(a72-mock.mjs), and measured (a72-type.mjs, a72-floor.mjs). Two numbers
decided it:
1. ADVANCE WIDTH against the system stack, same px size. A pixel face is
usually much wider per character, and the nav labels are text, so
width is what breaks a header:
Pixelify Sans .... 1.02x - 1.11x <- essentially metric-neutral
Silkscreen ....... 1.18x - 1.53x
Silkscreen Bold .. 1.38x - 1.80x
Press Start 2P ... 1.67x - 2.32x
VT323 ............ 0.67x - 0.93x
2. WHETHER IT SURVIVES clamp(). This is the one that actually
disqualified the favourites. Silkscreen and Press Start 2P are true
bitmap designs on an em/8 grid: they are perfectly crisp at multiples
of 8px and greyed at everything else. Measured as the fraction of
marked pixels that are neither ink nor paper, at DPR 1:
Silkscreen 8px 0.003 · 16px 0.000 · 24px 0.003 · 32px 0.002
13px 0.483 · 17px 0.278 · 21px 0.205 · 27px 0.255
Every display size on this site is a clamp() — a fluid value that is
whatever the viewport makes it. So on a real page Silkscreen is a
different quality of thing at every window width, and it is worse
than blurry: at 13, 15, 19, 21, 22, 27, 29, 30, 35, 37 and 38 px the
counters of o, 8, 9 and 0 CLOSE COMPLETELY (a72-floor.mjs). A zero
that swallows its own hole at some window widths and not others is
not a typeface, it is a bug with a licence.
Pixelify Sans is an OUTLINE face drawn as pixels rather than a bitmap
snapped to them, so it anti-aliases like any other font and its
counters grow smoothly with size. That is exactly the property this
site's fluid type needs, and it is why the loudest-looking candidate
is not the one that shipped.
THE LEGIBILITY FLOOR IS 21px, AND IT IS MEASURED, NOT A TASTE CALL.
a72-floor.mjs renders a, o, 8, B, D, 9, 0 and 6 at every size from 8 to
40 at DPR 1 and DPR 2, floods the background in from the border to find
the counters, and records the thinnest horizontal run of ink in DEVICE
pixels. At DPR 1 Pixelify Sans stops drawing whole-device-pixel strokes
below 21px:
19px minRun 2 21px minRun 2 24px minRun 2
20px minRun 1 22px minRun 2 32px minRun 3
Below 21 the face is still READABLE — that is not the point. Below 21
its own pixel is smaller than the screen's, so it renders as a blurred
approximation of a pixel font, which is the worst of both: it stops
looking deliberate and starts looking like a rendering fault. Looked at
as well as counted, 8x nearest-neighbour at DPR 1:
a72-type\a72-wordmark-8x-wordmark.png.
SO EVERY SURFACE BELOW 21px KEEPS THE FACE IT HAD, and the list of what
that excludes is the honest half of this change:
.nav__brand__label 17px the wordmark. The brief asked for it and
the measurement refused it — and raising it
to 21px would also widen the brand lockup
and move A70's 410px no-script threshold.
.card__title 17px
.eyebrow 12px and it already carries the 4px staircase
.foot h2 12px
.ph__label 12px
.todo 17px
.nav__links a 14px navigation, and A70's thresholds live here
.btn 17px a control, not display
every paragraph, lede, caption, table cell and line of legal copy
There are no numerals in stat-like positions on this site to set — no
counts, no prices, no measurements on a page. If any are ever added,
they are display and they belong in the list below, above 21px.
font-display: OPTIONAL, and this is the whole no-flash-no-shift answer.
`swap` guarantees a shift: the fallback paints, the face arrives, every
heading moves. `block` hides the text and then shifts it if the face is
late. `optional` gives the browser about 100ms and then commits for the
life of that page load — it NEVER swaps in afterwards, so a heading
cannot move because of font loading, by construction rather than by
luck. The cost is real and is stated rather than hidden: on a cold visit
that loses the race, that page renders in the system stack. The preload
in each page's and the year-long immutable cache in _headers are
what make losing it rare; --display-face's fallback is what makes losing
it survivable.
============================================================ */
@font-face {
font-family: "Pixelify Sans";
src: url("../fonts/pixelify-sans-v3-latin-wght.woff2") format("woff2");
/* One file, both ends of the variable axis. .display sets 700 and the
headings 600, and the browser interpolates rather than synthesising
a fake bold — a synthesised bold on a pixel face smears every
module sideways by a fraction of a pixel, which is the one thing
this whole block exists to avoid. */
font-weight: 400 700;
font-style: normal;
font-display: optional;
/* Google Fonts' own `latin` range, copied from the @font-face this
file was cut from. It is stated rather than omitted so that a
character outside the subset — a Malay diacritic, a currency sign —
falls straight through to the body stack instead of arriving as a
missing glyph. Nothing in a display position on this site is outside
it today; every heading, on all five pages, is plain ASCII. */
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;
}
/* ============================================================
TYPE
============================================================ */
h1,
h2,
h3 {
font-weight: 600;
letter-spacing: -0.03em;
line-height: 1.06;
text-wrap: balance;
}
/* 700 and -0.045em, not 600 and -0.04em. This is the whole of the "change
the font" answer and it is deliberately not a new typeface.
What the logo's wordmark actually is: heavy, tight, and squared off. A
geometric display face (the obvious reach) is ROUNDER than that, so it
moves away from the wordmark while costing a font file. Weight and
tracking move toward it and cost nothing. Only .display changes — the
headline and subhead stay at 600, because at 32-52px the extra weight
stops being confident and starts being shouty. */
.display {
font-family: var(--display-face);
font-size: clamp(2.6rem, 8vw, 5.5rem);
font-weight: 700;
letter-spacing: -0.045em;
}
.headline {
font-family: var(--display-face);
font-size: clamp(2rem, 5vw, 3.25rem);
}
/* 22px at its smallest, which clears the 21px floor by one pixel. That is
the tightest thing on this list and it is deliberately the last one in.
If .subhead's clamp minimum is ever lowered, this line comes out with
it. (It has no user in the markup today — grep: zero occurrences across
all five pages — so it is here as part of the scale, not as something
currently on screen.) */
.subhead {
font-family: var(--display-face);
font-size: clamp(1.375rem, 3vw, 1.75rem);
font-weight: 600;
letter-spacing: -0.02em;
}
/* THE TECHNICAL LABEL. The eyebrow, the placeholder's label and the footer
column headings are all the same thing: a four-to-twenty-character
uppercase tag that names a block. Monospace, because the other half of
this brand is a workshop — a mesh, a slicer, a file with dimensions in it
— and a monospace tag reads as something machine-set rather than
art-directed. It is also the one type change that costs nothing at all:
every platform ships a monospace face, so --mono is a zero-byte accent
where a display webfont would have been 15-25 KB.
The COLOUR IS UNCHANGED: --pink-text, measured 6.24:1 on white and
5.73:1 on --bg-soft, and re-measured after this change. Monospace faces
run narrow, so the size drops 13px -> 12px and the tracking opens
0.04em -> 0.14em; neither moves the contrast, and neither is a tap
target. Do not put --pink here — see the token block. */
.eyebrow {
font-family: var(--mono);
font-size: 0.75rem;
font-weight: 600;
letter-spacing: 0.14em;
text-transform: uppercase;
color: var(--pink-text);
margin-bottom: 14px;
}
/* THE CLICKER WONDERLAND LOCKUP — index.html, #clicker, once. Added
2026-08-08, when the owner supplied artwork for the app the way they had
already supplied it for Babah3D.
IT REPLACES THE EYEBROW that read "Clicker Wonderland" rather than sitting
above it. The artwork sets the name AND the byline; an eyebrow over it would
print the product's name twice inside 40 px of page, which is the same
mistake services.html's logo block exists to avoid. The cost is the eyebrow's
facet triangle, which is placement 1 of 3 and still appears on every other
chapter head — so the mark is not lost from the site, only from this one row.
The source is 1920 x 1080 with the artwork floating in a 60% empty frame and
NO alpha channel; img/brand/clicker-lockup.png is that artwork cut out and
resampled to 1100 x 183. assets/brand/README.md records the crop and why a
flat white knockout was not good enough (the background is a gradient, not a
colour).
1100 IS SIZED BY THE PDF, NOT BY THIS SLOT. The cut is 1681 px wide and that
was the first thing shipped — fine for the web at any size here, but this
same PNG is embedded in downloads/Clicker-Wonderland-Complete-Guide.pdf,
where it took a 424 KB customer download to 584 KB. At 1100 the largest use
(the guide cover, 420 CSS px) is still covered 2.6x, which is past retina, so
everything above it was paying only the PDF. Raising this number means
re-printing the guide and re-checking that file size.
The WebP is what a browser actually gets — 42 KB against the PNG's 104 KB.
The PNG stays as the fallback so no browser meets a missing logo, and alpha
is required in both because this sits on --bg-soft rather than on a plate.
min() rather than a media query: there is exactly one thing to protect, which
is a 320 px viewport where a fixed 340 would push the wrap sideways. */
.chapter__lockup {
display: block;
width: min(560px, 90vw);
height: auto;
margin: 0 auto 14px;
}
/* The same lockup on guide.html's cover, larger. A manual's cover page is the
one place a product mark cannot be mistaken for decoration, and unlike the
home page there is no redundancy problem in the
repeating the name
underneath it — that is what a cover is.
THIS ONE PRINTS. downloads/Clicker-Wonderland-Complete-Guide.pdf is rendered
FROM this page by headless Chrome, so the PDF's cover carries it too, and
`%` rather than `vw` is deliberate: the print medium has no viewport and vw
resolves against the paper unpredictably. After touching this rule, re-print:
`node tools/build-guide-pdf.mjs`, then `node tools/check-guide-pdf.mjs`. */
.cover .chapter__lockup {
width: min(420px, 80%);
margin-bottom: 22px;
}
/* THE FACET MARK — placement 1 of 3. A single triangle, drawn with
clip-path rather than set as a "▲" character, for three reasons: it is
geometry rather than a glyph so it is identical on every platform, a
font may not have the character at all, and a real triangle can be given
the exact proportions of a facet in the logo instead of whatever the
font designer chose. currentColor, so it can never drift away from the
label's own measured pink. Purely decorative and announced by nothing —
it is generated content, so a screen reader that reads it at all reads
an empty string. */
/* PIXELATED, 2026-08-02. This was a 9x8 solid triangle — placement 1 of the
facet motif, and the only one of the three A51 said read well. It is now
a 9x9 THREE-STEP STAIRCASE rising left to right: three 3px columns, 3px
then 6px then 9px tall.
Why change something that worked: it is the mark a visitor sees most
often on this site — every chapter head on every page — so it is the
cheapest place to say "pixel" once and be consistent. A triangle and a
staircase are the same gesture at different resolutions, which is
exactly the joke the low-poly logo is already making. Same 9px width,
same currentColor, no new colour; percentages keep the three steps at
exactly 3px each.
THE BOX IS 9px TALL WHERE THE TRIANGLE WAS 8, and that is the one thing
in this whole pass that moves anything: it grows this line box, so
content after an eyebrow sits 0.63-1.65px lower. Total page height is
unchanged on every page. 8px would put the steps on 2.67px boundaries
and blur them. The measurement is in the --px block above.
Still `background: currentColor` and still purely decorative — it
inherits --pink-text from .eyebrow, announced by nothing, and carries no
information a screen reader loses. */
.eyebrow::before {
content: "";
display: inline-block;
width: 9px;
height: 9px;
margin-right: 9px;
background: currentColor;
clip-path: polygon(
0 100%,
0 66.667%,
33.333% 66.667%,
33.333% 33.333%,
66.667% 33.333%,
66.667% 0,
100% 0,
100% 100%
);
}
.lede {
font-size: clamp(1.0625rem, 2vw, 1.3125rem);
line-height: 1.45;
color: var(--ink-2);
max-width: var(--measure);
margin-top: 18px;
}
.chapter__head .lede {
margin-inline: auto;
}
.fine {
font-size: 0.8125rem;
line-height: 1.5;
color: var(--ink-2);
}
.quote-start .chapter__head {
margin-bottom: 40px;
}
.quote-start .fine {
margin-top: 14px;
}
.quote-next {
display: grid;
grid-template-columns: repeat(2, minmax(0, 1fr));
gap: clamp(28px, 5vw, 64px);
max-width: 920px;
margin-inline: auto;
}
.quote-next h3 {
margin-bottom: 16px;
font-size: 1.125rem;
letter-spacing: -0.02em;
}
.quote-next ol {
padding-left: 22px;
}
.quote-next li {
padding-left: 4px;
margin-top: 12px;
line-height: 1.55;
}
.quote-faq dl {
margin: 0;
}
.quote-faq dl > div {
padding: 13px 0;
border-top: 1px solid var(--hairline);
}
.quote-faq dt {
font-weight: 650;
line-height: 1.4;
}
.quote-faq dd {
margin: 5px 0 0;
color: var(--ink-2);
line-height: 1.5;
}
@media (max-width: 680px) {
.quote-next {
grid-template-columns: 1fr;
gap: 32px;
}
}
/* ============================================================
BUTTONS AND LINKS
============================================================ */
.actions {
display: flex;
flex-wrap: wrap;
gap: 14px 28px;
align-items: center;
margin-top: 32px;
}
.chapter__head .actions,
.hero .actions {
justify-content: center;
}
.btn {
display: inline-flex;
align-items: center;
justify-content: center;
min-height: 44px; /* thumb-sized, not decorative */
padding: 12px 26px;
border: 0;
border-radius: 999px;
/* --pink-btn, not --pink: see the token block. White on --pink is
2.44:1 against a 4.5:1 bar, and it was the worst thing on the site.
Do not "restore the brand pink" here — the brand pink is still on
this button, it is just the one that can be read. */
background: var(--pink-btn);
color: #ffffff;
font: inherit;
font-weight: 600;
letter-spacing: -0.01em;
text-decoration: none;
transition: background 0.2s ease, transform 0.2s ease;
}
.btn:hover {
background: var(--pink-btn-hover);
}
.btn:active {
transform: scale(0.98);
}
/* THE PRIMARY BUTTON HAS NO EDGE RING, AND DOES NOT NEED ONE.
A dark-mode-only `box-shadow: 0 0 0 2px var(--pink-btn-ring)` used to sit
here. It existed for one measured reason: --pink-btn #90194c is 2.43:1
against the #000 dark page and 2.23:1 against that scheme's #0e0e10, and
WCAG 1.4.11 asks 3:1 of the visual information that identifies a control
— which, for a filled pill with no border, is the fill itself. Under 3:1
the button's own shape stopped being reliably findable, so dark mode drew
a boundary around it rather than change the owner's pigment.
NONE OF THAT IS TRUE ON A LIGHT PAGE, and this was re-measured on
2026-08-13 before the rule was deleted rather than assumed from the fact
that the block said "dark mode only":
#90194c fill vs #ffffff page ......... 8.64:1 (bar 3)
#90194c fill vs #f5f5f7 soft chapter . 7.94:1 (bar 3)
#c2185b hover vs #ffffff / #f5f5f7 ... 5.87 / 5.39:1
#ffffff label on the #90194c fill .... 8.64:1 (bar 4.5)
The fill clears the bar by 2.9x on its own, so the ring was compensating
for a black page that no longer exists. Deleting it removes a device, not
a safeguard. --pink-btn-ring is kept as a token because nothing else was
spending it and it costs one line, but nothing paints it today.
The old comment also recorded a worry that dimming --pink-text moved the
focus outline and this ring to 1.86:1 of each other. That worry is gone
with the ring: :focus-visible draws at outline-offset: 3px, so in light
the outline's neighbour is the page, at 6.24:1 against a 3:1 bar.
.btn--quiet was excluded from the ring and still has no ring. Its own
edge is 1px of --hairline, and that pair is measured in the note on
.btn--quiet below — it is the one thing on this site the dark theme's
removal exposed as never having been measured at all. */
/* THE ONE PAIR REMOVING THE DARK THEME EXPOSED AS NEVER MEASURED.
The deleted edge-ring comment waved this button through in one sentence:
".btn--quiet is excluded on purpose. It is transparent with a --hairline
border, so its edge is already its own and already flips." That is a
claim about a token flipping, not a contrast measurement, and nobody had
taken one. The dark figure sitting next to it in the same file is what
made it look answered. Measured on 2026-08-13, both schemes:
border --hairline rgba(0,0,0,0.12) on #ffffff .... 1.32:1
border --hairline rgba(255,255,255,0.16) on #000 . 1.44:1
the label, --ink #1d1d1f on #ffffff .............. 16.83:1
So the edge was never near WCAG 1.4.11's 3:1 in EITHER scheme — this is
not a regression the deletion caused, it is a number the deletion made
visible. It is left as it is, deliberately, and that is a judgement
rather than an oversight: this control is a link reading "Download the
PDF" at 16.83:1, so the visual information identifying it is the label,
which is what 1.4.11 asks about. The border is reinforcement, not the
identifier.
IF IT IS EVER TIGHTENED, tighten --hairline sitewide rather than this
rule — the token is spent on seven boundaries and a one-off here would
make this button the only edge on the site with its own opacity. That is
a design change and it belongs to the owner, not to a theme removal.
.btn--quiet appears exactly once in the whole site, in guide.html. */
.btn--quiet {
background: transparent;
color: var(--ink);
border: 1px solid var(--hairline);
}
.btn--quiet:hover {
background: var(--bg-soft);
}
/* The "Learn more ›" of this site. Deliberately not a button: a page
with two buttons has one call to action and one distraction. */
.more {
display: inline-flex;
align-items: center;
gap: 5px;
min-height: 44px;
color: var(--pink-text);
font-weight: 500;
text-decoration: none;
}
.more::after {
content: "\203A"; /* › */
font-size: 1.25em;
line-height: 1;
transform: translateY(-1px);
transition: transform 0.2s ease;
}
.more:hover::after {
transform: translate(3px, -1px);
}
/* ============================================================
HEADER — a hairline and nothing else.
============================================================ */
.nav {
position: sticky;
top: 0;
z-index: 50;
/* min-height, not height. The bar is allowed to become two rows on a
narrow screen — see .nav__inner. A fixed height would keep the bar
48px tall and let the second row hang out of the bottom of it. */
min-height: var(--nav-h);
/* Solid first, translucent second. A browser that does not know
color-mix() drops that line and keeps the opaque bar — without
the fallback it would drop the background entirely and the nav
would sit unreadable on top of the page content. */
background: var(--bg);
background: color-mix(in srgb, var(--bg) 82%, transparent);
backdrop-filter: saturate(180%) blur(20px);
-webkit-backdrop-filter: saturate(180%) blur(20px);
border-bottom: 1px solid var(--hairline-soft);
}
/* THE WRAP FALLBACK, which is the actual fix for the nav overflow.
The old bar was one row that could never become two: .nav__links was
`display:flex; overflow-x:auto` with `white-space:nowrap` links and no
wrap anywhere. So whenever the links were wider than the space they
got, the last one was cut mid-word — 29px clipped at 320px on every
page, and 15.4px past the viewport at 375px the moment a fourth link
exists. It stopped reproducing at 375px only because the Reviews link
was removed; the bug was never fixed, the nav just got shorter, and it
comes back the day anybody renames or adds a link.
Two levels of give, so no single word can push a link off the screen:
the menu drops to its own row under the brand, and if the links still
do not fit on that row they wrap among themselves. Neither is a
breakpoint — nothing here is keyed to a width, so it cannot be wrong
for the next set of words. */
.nav__inner {
display: flex;
flex-wrap: wrap;
align-items: center;
/* row gap first: it only exists once the bar is two rows. */
gap: 6px clamp(16px, 4vw, 34px);
min-height: var(--nav-h);
padding-block: 6px;
max-width: var(--page);
margin-inline: auto;
padding-inline: var(--gutter);
}
/* The