/* ========================================================================== TWM Legal - main.css - FOUNDATION ONLY (Build order steps 1-4). Constitution, tokens, synthetic fallback faces, base, layout primitives, guards. No components, no hover layer, no reveal keyframes: those are steps 5-9. Every number that could have been taste carries its arithmetic beside it; a value without a comment is a bug. Colour values WERE copied verbatim from reference/derivation/tokens.css (derive_colors.py). THAT IS NO LONGER TRUE OF THE ACCENT LADDER. Three generations of change sit on top of it, all verified by tools/verify_ratios.py, each marked at its own lines: [GLOW] the earlier pass. --ink-3 and --brand were each raised one step in LIGHTNESS ONLY (hue and saturation held) by reference/derivation/derive_glow.py's inverse solve, to pay for the pointer light in 6.26. SUPERSEDED, and kept below as the previous generation rather than deleted: it records why the values v7 replaced were chosen. [RED v7] 2026-09-05, SUPERSEDED IN ITS VALUES, KEPT IN ITS REASONING. The firm reported that "the red used throughout is not a deep enough red" and the measurement agreed: what shipped was #EE4C3D = hsl(5.08, 83.9%, 58.6%), five degrees off pure red, and that hue offset is what made it read CORAL. scratchpad/{derive_red_v7.py, lock_v7.py} re-solved the whole ladder at hue 0 / saturation 100 - the mark's own hue - SPLIT it into a TEXT stop (#FF3D3D, kept light so red text could hold AA on a near-black ground) and a FILL stop (#C00000), and spent the headroom on a 1.38x stronger pointer light. [RED v8] 2026-09-06, THE PASS THAT SHIPS. The firm read v7 on the built site and instructed, in full: "The Button color red and title font color in the body is not as dark red as the text highlight. All red should be the color of the text highlight color. Fix." The text highlight is ::selection, which paints --brand-deep, so EVERY red on the site collapses onto the 2020 wordmark's own #BF0000 - fill, rule, mark, selection AND TEXT. THE FIRM WAS SHOWN THE MEASUREMENTS FIRST AND INSTRUCTED THE DEEP RED ANYWAY. Red text therefore no longer meets WCAG AA anywhere on this site; the elements, their measured ratios and the one-line revert are named in full in the token block below, and tools/verify_ratios.py asserts that they are BELOW AA so that silently "fixing" the colour back fails the build as loudly as letting the comments go stale would. Because red text is no longer held to 4.5:1, the pointer light's ceiling is now set by --ink-3 instead, and the light runs 1.62x brighter - which the firm asked for in the same breath. derive_colors.py has NOT been re-run, so tokens.css carries the pre-glow, pre-v7 palette. [FACE v9] 2026-09-06, A SECOND PASS ON THE SAME DAY AND A LARGER ONE: THE TYPEFACES CHANGED. The firm instructed, in full, two Google Fonts families - Newsreader for display/headings (400-600 plus a 400 italic) and Montserrat for body, nav, buttons and labels (300-600) - and supplied both stacks and both metric-override sets itself. Titillium Web and Source Serif 4 are retired. This is not a rename: this file DERIVES numbers from font metrics, so the per-character advance (0.4179 -> 0.49072em, +17.4%), the display face's "0" (which now WIDENS with opsz instead of narrowing), the x-heights, the glyph extents and the wordmark's own raster fitting all moved, and every figure standing on one moved with them. What changed in VALUES: --measure 29.25 -> 34.35rem, --leading-body 1.6 -> 1.68, --leading-lede 1.5 -> 1.575, the whole tracking ladder down two rungs (--track-1 0.40 -> 0.32em), .hero-title 19ch -> 16ch, .display 26ch -> 22ch, .form-grid's track 12 -> 13.78rem, the header CTA query 88 -> 89rem, and the third synthetic serif family (--font-display-hero) deleted. What is HELD and now carries a recorded exception rather than a satisfied rule: --grid-track (misses its 40-character content rule by 2.0 characters), --gutter-phone (the 45-55 phone measure is UNREACHABLE at any gutter), and the structural breakpoint pair ([REPAIR v10] NO LONGER AN EXCEPTION: the pair moved 64 -> 67rem and 71 -> 74rem, the rows' own sums rounded up, so the nav no longer overshoots and the header mark holds its full 243.63px at every width the nav is up - see 6.1). The firm's supplied fallback overrides ship exactly as given INCLUDING one that measures wrong by 22.7% (Newsreader Fallback's ascent); the check is written beside it in block 2. One correction is recorded and NOT acted on: the brief calls Montserrat "the face in your logo", and the 2013 vector measures the wordmark as Titillium Text + Arvo. The pairing is the firm's decision and ships; the provenance claim does not. THE ROOT SIZE MOVED IN AN EARLIER PASS: html { font-size: 106.25% } (block 3). Every px figure in this file is therefore 1.0625 x its 16px-root value; every rem is unchanged; and because the whole system is expressed in rem, every character count and every ratio between two rem quantities is unchanged with it. Only comparisons against a VIEWPORT (which did not scale) had to be re-solved. Sources: reference/derivation/{tokens.css, derivation.json, type-measurements.json, logo-measurements.json, measure_variable.py}, reference/fonts/{font-metrics.json, *.ttf}, reference/playbook/PLAYBOOK.md. Synthesised 2026-09-05 from drafts A (type) and B (layout); see docs/DESIGN-SYSTEM.md. ========================================================================== */ /* ---- 0 · THE CONSTITUTION ------------------------------------------------ */ /* LAYER ORDER, NOT SOURCE ORDER, GOVERNS THE CASCADE. Declared first, so the next person does not assume "append or it will not ship". A later layer beats an earlier one regardless of position or specificity: components beats layout beats base beats tokens, and guards beats everything - so a guard never needs a specificity game, only the right layer. A component's hover is declared exactly once, in its own block, never appended later to win by position. ONE INVERSION TO HOLD IN MIND: for !important declarations the layer order is REVERSED (the earlier layer wins). The guards layer's reduced-motion clamp relies on !important, so it is safe only because NO OTHER LAYER MAY USE !important. The single exception, [hidden] in base, is harmless: nothing in guards contests display, and being earlier makes it stronger. */ @layer tokens, base, layout, components, guards; /* TYPE SYSTEM - two invariants. Breaking either collapses this into a stock template, so they are rules, not preferences: 1. ALL-CAPS AND POSITIVE LETTER-SPACING BELONG TO MONTSERRAT ONLY, and only at --text-label (0.786rem = 13.36px, inside the 0.70-0.80rem label band): eyebrows, nav, buttons, field labels, attribution, licence strings, counter units. The mark performs exactly ONE tracked-caps gesture - the sub-line "ATTORNEY SERVICES", cap height 0.24 of the wordmark's, tracked 0.306em as the raster measures in Montserrat (the ladder's own rung is 0.32em, the nearest 0.04 step) - and echoing it at 13.4px reads as family resemblance. NOT "in the logo's own face": THAT CLAIM IS RETIRED AND MUST NOT COME BACK. The 2013 vector's wordmark is Titillium Text ("TWM" Light, "Legal" Medium) with Arvo for ".com" (logo-measurements.json); Montserrat appears nowhere in the mark. What survives the face change is the GESTURE - tracked caps at label size under a display line - not a shared typeface. FAILURE MODE: the same gesture at headline scale competes with the mark for the same job. 2. NEWSREADER IS NEVER SET IN CAPS, NEVER TRACKED POSITIVE, AND NEVER RENDERS BELOW --display-floor (provisional 1.272rem). Display type is sentence case at zero or negative tracking, always. Emphasis inside display type is weight + colour (600 + --brand), never slant - the em rule itself is component styling, written in the hero/display block at step 7; the serif italic is reserved for citation - case names, statutes, Latin - and the TRUE italic is loaded (Newsreader ital 400) so font-synthesis: none can never fake one. IT IS LOADED AND UNASSIGNED TODAY: the firm's request carries one italic at one weight, and .hero-title em / .display em explicitly set font-style: normal, so nothing claims it yet - same status Titillium 700 had, and DESIGN-SYSTEM.md s9's rule applies (drop it from the request if nothing claims it by the next pass). FAILURE MODE: below its floor a serif's stroke modulation stops resolving - all of the second font's cost (download, FOUT, a second voice), none of its benefit. THE FAILED AND FORBIDDEN ALTERNATIVES, recorded so neither is re-proposed: futura-pt all-caps page titles at 42px re-staged the sub-line's gesture and fought the wordmark; and a SANS sentence-case headline would re-stage the wordmark itself, which is set sentence-case in a humanist sans ("TWM" Titillium Text Light, "Legal" Titillium Text Medium - the 2013 vector). Hence the display face is the serif, and Montserrat never carries sentence case above --text-1. THAT ARGUMENT IS WEAKER THAN IT WAS AND IS KEPT ANYWAY: it used to be airtight because the body face WAS the wordmark's face, so a sans headline was literally the mark enlarged. Montserrat is a geometric sans and Titillium Text a humanist one, so a Montserrat headline is no longer the mark enlarged - only a near neighbour of it. The rule stands on the register argument alone (one voice per job), which is the half that never depended on the wordmark's face. */ /* FOUR REGISTERS. The type system speaks in four voices and the motion system gets the same four, mapped one to one, heaviest slowest and travelling least. Reveal durations are the playbook's register values x 1.5 (a measured brand, and since [MOTION v20] a SLOW one - the tokens carry the multiplier's whole argument); they are tokens, not rungs of the ladder. REGISTER TYPE ARRIVAL LABEL/RULE Montserrat --text-label caps, --wt-label 600, CSS-owned (no script reaches a --track-N by role; draws its own hairline on pseudo-element): hairline draws ::before --dur-slow --ease-out DISPLAY Newsreader - the ONLY place it appears; --reveal-display 1.425s --ease-out; sentence case, >= --display-floor, tracking <= 0, the heaviest thing travels least text-wrap: balance (hero-title, display only) PLATE a card: serif h3 + sans body + tracked-caps --reveal-plate 1.2s --ease-out, attribution ONE object - never sub-staggered; the cascade comes from the grid LIST enumerated procedure (matter stages, engagement --dur-slow --ease-out; its hairline steps) ENTIRELY in Montserrat - its type sits draws with a fixed --lag-rule below the serif floor; hairline on a pseudo (0.18s) lag, and since [MOTION v20] its numeral follows at twice that + one CSS-only opt-out: [data-reveal="fade"] for imagery - opacity only, no translate, --dur-media. Three JS registers, four arrival behaviours. Registry order (step 8): the DISPLAY row precedes the PLATE row; first match wins. DIVISION OF LABOUR (IntersectionObserver + CSS transitions, no GSAP): · CSS owns pseudo-element STATES keyed on .is-revealed, and every duration and ease. · JS only ever animates TOWARD visible: it adds .is-revealed and nothing else. It never writes opacity: 0 or a transform. If JS never hides anything, no JS failure can leave anything hidden. The pre-state lives in CSS under html.js [data-reveal]:not(.is-revealed). · Stagger is JS's job; a fixed intra-object lag (--lag-rule) is CSS's - choreography within one object, not stagger across a group. JS publishes an element's place in the cascade as ONE inherited custom property, --reveal-delay, and CSS spends it: on the element as its transition-delay, and on the element's decorated pseudo-elements added to their own lag. It cannot be an inline transition-delay, because that never reaches a ::before, and every hairline in this stylesheet lives on one (guards 7.4 carries the failure it caused). The reduced-motion clamp still flattens the cascade without flattening the object, because it resets transition-delay on *, *::before and *::after alike. TRAILING-SPACE RULE: CSS adds letter-spacing after the LAST character too, so any centred or right-abutted tracked label pulls the thing after it back by exactly its own tracking - --eyebrow-track-cancel: calc(-1 * var(--eyebrow-track)) - never a retyped number. PLACEMENT - two departures from the build brief, stated so they are not read as drift: the reduced-motion clamp lives in @layer guards, not base, because it is the one rule that must win by layer over every component and it is the only sanctioned !important; the display-face hook list lives in base, not layout, because it is a type GRANT (which selectors may carry the serif), not a layout primitive. Cascade unchanged either way: [hidden] in base contests nothing in guards. */ /* ---- 1 · TOKENS ---------------------------------------------------------- */ @layer tokens { :root { /* ---- Colour. The block from reference/derivation/tokens.css, VERBATIM (values and comments). OKLCH appears only in comments; values ship as hex. One reading note the verbatim block does not carry: the "x1.6 per step" ladder is --bg 0.00380 -> --bg-2 0.00612 (x1.61, 1.043:1) -> --bg-3 0.00963 (x1.57, 1.063:1), both pairs inside worksheet #10's 1.04-1.06 window. --bg-0 is hex-quantised at this darkness: L 0.00225 against a 0.0038 / 1.6 = 0.00237 target (a x1.69 step, 1.03:1 over --bg, just under the window). At 3% lightness one channel step is ~0.0003 of luminance, more than the 0.00012 shortfall: #0A0808 lands at 0.00256 (farther, on the far side) and #0A0707 at 0.00232 (nearer) breaks the 12-13% saturation bracket (18%). --bg-0 is a sub-ground, never a text ground, so the pair test does not bind; it moves only if derive_colors.py is re-run. Second reading note, AND [RED v7] INVERTED IT: --brand-ink's "(beat #FFFFFF at 2.75:1)" was white on --brand-BRIGHT, and on that stop the near-black still wins - white there is 2.69:1 against its 7.38:1. It does NOT win on the deep fill: on --brand-fill white is 6.53:1 where the near-black is 3.04:1. So the two fills took OPPOSITE inks (3.04 and 7.38 for the near-black), which was not an inconsistency but the point of keeping TWO fills - one dark enough to carry white, one light enough to carry near-black, and each taking the ink it can carry. [HOVER v22] THAT SPLIT IS OVER AND THE NOTE IS KEPT AS ITS RECORD. The light fill was --brand-bright and it is retired with the rest of the pink; the hover fill is now --brand-fill-hover #8F0000, a SHADE, so both fills are dark and both carry #FFFFFF - 6.53:1 resting, 9.69:1 hovered. There is one ink on red areas again, --brand-ink has no ground left to sit on and is retired with the stop it was solved against, and the paragraph above survives only to explain why two inks ever existed. [RED v8] THE THIRD SENTENCE OF THAT NOTE IS GONE, and its removal is the whole of this pass. It read "--brand itself is no longer a fill at ALL - not because it could not carry ink (near-black on it measures 5.66:1) but because the whole point of the split is that a fill may be deep, so a text stop has no business being one." The firm has instructed that the text stop BE the fill. --brand and --brand-fill now hold the same hex, and they are still two tokens: see the collapse note below. THIRD READING NOTE, AND THE ONE THAT DATES THIS BLOCK: --ink-3 and the whole brand ladder are no longer the values derive_colors.py printed. TWO GENERATIONS, in order, both dated 2026-09-05: [GLOW] superseded, kept for its reasoning. The pointer light (6.26) is a screen-blended layer over the whole viewport, so it lightens the TEXT as well as the ground and both sides of every pair move; both tokens sat on the 4.5 floor with ~0.01 of headroom, which made the light unaffordable at any useful alpha. derive_glow.py's inverse solve fixed the light at the alpha that reads (0.055 peak, against the reference site's 0.063) and asked what the palette must become: one step of sRGB LIGHTNESS on each, hue and saturation held. Nothing else in the block moved. [RED v7] superseded in its values, kept because it is the record of what v8 traded away. "Deeper" turned out to be TWO corrections and only one of them is lightness. (1) HUE 5.08 -> 0 and SATURATION 83.9% -> 100%. That is what makes the red read as red rather than as coral, it is the mark's own hue, and it costs NOTHING in contrast - it is free, and it applies to every stop on the ladder at once. THAT CORRECTION STANDS UNTOUCHED IN v8. (2) LIGHTNESS down, bounded, and only where a stop is used as a FILL. On a near-black ground the two uses pull opposite ways: a FILL has ink ON it, so deeper RAISES the ink ratio (white on #C00000 was 6.48:1 against the old near-black-on-#EE4C3D at 5.43:1 - deeper AND more legible); TEXT sits on the ground, so deeper LOWERS its ratio (#BF0000 as text is 2.99:1, a fail). Hence v7's split into --brand-fill and --brand - and hence v7 kept the TEXT stop light at #FF3D3D, 5.02:1 on --bg-3, deliberately refusing the mark's own red for type. [RED v8] what ships. The firm was shown those measurements and instructed the deep red for every red on the site, TEXT INCLUDED. So the lightness half of v7 is reversed and the whole ladder lands on #BF0000: fill, text, selection, marks. The consequences, all of them measured: (a) FILLS GET BETTER. White on #BF0000 is 6.53:1 against #C00000's 6.48:1. (b) RED TEXT FAILS AA, EVERYWHERE. 2.99:1 on --bg, 2.86:1 on --bg-2, 2.70:1 on --bg-3. Named element by element below. This is the firm's recorded decision of 2026-09-06, not an oversight, and it is asserted as a failure by tools/verify_ratios.py so it cannot be quietly reverted or quietly forgotten. (c) THE LIGHT GETS 1.62x BRIGHTER, because the ceiling was set by the lowest-contrast TEXT and that was red at 5.02:1. With red out of the AA budget the binding pair becomes --ink-3 and the peak goes 0.076 -> 0.123. The firm asked for a stronger glow in the same message; it is a consequence of (b) rather than an independent decision. (d) FOUR DERIVED VALUES WERE RE-SOLVED, not re-chosen, because each is defined in this file as a function of the light: --line-control 0.36 -> 0.37, .band--ivory's and print's --line-control 0.47 -> 0.49, [aria-busy]'s opacity 0.70 -> 0.73, and --danger-ivory one rung darker. Each carries its own solve at its own line. ------------ */ /* TWM Legal - colour tokens. EVERY value below is derived, not picked; the arithmetic is beside it. Method: reference/playbook/PLAYBOOK.md, worksheet #07-#14 and section 2. The grounds, the inks other than --ink-3, the hairlines, --danger and the ivory family were computed by reference/derivation/derive_colors.py on 2026-09-05. The accent ladder, --ink-3, the two glow triplets and the ivory accents were re-solved the same day by scratchpad/derive_red_v7.py and locked by scratchpad/lock_v7.py (results in scratchpad/v7.json). THE 2026-09-06 COLLAPSE ONTO #BF0000 HAS NO PRIVATE SCRIPT AT ALL, deliberately: every figure it moves - the new peaks, the four dependent re-solves, and the failing red-text pairs - is re-derived on every run by tools/verify_ratios.py, which is checked in, where scratchpad/derive_red_v7.py never was. Do not edit a value without re-running the thing that owns it. Inputs: dark-primary ground; brand hue 0 / saturation 100% from the logo red #BF0000. The CSS keyword red the Squarespace site used, #FF0000, is that SAME hue and saturation and was never the drift; the drift was the ~5 degrees of hue the derived ramp had picked up, which v7 removed. Every brand stop below is an sRGB tint or shade of hue 0 / saturation 100. */ /* Grounds - a geometric luminance ladder, x1.6 per step from L0 = 0.0038 (worksheet #10). Hue bracketed 20 / 0 / 340 at 12-13% saturation so every dark neutral is a red-tinted black, never #000. */ --bg-0: #090707; /* hsl(20, 12%, 3.06%) L 0.00225 footer sub-ground */ --bg: #0E0C0B; /* hsl(20, 12%, 4.73%) L 0.0038 page ground */ --bg-2: #161111; /* hsl(0, 12%, 7.53%) L 0.00612 band + plate (1.043:1 over --bg) */ --bg-3: #1E171A; /* hsl(340, 13%, 10.58%) L 0.00963 raised plate + focused field (1.063:1 over --bg-2) */ --bg-rgb: 14, 12, 11; /* scrims and washes: rgba(var(--bg-rgb), a) - never a new grey */ /* Inks (worksheet #11) - tinted toward the brand hue; each verified on every ground it can land on. */ --ink: #F7F3F4; /* hsl(335, 18%, 96%) 17.73:1 on --bg, 16.0:1 on --bg-3 */ --ink-2: #B3A8A8; /* hsl(0, 7%, 68%) 8.44:1 on --bg, 7.62:1 on --bg-3 */ /* [GLOW] PREVIOUS GENERATION, kept because it records why the value v7 replaced was chosen: --ink-3 was #8B7E7E (hsl(0, 5.3%, 51.96%); 5.00:1 on --bg, 4.51:1 on --bg-3). Same hue, same 5% saturation, +0.98% lightness - one channel step, (139, 126, 126) -> (141, 129, 129). WITH the pointer light at its 0.055 peak this pair measures 4.55:1 on --bg-3; at the old value, 4.39:1. BOTH LIT FIGURES ON THAT LINE ARE HISTORICAL: they were measured under the v6 light (lead #FF6E5C at a 0.055 peak, trail #C91810 at 0.026), and neither the lobes nor the peaks still ship. [RED v7] --ink-3 was #8D8181 (hsl(0, 5%, 52.94%); 5.19:1 on --bg, 4.69:1 on --bg-3). Same hue, saturation 5.0% -> 4.8%, +2.16% lightness - (141, 129, 129) -> (146, 135, 135). THE CAUSE IS THE LIGHT, NOT THE RED: --ink-3 is not a brand stop and did not need the hue correction, but it shares the ceiling the light is solved against, so raising the peak 0.055 -> 0.076 moved it too. Two channel steps this time, not one, because the light rose 1.38x rather than holding. [RED v8] --ink-3 DOES NOT MOVE, AND THAT IS NOW ITS WHOLE JOB. With red text out of the AA budget this token IS the ceiling the light is solved against: the binding pair for the entire palette is --ink-3 on --bg-3, and 0.123 is the largest lead peak at which that pair still holds - 4.5041:1 with both lobes converged. Under v7's dimmer light the same pair sat at 4.7591:1, i.e. the value was chosen with a quarter of a point of headroom over the floor; v8 spends every bit of it. Raising the light again from here means moving THIS token, exactly as v7 had to move it. */ --ink-3: #928787; /* hsl(0, 5%, 55.10%) 5.61:1 on --bg, 5.06:1 on --bg-3 - recede by size, never by dimming further */ --ink-nav: #CAC4C4; /* hsl(0, 5%, 78%) THE HEADER NAV'S RESTING LABEL, and its lightness is solved rather than chosen. The nav sits on .site-header::before, a scrim that thins to rgba(--bg, 0.72) at its 53% stop, and the hero beneath reaches a full 255 - so the binding ground is 0.72 over a WHITE pixel, which composites to #51504F, where the obvious muted stop --ink-2 lands under AA for 13.36px type - which is why it could not be used. 78% lightness is the lowest whole step that clears the floor on that worst case; the three grounds it faces are claimed on the declaration itself rather than restated here. Against --ink it reads plainly fainter, which is the whole point - the firm asked for a faded label that brightens on the current page and under the pointer. */ --ink-rgb: 247, 243, 244; /* Hairlines (worksheet #12) - alpha of --ink, ONE OCTAVE APART, split by AFFORDANCE not prominence. COMPOSED from --ink-rgb, not retyped: --ink appears at four alphas across this file (0.09, 0.18, 0.36 and the washes in 6.1/6.9), which is the playbook's own "three or more alphas earns a triplet" case, and hand-typed channels would keep pointing at the old colour if --ink is ever re-derived. The print block (6.25) and the ivory band (step 5) compose the same rungs the same way. This is a FORM change, not a value change - the computed colours are byte-identical to the two literals that stood here and to reference/derivation/tokens.css, which still carries the literal form. THERE ARE THREE RUNGS SINCE THE v7 REPAIR PASS, AND THE THIRD IS DERIVED RATHER THAN CHOSEN. --line and --line-strong are a TONAL pair and neither carries an accessibility obligation: a seam, and an emphasis edge that always has a louder indicator beside it (a plate's :focus-within warms this edge while the focused LINK inside still draws base's 2px --ink ring, and .svc-card's hover tint composites to #682020, the same 1.62 weight warmed). --line-control is the rung for an edge that is the ONLY thing identifying a control - a text field's boundary, a ghost button's whole affordance, an underline that is a link's only non-colour cue - where WCAG 1.4.11's non-text floor binds for real, and where 0.18 measured 1.62 against it. It is the SMALLEST alpha clearing that floor on every ground in the palette in BOTH states, lit and unlit - and "in the palette" is the exact scope, not a loose one. A CONTROL OVER A PHOTOGRAPH IS NOT COVERED BY IT: .btn--ghost's border in a hero or in the closing band sits on a scrim ground, where the pair measures 3.04 unlit / 2.74 lit at the hero's action row and 3.23 / 2.99 in the band - under 1.4.11 in the reading state, on the edge that is that button's whole affordance. It is recorded here rather than repaired because the repair is a token change with site-wide reach (every hairline on every ground moves with this alpha) and the pairs it would fix are the same pairs the scrim re-solve of [SCRIM v12] did not have to touch; it is the next thing to take to the palette, and it should be taken there deliberately rather than inside a media pass. A HAIRLINE composite is quantised to 8 bits before measuring, because that is what a browser paints: --line* is an ink at an alpha that resolves to ONE painted colour, and the comments name that colour as a hex (#646161 below). THE RULE IS SCOPED TO PAINTED COLOURS AND SAYING SO IS NOT PEDANTRY - a review has already read it as universal and reported the light's ceiling pair as failing on that reading. It is not universal. A scrim veil, an element opacity and the pointer light's screen blend are COMPOSITOR operations that never become an authored colour, so they are measured raw, exactly as tools/verify_ratios.py measures them (its LINE() quantises, its LIT() and BUSY() do not, and BUSY() says why in one line). The ceiling below is therefore 4.5041:1 as written; quantised it would read 4.48:1, a number about a paint step this pair never takes. [RED v8] THAT ALPHA IS 0.37 AND IT USED TO BE 0.36, and the difference costs the ladder a coincidence worth naming so nobody restores it out of tidiness: 0.36 was EXACTLY one octave above --line-strong's 0.18, and this file used to argue the rung partly from that. It cannot any more. The 1.62x brighter light drags a hairline's pair down on the ground it is faintest against, and at 0.36 the --bg-3 case fell to 2.9514:1 - under the floor, in the reading state, on edges that are some controls' only boundary. 0.37 is the re-solve: one hundredth above the octave rather than on it. THE ALPHA IS THE DERIVED THING AND THE OCTAVE WAS THE COINCIDENCE, so the alpha wins. WHAT THIS IS NOT: a brightening of the site's hairlines. Neither existing rung moved, and nothing drawn at 0.09 or 0.18 for TONE is redrawn at 0.37 - the new rung has SIX declarations, each with its reason in its own block: .prose and .check-list links (6.6/6.7), 6.16's contact links, 6.17's field border, 6.18's ghost button, and 6.21's one rule covering the four footer link families. .svc-card and .package keep --line-strong on :focus-within, deliberately: the ring on the focused child is the indicator there, and this edge is the quieter parity response the block asks for. */ --line: rgba(var(--ink-rgb), 0.09); /* seams: composites to #232120, 1.22:1 - a tonal seam, not a state */ --line-strong: rgba(var(--ink-rgb), 0.18); /* emphasis edge, never a control's only boundary: #383635, 1.62:1 */ --line-control: rgba(var(--ink-rgb), 0.37); /* a control's ONLY boundary: #646161 on --bg. The binding case is --bg-3 under the converged light at 3.03:1; then --bg-2 lit 3.13:1, --bg-0 unlit 3.13:1, --bg lit 3.16:1 */ /* Brand (worksheet #07-#08) - FOUR stops, split by JOB, on ONE sRGB hue and ONE sRGB saturation, and since [RED v8] on ONE LIGHTNESS as well for three of the four. [HOVER v22] THE FOURTH STOP IS A DIFFERENT STOP, and the swap gives the ladder something [RED v7] recorded giving up. It was --brand-bright #FF7070, a TINT of the mark; it is now --brand-fill-hover #8F0000, a SHADE of it. A tint of a hue-0 red drifts in OKLCH - #FF7070 measures hue 22.50 there against #BF0000's 29.2339 - where a shade does not, so all four stops now sit on OKLCH hue 29.2339 and the ladder holds ONE hue in BOTH spaces for the first time: sRGB by construction, OKLCH by consequence. Why the tint left at all is THE RETIREMENT, below the stops. [RED v7] THE LADDER IS ANCHORED IN sRGB, NOT IN OKLCH, AND THAT IS A CHANGE OF METHOD, stated rather than smuggled. Every stop is hue 0 / saturation 100 - the mark's own coordinates, and the thing the firm was actually asking for - so the OKLCH figures below are now a CONSEQUENCE, not the input: hue 29.23 at every stop since [HOVER v22], and 22.50 at the retired --brand-bright. The old ramp held one OKLCH hue (29.2) and one OKLCH chroma, and holding those is precisely what put --brand five degrees off pure red in sRGB - which is what read as coral. [RED v8] THE LADDER COLLAPSES. The firm's instruction of 2026-09-06 was that every red on the site be the red the text highlight paints, which is --brand-deep, which is the 2020 wordmark's #BF0000. So --brand-fill, --brand and --brand-deep now hold ONE value and only the fourth stop stands apart. WHERE EACH BOUND COMES FROM, so no stop can be nudged without breaking something nameable: --brand-fill the mark's own red, #BF0000, on the firm's instruction. Its own edge no longer clears WCAG 1.4.11's 3:1 against --bg - it measures 2.988:1, missing by 0.012 - and the cost of that miss is a fifth of what the v7 comment implied it was, which is why the instruction was cheap to honour on the FILL. See the stop's own line. --brand THE SAME VALUE, on the firm's instruction, over a measured objection. Red TEXT is now 2.99:1 / 2.86:1 / 2.70:1 on the three grounds and meets AA on none of them. v7 had held this stop at #FF3D3D (5.02:1 on --bg-3) for exactly that reason. See THE AA FAILURE, RECORDED below - it is a decision, not a defect, and the only thing that would make it a defect is a comment that hid it. --brand-deep #BF0000, unchanged since v7 and now the value the other two were collapsed ONTO. --brand-fill-hover #8F0000, and DERIVED from --brand-fill rather than picked: the resting plate's one live channel at three quarters, 0.75 x 191 = 143.25 -> 143 = 0x8F. It is the only stop with no legibility of its own and the only one that is never at rest. WHY --brand AND --brand-fill REMAIN TWO TOKENS WHILE HOLDING ONE VALUE. They were split because they do different jobs - one has ink on it, one sits on the ground - and every consumer in this file is already labelled with which job it is doing. Keeping them split is precisely what makes restoring AA on text a ONE-LINE change: put --brand back to #FF3D3D and every red AREA stays exactly as the firm asked for it. Merging them would throw that away to save a line. [GLOW] PREVIOUS GENERATION, kept for the lesson it records: --brand had been the smallest lightness clearing 4.6:1 on --bg-3, the lightest ground a brand-coloured link can sit on, and was raised one sRGB lightness step above that floor because the SMALLEST passing value is by construction the one with no headroom to spend on a light laid over it. That move was lightness only - hue 4.92 -> 5.08, saturation 83.6% -> 83.9%, held to within hex quantisation - so the OKLCH chroma drifted 0.2070 -> 0.2009 as a consequence rather than as a decision. v7 keeps that lesson and discards the method: hue 5.08 -> 0.00 and saturation 83.9% -> 100.0% are DELIBERATE this time, and the chroma drifts 0.2009 -> 0.2292 - it RISES, still as a consequence. The one hue no longer holds in OKLCH and is no longer asked to: 29.25 -> 26.25 there, 0 -> 0 in sRGB, which is the space the mark is specified in. (The retired --brand-bright's chroma was 0.1751, GAMUT-CLIPPED, the same kind of rounding; --brand-fill-hover's 0.1675 is not clipped at all, because a shade of an in-gamut colour cannot leave the gamut - one more thing the tint-to-shade swap tidies rather than trades.) [RED v8] The sRGB hue and saturation that v7 fixed are exactly what v8 keeps; only lightness moved, and it moved to the mark's, so the OKLCH figures walk back to #BF0000's own 0.2073 at 29.2. */ --brand-fill: #BF0000; /* oklch(50.5% 0.2073 29.2) hsl(0, 100%, 37.45%) - every red AREA: .btn, drawn rules, filled marks, accent borders. THE 2020 WORDMARK'S OWN RED, on the firm's instruction of 2026-09-06. Ink on it is #FFFFFF at 6.53:1, BETTER than the 6.48:1 #C00000 gave and far better than the 5.43:1 that shipped before v7 (the retired --brand-ink here would be 3.04:1 and fail). NEVER TEXT. [RED v8] WHY THIS COST ALMOST NOTHING, and the finding is recorded here so it is not rediscovered from scratch. v7 chose #C00000 over the mark's #BF0000 for ONE reason - to clear WCAG 1.4.11's 3:1 floor on the control's own edge - and that margin was mostly illusory. Measured on the file v7 shipped, under v7's own converged light, #C00000's edge was 3.01:1 on --bg unlit but 2.89:1 lit, 2.89:1 on --bg-2 unlit and 2.73:1 lit, 2.72:1 on --bg-3 unlit and 2.53:1 lit - so the floor was ALREADY unmet on every tinted ground and in the reading state on the plain one, and .btn demonstrably ships on --bg-2 (four pages; nine buttons inside .package on /flat-fee-services alone). #BF0000 measures 2.988:1 on --bg unlit: the collapse forfeits 0.024 on ONE ground in ONE state and nothing anywhere else. A LIGHTER RIM TOKEN WAS BUILT FOR THIS AT v7 AND DISCARDED; do not reinvent it. At 1px a #D90000 rim measures 1.22 against the #BF0000 plate it edges - invisible - which is a number that passes an audit while helping nobody. WHAT ACTUALLY IDENTIFIES THE CONTROL is its own label: #FFFFFF tracked caps at 6.53:1 on the plate, which is what 1.4.11 allows where a visible label identifies the component. That is the honest account of where the affordance comes from; the edge never was. A lighter FILL is still the one lever nobody may pull silently. */ --brand-fill-hover: #8F0000; /* oklch(40.8% 0.1675 29.2) hsl(0, 100%, 28.04%) - the fill a red AREA takes on HOVER, and nothing else: .btn's plate and .btn's edge. NEVER text, never a rule, never anything at rest. The name carries "fill" for a reason - this is the one stop in the ladder with no legibility of its own. DERIVED, NOT PICKED. It is --brand-fill's one live channel at three quarters: 0.75 x 191 = 143.25 -> 143 = 0x8F. A hue-0 / saturation-100 red HAS exactly one live channel, so that single multiply is the whole of the shade and both coordinates come through it untouched - which is why this stop lands on the ladder's own OKLCH hue (29.2339, #BF0000's own figure) rather than drifting off it the way the tint it replaced did. WHAT IT BUYS IS THE WHITE LABEL, and the two figures are the same figure: #FFFFFF on the plate goes 6.53:1 at rest -> 9.69:1 hovered, a 1.48x lift, and the two plates measure 1.48:1 against EACH OTHER. That identity is not a coincidence - darkening a ground scales a white ink's ratio by exactly the ground's own step - and it is the reason the gesture reads: nothing else on this control changes colour, so the plate carries the whole hover and the label's legibility rises with it instead of crossing anything. WHAT IT COSTS IS THE PLATE'S OWN EDGE, recorded in half (B) of THE AA FAILURE below rather than left to be discovered: 2.99 / 2.86 / 2.70:1 at rest becomes 2.01 / 1.93 / 1.82:1 on --bg / --bg-2 / --bg-3. That edge was ALREADY under 1.4.11's 3:1 as a recorded decision, so this deepens an accepted shortfall rather than opening a new one, and the defence is --brand-fill's own: what identifies a red plate here is its white LABEL, not its rim, and the label gets BETTER on hover. A hover is also transient and is reached only after the control has already been found. DO NOT INVENT A RIM TOKEN FOR IT - v7 built one and discarded it, six lines up. */ --brand: #BF0000; /* THE SAME VALUE AS --brand-fill, and still its own token - red TEXT on dark: links, eyebrows, [aria-current], list numerals, arrows. 2.99:1 on --bg, 2.86:1 on --bg-2, 2.70:1 on --bg-3. THOSE ALL FAIL WCAG AA, and under the light at its shipped peaks they fall further: 2.73:1 on --bg and 2.36:1 on --bg-3. THE FIRM'S RECORDED DECISION OF 2026-09-06, taken after being shown these measurements. It is not a defect and it is not to be silently repaired; tools/verify_ratios.py asserts these pairs are BELOW AA so that a quiet "fix" fails the build. See THE AA FAILURE, RECORDED below. [RED v7] was #FF3D3D (5.56:1 / 5.33:1 / 5.02:1), chosen as the deepest hue-0 red that still cleared AA under v7's light. THE ONE-LINE REVERT IS THIS LINE: --brand: #FF3D3D restores AA on every element in the list below and changes no red AREA anywhere, because the fill is a separate token. */ --brand-deep: #BF0000; /* oklch(50.5% 0.2073 29.2) - and 0.2073 is #BF0000's OWN chroma, the nominal the old ramp was built to, now shipping as itself. 2.99:1 on --bg. Selection fill, decorative marks and the trail lobe. [RED v8] This stop did not move; the other two moved onto it, because the firm named the highlight as the reference. */ /* ---- THE RETIREMENT: --brand-bright #FF7070 and --brand-ink #110707 are GONE, [HOVER v22] --------- THE FIRM'S INSTRUCTION OF 2026-09-06, verbatim: "I do not like the pink color that is used when certain links and buttons are hovered over with mouse. They should all be the dark red color which is the signature color for the brand. fix throughout site." #FF7070 was the pink, and it held THREE JOBS on one token - every hover colour, every focus ring, and the pointer light's lead lobe. The firm named one of the three, so the three had to be separated before anything could be answered. THE LITERAL INSTRUCTION IS IMPOSSIBLE AND THE FIRM WAS TOLD SO BEFORE CHOOSING. #BF0000 is ALREADY the resting colour of every red link and the resting fill of every .btn, so "the hover is #BF0000" is "the hover looks exactly like rest" - no feedback at all, on every interactive red on the site. Shown that, and shown the measurements below, the firm chose this scheme the same day: TEXT HOVERS -> var(--ink). A red link at 2.99:1 warms to 17.73:1 on --bg (17.00:1 on --bg-2, 16.00:1 on --bg-3). It is the largest lift the palette can give, and it introduces no colour: --ink is what the copy around the link is already set in, so a warming link resolves INTO its paragraph rather than away from it. Nav, mobile menu, contact list, .link-arrow, .crumbs, the four footer families and the linked stat all take it, so the site keeps ONE hover colour rather than two. BUTTON FILL -> var(--brand-fill-hover), the stop above. The plate DEEPENS toward a shade of the signature red instead of inverting to a tint of it, which is as near the literal instruction as a hover can be while still being a hover. FOCUS RINGS -> var(--ink), everywhere, AND THIS ONE IS NOT THE FIRM'S AESTHETIC CHOICE TO MAKE. A #BF0000 ring measures 2.99:1 / 2.86:1 / 2.70:1 on --bg / --bg-2 / --bg-3 - all three under WCAG 1.4.11's 3:1 - and on a #BF0000 button it is 1.00:1, invisible by definition rather than by measurement. --ink is 17.73:1. Keyboard users navigate by this ring and by nothing else, so it is the one value in this scheme that is a correctness constraint rather than a preference: it may not be rebound to a brand colour without taking the site's only keyboard affordance away. THE LIGHT -> UNCHANGED, and deliberately so. The lead lobe keeps #FF7070 as a bare triplet (--glow-lead, in worksheet #14/#15 below) and not one stop of 6.26 moves. It is not a hover colour and it is not read as pink: at the shipped 0.123 alpha over the near-black ground the lobe core composites to #351918, a dark warm red. Dimming it would also undo "make the glow stronger", which is the firm's OTHER instruction of the same day. WHY THE TOKENS GO RATHER THAN STAYING ON AS DOCUMENTATION. With the hovers and the rings moved off it, NO RULE IN THIS FILE READS --brand-bright - its only surviving trace is #FF7070 as --glow-lead's triplet, and a triplet cannot be composed from a hex token in CSS anyway, so "the documented source of the lead lobe" could only ever have meant a comment. This is that comment. Left in the ladder the token would be worse than merely dead: a stop named for hover fills and focus rings, sitting one line under the reds, is an invitation to paint the pink straight back. --brand-ink goes with it because it was defined as "text ON --brand-bright" and had exactly two consumers, both .btn rules that now carry #FFFFFF at rest and hovered alike. THE RETIRED VALUES, so they stay measurable rather than becoming folklore: --brand-bright was #FF7070 = oklch(71.9% 0.1751 22.5) = hsl(0, 100%, 72.0%), 7.25:1 on --bg and 6.54:1 on --bg-3; --brand-ink was #110707, 7.38:1 on --brand-bright where #FFFFFF managed 2.69:1. tools/verify_ratios.py keeps both constants and still re-derives every one of those figures. .band--ivory (step 5) and @media print (6.25) each lost the two rebindings that went with them. ---- */ --brand-rgb: 191, 0, 0; /* = --brand, the TEXT stop, as a triplet - and since [RED v8] also = --brand-fill's and --brand-deep's channels, so the "an AREA that needs a triplet would need a --brand-fill-rgb" caveat is dormant rather than gone: it wakes the moment the one-line revert above is taken. Its one alpha use is 6.9's card edge. */ /* ---- THE AA FAILURE, RECORDED -------------------------------------------------------------------- THIS LIST HAS TWO HALVES AND THEY ARE ONE DECISION: red TEXT that misses WCAG 2.1's 1.4.3, and red NON-TEXT that misses 1.4.11. It used to have only the first half, and the omission was not harmless - two comments elsewhere in this file pointed a reader at "the failure list" for a non-text failure that was not in it, and the summary sentence at the foot of the block claimed every focus state still passed. Both were repaired on 2026-09-06 by writing half (B), not by softening half (A). The colour is the firm's instruction of 2026-09-06 ("All red should be the color of the text highlight color"), given after the measurements were put in front of them. It is written out in full because a comment that let the reader assume otherwise would be the defect - the colour itself is a decision the firm is entitled to make. (A) TEXT. AA needs 4.5:1 below 24px (or below 18.66px at 600+), and 3:1 at or above it. Ratios are unlit; the pointer light takes each one lower still (2.73:1 on --bg, 2.56:1 on --bg-2, 2.36:1 on --bg-3). 2.99:1 on --bg / 2.86:1 on --bg-2 / 2.70:1 on --bg-3, at these sizes: a, .prose a, .check-list a, .contact-list a, .form-sent a 17px 400 needs 4.5 .form-note a 13.36px 400 needs 4.5 .eyebrow, .link-arrow, .num-list li::before, .mobile-menu-contact a, .nav-links [aria-current="page"] 13.36px 600 needs 4.5 .display em 34.99px 600 needs 3, misses by 0.01 .hero-title em 44.51px 600 needs 3, misses by 0.01 .mobile-menu [aria-current="page"] 27.51px 400 needs 3, misses by 0.01 .stat--linked:focus-within .stat-num 27.51px 400 needs 3, misses by 0.01 AND ONE PAIR THAT IS WORSE THAN THE GROUND FIGURES SUGGEST: the header's current-page label sits over the hero photograph behind a scrim, where against a pure-white pixel it measures 1.23:1 at the scrim's 0.72 worst-case stop and 2.64:1 on the 0.94 ground the no-JS gate pins (6.1 carries the arithmetic). No veil alpha rescues it - see the hero scrim note in 6.3. (B) NON-TEXT. 1.4.11 asks 3:1 of whatever identifies a component or one of its states, and FOUR red things answer to it since [HOVER v22]. Three are covered by something louder. The fourth was not, and was the only accessibility cost of the colour pass that landed on a KEYBOARD user rather than on a reader - it has since been repaired, and the repair is written at the foot of its own row. THE PLATE RIM of .btn, .skip-link and .form-sent is 2.99:1 / 2.86:1 / 2.70:1 on the three grounds. COVERED: what identifies a red plate is the white label on it at 6.53:1, which is exactly what 1.4.11 allows where a visible label identifies the component. The rim never was it, and the stop's own line above carries the arithmetic of what the collapse cost here (0.024, once). THE HOVERED PLATE RIM, [HOVER v22], IS THE SAME EDGE DEEPER, AND IT IS RECORDED HERE RATHER THAN DISCOVERED. --brand-fill-hover darkens the plate toward the page, so the rim it draws falls to 2.01:1 / 1.93:1 / 1.82:1 on --bg / --bg-2 / --bg-3. COVERED BY THE SAME ARGUMENT, AND BY ONE MORE THAT ONLY A HOVER GETS. The white label goes the other way - 6.53:1 -> 9.69:1 - so the thing 1.4.11 actually accepts as the identifier gets BETTER exactly when the rim gets worse; and a hover state is transient and is reached only after the control has already been found, which a resting state cannot say. This deepens an accepted shortfall on the row above rather than opening a new one. It is NOT a licence to deepen the resting fill, and it is not an argument for a rim token: see --brand-fill. THE DECORATIVE MARKS - .check-list's diamond (6.7), .quote-card's leading edge (6.14), .form-sent's leading edge (6.17) - carry no information the words beside them do not, so no floor binds. THE FIELD'S SUBSTITUTED FOCUS BORDER WAS THE ONE WITH NOTHING BEHIND IT, and it was a REGRESSION rather than an inheritance: 6.17 sets outline: none on inputs, textareas and selects, so its 1px edge IS the focus indicator, and at --brand it measured 2.70:1 against the --bg-3 it encloses and 2.86:1 against the --bg-2 outside it - under the floor on both surfaces it separates, where v7's lighter text stop cleared both at 5.02:1 on --bg-3. Every field in the contact form lost a compliant focus cue on 2026-09-06. THAT ONE-LINE REPAIR WAS TAKEN THE SAME DAY and has been taken a second time since. On 2026-09-06 6.17 moved its border-color to --brand-bright, 6.54:1 inside and 7.25:1 outside; [HOVER v22] retired that stop with the rest of the pink, so the border now takes var(--ink) - 16.00:1 against the --bg-3 it encloses and 17.00:1 against the --bg-2 outside it. The requirement did not change and neither did the reason: this edge is a SUBSTITUTED focus indicator, so 1.4.11 binds on it as a function, and the colour that satisfies a function is whichever one clears it. The checkbox is excluded by type there and keeps base's ring already. THE SENTENCE THIS ROW USED TO END ON IS DEAD AND IS NOT WORTH SALVAGING: "it is the ONLY red the collapse did not take". There is no red in a focus indicator anywhere on the site now. Every red a visitor READS as brand is #BF0000; every indicator a visitor NAVIGATES by is --ink. WHAT IS NOT ON THIS LIST, because it still passes: every red AREA's INK - white on the resting fill is 6.53:1 and on the hovered fill 9.69:1 - then every state drawn in --ink since [HOVER v22]: base's focus ring, every text hover, the ghost button's hover and focus edge and 6.17's substituted field border, at 17.73:1 on --bg, 17.00:1 on --bg-2 and 16.00:1 on --bg-3. Then --ink/--ink-2/--ink-3 body copy, --danger, and both light-band accents. READ THAT SECOND CLAUSE AS WRITTEN: it is now the --ink set, and it IS the focus set as well as the hover set, which is the first time this sentence has been able to say so. It said "every hover and focus state" once before and was false, because the substituted border in (B) was then a focus state drawn in --brand; the repair above is what makes the wider claim true rather than convenient. THE ONE-LINE CHANGE THAT RESTORES COMPLIANCE: --brand: #FF3D3D. That is v7's text stop; it clears AA on every row above and leaves every red AREA at the mark's #BF0000 exactly as instructed. It would also drop the pointer light's ceiling back to a 0.076 peak, because --brand would rejoin the pairs the light is solved against. ---- */ /* Semantic state (declared, with its ratio - the playbook's source file never did). */ --danger: #FFA033; /* hsl(32, 100%, 60%) 9.6:1 on --bg; warm so it cannot be mistaken for the brand red; errors also carry text */ /* Light band family (worksheet #13) - warm ivory against the cool-red grounds. */ --ivory: #F3F1ED; /* hsl(40, 20%, 94%) L 0.8808 */ --ivory-ink: #150909; /* 17.32:1 on ivory */ /* [RED v7] BOTH IVORY ACCENTS WERE RE-SOLVED, for two independent reasons. (1) HUE. --brand-ivory was #D4281D = hsl(3.61, 75.93%, 47.25%) - the same few degrees of hue offset and the same sub-100 saturation the whole v7 correction removes on the dark ground. An in-band accent that is not the mark's hue re-introduces the coral the firm reported, in the one place a printed page would show it most plainly. (2) HEADROOM. The light got 1.38x stronger, and rule (b) below says a light band LOSES ratio under it. The old pair was already under the file's own >= 4.70 bar and fell further. THE BAR ITSELF WAS RE-MEASURED and it is hue-dependent, which a single figure hides: the unlit ratio that lands on exactly 4.50 lit differs at hue 0 and at --danger's hue 32. [RED v8] BOTH ACCENTS MOVE AGAIN, and for the two reasons that generalise: (1) THE COLLAPSE REACHES THE BAND. --brand-ivory was #C00000 because that was --brand-fill; the fill is now the mark's #BF0000, so the in-band red follows it. On IVORY a deeper red is strictly better - dark ink on a light ground - so this is the one place the firm's instruction costs nothing at all: 5.74:1 -> 5.79:1 unlit, 5.28:1 lit. (2) THE LIGHT GOT 1.62x STRONGER AGAIN AND THE BAR ROSE WITH IT. Re-solved at the shipped peaks, the unlit ratio that lands on exactly 4.50 lit is 4.79:1 at hue 0 and 5.30:1 at --danger's hue 32, so the stated bar is therefore raised to >= 5.30:1 on ivory before the light - the worse of the two, so one number still covers both hues. It has now been raised three times, 4.50 -> 4.70 -> 5.00 -> 5.30, once per brightening, which is the clearest evidence that this bar is a FUNCTION of the light and not a preference. The retired v6 pair falls to 4.15 and 3.93 lit at these peaks, and even the v7 pair does not survive: #995200 measured 5.23:1 unlit and lands at 4.46:1 lit, UNDER AA on a light band nobody decided to give up. So --danger-ivory steps one rung darker to #944F00 = hsl(32, 100%, 29%): 5.51:1 unlit, 4.67:1 lit. HUE 32 IS STILL HELD ON PURPOSE: --danger exists so an error cannot be read as the brand red, and taking it to hue 0 to match would destroy the token. Only its lightness has ever moved. All three in-band values clear the new bar; --ink-muted-ivory clears it by the least (5.39:1 unlit, 4.52:1 lit) and is the band's binding pair now, the way --ink-3 is the dark ground's. */ --brand-ivory: #BF0000; /* hsl(0, 100%, 37.45%) 5.79:1 on ivory - the substitute for --brand in-band, and since [HOVER v22] for --brand alone: --brand-bright was the other consumer of this line and is retired. = --brand-fill, and since [RED v8] = every other red on the site */ --ink-muted-ivory: #6D5F5F; /* 5.39:1 on ivory - substitute for --ink-2 and --ink-3 in-band; 4.52:1 under the light, the tightest pair in the band */ --danger-ivory: #944F00; /* hsl(32, 100%, 29%) 5.51:1 on ivory */ /* ---- end of the block derive_colors.py owns; the [GLOW] and [RED v7] lines above are the exceptions. ---- */ /* ---- WORKSHEET #14/#15: THE EXCEPTION COLOUR IS LIGHT, NOT PIGMENT --------------------------- The earlier answer here was "NONE - no cursor glow ships": red + gold screen-blended goes orange, and a metallic suits neither the register nor the accent. That refused the reference site's SECOND colour, and it was right to. What ships instead is the reference's STRUCTURE in this palette's own two brand stops - a bright lead lobe and a deep trail lobe at different lag rates - so the pair still changes shape with velocity without introducing a colour the site does not otherwise own. THESE TWO TOKENS EXIST ONLY AS LIGHT. Never a fill, never a rule, never a type colour; nothing but 6.26 may name them. They are bare RGB triplets because each is composed at four alphas, which is the playbook's "three or more alphas earns a triplet" case - and because a triplet cannot be pasted into a `background` by mistake, where a hex literal invites exactly that. THE ALPHAS ARE DERIVED, NOT PICKED - reference/derivation/derive_glow.py for the [GLOW] generation, scratchpad/{derive_red_v7.py, lock_v7.py} for v7, tools/verify_ratios.py for the one that ships; worksheet #15. Screen with a source alpha resolves per channel to out = b + a * c * (1 - b) and the layer lies over the TEXT as well as the ground, so both sides of every pair move together. The ground is darker, so it gains proportionally more, and every ratio FALLS. THE CEILING IS THEREFORE SET BY THE LOWEST-CONTRAST TEXT THAT IS HELD TO AA, and raising it means moving that TOKEN - or removing a token from the budget, which is what happened here. [RED v7] moved a token, lifting --brand to #FF3D3D (5.02:1 on --bg-3) and --ink-3 to #928787 (5.06:1); that raised the ceiling from 0.0554 to 0.0763, and 0.076 shipped. [RED v8] REMOVED A TOKEN FROM THE BUDGET INSTEAD, and this is the honest description of why the light got so much brighter so cheaply: red text is no longer held to AA (the firm's decision of 2026-09-06, recorded in full with --brand above), so --brand is no longer one of the pairs the ceiling is solved against. The binding pair becomes --ink-3 on --bg-3, and the converged ceiling goes 0.0763 -> 0.1237. It is not that the light became safer; it is that one of the things it was being kept safe for was taken out of the calculation, deliberately and on the record. shipped peak 0.123 on the lead (v7 shipped 0.076, [GLOW] 0.055; the reference site ships 0.063) - measured against the generation before v7, the light rose 2.24x, and it is 1.62x what v7 allowed. That is the firm's "make the glow stronger", paid for by (b) above rather than by a taste argument. failure alpha 0.1474 - the lead alpha at which --ink-3 on --bg-3 is dragged to exactly 4.5:1. [RED v8] INVERTED v7's INVERSION: --brand was the first pair to fail (0.0920) and is now not a pair at all, so --ink-3 - the tighter one two generations ago, the looser one at v7 - is the binding pair again, and by default rather than by measurement. The next-tightest thing still in the budget is --ink-2 on --bg-3, which does not fail until 0.3733. THOSE ARE LEAD-LOBE-ONLY FIGURES, stated because reading them under the other convention is the one mistake this paragraph invites. It is the convention the playbook's own "1/5-1/6 of failure alpha" uses and the one verify_ratios.py re-derives: a failure alpha is a property of the LIGHT being solved for, so the trail - a lobe already chosen - is held out of it. Converged, the same two pairs fail at 0.1237 and 0.3242, and that 0.1237 is exactly the ceiling the shipped 0.123 is rounded down from four lines below. Both numbers are real and the file quotes both; what it must never do is compare one with the other. The playbook ships at 1/5-1/6 of the failure alpha. THIS DOES NOT - 0.123 is 0.83 of failure - and that departure is the entire reason the token moves exist: the budget is spent, not banked. (The fraction is unchanged from v7 by construction: both generations round the converged ceiling down and quote it against the lead-only failure alpha, so 0.83 is a property of the two conventions rather than a coincidence.) Two consequences, both measured, both printed by tools/verify_ratios.py: (a) AT REST THE TWO LOBES CONVERGE and their peaks compose - screen(screen(x, lead), trail), so the stacked case is the READING state, not an edge case. Budgeting the lobes separately (as the first derivation did) put --ink-3 at 4.4949:1 and --brand at 4.4773:1 on --bg-3, both ~0.005 under AA. FIXED by dimming the TRAIL to a 0.026 peak and holding the lead at 0.055: the lead is the lobe a visitor actually sees, so spending the correction on the tail costs the effect least (the alternative, scaling both, kept only 93.2% of the lead). Those four figures are the [GLOW] generation's and are HISTORICAL; what they established is the RATIO, and every generation since holds it - the trail still rides at the same 0.4727 of the lead (0.123 x 0.4727 = 0.05814, shipped as 0.0581, i.e. 0.4724 after rounding), so the whole lift is again ONE number. Stacked at the [RED v8] peaks, and the red is printed alongside the ink it no longer shares a budget with, because omitting it is exactly how a reader would conclude the site still passes: --brand 2.3597, --ink-3 4.5041 on --bg-3; 2.5571 and 4.8809 on --bg-2; 2.7301 and 5.2111 on --bg. The binding pair for the entire palette is --ink-3 on --bg-3 at 4.5041; the red is not a pair the light is solved against at all any more. verify_ratios.py re-derives every one of those, and the stops from the peaks, on every run. (The ground at the lobe core goes #0E0C0B -> #351918: 3.99x the unlit ground, 1.58x what the v7 light reached and 1.95x the [GLOW] light.) (b) A LIGHT BAND IS NOT PROTECTED THE WAY THE GROUND IS. screen can only lighten, so no surface can be muddied - but a dark-on-light PAIR loses ratio, because the ink lifts far more in relative terms than a near-white ground does (6.26 carries the arithmetic). Measured on the .band--ivory rebindings as they now ship: --brand-ivory 5.79 -> 5.37, --danger-ivory 5.51 -> 4.77 with the lead lobe alone (5.28 and 4.67 with both). RULE, RE-MEASURED UNDER THE STRONGER LIGHT AND RAISED AGAIN: any accent that ever ships inside a light band must measure >= 5.30:1 on ivory BEFORE the light - not 4.50:1, no longer v7's 5.00:1, no longer 4.70:1. The bar is hue-dependent and the single covering figure hides that, so both thresholds are kept: the unlit ratio landing on exactly 4.50:1 lit is 4.79:1 at hue 0 and 5.30:1 at --danger's hue 32. All three in-band values clear the new bar; the retired v6 pair (#D4281D 4.52, #A85A00 4.51) never cleared any version of this bar. ---- */ --glow-lead: 255, 112, 112; /* #FF7070 as a triplet. The lead lobe, and nothing else. [HOVER v22] THIS TRIPLET NOW STANDS ALONE: it used to read "= --brand-bright #FF7070", and that stop is retired (see THE RETIREMENT in the ladder above). The value does not move with it - the firm's instruction was about the pink a POINTER lands on, and a screen-blended lobe at 0.123 over the near-black ground composites to #351918, a dark warm red nobody reads as pink. The triplet was never composed FROM the token in any case: CSS cannot decompose a hex, so the two were only ever kept equal by hand and by comment, which is the other reason retiring the token costs this line nothing. #FF7070 remains oklch(71.9% 0.1751 22.5) - hue 22.50 is why it could not stay in a ladder that now holds one OKLCH hue, and is irrelevant to a light. */ --glow-trail: 191, 0, 0; /* = --brand-deep #BF0000 as a triplet. The trail lobe, and nothing else: the DEEP stop because a darker colour adds less light at the same alpha, which is what lets the trail carry a warmer weight without buying more budget. [RED v7] Both lobes moved with the ladder. Solving against the SHIPPING lobes rather than the retired coral ones is not a formality: a pinker lead costs a little more contrast than the coral it replaces, and the hue-0 pair happens to allow slightly MORE light overall (0.0763 against 0.0742). [RED v8] NEITHER LOBE MOVES. --brand-bright and --brand-deep were the two stops the collapse did not touch, so the light keeps exactly the colours it had and only its peaks change - which is why the whole v8 solve is two alphas and not a re-derivation. [HOVER v22] NEITHER LOBE MOVES AGAIN, and this time the lead's stop is not merely untouched but gone: --brand-bright is retired and this file's only #FF7070 is the triplet above. --brand-deep survives and this trail is still its channels, so the two lobes are no longer symmetric in provenance the way the [RED v7] line assumed - one names a live stop, one names a colour the ladder no longer carries. Neither peak, stop or lobe geometry changes. */ /* ---- Type: faces (worksheet #02-#03). THE PAIRING IS THE FIRM'S DECISION OF 2026-09-06, stated verbatim: Newsreader for display/headings (400-600 plus a 400 italic), Montserrat for body, nav, buttons and labels (300-600), both from Google Fonts, with the two stacks below written as the firm wrote them. It is implemented as instructed and the stacks are not ours to re-derive. ONE CORRECTION TO THE BRIEF, RECORDED BESIDE THE DECISION AND NEVER FOLDED INTO IT. The brief that carried this pairing says Montserrat "is the face in your logo". For this firm it is not. reference/derivation/logo-measurements.json and the 2013 vector ly_proj_193320.svg measure the wordmark as Titillium Text - "TWM" Light, "Legal" Medium - with Arvo for ".com", and the letterspaced "ATTORNEY SERVICES" sub-line added in GIMP in 2020 as a generic "Sans". Montserrat appears nowhere in the mark. So there is NO "same typeface as the wordmark" relation to claim here, and nothing downstream may be justified by one. (What IS measured, and is a coincidence rather than a provenance: Montserrat's caps fit the 2020 raster's sub-line closer to the way the raster's own generic Sans fits it than Titillium's did - see the tracking ladder below.) WHAT THE PREVIOUS SETTING WAS, kept because it explains the shapes this file still has: Titillium Web (the wordmark's own face, which is why invariant 1 used to be able to call the tracked-caps sub-line a family resemblance) + Source Serif 4, chosen by register-avoidance with the note "NOT Newsreader - the sister site landcatchers.com owns it". That note is now overruled BY THE FIRM: Newsreader ships here, and the landcatchers.com overlap is a consequence the firm accepted, not an oversight. ".com" is Arvo INSIDE THE MARK ONLY and never appears in CSS. The synthetic fallback family sits SECOND in each stack, ahead of the raw system faces, so the pre-swap render occupies the same box (block 2). THERE ARE TWO STACKS AND TWO SYNTHETIC FAMILIES, NOT THREE: the serif's third family ("Source Serif 4 Fallback Hero", consumed through a --font-display-hero token) is RETIRED with the face that needed it - the firm specified exactly two stacks, and the measurement that would have justified re-introducing a third is reported in block 2 rather than acted on. */ --font-body: "Montserrat", "Montserrat Fallback", "Segoe UI", "Helvetica Neue", Arial, sans-serif; --font-display: "Newsreader", "Newsreader Fallback", Georgia, "Iowan Old Style", "Times New Roman", serif; /* ---- Type: size scale (worksheet #04). THE RATIO WAS DERIVED AT A 16px BASE AND IS UNCHANGED; only the base moved, to 17px, when [RED v7] set html { font-size: 106.25% } (block 3). The original derivation, kept because it is what fixes the RATIO: proxima-nova 300 x-height 0.480em -> the body face's own x-height. Under Montserrat 400 (0.525em, measured at the resolved variable instance - the OS/2 sxHeight 0.517 is the wght-100 default and MVAR moves it) that is 16 x 0.480 / 0.525 = 16 x 0.9143 = 14.63px, where Titillium's 0.500em used to give 16 x 0.96 = 15.4px. The 16px floor binds HARDER than it did, not less: running copy and form fields never go below 16px (iOS zooms a sub-16px field), so the floor bound and the scale was rebuilt upward from it. Conclusion unchanged. RATIO r = (hero / base)^(1/4). The hero must carry the old 42px futura caps' mass of capital, 42 x 0.67 = 28.1px, in a sentence-case serif. [REPAIR v10] THE CAP FIGURE THIS ROW USED WAS READ OFF THE WRONG INSTRUMENT, AND THE CORRECTION IS WRITTEN OUT RATHER THAN PATCHED IN, because it is the one number in this block that was called "measured" and was not. What the previous pass measured is true and reproduces exactly: the CSS `cap` unit returns 0.67000em for Newsreader at opsz 21.62 / 27.51 / 34.99 / 44.51 and at 1000px, and `ex` returns 0.42600em, both dead constant. But `cap` and `ex` read the STATIC OS/2 fields sCapHeight and sxHeight, and OS/2 is a table the opsz axis cannot touch - "no MVAR" is precisely why the READOUT cannot move, not evidence that the OUTLINES do not. They do. Ink cap of "H", served Newsreader at wght 450, canvas supersampled 24x through the CTM so font-size (and with it the resolved opsz) is untouched - the rig reproduces Montserrat cap 0.70000 / x 0.52500, Segoe UI x 0.50000, Georgia x 0.48167 and Arial cap 0.71583 before it is trusted here: opsz 21.62 0.67407 opsz 34.99 0.68415 opsz 44.51 0.69224 opsz 27.51 0.67775 opsz 41.94 0.69059 opsz 72 0.71528 The drawn cap rises 2.7% across the display band and is 3.3% over the table figure at the hero. No shipped value changes - the ladder is held by the firm's own "slightly bigger" instruction and every rung is a rem multiple that does not depend on this number - but three claims that hung off it do, and all three are corrected here rather than left to be re-derived by the next reader. (1) SOLVING THE ROW HONESTLY. 28.1 = px x capInk(px) is a fixed point, not a division, because the cap ratio is itself a function of px; solved against the ink it gives 40.77px, where dividing by the table's 0.670 gave 41.94px. (2) SO THE sqrt(phi) COINCIDENCE IS AN ARTEFACT OF THE TABLE, NOT A RESULT. (40.77 / 16)^(1/4) = 1.26343 against sqrt(phi) = 1.27202 - a 0.68% miss. The scale STAYS 1.272 exactly as shipped, and it always was the ratio the previous face was solved to; what does not survive is the sentence claiming the new face independently re-measured its way back to it. It re-measured its way back to 1.2634 and the two were read as one because both were compared through a table field. (3) THE HERO'S OVER-SHOOT IS BIGGER THAN THE ANNOTATION BELOW SAID - see the 106.25% paragraph. Two steps = phi (1.618) and the space ladder below is the same progression. Every step is base x 1.272^n, unrounded. There is NO rung above --text-4: the derivation matched the loudest thing on the old site, and anything louder out-weighs the wordmark. WHAT THE 106.25% BASE CHANGES, AND WHAT IT DOES NOT. Every rung is unmoved in rem, so every ratio between two of them and every character count anywhere in this file is unmoved with it; only the px ANNOTATIONS move, by 1.0625. Two absolutes do not scale and are re-checked: the 16px iOS field floor still clears, now by a whole pixel (--text-0 is 17px); and the hero carries 44.51 x 0.69224 = 30.81px of capital against the old site's 28.1px target - [REPAIR v10] 9.7% OVER, not the 6.1% this line carried while it was multiplying by the table's 0.670. The direction and the reason are unchanged - it is the instruction ("slightly bigger") landing on the one rung matched to an external figure rather than to the ladder - and 9.7% is still comfortably inside what "slightly" will carry at this size, which is why the rung is held and only the arithmetic is repaired. The ONLY size below --text-0 is --text-label; nothing runs at it. */ --text-label: 0.786rem; /* 17 / 1.272 = 13.36px tracked caps; also sentence-case provenance notes and units (recede by size AND by dropping caps) */ --text-0: 1rem; /* 17px body, form fields, legal - the floor (the 16px iOS floor clears by 1px) */ --text-1: 1.272rem; /* 17 x 1.272 = 21.62px lede / deck (sans); = the provisional serif floor */ --text-2: 1.618rem; /* 17 x 1.618 = 27.51px card h3, pull-quote, stat numeral - the SMALLEST serif hook, one rung above the floor */ --text-3: 2.058rem; /* 17 x 2.058 = 34.99px section display (old 36px caps = 24.1px of capital -> 36px serif; nearest rung) */ --text-4: 2.618rem; /* 17 x 2.618 = 44.51px hero / page title: 44.51 x 0.69224 (the INK cap at this opsz, not OS/2's 0.670) = 30.81px of capital, 9.7% over the 28.1px the 16px-base target set */ /* Serif modulation floor (worksheet #05) - PROVISIONAL UNTIL VIEWED ON CLEARTYPE / MAC AT 1x. Method: one paragraph at 1rem, 1.272rem, 1.618rem in Newsreader at --wt-display, in --ink on --bg and --ink-2 on --bg-3 (light-on-dark erodes hairlines fastest); the floor is the smallest size at which a blind A/B against the same string in Montserrat 400 is NOT indistinguishable. Set at the first rung above body; the smallest serif hook sits a full rung higher (--text-2), so the test can land anywhere in 1.272-1.618rem without moving a hook. THE ONE MEASURED NUMBER THAT MOVED ARGUES FOR HOLDING 1.272rem, and it argues harder than the previous pair did. The serif/sans x-height ratio was Titillium 0.500 / Source Serif 4 0.475 = 1.053 - two faces of almost the same apparent size, which is what made a small-size A/B hard. It is now Montserrat 0.525 / Newsreader 0.4332 = 1.212 AT THE RUNG THIS FLOOR IS SET AT. [REPAIR v10] THE 0.426 THIS ROW CARRIED WAS THE `ex` / OS-2 sxHeight FIGURE, the same table field the cap-height row above was reading, so it was constant for the same wrong reason. Newsreader's INK x-height moves with opsz exactly as its cap does (same rig, same controls): 0.43316 at opsz 21.62, 0.44148 at 27.51, 0.45313 at 34.99, 0.46851 at 44.51. The ratio is therefore 1.212 at the floor rung (21.62px) and 1.189 at the smallest serif hook (27.51px), not a flat 1.232. THE ARGUMENT IS UNCHANGED AND ONLY ITS SIZE MOVES: 1.212 against Titillium/Source Serif 4's 1.053 is still a far more distinguishable pair than the one it replaces, still pushes the floor DOWN rather than up, and still leaves the "if the test lands above 1.618rem" branch unlikely. The correction is 2 points of ratio, and it changes no conclusion in this block. THE NEW WORRY IS THE OPPOSITE ONE, and the viewing test should look for it: set at the same px, Newsreader reads ~17.5% smaller on the x-line than Montserrat at the floor rung and ~15.9% smaller at --text-2, so a serif hook there sitting beside body copy can read as a size MISMATCH rather than as a change of voice. ([REPAIR v10] This line said "~23% smaller", which was the inverse ratio read as a shortfall - 0.525/0.426 = 1.232 makes MONTSERRAT 23% larger; the serif is correspondingly 18.9% smaller, and on the ink figures 17.5%. Two errors, one compounding the other, in the safe direction both times.) If it does, the answer is a hook rung, not a floor - and not a face. If the test does land ABOVE 1.618rem, the smallest serif hook rises to --text-3 and the card h3s, .quote and .stat-num STAY in the serif - a Montserrat sentence-case heading at --text-2 is exactly what the constitution forbids. THAT USED TO COST A WRAP, THEN FITTED BY 0.9px, AND IS NOW COMFORTABLE: "Intellectual Property", the longest practice-area name, measures 8.651em in Newsreader at the h3's instance (opsz 27.51 / wght 450) = 238.0px against 316.99px of card inner, where Source Serif 4's 9.035em gave 316.1px against the same 316.99 - a 0.9px fit that this paragraph warned would come back if --grid-track ever fell below ~21.95rem. Newsreader is 4.3% narrower than Source Serif 4 at this instance, so the fit is now 79.0px and the wrap returns only below ~17.35rem of track ((238.0 + 55.01 padding + 2 border) / 17). The warning stands down. ([v7 REPAIR PASS] Both inner figures dropped 2px: the card is a BORDER box and carries its own two 1px edges, which the sum in the container derivation had omitted.) Never change the face. */ --display-floor: 1.272rem; /* = --text-1, 21.62px; provisional */ /* ---- Type: leading. THE GOVERNOR CHANGED FACES AND SO DID TWO OF THE FIVE VALUES. PREVIOUS SETTING, kept because it is why --leading-body was ever 1.6: Titillium's hhea box is TALL (ascent 1.133 + descent 0.388 = 1.521em, so `line-height: normal` was already 25.9px at 17px) and 1.6 was the smallest value that kept adjacent line boxes from touching. Montserrat's `normal` box is 1.219em (measured; hhea 0.968 + 0.251), so THAT CONSTRAINT STOPS BINDING ENTIRELY - 1.6 would clear it by 0.381em where Titillium was cleared by 0.079em - and the x-height ratio, which used to be the slack half of the pair, becomes the only governor. Montserrat's x-height is 0.525em = 8.925px at 17px, against Titillium's 0.500em = 8.50px. Newsreader's glyph extent is measured per optical size (canvas ink box, d ascender + p descender): 0.982em at opsz 27.51, 1.000em at 34.99, 0.989em at 44.51 - against Source Serif 4's flat 1.01em. Every figure here is a MULTIPLIER, so the 106.25% base moves only the px. */ --leading-body: 1.68; /* 1.6 -> 1.68, FORCED: at 1.6 the pitch is 27.20px against Montserrat's 8.925px x-height = 3.048, a hair BELOW the reference design's 3.05 floor, so the old value no longer satisfies its own rule. 1.68 gives 28.56px = 3.200 x the x-height - the same ratio the previous face was set to, between 3.05 and the old site's 3.75. Clears Montserrat's 1.219em `normal` box by 0.461em (7.84px) */ --leading-lede: 1.575; /* 1.5 -> 1.575, same reason: at --text-1 21.62px the x-height is 11.35px, and 1.5 gives 32.44 / 11.35 = 2.857 against this row's stated target of 3.0. 1.575 gives 34.05px = 3.000 exactly - a shorter measure takes tighter leading, and 3.0 is what "tighter" means here */ --leading-heading: 1.15; /* HELD. Newsreader at --text-2..--text-3: the governing extent is the larger of the two rungs, 1.000em at opsz 34.99, so 1.15 is a 0.150em pad (5.24px at 34.99px, 4.63px at 27.51px where the extent is 0.982em). The rule the previous face stated was "extent + 0.14em"; Newsreader's extent is 0.02em SHORTER than Source Serif 4's, so re-deriving to the letter would give 1.14 and the change would be 0.01 - below anything a reader can see and not worth moving every heading's rhythm for. Recorded rather than applied */ --leading-display: 1.1; /* HELD, same argument. Newsreader at --text-4 (opsz 44.51) has a 0.989em extent, so 1.1 is a 0.111em pad = 4.96px at 44.51px, against the 0.09em / 4.01px the previous face was solved to. A descender never meets the next line's ascender, with more room than before; the literal re-derivation is 1.08 and is not worth a visible change */ --leading-label: 1; /* single-line caps: cap height 0.700em (Montserrat, constant across the axis) centred in a 1em box - it was 0.692em under Titillium */ /* ---- Type: weight per GROUND. BOTH FACES ARE NOW VARIABLE AND BOTH ARE RANGE-LIMITED BY THE FIRM'S OWN REQUEST: Montserrat wght 300..600 and Newsreader wght 400..600 are what the loader asks for and what fonts.googleapis.com returns (verified 2026-09-06: font-weight: 300 600 and 400 600 in the served @font-face blocks). Every value below is inside those ranges, so nothing here is synthesised. PREVIOUS SETTING: Titillium shipped 200/300/400/600/700/900 as static files with NO 500, which is why several of the notes below used to argue from "the next shipped step" - a half-step in the sans is now reachable and simply is not wanted. Physics: light-on-dark erodes (hold 400 or go heavier), dark-on-light blooms (go lighter). Dark-ground values here; .band--ivory rebinds them. Full role x ground table: DESIGN-SYSTEM.md. THREE GAPS THE NEW REQUEST OPENS, none of them a token, all of them worth an audit before ship: (1) NO SANS ITALIC AT ALL. The previous loader carried real Titillium italics at 300 and 400. Montserrat is requested roman-only, so base's `img { font-style: italic }` (broken-image alt text) and any future in body copy render as a SYNTHESISED oblique - font-synthesis is `none` only inside the display grant. No page ships // today, so as it stands this touches alt text only. (2) NOTHING ABOVE 600. Titillium 700 was loaded-but-unassigned; now there is no 700 to inherit. The 27 bare

elements in src/pages inherit the UA's `bold`, and where a rule catches them (.svc-card h3, .act-card h3, .package h3 through the display grant; .prose h3 and .num-list h3 through --wt-strong) they resolve at 600. A bare

outside those contexts clamps to Montserrat 600 PLUS synthetic bold. (3) NEWSREADER ITALIC 400 IS LOADED AND UNASSIGNED - the same status Titillium 700 had, and DESIGN-SYSTEM.md s9's rule applies to it in the same way. */ --wt-body: 400; /* never 300 reversed out of near-black - see body. 300 is the light-ground step-down and stays inside the ivory band. IT IS NO LONGER "the wordmark's TWM weight": that was a Titillium Text Light relation and it died with the face - see the correction in the faces block */ --wt-label: 600; /* tracked caps at 13.36px reversed: 400 spindles at 0.16-0.32em of air, and 600 is the top of the requested range. 500 now EXISTS (Montserrat is variable 300..600 here) and is not taken: 600 advances 3.7% over 400 (0.50906 / 0.49072em over the 108-character sample) where Titillium's 600 advanced only 1.8%, so the wider face already carries more ink per label and a half-step would be a fourth weight for nothing */ --wt-display: 450; /* Newsreader reversed: nominal 400 plus the half-step erosion takes back (the playbook's "425-450 reversed"); a real point on the requested 400..600 axis, never synthesised */ --wt-strong: 600; /* emphasis in the sans and inside display type: the top of BOTH axes as requested, so one number covers both faces and neither can be over-asked */ /* ---- Type: tracking ladder (worksheet #01), indexed to ROLE, never to size. THE WHOLE LADDER DROPS TWO RUNGS WITH THE FACE, because its anchor is a FITTING and Montserrat fits the same raster differently. Top rung = the sub-line's tracking, DERIVED from the 2020 raster, not read off it: tracking = (measured line - untracked line at the implied size) / 16 gaps. The raster is fixed (1386px sub-line, 16 gaps, 62px caps); only the face inside the sum moves. Montserrat 400 (SHIPPED ANCHOR) cap 0.700 -> 62 / 0.700 = 88.57px type; "ATTORNEY SERVICES" untracked = 10.747em x 88.57 = 951.9px; (1386 - 951.9) / 16 = 27.13px = 0.3063em = 0.438 x cap Titillium 400 (PREVIOUS ANCHOR) cap 0.700 -> 88.57px; untracked = 9.009em x 88.57 = 797.9px; (1386 - 797.9) / 16 = 36.75px = 0.4150em = 0.593 x cap Arial 400 (the width control) cap 0.716 -> 86.55px; untracked 923.5px; (1386 - 923.5) / 16 = 28.91px = 0.3340em = 0.466 x cap Montserrat's caps are 19.3% wider than Titillium's over that string, so the same raster leaves 27.13px per gap instead of 36.75px and the top rung falls from 0.415em to 0.306em -> 0.32em at the nearest 0.04 step. TWO THINGS TO READ BEFORE MOVING IT. First, the new anchor agrees with the raster's own fitting BETTER than the one it replaces: the 2020 sub-line was set in GIMP's generic "Sans", and Montserrat's 0.3063em lands beside the Arial-width control's 0.3340em where Titillium's 0.4150em sat well outside it. (The face-independent observation - a 37px median gap between glyph clusters, logo-measurements.json - includes sidebearings, so it corroborates without deciding.) Second, the wordmark-check render (reference/fonts/wordmark-check.html) matched the raster at 0.42em IN TITILLIUM and has NOT been re-run in Montserrat; 0.32em is PROVISIONAL on that re-run, exactly as 0.40em was provisional on the render that did happen. See DESIGN-SYSTEM.md. THE COST, WHICH IS A DESIGN DECISION AND NOT A MEASUREMENT, STATED SO IT IS NOT DISCOVERED LATER: each quieter role still steps down 0.04em in the playbook's role order, so an anchor two rungs lower drags the whole ladder two rungs down and the BOTTOM RUNG LANDS AT 0.04em, which does not read as tracked caps at all - it reads as a rendering artefact. --track-7 (0.08em) is marginal for the same reason. The 8 x 0.04 ladder no longer spans a usable range at this anchor. Two exits, both decisions rather than edits: compress the step (0.32 down to ~0.11 in seven steps of 0.03) or drop to six rungs and re-map the roles. Neither is taken here, because the step is part of the derivation the firm's face change was applied to, and changing both ends at once would leave no measured number in the ladder at all. Always em. Narrow-width overrides step DOWN the ladder: a label sheds tracking before size, and body copy sheds neither. Positive tracking exists ONLY on --font-body at --text-label. UNITS: --track-1..8 and --track-nav are LETTER-SPACING in em. The card grid's column width is --grid-track (rem) - a different quantity, named so the two can never be confused. */ --track-1: 0.32em; /* 0.40 -> 0.32. hero label - the ONE loudest label, sitting under the title as the sub-line sits under the wordmark; = 0.46 x Montserrat's 0.700 cap */ --track-2: 0.28em; /* 0.36 -> 0.28. section eyebrow */ --track-3: 0.24em; /* 0.32 -> 0.24. footer heads, kicker, scroll cue */ --track-4: 0.20em; /* 0.28 -> 0.20. stat / role / info labels, attribution */ --track-5: 0.16em; /* 0.24 -> 0.16. nav at rest */ --track-6: 0.12em; /* 0.20 -> 0.12. buttons, link-arrows */ --track-7: 0.08em; /* 0.16 -> 0.08. field labels, hero meta; the nav's shed value in the compact band. MARGINAL as tracked caps - see the ladder note */ --track-8: 0.04em; /* 0.12 -> 0.04. licence strings, counter units - the bottom rung, and BELOW what reads as tracked caps. Recorded, not repaired: see the ladder note's two exits */ /* Role aliases exist only for the two rungs that are consumed or rebound elsewhere. */ --eyebrow-track: var(--track-2); --eyebrow-track-cancel: calc(-1 * var(--eyebrow-track)); /* the trailing-space correction; the two can never drift apart */ --track-nav: var(--track-5); /* rebound to --track-7 in the compact band (block 4) */ /* ---- Space: the phi ladder - every second step of the type ratio (1.272^2 = 1.618), so a gap and a size at the same step agree. 1rem x phi^n. Note --space-3 (27.51px) used to be within 0.31px of one body line and is now 1.05px under it: --leading-body moved 1.6 -> 1.68 with the face, so one line of copy is 28.56px against the 27.20px it was. Card padding and grid gap are still one line of copy to within 3.7%, which is close enough to keep the relation and too far to keep calling it exact. It is a relation between a rem quantity and a MULTIPLIER, so the 106.25% base still carries it unchanged and only the px below move; what moved it was the leading, not the base. */ --space-1: 0.618rem; /* phi^-1 = 10.51px label-to-rule, micro gaps */ --space-2: 1rem; /* phi^0 = 17px inline gaps, field padding, the compact nav gap */ --space-3: 1.618rem; /* phi^1 = 27.51px grid gap, card padding, desktop gutter, nav gap at rest */ --space-4: 2.618rem; /* phi^2 = 44.51px component stacks, feature-split gap, logo-to-nav clearance, landscape-phone section padding */ --space-5: 4.236rem; /* phi^3 = 72.01px phone section padding */ --space-6: 6.854rem; /* phi^4 = 116.52px desktop section padding */ --space-7: 11.09rem; /* phi^5 = 188.53px hero vertical slack (reserved for step 7) */ --gutter: var(--space-3); /* 27.51px each side */ /* [FACE v9] THIS TOKEN NOW FAILS ITS OWN STATED CONSTRAINT AND NO VALUE OF IT CAN PASS. Read before touching it. The rule is a 45-55 character measure on a 375px phone. Montserrat 400 averages 0.49072em per character = 8.3422px at the 17px root, against Titillium's 7.1043px - 17.4% wider - so 375 - 2 x 21.62 = 331.76px is 39.8 characters where it was 46.7. THE BAND IS UNREACHABLE AT ANY GUTTER: 375 / 8.3422 = 45.0 characters with ZERO gutter, and 47.8 even if the root were dropped back to 16px. The only lever that reaches 45 is a smaller body size on phones, and body is pinned at the 16px iOS field floor (--text-0 is 17px and clears it by one pixel). So this is a stated-constraint failure of the kind the palette block records for the red, not a value that can be re-solved: the token HOLDS at one type step down, and the 45-55 rule is recorded as broken by the firm's face choice rather than quietly re-written to a band 39.8 happens to fall inside. */ --gutter-phone: 1.272rem; /* one type step down: 1.618 / 1.272 = 21.62px each side -> a 375px phone holds 331.76px = 39.8 characters, BELOW the 45-55 phone measure (46.7 under Titillium, 50.0 of them at the 16px base). See the note above: no gutter reaches 45 */ --nav-gap: var(--space-3); /* between nav labels at rest; rebound to --space-2 in the compact band */ /* ---- Measure, container, track, logo (worksheet #18). THE PER-CHARACTER FIGURE IS THE NUMBER THE FACE CHANGE MOVED FURTHEST, AND EVERYTHING IN THIS PARAGRAPH HANGS OFF IT. Montserrat 400 averages 0.49072em per character over the same 108-character prose sample -> 0.49072 x 17 = 8.3422px per character at body size, against Titillium 400's 0.4179em / 7.1043px. That is +17.4%: Montserrat is a WIDE geometric sans and Titillium a narrow humanist one, so every character count in this file moved with it and none of them could be carried over. 60 characters = 29.443rem = 500.5px (the floor for any text block), 75 = 36.804rem = 625.7px. The measure still sits at 70: legal prose runs to long words ("indemnification", "subrogation") with few break opportunities, and the upper half of the band rags less. 70 x 0.49072 = 34.350em -> 34.350rem = 584.0px. THE TOKEN HAD TO MOVE AND COULD NOT BE HELD. 29.25rem in Montserrat is 497.3 / 8.3422 = 59.6 characters - BELOW the 60-character floor - so the previous literal does not merely mean something different, it breaks the rule the token exists to keep. The alternative considered and rejected: 29.443rem (60 characters, 500.5px) is within 3px of the old width and would have preserved every downstream px, but it drops the token's meaning from the upper half of the band to its floor, which is the opposite of the reason 70 was chosen. The character count is what the token means. Declared in rem, NOT ch: Montserrat's "0" advances 0.662em (11.25px), 34.9% wider than the average character, so 1ch overstates the measure (34.35rem is only 51.9ch) - the same relation Titillium had (0.560 / 0.4179 = 1.340) and the reason the ch caps on .hero-title and .display are set from the DISPLAY face's own "0" and not from this one. CONTAINER. The derivation still runs, and the wider measure hands (a) the lead back: (a) a feature split: text 34.350 + --space-4 gap 2.618 + equal media column 34.350 = 71.318rem (b) the 3-up card grid: 3 x 22rem track + 2 x 1.618rem gap = 69.236rem The larger governs, rounded UP to the next whole rem so the third track survives at the container's own maximum, which now yields 72rem - AND THE DIRECTED VALUE STOPS BEING DIRECTED. [RED v7] set 72rem against a derivation that asked for 70, on the firm's instruction ("all of the cards on the main page are too small"); the same 72rem is now what the derivation itself asks for, and the two agree for the first time. Nothing about the shipped value changes; what changes is that it no longer needs the instruction to justify it. Third-track check at 72rem: (72 - 3.236) / 3 = 22.921rem = 389.66px, above the 22rem minimum, so a 3-up row survives the cap. THE 60-75 EXCEPTION [RED v7] RECORDED HERE HAS SELF-HEALED, and its removal is the one place in this pass where the new face repairs something rather than costing it. The split at 72rem is (72 - 2.618) / 2 = 34.691rem = 589.75px, which in Montserrat is 589.75 / 8.3422 = 70.7 characters - INSIDE the band, where the same width in Titillium was 83.0 characters and outside it. The .feature-split text column carries no --measure cap of its own, and it no longer needs one: a .feature-body holding bare

at this container width now runs to 70.7 characters, which is what the band asks for. Reached at 1224 + 55.01px of gutters = 1279.0px of viewport. GRID TRACK (--grid-track). THE CONTENT DERIVATION MOVED ABOVE THE SHIPPED VALUE AND THE SHIPPED VALUE IS HELD - a second recorded exception, in the opposite direction to the one that just healed. 40 characters of body per line = 40 x 8.3422 = 333.69px + 2 x 27.51px card padding + 2 x 1px border = 390.70px -> 22.982rem, i.e. 23rem, where Titillium gave 20rem. Against that: at the track minimum 374 - 2 border - 55.01 padding = 316.99px of inner = 38.0 characters at the grown track 389.66 - 2 - 55.01 = 332.65px = 39.9 characters BOTH ARE BELOW 40, so the claim this paragraph used to make - "the content rule is satisfied with room rather than met exactly" - is false in both places and has been deleted rather than softened. 22rem is HELD anyway, and the reason is that it is the firm's own directed card width; raising it to 23rem would also re-open the container ((b) becomes 3 x 23 + 3.236 = 72.236 -> 73rem), and at the shipped 72rem cap the third track would fall to 22.921rem and the grid would silently drop to 2-up - which is precisely the failure the round-up rule exists to prevent. So the choice is between missing a content rule by 2.0 characters and restructuring the page's whole width system against a directed value; the first is recorded, the second is not taken. If it is ever revisited, the pair that works is --grid-track 23rem WITH --container 73rem, together, never one alone. [v7 REPAIR PASS] THE TWO BORDERS ARE PART OF THE SUM: .svc-card carries `border: 1px` under the global border-box, so the 22rem track is a BORDER box. Measured on a 374.98px track: card 374.98 -> body border box 372.98 -> content 317.97. Heading check: "Intellectual Property", the longest practice-area name, is 8.651em in Newsreader at the h3's instance (opsz 27.51 / wght 450) = 238.0px at --text-2 against 316.99px of inner - one line with 79.0px to spare, where Source Serif 4's 9.194em/252.9px left 64.1px. LOGO: the 2020 horizontal mark is 2505 x 654 (3.830:1). Its header height is fixed by its smallest text: the sub-line's cap height is 62 / 654 of the image, and the smallest capital a screen renders legibly is ~7.2px (10px type x 0.72 cap height) -> 7.2 x 654 / 62 = 76px. THAT FLOOR IS ABSOLUTE px AND DID NOT SCALE, so at the 106.25% base it is 4.471rem, not the 4.75rem it used to be. The token HOLDS at 4.75rem: it is now one notch ABOVE its floor rather than sitting on it, which is the same direction of travel as everything else in this pass (80.75px tall, 309.3px wide, sub-line caps 7.66px against the 7.2px floor). It is no longer the smallest legible mark; it is a mark with 0.46px of cap in hand. (The 44px tap-target floor is not what governs; the sub-line is.) Assumption stated in DESIGN-SYSTEM.md section 9. */ --measure: 34.35rem; /* 29.25 -> 34.35. 584.0px, 70 characters in Montserrat 400: max-width on every running-text block. Holding 29.25rem would have meant 59.6 characters, below the band's own floor */ --container: 72rem; /* 1224px - now BOTH the derivation's answer (a: 71.318 -> 72) and the firm's directed value; they agree since --measure moved */ --grid-track: 22rem; /* 374px: the card grid's minimum column width, DIRECTED (the content derivation now gives 23rem and is MISSED by 2.0 characters - recorded exception above) - a WIDTH in rem; the em letter-spacing ladder is --track-N */ --logo-h: 4.75rem; /* 80.75px -> 309.3px wide; 4rem (68px -> 260.4px) once the nav has collapsed */ /* ---- Breakpoints (worksheet #18): two width numbers, both from content, plus one height query. Media queries cannot read custom properties, so the numbers are repeated as literals in block 4 (66.99rem / 67rem / 73.99rem / 29.99rem) - grep before changing a token here. [RED v7] A CORRECTION THAT PRECEDES EVERY SUM BELOW, AND THE REASON THEY NOW READ AS THEY DO: rem INSIDE A MEDIA QUERY DOES NOT RESOLVE AGAINST html's font-size. Per CSS Values, font-relative units in a media query use the INITIAL value of font-size - the browser default - so `67rem` in block 4 is 1072px whatever :root says. The note that used to stand here ("they are in rem, not px, because a visitor at a 20px root grows every label 25% and the collapse must move up with them") was therefore only half true, and the untrue half is the half that matters now: html { font-size: 106.25% } grew every label by 6.25% and moved NO query literal with it. Every row below is re-summed at the new size, and the two structural literals did not cover their own sums. [REPAIR v10] THAT IS NOW FIXED RATHER THAN RECORDED, and the decision is written out in THE OVERSHOOT note below: exit (i) was taken and the pair moved 64 -> 67rem and 71 -> 74rem, which is the value each literal's own derivation has been asking for since the face changed. STRUCTURAL 67rem = 1072px: where the tracked-caps nav labels stop fitting beside the logo, even with their tracking shed. THIS SUM IS NOW RUN ON THE STRING THE SITE ACTUALLY SHIPS, not on the six retired labels it used to carry - the two frames of reference are what made this block and 6.1 disagree, and one string ends that. Labels "PRACTICE AREAS / ATTORNEYS / FLAT FEE SERVICES / MAKE A PAYMENT / CONTACT US" = 64 characters, five rows, from site-plan.json nav.header (Title Case in the markup, uppercased by CSS). MEASURED per label with getBoundingClientRect at --text-label 13.36px / --wt-label 600 in Montserrat, tracking included - CSS adds letter-spacing after the last character too, so the trailing rung is inside these figures: at rest --track-5 0.16em -> labels 691.39px; 4 gaps x --space-3 27.51 = 110.04; caret 9.62 -> nav 811.05px compact --track-7 0.08em -> labels 622.98px; 4 gaps x --space-2 17 = 68.00; caret 10.69 -> nav 701.67px (The caret is .nav-menu-btn's ::after, 0.38em + (0.5em - track) at the button's own 13.36px; it grows as tracking is shed, because the margin cancels the label's trailing rung. 6.1 carries it.) Row = gutter 27.51 + logo 243.6 (the shipped 3.75rem header cap, measured) + clearance --space-4 44.51 (one step above the label gap, or the first label reads as a sixth word of the mark) + nav + gutter 27.51 + 17px classic-scrollbar allowance (media queries measure the viewport including it): at rest 27.51 + 243.6 + 44.51 + 811.05 + 27.51 + 17 = 1171.18 -> full tracking needs 74rem compact 27.51 + 243.6 + 44.51 + 701.67 + 27.51 + 17 = 1061.80 -> the compact nav needs 67rem THE OVERSHOOT, AND THE ONE THING TO READ BEFORE TOUCHING THE HEADER. IT IS NO LONGER SMALL. [RED v7] left this row 8.1px over 1024 and 5.4px over 1136 and held the literals, on the ground that the mark absorbs a shortfall that size invisibly. Montserrat 600 is materially wider than Titillium 600 across these five labels (554.58px against 457.56px untracked, +21.2%), so at the SAME ladder the overshoot would have been 105.1px and 102.5px. Re-deriving the tracking ladder from the 2020 raster (two rungs down, above) pays most of that back and is the tightest tracking this file can defend - and the rows STILL come to +37.8px at 1024 and +35.2px at 1136. WHAT THAT COSTS, MEASURED RATHER THAN WAVED AT. Nothing overflows: .site-logo is `flex: 0 1 auto; min-width: 0` and its img is `max-width: 100%; object-fit: contain`, so the MARK absorbs the shortfall. But it now absorbs 37.8px of it - the logo renders 205.8px wide against its natural 243.6, i.e. 15.5% narrower, and the sub-line's caps fall from 6.04px to 5.10px (14.4% and 5.17px at 1136). Under [RED v7] the same mechanism cost 2.5% and 0.15px of cap and was fairly called invisible; at 15.5% it is a visibly smaller mark in a ~38px band of widths, and it is recorded as a DEGRADATION THAT IS NOW VISIBLE rather than carried forward under the old adjective. [REPAIR v10] EXIT (i) IS TAKEN. THE LITERALS MOVE TO THE ROWS. Two passes held this pair while the shortfall grew from 8.1px to 37.8px, each time on the ground that the fix was "a decision, not a token edit". It is a decision, and this pass makes it, because the third reading of the same paragraph is the one that settles it: the structural literal is DEFINED, four lines above, as "where the tracked-caps nav labels stop fitting beside the logo". The rows say that width is 1061.80px compact and 1171.18px at rest. 1024 and 1136 are therefore not a judgement about the collapse - they are simply the wrong answer to the question the literal asks, inherited from a face that is no longer loaded. Holding them was not conservatism; it was shipping a number that contradicted its own definition, and paying for it with the mark. new literals 67rem = 1072px against the compact row's 1061.80 -> 10.2px of slack 74rem = 1184px against the at-rest row's 1171.18 -> 12.8px of slack rounded UP to the whole rem, the same rule the container uses, so the row survives at the boundary rather than at one width inside it. WHAT THIS BUYS, VERIFIED ON THE SERVED PAGE AT 4px STEPS: the mark now renders its full 243.63px at EVERY width where the nav is up. Before this change it measured 207.84px at 1024 (14.7% narrow, sub-line cap 5.15px) and 210.50px at 1136 (13.6%), recovering only at 1060 and 1172 - two bands about 36px wide in which the wordmark was visibly the wrong size. Both bands are gone, not moved: at 1072 and at 1184 the row now fits with slack, so object-fit never binds. WHAT IT COSTS, STATED IN FULL, because it is a real trade and not a free win: - the burger persists to 1071px. A 1024x768 tablet in landscape now gets the mobile menu. That is the honest answer - the desktop nav genuinely does not fit at 1024 - but it IS a change of behaviour at the single most common tablet width on the web, and it is the reason this was called a decision rather than a repair. - every two-up structure collapses 48px earlier, and the compact band starts and ends 48px higher. Only three rules hook the structural number (--logo-h's footer rebinding, the nav/burger swap, .stats-row), and all three collapse in the SAFE direction: a structure that goes single-column earlier was cramped in the band it gave up. The intrinsic grids (.svc-grid, .act-grid, .package-grid, .form-grid) and .feature-split's container query do not read this number at all, so nothing else moves. - the header tel: CTA's 89rem query does NOT move, and that is the check that proves the two numbers are independent: it is derived from the at-rest ROW (1171.18 + 27.51 + 222.24 = 1420.9 -> 1424px), not from the structural literal, so re-deriving the literal to match the same row leaves it exactly where it was. THE TWO EXITS NOT TAKEN, kept because they remain the answers if this one is ever reversed: (ii) shed a nav label in site-plan.json. Dropping "FLAT FEE SERVICES" takes 153.95px of label plus one 17px gap off the compact row -> 890.85px, inside 1024 with 133px of slack; the at-rest row goes to 971.56px, inside 1136 with 164px. Cheapest by a wide margin in pixels and the only exit that would have kept the nav up at 1024 - and it is REFUSED here on the ground that it is not a typographic decision at all. Which pages sit in the primary nav is the firm's own information architecture (site-plan.json nav.header), and /flat-fee-services is a priced commercial page. A stylesheet may not quietly drop a route from the nav to make its own sum come out. (iii) cap the header mark. CAPPING CANNOT WORK, and that finding stands: the mark would have to fall to 205.8px = 53.85px tall = 3.167rem for the compact row to fit 1024 outright, where sub-line caps are 5.1px against the ~7.2px legibility floor. Capping does not avoid the degradation, it makes it permanent at every width instead of only in a band. Between 67 and 74rem the labels shed tracking BEFORE size (0.16 -> 0.08em, gap 27.51 -> 17px); size and case never move. Below 67rem the nav collapses and EVERY two-up structure collapses with it - one number for every structural collapse (a feature split would survive to ~1267px by its own sum, but a second number is exactly the playbook's stats-row bug). Re-sum before changing a label; the per-label figures are in reference/derivation/type-measurements.json. PHONE 30rem = 480px: the largest width at which a phone re-solve is needed - three conditions, all re-summed at the new base: hero the title at its 16ch cap = 16 x 0.5845em (Newsreader's "0" at the hero instance, opsz 44.51 / wght 450 - it WIDENS with opsz, 0.569em at 27.51, where Source Serif 4 narrowed) x 44.51px = 416.2px; + gutters 55.01 = 471.2px. The cap moved 19ch -> 16ch with the face and the px it defends is within 4px of what it was, which is why this row still fits inside the 480 literal. [REPAIR v10] AND HOLDING 19ch WOULD NOT HAVE MOVED THIS BREAKPOINT - the claim that stood here, that it "would have taken over the max() below", is arithmetically false against this block's own rows and is withdrawn rather than softened. 19 x 0.5845 x 44.51 = 494.3px + 55.01 = 549.3px, and the form row below is 550.9px: the hero row comes within 1.6px of governing and does not govern. max() is 550.9 either way, the derivation asks 34.43rem either way, and this literal is exactly where it was. The cap moved to 16ch on its OWN ground - 16ch is 21.7 average characters against the 22.0 the retired face's 19ch held, i.e. the same line - and that ground is sufficient; it never needed a breakpoint argument and now does not have one. Below the literal the title spans the whole container, the left-weighted scrim stops protecting the copy, and 44.51px is 11.9% of a 375px viewport (3.1% at 1440): the hero title drops one rung. form two fields abreast, each a 24-character e-mail at 17px: 24 x 8.3422 + 2 x 17 padding = 234.2px (it was 204.5px in Titillium); 2 x 234.2 + 27.51 gap + 55.01 gutters = 550.9px. THIS IS THE CONDITION THAT RUNS AWAY FROM THE LITERAL - see below. header collapsed logo 243.63 + --space-3 27.51 + 44px menu target + 43.25 phone gutters = 358.4px - comfortably inside a 320px phone once the mark's own max-width guard is counted, where it used to read as 8px inside a 375px one. [v7 REPAIR PASS] THE 260.4 THIS LINE CARRIED WAS THE TOKEN, NOT THE HEADER: --logo-h does drop to 4rem (68px -> 260.4px) below 67rem and the FOOTER mark takes it, but 6.1 caps the header's own mark at min(--logo-h, 3.75rem) = 63.75px -> 243.63px on the shipped asset's 3.8216 ratio (244.2 is the 2505x654 master's; 6.1's .site-logo img note now names both). Safe direction, wrong number, and it fed the max() below. max(471.2, 550.9, 359.0) = 550.9 -> the derivation now asks for 34.43rem where the shipped query is 30rem (480px). It asked for 30.72rem before the face changed; the whole of the extra 3.7rem is the form row, because a 24-character e-mail is 17.4% wider in Montserrat than it was in Titillium. THE LITERAL IS HELD, and the consequence is stated in full because it is bigger than the one this paragraph used to describe. The hero and header conditions still fit inside 480 with room (471.2 and 359.0). The form does not, and .form-grid is INTRINSIC (auto-fit / minmax), so it resolves on its own sum wherever the query does not pin it. WHAT ACTUALLY HAPPENS: 6.17's track was re-derived with the same character figure that moved this row (12rem -> 13.78rem, its own note carries the sum), so 2-up needs 2 x 234.2 + 27.51 = 495.9px of container = 550.9px of viewport, and .form-grid is one column from 480 up to 551 - a 71px band where the fields are stacked and the nav is not yet collapsed. That is the derivation's own answer arriving 71px late rather than a defect: two fields that cannot hold their stated 24 characters are exactly what this breakpoint exists to prevent, and stacking them early is the safe direction. [v7 REPAIR PASS, STILL LOAD-BEARING] The pin inside the phone query stays. --gutter steps down at this SAME 480, handing the container 11.76px, and with the OLD 12rem track the 2-up sum was met again from 478.75px of viewport - so 480 was one column, 479 was TWO and 478 was one again (measured on /contact-us: 491 two, 490 one, 480 one, 479 two, 478 one). The re-derived 13.78rem track puts 2-up at 550.9px and out of reach of that oscillation, but the pin costs nothing and removing it would make the phone band depend on a sum the gutter step has already crossed once. Nothing between 551 and 1072 needs a width query: card grids are intrinsic. 640 was not chosen: no condition lands there. LANDSCAPE PHONE (max-height: 480px) and (orientation: landscape): 812 x 375 matches ONLY the structural collapse; the height query re-solves the section rhythm (and, in step 7, the hero). */ --bp-structural: 67rem; /* [REPAIR v10] 64 -> 67rem = 1072px, the compact row's own 1061.80px sum rounded up to the whole rem */ --bp-phone: 30rem; /* ---- Radius. The mark is rectilinear (the square variant is a hard square; the only curves are the gavel's brush strokes) and the old 300px pill buttons re-staged nothing in it. 2px is the smallest radius that reads as intended on a 1px hairline edge (1px reads as anti-aliasing). ONE radius. */ --radius: 2px; /* ---- Motion (worksheet #16). [MOTION v20] 2026-09-06. THE LADDER IS THE PLAYBOOK'S x 1.5, AND THE MULTIPLIER MOVED 1.2 -> 1.5 ON THE FIRM'S INSTRUCTION OF THE SAME DAY, quoted in full: "all of the animations throughout all pages of the website are to fast and too subtle. Make them more prominent. Use www.LandCatchers.com as a basis if you can tell from the page". THE SISTER SITE IS NOT THE ANSWER AND THAT IS THE FIRST THING THIS BLOCK HAS TO SAY, because the instruction names it and the next reader will go and copy it. LandCatchers' own ladder MEASURES 0.20 / 0.40 / 0.55 / 0.85 - it is the playbook's, unmultiplied - so this site's ladder was ALREADY that site's x 1.2 on every rung, and its reveal travel was already byte-identical (16px, and 26px in the hero, in both files). Adopting the sister site's numbers would have made every motion on this site FASTER, which is the opposite of the instruction. What LandCatchers actually has more of is BREADTH (59 transition declarations against this file's 30, 81 transforms against 47, 13 distinct translate literals against 5) and a harder-front-loaded curve. Both are answered below and in block 6; the numbers are not copied from it, because there was nothing there to copy. ONE MULTIPLIER, APPLIED TO EVERY RUNG AT ONCE. That is the only thing that keeps a ladder a ladder: after the change every ratio inside it is exactly what it was, and every rung is still the playbook's own value times one number a reader can check in their head. The multiplier reaches the four rungs, both register reveals, --lag-rule, the two hard-coded literals in block 6 (the arrow's asymmetric pair and the quote bar's lag), the hero's entrance in 6.28 and main.js's stagger step and cap. A rung left behind would not be a small error; it would be a different ladder. WHY 1.5 AND NOT MORE. 1.5 is the largest multiplier under which the two rungs a POINTER waits on still answer within one frame of what they answer in today - see the ceiling arithmetic below. At 1.75 --dur-base is 0.70s and the perceived arrival slips past a quarter of a second; at 2.0 the card lift is 0.80s and a pointer flicked across a row of three leaves three lifts overlapping, which reads as lag rather than as weight. 1.5 is also the point at which the slowest thing on the page, --reveal-display, crosses 1.4s: past that a reveal starts to look like a page still loading. THE POINTER CEILING, AND THE LADDER DOES SPLIT AFTER ALL. [MOTION v21] REWRITES THIS PARAGRAPH RATHER THAN AMENDING IT, because it was headed "AND WHY THE LADDER DOES NOT SPLIT" and a render pass then measured one gesture at more than twice the line it claimed to hold. A hover must feel answered; a scroll arrival must feel deliberate, and the two have different budgets. The test is NOT the nominal duration - by that test this ladder was already over the line at x 1.2, since --dur-base was 0.48s - but the PERCEIVED arrival, i.e. when the travel is visibly finished. Every curve this file uses reaches 90% of its travel at a fixed fraction of its duration, solved from the curve rather than estimated: --ease-out expo-out cubic-bezier(0.16, 1, 0.3, 1) 90% at 0.329 of the run ease the CSS default 90% at 0.625 linear 90% at 0.900 --ease-inout cubic-bezier(0.65, 0, 0.35, 1) 90% at 0.714 (Quint-out, retired this pass, sat at 0.374, and those two numbers are what the x 1.5 move was solved against: --dur-base BEFORE 0.48s quint -> 0.1795s perceived, AFTER 0.60s expo -> 0.1974s, +18ms and about one frame; --dur-fast 0.0898s -> 0.0987s, +9ms. THE CURVE IS WHAT PAID FOR THE DURATION, which is the whole reason those two changes were one decision and not two.) THE CEILING IS ROUGHLY 0.40s OF PERCEIVED ARRIVAL ON ANYTHING A POINTER WAITS ON, and it binds the PRODUCT rather than the rung: duration x the curve's fraction. Solved per curve, the longest duration each may carry on a pointer response is --ease-out 0.40 / 0.329 = 1.216s every rung clears it ease 0.40 / 0.625 = 0.640s --dur-base clears it at 0.375s; --dur-slow would not linear 0.40 / 0.900 = 0.444s --dur-fast clears it at 0.270s; --dur-base would not --ease-inout 0.40 / 0.714 = 0.560s --dur-base clears it at 0.429s; NOTHING ABOVE IT DOES WHERE THE SPLIT ACTUALLY BINDS, both cases repairs rather than new policy: (i) 6.18's .btn takes --dur-fast for its plate and its ink, not --dur-base. That is what this rung's own note has always said it was for ("colour and opacity only"), so the button was breaking a rule rather than needing a new one; its LIFT keeps --dur-base, which is the rung the card and the footer nudge also rise on. Two moving parts, two timings, one gesture. (ii) --ease-inout IS BARRED ABOVE --dur-base ON ANYTHING A POINTER WAITS ON. 6.9a's hover clip was --dur-media on --ease-inout: 1.275 x 0.714 = 0.910s before the picture is there, more than twice this ceiling, and measured at 0.157 of opacity 431ms after the pointer landed while every other property on the same card had settled. It takes --ease-out now - 0.4195s, which is the same figure as the photograph push underneath it, so the two arrive together. WHAT THE CEILING DELIBERATELY DOES NOT BIND, said out loud rather than left to be found: IMAGERY, --dur-media on --ease-out = 0.4195s, 19ms past a ceiling written as "roughly". Three gestures, and the subject of each is a photograph rather than a control: 6.29's push on both frames, and .act-card's watermark numeral. The pointer is not waiting on any of them - the object it is over answered in 0.1974s and the picture is the slow half of a gesture already acknowledged. A MATERIAL may take its time; a control may not. THE FOUR --ease-inout CONSUMERS, COUNTED RATHER THAN REMEMBERED, because the paragraph this replaces named two and there were three. All four are CHROME THAT TOGGLES BETWEEN TWO PERSISTENT STATES - opened and closed - which is what "reversible state" in that token's comment actually denotes, and none of them is a hover: 6.2 .nav-menu-btn::after caret rotate + translate --dur-fast 0.214s perceived 6.2 the practice panel opacity --dur-fast 0.214s 6.2 .nav-toggle the burger's three bars --dur-base 0.429s 6.2 .mobile-menu the full-screen fade --dur-base 0.429s The first two are inside the ceiling outright; the last two are the accepted pair - tapped, once per visit, on a panel that covers the viewport. WHAT MAKES (ii) A RULE AND NOT A SPECIAL CASE: after 6.9a moved off it, every remaining consumer is a toggle and no hover uses it, so "reversible" stops being a word two different kinds of gesture can both claim. A hover is reversible too - the lift, the edge and the push all return - and every one of them is on --ease-out, which is the evidence that the distinction was never symmetry. IF THE FIRM EVER REPORTS THE MENU AS SLOW, the repair is a second, shorter rung for reversible state - not a retune of --dur-base, which every hover on the site is solved against. */ --ease-out: cubic-bezier(0.16, 1, 0.3, 1); /* travel: expo-out, THE PLAYBOOK'S OWN - see the note below; the initial slope is 1/0.16 = 6.25 against quint-out's 1/0.22 = 4.545 */ --ease-inout: cubic-bezier(0.65, 0, 0.35, 1); /* reversible state, symmetric: menus, toggles, anything that returns */ /* [MOTION v20] --ease-out MOVED FROM QUINT-OUT TO EXPO-OUT, AND THE ARGUMENT THAT STOOD HERE IS REPLACED RATHER THAN AMENDED, BECAUSE IT ARGUED FOR THE OPPOSITE VALUE. It read: "travel: quint-out - one order gentler than the playbook's expo-out (0.16, 1, 0.3, 1); the same decisive arrival without the snap". Every word of that was true and the file was right to prefer it while the brief was a quiet site. The brief is now "too subtle. Make them more prominent", and GENTLE IS EXACTLY WHAT WAS ASKED TO STOP. The eye reads motion by VELOCITY, not by displacement, so the curve's initial slope is the single largest lever on whether a movement is noticed at all: expo-out leaves 37.5% faster (6.25 against 4.545 at the same travel and duration), and against the new travel and the new ladder a plate's peak velocity very nearly doubles - 75.8 to 145.8 px per second, computed in guards 7.3 where the travel is declared. WHAT THE SNAP COSTS AND WHY IT IS NOW WORTH PAYING. Front-loading shortens the phase in which the motion is visible: expo finishes 90% of its travel at 0.329 of the run against quint's 0.374, so at an unchanged duration each arrival would read 12% SHORTER - the wrong direction for "too fast". The duration is not unchanged. 1.20s of plate at 0.329 is a 0.395s visible phase against 0.96s of plate at 0.374 = 0.359s, so the visible phase is 10% LONGER and covers 75% more ground. Travel, duration and curve were solved together for exactly this reason; each on its own would have moved the wrong number. AND IT PUTS THE FILE BACK ON THE PLAYBOOK'S VALUE. This was the one place the derivation departed from its constitution, and the departure is what the firm has now asked to be reversed. main.js's counter tween carries a hand-written copy of this curve and must move with it - it mirrors the token in JS so the numeral eases like everything else, and a stale quint there would be the one thing on the page still arriving on the old curve. */ --dur-fast: 0.30s; /* 0.20 x 1.5 colour and opacity only */ --dur-base: 0.60s; /* 0.40 x 1.5 UI state: buttons, header, menu, card lift */ --dur-slow: 0.825s; /* 0.55 x 1.5 structural: rule draws, underlines, LABEL/RULE and LIST reveals */ --dur-media: 1.275s; /* 0.85 x 1.5 imagery ([data-reveal="fade"]) - slow reads as heavy, heavy as expensive */ /* Register reveals - not rungs; each is the playbook's register value x 1.5, and each can name why it is not a rung: DISPLAY must be the slowest thing on the page; PLATE sits between it and the rule draws. */ --reveal-display: 1.425s; /* 0.95 x 1.5 */ --reveal-plate: 1.2s; /* 0.80 x 1.5 */ --lag-rule: 0.18s; /* 0.12 x 1.5 fixed intra-object lag on a LIST row's hairline (CSS's, not stagger) */ /* JS stagger (step 8): per-element step = min(0.135s, 0.675s / (n - 1)) - the playbook's 0.09 and 0.45 x 1.5; the 0.675s cap is ~half of --reveal-display so the last element starts before the first finishes. THOSE TWO NUMBERS LIVE IN main.js AND MUST MOVE WITH THIS BLOCK, along with the three duration copies main.js keeps for its will-change release timer (1.425 / 1.2 / 0.825, this block's three arrival values). A stale copy there does not stop the motion - CSS owns every duration that runs - it releases the compositor layer early, which is the benign failure main.js's own comment describes. THE WATCHDOG IS UNAFFECTED AND WAS CHECKED, because a longer ladder must not outlive it: the 2.5s in src/partials/watchdog.html is a deadline for main.js STAMPING data-motion-ready, which block 0 does as its first statement, and not a deadline for anything finishing. The one timer that could have collided is the hero's rAF backstop, setTimeout(go, 1000), and it does not move in this pass. */ /* ---- THE SITE'S ONE NUDGE, NOW A TOKEN. It was three copies of the literal 3px - the card rise, the button rise and the arrow's lateral travel - held in step by a sentence in 6.18 ("the site's ONE nudge is 3px ... so the page has one nudge rather than five"). [MOTION v20] gives that sentence a declaration to point at, because this pass raises it and adds three more consumers, and a prose rule with six copies is a rule that drifts on the next edit. 3px -> 4px, AND THE SIZE IS SOLVED RATHER THAN CHOSEN. 6.18's own test for the rise is "present, under the threshold of a hop", and a hop on a control is read against the control's own height: the .btn box is 46.64px (6.18 carries the sum), and 10% of a thing's own height is the conventional edge at which a shift stops reading as a response and starts reading as a jump. 4.66px is that edge here, so 4px is the largest whole pixel under it. It is deliberately NOT the reveal travel's x 1.75 (which would give 5.25px and clear the hop threshold): a reveal is watched once and a nudge tracks a pointer, so the two distances answer to different limits and only one of them may be scaled freely. AN ABSOLUTE px, LIKE EVERY OTHER MOTION DISTANCE IN THIS FILE - it does not take the [RED v7] root multiplier, for the reason guards 7.3 gives at length about the reveal travel. main.js's magnetic button carries the fourth copy (LIFT = 3, ported into the JS offset because an inline transform outranks 6.18's hover) and MUST move to 4 with this token, or the one magnetic button on each page becomes the only control on the site that rises less than its neighbours - which is the recorded failure 6.18 already exists to prevent, one pixel along. */ --nudge: 4px; /* ---- [STAT v24] 2026-09-07. THE SITE'S ONE POP, AND IT IS A SECOND TOKEN RATHER THAN A SECOND NUDGE. The firm asked (2026-09-06) that the two stat numerals "slightly enlarge" under the pointer. An enlargement is not a travel, so it cannot take --nudge's VALUE - 4px of scale is not a quantity - but it must take --nudge's METHOD, which is 6.18's test: "present, under the threshold of a hop", where a hop is read against the object's OWN height and the answer is rounded DOWN to the coarsest step the property has. THE ARITHMETIC, so nobody re-derives it. The governing object is the wider of the two figures, "13+" at --text-4: line box 44.506 x --leading-heading 1.15 = 51.18px, so its hop edge is 10% of that, 5.118px. The figure is scaled about `transform-origin: left center` (6.12 says why), so the farthest-moving point of a uniform scale is the far corner at r = sqrt(W^2 + (H/2)^2). W is MEASURED, not estimated - 75.94px rendered at --text-4 with justify-self: start, the trimmed box; the untrimmed grid item is 285.38px wide at 1440 and would have made the sum meaningless - so r = sqrt(75.94^2 + 25.59^2) = 80.14px. Solving (s - 1) x r <= 5.118 gives s <= 1.0639, and rounding down to the hundredth the way --nudge rounded down to the whole pixel gives 1.06. The "3" is inside the cap by construction (W 26.02px, r 36.49px, whose own edge would allow 1.140), and ONE value serves both figures exactly as one --nudge serves the card, the button and the arrow. A SECOND READING, FOR FREE, FROM THE TYPE SCALE: its own step is x1.272, and ln(1.06) / ln(1.272) = 0.242, so the pop moves the figure a QUARTER of one rung. That is a response, not a resize, which is the whole of what "slightly" had to mean. THE ALTERNATIVE CAP, NAMED AND REJECTED: capping the far corner's travel at --nudge itself (4px) would give s <= 1.0499 and therefore 1.04. It was rejected because --nudge is a DISTANCE shared by six consumers so that the page has one travel, and a scale is not one of them; what 6.18 exports to a new gesture is the hop TEST, not the literal. Recorded so the choice is visible rather than silent. UNITLESS, so `scale: var(--pop)` reads as the one number it is, and so the token cannot be mistaken for a length and dropped into a translate. */ --pop: 1.06; } } /* ---- 2 · METRIC-ADJUSTED FALLBACK FACES ---------------------------------- */ /* display=swap renders a system face first, so its metrics are a design surface. Each family below aliases a local system font and overrides size, ascent and descent so that a headline set before the swap occupies the same box afterwards. One @font-face carries ONE size-adjust, so each local() list must resolve to ONE metric set on every platform - which is why each family aliases a single system face rather than every face the measurements were taken for. THE OVERRIDE VALUES BELOW ARE THE FIRM'S, SUPPLIED WITH THE FACES AND SHIPPED EXACTLY AS GIVEN. They were checked against the fonts' own tables and against a Chrome probe; the check is written beside each family, INCLUDING where it disagrees, and nothing is silently corrected. line-gap-override is added to both (0%, which is what the retired faces carried and what these values assume) so leading comes only from line-height. Overrides match line boxes, not per-glyph advances, so step 5's observer still refreshes on document.fonts.ready. ONE SEMANTICS RESULT THE CHECKS DEPEND ON, probed rather than assumed (Chrome, four @font-face rules over local(Arial) at 100px: plain -> fontBoundingAscent 91; size-adjust 50% -> 45; ascent-override 100% -> 100; both -> 50). SIZE-ADJUST MULTIPLIES THE OVERRIDES: effective ascent = ascent-override x size-adjust x font-size, so the correct declaration is override = webfont metric / size-adjust. THE RETIRED FACES DECLARED THEM THE OTHER WAY - "ascent-override: 113%" annotated "Titillium hhea ascent 1.133em" at size-adjust 94% - which built a line box 6% short of the webfont's. That was a pre-existing defect in faces this pass removes; it is recorded because it is why the firm's numbers look different in KIND from the ones they replace (the firm's Montserrat pair is scaled, i.e. correct under this probe), not because anything still depends on it. */ @font-face { font-family: "Montserrat Fallback"; /* SEGOE UI, and the choice is the firm's stack's, not this file's. The body stack lists Segoe UI ahead of Arial, reversing the retired face's own reasoning (Arial resolves on Windows, macOS AND Linux - fontconfig aliases it to the metric-compatible Liberation Sans - where Segoe UI is Windows-only), and the supplied size-adjust confirms which face it was solved against: 105% is an EXACT x-height match to Segoe UI (0.500 x 1.05 = 0.525 = Montserrat's x-height at wght 400, measured at the resolved instance). Against Arial the same 105% gives 0.5445 against 0.525, +3.7%. So this family aliases the face its number was built for. THE COST, STATED: where local("Segoe UI") finds nothing - macOS, Linux - this @font-face contributes no face at all and the UA falls straight through to the raw stack ("Helvetica Neue", Arial, sans-serif) UNADJUSTED, so those platforms get no metric match at all pre-swap rather than a slightly wrong one. Helvetica Neue and Iowan Old Style cannot be measured on the Windows machine these figures come from (their canvas rows come back byte-identical to Times New Roman, i.e. the face is absent and canvas fell back) and carry NO figure here. THE CHECK, run against Montserrat's own tables and shipped as supplied either way: size-adjust 105% the advance ideal over the 108-character sample is 52.9982 / 47.4634 = 111.66% against Segoe UI (110.39% against Arial), so 105% is 6.0% NARROW on the advance basis this file used for every previous synthetic face. It is exact on the x-height basis. The firm adjusted for x-height; reported, not changed. ascent 92% 0.92 x 1.05 = 0.966em against Montserrat's real hhea ascent 0.968em. CORRECT. descent 24% 0.24 x 1.05 = 0.252em against 0.251em. CORRECT. Synthetic line box 1.2180em against Montserrat's own 1.219em - 0.1%. The exact pair would be 92.2% / 23.9%, which is not worth a decimal. */ src: local("Segoe UI"); size-adjust: 105%; /* THE FIRM'S. Exact x-height match to Segoe UI (0.500 x 1.05 = 0.525 = Montserrat 400); 6.0% narrow on advance, where the ideal is 111.66% */ ascent-override: 92%; /* THE FIRM'S. x 1.05 = 0.966em against Montserrat hhea ascent 0.968em */ descent-override: 24%; /* THE FIRM'S. x 1.05 = 0.252em against Montserrat hhea descent 0.251em */ line-gap-override: 0%; /* Montserrat's hhea lineGap is 0; leading comes only from line-height */ } @font-face { font-family: "Newsreader Fallback"; /* Georgia, unchanged from the retired serif family and for the same reasons - it is the metric neighbour at the sizes the serif actually renders, its stroke contrast is a text serif's where Times has a newsprint face's, and it is first in the firm's own display stack. Cost, also unchanged: no universal Linux alias (Gelasio is metric-compatible where a distro ships it); where local() finds nothing the raw stack falls to Iowan Old Style / Times New Roman / Liberation Serif unadjusted. Iowan Old Style is macOS-only and is not on the measuring machine, so it carries no figure. THIS FAMILY IS NOW THE ONLY SERIF SYNTHETIC. The retired setting carried TWO - a band family for --text-2/--text-3 and a separate "…Fallback Hero" for --text-4, because Source Serif 4's width is a function of opsz and it NARROWED as opsz rose. Newsreader's width is also a function of opsz (the axis survives the Google Fonts subset - fvar/avar/gvar/HVAR/STAT are all present in the served woff2, so font-optical-sizing: auto really does move it) BUT IT WIDENS instead: measured over the 108-character sample at wght 450, 45.0274em at opsz 27.51, 45.6840 at 34.99, 46.5373 at 44.51, +3.4% across the band where Source Serif 4 went the other way. The sign of the hero's correction flips, and the firm specified exactly two stacks, so the third family and its --font-display-hero token are DELETED rather than re-solved. WHAT THAT COSTS, REPORTED RATHER THAN QUIETLY RE-INTRODUCED AS A THIRD FACE. Against Georgia's 47.5435em the ideal per-rung adjust is 94.71% (--text-2), 96.09% (--text-3), 97.88% (--text-4); a band family at the geometric mean of the first two would be sqrt(0.9471 x 0.9609) = 95.40%, and using that at --text-4 is 2.61% wrong - above the ~1% threshold at which a separate hero family earns its keep. So a balanced multi-line hero title CAN re-wrap on swap, and the fix if it ever shows is a third @font-face aliasing Georgia at ~97.9%, consumed by .hero-title alone. It is not taken here because the firm's brief is two stacks. THE CHECK on the firm's supplied values, shipped as given either way: size-adjust 92% 2.9% narrow at --text-2, 4.3% at --text-3, 6.0% at --text-4. It matches neither basis: the advance mean is 95.40% and the x-height match against Georgia would be 88.5% (0.48145 x 0.885 = 0.426 = Newsreader's x-height AS OS/2 REPORTS IT; [REPAIR v10] on the ink figures the serif's x-height is a function of opsz - 0.4415 at --text-2 rising to 0.4685 at --text-4 - so there is no single x-height basis to match here either, and the range it would ask for is 91.7-97.3%. That brackets the firm's 92% at the small end and misses it at the large, which is one more reading on which the number is defensible at --text-2 and narrow above it - the same shape as the advance check beside it). Unlike the Montserrat trio there is no reading of the number that makes it exact. ascent 98% WRONG BY 22.7%, AND SHIPPED ANYWAY BECAUSE IT IS THE FIRM'S. 0.98 x 0.92 = descent 26% 0.9016em against Newsreader's real hhea ascent 0.735em; 0.26 x 0.92 = 0.2392em against 0.265em. Newsreader's hhea ascent + descent is exactly 1.000em - the tightest of any face this file has carried - and the synthetic line box these values build is 1.1408em, +14.1%. So every display hook set before the swap occupies a line box 14% TALLER than the one it lands in, which is precisely the reflow a synthetic family exists to prevent. The pair that would match at size-adjust 92% is 79.9% / 28.8%. Reported to the firm, not changed here. */ src: local("Georgia"); /* family name = PostScript name, so one local() */ size-adjust: 92%; /* THE FIRM'S. Ideal against Georgia is 94.71 / 96.09 / 97.88% by rung, band mean 95.40%; 92% is 2.9-6.0% narrow */ ascent-override: 98%; /* THE FIRM'S. x 0.92 = 0.9016em against Newsreader hhea ascent 0.735em - see the check above */ descent-override: 26%; /* THE FIRM'S. x 0.92 = 0.2392em against Newsreader hhea descent 0.265em */ line-gap-override: 0%; /* Newsreader's hhea lineGap is 0; leading comes only from line-height */ } /* ---- 3 · BASE ------------------------------------------------------------- */ @layer base { *, *::before, *::after { box-sizing: border-box; } /* [RED v7] 106.25%, and A PERCENTAGE IS THE WHOLE POINT - never a px override. The firm asked for the font everywhere to be slightly bigger, and a px value here would have thrown away the visitor's own setting to do it: a reader who has set 20px would be forced back to 17. A percentage MULTIPLIES what they chose - 20 x 1.0625 = 21.25px - so the preference survives and the instruction is still carried out. And because every size, space, measure, container, track and grid figure in this file is expressed in rem, ONE multiplier here scales the entire system as a unit: every ratio between two of them and every character count in the derivation comments stays exactly true, and only the px annotations move (x1.0625). What does NOT scale, and is re-solved case by case rather than assumed: the viewport, the 44px tap floor, the 16px iOS field floor, the 17px classic-scrollbar allowance, the 1px hairlines, the ~7.2px cap-legibility floor, the reveal travel distances - and rem inside a media query, which resolves against the initial font-size and never sees this line (see the breakpoints). */ html { font-size: 106.25%; /* 16 x 1.0625 = 17px = --text-0 at the browser default; a PERCENTAGE so a visitor's own size is multiplied, not replaced */ -webkit-text-size-adjust: 100%; /* iOS must not inflate text in landscape - the scale is already derived */ text-size-adjust: 100%; background: var(--bg); /* the ground reaches the overscroll area too, so a bounce is never white */ scroll-behavior: smooth; /* skip link and in-page anchors; clamped to auto under reduced motion (guards) */ } body { margin: 0; min-height: 100dvh; background: var(--bg); color: var(--ink); /* 17.73:1 on --bg */ font-family: var(--font-body); /* 400, never 300. Light-on-dark antialiasing composites in gamma-incorrect space and erodes stroke edges; Montserrat is a geometric sans with no modulation in reserve at all - less than Titillium had - so Light goes grey and unstable reversed out of near-black, and 300 is exactly what the old site ran in its black footer. 300 belongs to the ivory band, where dark-on-light blooms it back up. (It used to belong to "the mark" as well; that was a Titillium Text Light relation and it went with the face.) Airiness comes from colour (--ink-2, --ink-3) here, not from weight. */ font-weight: var(--wt-body); font-size: var(--text-0); /* 1.68 against Montserrat's 1.219em `normal` box: the box no longer constrains anything (it did under Titillium's 1.521em), so the x-height governs alone - 28.56px pitch, 3.20 x the 8.925px x-height, 7.84px of clear between adjacent content boxes. */ line-height: var(--leading-body); letter-spacing: 0; /* Montserrat is wide-set (0.49072em average against Titillium's 0.4179); body carries no tracking, so no display hook has to undo any */ /* Subpixel (auto), NOT antialiased: grayscale AA thins light-on-dark type a further half-step on macOS, and thinning is the one thing reversed type cannot afford. The ivory band flips this, because dark-on-light blooms. */ -webkit-font-smoothing: auto; -moz-osx-font-smoothing: auto; overflow-wrap: break-word; /* a long citation URL can never force a horizontal scroll */ } h1, h2, h3, h4, p, ul, ol, dl, figure, blockquote { margin: 0; } /* rhythm comes from the space scale, set per component */ /* Form controls inherit the 1rem body font: a field never falls below 16px (iOS Safari zooms the viewport on a sub-16px field focus - an ABSOLUTE px floor, so the 106.25% base does not move it; --text-0 now runs at 17px and clears it by a whole pixel), and it never picks up a UA face. */ button, input, select, textarea { font: inherit; color: inherit; letter-spacing: inherit; } button { cursor: pointer; } textarea { resize: vertical; } a { color: var(--brand); } /* 2.99:1 on --bg, 2.70:1 on --bg-3 (the lightest ground a link sits on) - BELOW AA at 17px, by the firm's decision of 2026-09-06; see THE AA FAILURE, RECORDED in the token block */ strong, b { font-weight: var(--wt-strong); } /* Image defaults: block so no baseline gap, intrinsic ratio kept, never wider than the column. Alt text, if the image fails, reads as a caption (italic, --ink-3 at 5.61:1) and not as copy. */ img, svg, video, canvas { display: block; max-width: 100%; height: auto; } /* [FACE v9] THIS ITALIC IS NOW SYNTHESISED. The firm's request loads Montserrat roman only (300..600, no ital axis), where the retired loader carried real Titillium italics at 300 and 400, and font-synthesis is `none` only inside the display grant below - so broken-image alt text renders as a slanted roman rather than as a drawn italic. Kept because the JOB is unchanged (alt text must read as a caption and not as copy) and a synthetic oblique still does it; recorded because it is the only place on the site the missing sans italic is visible today. No page ships // in body copy; the day one does, this note is where the decision to load an italic starts. */ img { font-style: italic; color: var(--ink-3); } /* Selection and focus are palette decisions. The deep stop as fill - a full-strength accent behind a dragged paragraph is unbearable - with white text: 6.53:1. [RED v7] --brand-deep is now the mark's own #BF0000, so a dragged paragraph is highlighted in the firm's literal red, and white on it went from 5.8:1 to 6.53:1: deeper AND more legible, which is the fill half of the split stated once more. [RED v8] THIS DECLARATION IS THE REFERENCE THE WHOLE PASS WAS MEASURED AGAINST. The firm's instruction of 2026-09-06 names "the text highlight color" as the red every other red must match, and the text highlight is this line. It did not move; everything else moved onto it. #FFFFFF is THREE literals outside the token block rather than one - here, .skip-link's ink and .btn's ink, every one of them the ink ON --brand-fill or --brand-deep, which are now the same colour - and all three are deliberate: white is not a palette decision, it is the absence of one, and it is what a fill this deep can carry where the near-black cannot (6.53:1 against 3.04:1). There is no --brand-fill-ink token because a token would invite a fourth, lighter fill to reuse it. */ ::selection { background: var(--brand-deep); color: #FFFFFF; } /* 6.53:1 */ /* ---- [HOVER v22] THE RING IS WHITE, AND IT IS THE ONE VALUE IN THE HOVER/FOCUS SCHEME THAT IS NOT A TASTE DECISION. The firm's instruction of 2026-09-06 was that the pink hover states become "the dark red which is the signature color for the brand"; applied to this line it is not merely unattractive, it is unimplementable. #BF0000 measures 2.99:1 on --bg, 2.86:1 on --bg-2 and 2.70:1 on --bg-3 - every one of them under WCAG 1.4.11's 3:1 for the visual indicator of a component's state - and on a .btn, whose plate IS #BF0000, a #BF0000 ring is 1.00:1: not dim, not marginal, ABSENT, and absent on the one control the site treats as primary. --ink is 17.73:1 / 17.00:1 / 16.00:1 on the same three grounds and 5.93:1 inset on the brand fill. A keyboard visitor has no pointer to tell them where they are and this outline is the entire answer, so the ring was settled by measurement and the firm was told so rather than asked. Everything else in the scheme - the white text hovers, the deepened button plate - is the firm's preference honoured. WHY THIS AND NOT A COMPROMISE. Three were measured and all three lose to white. A red ring with a white halo doubles the drawn weight of every focus state on the site to rescue a colour. Keeping #FF7070 here alone would have left exactly the pink the firm objected to on the states a mouse user sees least and a keyboard user sees most. And a thicker red ring does not help at all: 1.4.11 is a CONTRAST floor, so 4px of 1.00:1 on a red button is still nothing. THE IN-BAND FIGURE IS AUTOMATIC AND STAYS AUTOMATIC. --ink rebinds to --ivory-ink inside .band--ivory and in print, so the ring inverts with the band and measures 17.32:1 there without a rule naming it - which is a property this ring did not have while it was painted in a brand stop, because that stop needed a rebinding of its own to be legible on ivory (it measured 2.39:1 unrebound). WHAT THIS BLOCK USED TO ARGUE, kept because the shape of the file depends on it: the ring was 2px of --brand-bright at 7.25:1 on --bg and 6.54:1 on --bg-3, and the token block called it "the one red the collapse did not take". Both halves of that sentence are gone - the colour is no longer red, and --brand-bright is no longer a token. The GEOMETRY is untouched: 2px, offset 3px, radius 1px, and 6.1's header-scrim paragraph re-measures where a ring lands over a photograph at the new colour. */ :focus-visible { outline: 2px solid var(--ink); outline-offset: 3px; border-radius: 1px; } /* 17.73:1 on --bg, 16.00:1 on --bg-3, 17.32:1 in-band via the rebinding */ :focus:not(:focus-visible) { outline: none; } /* Required, or hiding any grid/flex element via the attribute silently fails: an author display always beats the UA-origin [hidden] rule, so !important is the only reliable fix. The single !important outside guards - and, because earlier layers win among !important declarations, the strongest place for it. */ [hidden] { display: none !important; } /* Skip link: the label voice on the brand fill, parked above the viewport by position (never display, so it stays in the tab order) until it takes focus. */ .skip-link { position: absolute; top: 0; left: var(--gutter); z-index: 100; padding: var(--space-2) var(--space-3); background: var(--brand-fill); /* [RED v7] an AREA, so the fill stop */ color: #FFFFFF; /* 6.53:1 on --brand-fill; the retired --brand-ink there is 3.04:1 and fails */ font-size: var(--text-label); font-weight: var(--wt-label); letter-spacing: var(--track-6); /* the button rung */ text-transform: uppercase; text-decoration: none; border-radius: 0 0 var(--radius) var(--radius); transform: translateY(-110%); /* 100% of its own height plus its radius and ring */ } /* THE RING IS INSET (at top: 0 a +3px ring is clipped by the viewport edge), and that changes what it has to contrast against: at -3px it lands wholly INSIDE the fill, so the ground plays no part and the site's ring is measured against --brand-fill instead of against --bg. [HOVER v22] THAT USED TO BE A REPAIR AND IS NOW A REFINEMENT, and the difference is worth one line because it changes what a future editor may safely delete. The base ring was --brand-bright, which measured 2.43:1 on this plate - a failure, and the whole reason this declaration existed. The base ring is now --ink, which measures 5.93:1 there and clears 1.4.11 with room; the override therefore no longer FIXES anything. It is kept because #FFFFFF is this plate's own label ink and one plate should carry one white, and there is still no --brand-fill-ink token for the reason base's ::selection note gives. Deleting it would cost nothing measurable, which is exactly why the reason for keeping it has to be written down rather than assumed. This is still the ONE control on the site whose ring lands on a fill; everywhere else the +3px default puts the ring on a ground. */ .skip-link:focus-visible { transform: none; outline-offset: -3px; outline-color: #FFFFFF; } /* 6.53:1 on --brand-fill, where the base ring's --ink measures 5.93:1 and the retired --brand-bright measured 2.43:1 */ /* ---- The display-face GRANT: a closed, enumerated hook list. The serif appears here and nowhere else; everything else inherits --font-body from body. Listed explicitly on purpose: a substring selector like [class*="title"] would silently capture .section-subtitle and drag the serif onto its descendants. font-synthesis: none because the request is Newsreader ital,opsz,wght@0,6..72,400..600;1,6..72,400 - a weight of 700, or anything outside 400..600, must break visibly rather than smear a fake. THE LOADER WAS VERIFIED, not assumed: fonts.googleapis.com returns 11 @font-face blocks for that URL, Newsreader roman at font-weight: 400 600 and Newsreader italic at 400, every one font-display: swap. Optical sizing stays auto so opsz follows font-size (the hero at 44.51px gets the display cut, a card h3 at 27.51px the text cut) - and the opsz axis SURVIVES the Google Fonts subset, checked by decoding the served woff2's table directory, so this declaration is doing something rather than nothing. The width moves with opsz here too, but Newsreader WIDENS as opsz rises where Source Serif 4 narrowed, which is why there is no longer a separate hero synthetic face (block 2 carries the measurement and the 2.61% it costs). letter-spacing: 0 is the invariant's ceiling: a hook may go negative in its own block, never positive. text-wrap: balance belongs to .hero-title and .display only (step 7, paired with a ch max-width) - never to .quote, where a citation's break points matter legally. Components may add hooks ONLY by adding them to this list. THE LIST IS THE WHOLE ANSWER TO "WHERE DOES THE SERIF APPEAR", so it holds every consumer of var(--font-display), including the four hooks that arrived with the components layer and used to be declared outside it: .svc-card h3, .act-card h3, .package h3 the three card headings the markup contract names as DISPLAY hooks. They replace ".card h3", which named a class no page ships - the components layer re-declared the identical property set for them (old 6.8) and two copies of a closed grant is a grant an edit can silently miss. Folded in here, that block is deleted. .act-card[data-numeral]::before the watermark numeral (6.10). It is set in the serif at --text-4 and was the one consumer outside this list: font-synthesis is INHERITED and nothing on the .act-card path sets it, so it computed to `auto` there. Listing it takes its weight from the inherited --wt-body 400 to --wt-display 450 - a real step on the real 400..600 axis, so nothing is synthesised, and at rgba(--ink-rgb, 0.05) the numeral is texture, where 50 units of weight is not a visible change. A pseudo-element in this list generates nothing on its own: the numeral's own rule owns `content`. */ .hero-title, .display, .svc-card h3, .act-card h3, .package h3, .quote, .stat-num, .mobile-menu a, .act-card[data-numeral]::before { font-family: var(--font-display); font-weight: var(--wt-display); font-synthesis: none; font-optical-sizing: auto; letter-spacing: 0; /* never positive - invariant 2 */ text-transform: none; /* never caps - invariant 2 */ } /* [FACE v9] THE .hero-title REBIND IS GONE. It read `font-family: var(--font-display-hero)` and pointed at a third synthetic family sized for --text-4 alone. The firm specified two stacks; Newsreader's width moves the opposite way across opsz from Source Serif 4's, so the hero rung is collapsed onto --font-display and the token and its @font-face are deleted (block 2 reports the 2.61% pre-swap width error that collapse accepts, rather than re-introducing a face to hide it). .hero-title now takes the grant above and nothing else, which is also why 6.24's phone rule no longer has a family to reset. */ /* Emphasis inside display type (600 + --brand, never slant) is a component rule: hero/display block, step 7. */ /* ---- Inverted band. CURRENTLY UNUSED. Kept deliberately: the token rebindings below are the safety net for any future light band (an ivory credentials strip, a letterhead section), and the reasoning is not obvious. Deleting it invites someone to reintroduce a light section without them. (tokens.css, verbatim, plus the weight step-down it points to.) */ .band--ivory { background: var(--ivory); color: var(--ivory-ink); /* MANDATORY, not cosmetic. On ivory the dark-ground tokens fail WCAG AA: --brand #BF0000 = 5.79:1, the retired --brand-bright #FF7070 = 2.39:1, --ink-2 = 2.05:1, --ink-3 #928787 = 3.08:1. [RED v8] --brand IS THE ONE THAT STOPPED FAILING HERE, and its line stays anyway. The collapse onto the mark's #BF0000 made the dark-ground text stop a legal in-band value by accident - a light ground wants a dark accent, which is the exact inverse of the near-black case that made the same colour fail as text outside the band. The rebinding is kept because it is a REBINDING TO A NAMED IN-BAND TOKEN, not a coincidence of two hexes agreeing: --brand-ivory is where an in-band red is decided, and if the one-line revert to #FF3D3D is ever taken, --brand goes straight back to 3.11:1 here. [RED v7] --brand-fill IS THE ONE STOP WITH NO LINE HERE, and its absence is the decision, not an omission: --brand-ivory is re-solved to the same value --brand-fill holds, so the fill is already the correct in-band value and a rebinding would be a no-op that the next editor would have to verify. On ivory the dark/light split that forces two stops on a near-black ground has no reason to exist - text and fill both want a dark red - so the ladder collapses to one red in-band, and .btn keeps its #FFFFFF ink at 6.53:1 inside a light band exactly as it has it outside one. [RED v8] Since the whole dark ladder has now collapsed onto that same red, in-band and out-of-band are the same colour for the first time - which is a coincidence of this decision and not a licence to delete either rebinding. [v7 REPAIR PASS] THREE THINGS THE REBINDING LIST WAS MISSING, all of them consequences of the same omission - it rebound the INKS and left everything an ink lands ON at its near-black: THE PLATE GROUNDS. --bg-2 and --bg-3 paint .svc-card, .act-card, .package, .contact-card, .form-error, .form-sent, .field input and .quote-card. Inside this band the inherited --ivory-ink on --bg-2 measured 1.04:1 - a plate of near-black carrying near-black type. All four grounds now rebind to --ivory, which is exactly what @media print (6.25) has always done; that the print block did it and this one did not is the proof it was an omission and not a budget. --brand-ink. THIS ROW IS HISTORY SINCE [HOVER v22] AND IS KEPT AS THE RECORD OF A REAL DEFECT. This block used to rebind --brand-bright to --brand-ivory (= --brand-fill), and .btn's hover and :focus-visible both paired --brand-bright with --brand-ink - so in-band they recreated precisely the near-black-on-#BF0000 pairing the token block records as failing. The fix was to rebind --brand-ink to #FFFFFF. BOTH LINES ARE NOW DELETED, because both tokens are: the hover fill is --brand-fill-hover #8F0000 and its ink is the resting #FFFFFF, on ivory exactly as on the near-black, so there is nothing left for the band to correct. The reason the deletion is safe is that the hover no longer inverts anything - it deepens one plate - and a deepening reads the same on any ground. Deleting --brand-bright's line back when the token existed would have been the wrong repair, and the number that made it wrong is still true: a light pink plate on ivory is 2.39:1. THE HAIRLINES. --ink-rgb rebinds, so --line and --line-strong recompose automatically - but at the DARK ladder's alphas, which on a light ground are far too faint (0.18 gave 1.49:1). All three rungs are restated at the light-ground alphas, --line-control re-solved to the same 1.4.11 floor the dark rung was solved to and against the same converged light - which is why [RED v8]'s brighter light moved it, 0.47 -> 0.49, in the same pass and for the same reason it moved the dark rung 0.36 -> 0.37. */ --brand: var(--brand-ivory); /* 5.79:1 */ /* [HOVER v22] --brand-fill-hover IS NOT REBOUND, and the reason is --brand-fill's own: an in-band plate wants a dark red and #8F0000 is one, so a rebinding here would be a no-op. Its white label measures 9.69:1 on it inside the band exactly as outside it, because an ink on a plate never sees the ground. The two lines that USED to sit here, --brand-bright and --brand-ink, went with their tokens; the paragraph above says what they were for. */ --ink: var(--ivory-ink); /* 17.32:1 - and since [HOVER v22] this is the focus RING as well as the type, so the ring inverts with the band and no rule has to name it */ --ink-2: var(--ink-muted-ivory); /* 5.39:1 */ --ink-3: var(--ink-muted-ivory); --danger: var(--danger-ivory); --ink-rgb: 21, 9, 9; --bg-rgb: 243, 241, 237; --bg: var(--ivory); --bg-0: var(--ivory); --bg-2: var(--ivory); --bg-3: var(--ivory); --line: rgba(var(--ink-rgb), 0.20); /* 1.55:1 on ivory - the seam rung, the print block's own pair */ --line-strong: rgba(var(--ink-rgb), 0.35); /* 2.29:1 - emphasis, still never a control's only boundary */ --line-control: rgba(var(--ink-rgb), 0.49); /* 3.48:1 unlit and 3.08:1 lit: the same non-text floor, solved in the other direction */ /* Dark-on-light blooms: the identical paragraph reads a half-step heavier here than reversed out of near-black. Body weight steps DOWN inside this band (see the type tokens). */ /* The step-down itself. The physics wants a half-step (350) and Montserrat's variable axis could now give it - the retired Titillium shipped as static files where the smallest step down was a whole one. 300 is kept anyway: it is the bottom of the range the firm requested, the whole step is what the light ground was solved against, and a 350 would add a fifth weight to the system for a difference no reader can name. TWO THINGS THIS LINE USED TO SAY AND CANNOT: 300 is NOT "the wordmark's own TWM weight" (that was Titillium Text Light, in the mark, not on the page), and its italic is NOT loaded - the firm's request carries no sans italic at any weight, so an inside this band would be synthesised. The serif returns to its nominal 400 - it blooms back to ~450 optically, parity with the dark ground. Labels and strong HOLD 600: dark tracked caps at 600 on a light fill is the playbook's own button case, and the playbook's band never touched label weight. font-weight is re-declared here because descendants inherit the COMPUTED weight, not the token; the rebound tokens carry the rest. */ --wt-body: 300; /* 400 -> 300 */ --wt-display: 400; /* 450 -> 400 */ font-weight: var(--wt-body); -webkit-font-smoothing: antialiased; /* dark-on-light blooms; grayscale AA takes the bloom back */ -moz-osx-font-smoothing: grayscale; } } /* ---- 4 · LAYOUT PRIMITIVES ------------------------------------------------ */ /* Two primitives carry the whole page: one width constraint, one vertical band with ONE tonal variant (a second starts a stripe pattern rather than a rhythm). Markup shape is invariant:

. The gutter subtraction lives inside .container so no component ever sets its own page margin. RESTRUCTURE, DON'T STACK: when a row will not fit, the reflex is one column plus text-align: center - that is stacking, and it changes the page's alignment axis mid-scroll. Before writing any single-column fallback ask (a) does the collapse change the alignment axis relative to what sits directly above it, and (b) is the result taller than roughly the sum of its content? If either is yes, re-lay each item as [figure | label] on one row instead - it keeps the left axis, keeps figures full size, and roughly halves the height. Measure the widest label at its real tracked-caps size against the available track BEFORE choosing a breakpoint. */ @layer layout { .container { width: min(100% - 2 * var(--gutter), var(--container)); /* 100% - 55.01px, capped at 72rem */ margin-inline: auto; } .section { padding-block: var(--space-6); position: relative; } /* 116.52px */ .section--tight { padding-block: var(--space-5); } /* 72.01px - a density step, not a tone */ /* ADJOINING-EDGE TRIMS, added 2026-09-08 on the firm's instruction: "the gap between Experience and Accredidations cards and The Disciplines is visually much too large; shrink it." WHY NOT .section--tight: that modifier moves BOTH edges of a band, so putting it on #disciplines would also have pulled in the gap below it (to #current-practice) and putting it on #credentials would have pulled in the gap above it (to #name). The firm named ONE seam. These two trim one edge each, so every other gap on the page is left exactly as it was. WHY --space-5 AND NOT A NEW NUMBER: the scale is a phi ladder (939-945), and --space-5 / --space-6 = 4.236 / 6.854 = 0.618 = 1/phi. Stepping each side down one rung takes the measured 233.03px seam (116.518 x 2, the two paddings exactly - the bands are flush, no margin between them) to 144.02px, which is the same seam divided by phi. Inventing a pixel value would have put a number on the page that the ladder cannot explain. The next rung down, if the firm wants it tighter still, is --space-4 = 44.51px a side for an 89.02px seam. */ .section--tight-start { padding-top: var(--space-5); } /* 72.01px - trims the seam above */ .section--tight-end { padding-bottom: var(--space-5); } /* 72.01px - trims the seam below */ .section--alt { /* the ONE tonal variant */ background: var(--bg-2); /* 1.043:1 over --bg: the border does the delineating */ border-block: 1px solid var(--line); /* seam, not state */ } /* NO `.grid` PRIMITIVE HERE, deliberately. One existed and nothing consumed it: `class="grid"` appears in none of the 20 pages and neither partial, while 6.9 declared the identical three-property recipe for the three grid classes that ARE shipped (.svc-grid, .act-grid, .package-grid). Two copies of one sum is the shape an edit misses, and the copy carrying the derivation was the dead one. The rule and its arithmetic now live once, in 6.9. Add a primitive back only if a page consumes it. */ /* The prose measure: any running-text block is capped here (70 characters). A class, so the cap is visible in markup; a component that holds copy at another width states its own arithmetic. */ .prose { max-width: var(--measure); } /* COMPACT NAV BAND (67rem <= width < 74rem): the nav is up but full tracking does not fit (arithmetic in the breakpoint tokens). The labels shed tracking before size: 0.16 -> 0.08em, gap one step down. Both are token rebindings, so the header component reads var(--track-nav) and var(--nav-gap) and never carries a query of its own. The 74rem upper bound is the only number in this file that is neither breakpoint; it is the "full tracking fits" row of the same sum. [REPAIR v10] BOTH LITERALS NOW SIT ON THE ROWS THEY ARE DERIVED FROM, where [FACE v9] left them 37.8px and 35.2px below (and [RED v7] 8.1 and 5.4 below). 67rem = 1072px carries the compact row's 1061.80px with 10.2px of slack; 74rem = 1184px carries the at-rest row's 1171.18px with 12.8px. The consequence worth knowing before touching this: the burger now persists to 1071px, so a 1024x768 tablet in landscape gets the mobile menu. THE OVERSHOOT note in the breakpoint tokens carries the decision, the two exits refused, and what the change bought back. */ @media (min-width: 67rem) and (max-width: 73.99rem) { :root { --track-nav: var(--track-7); --nav-gap: var(--space-2); } } /* STRUCTURAL (below 67rem = 1072px): the desktop nav is gone and every two-up structure restructures. Components hook their collapses under THIS number only. The TOKEN drops to 4rem (68px -> 260.4px), which is what the FOOTER mark takes below this number; the collapsed header does not need the sub-line at 6.5px - the same words sit legibly in the footer. [v7 REPAIR PASS] AND THE HEADER NEVER RENDERS 4rem AT ALL: 6.1 caps its mark at min(--logo-h, 3.75rem), so the header mark is 63.75px -> 243.63px with a 6.04px sub-line cap here, not 68px -> 260.4px with 6.5px. This line describes the token, 6.1 describes the bar, and the two were being read as one number. Rebinding on :root here beats the token-layer value because `layout` is a later layer, not because it is later in the file. */ @media (max-width: 66.99rem) { :root { --logo-h: 4rem; } } /* PHONE (below 30rem = 480px): the gutter steps down one type step; sections drop one space step (116.52px x 2 was 28.7% of a 812px-tall phone). The hero drops one rung in its own component under this number. THE GUTTER STEP IS ALSO WHY .form-grid IS PINNED HERE (6.17): stepping the gutter down hands the container 11.76px at exactly this width, which was enough to put the form's two OLD 12rem tracks back abreast at 479px. [FACE v9] The track was re-derived to 13.78rem (a 24-character e-mail is 17.4% wider in Montserrat), so 2-up now needs 550.9px of viewport and the gutter step can no longer reach it - the pin closes an island that no longer exists and is kept because the sum it guards against has been crossed once already. The breakpoint tokens carry both arithmetics. */ @media (max-width: 29.99rem) { :root { --gutter: var(--gutter-phone); } /* 21.62px each side: 375 - 43.25 = 331.76px of column = 39.8 characters in Montserrat, below the 45-55 phone measure and unreachable at any gutter - the token's own note carries the failure */ .section { padding-block: var(--space-5); } /* 72.01px */ .section--tight { padding-block: var(--space-4); } /* 44.51px */ } /* LANDSCAPE PHONE: 812 x 375 matches only the structural query above and would otherwise get desktop padding - 2 x 116.52px on a 375px-tall screen is 62% of the viewport in padding. --space-4 (44.51px) keeps it under ~12% per side so a section's content reaches the screen. The hero component MUST add its min-height: 0 and padding step inside THIS query, not in a query of its own; and every display: none in a later component is checked at 812 x 375 as well. */ @media (max-height: 480px) and (orientation: landscape) { .section, .section--tight { padding-block: var(--space-4); } } } /* ---- 5 · GUARDS - win by layer, not by position ---------------------------- */ /* prefers-reduced-motion means "do not move things at me", not "remove the interface's responses". The pre-state override is limited to the un-revealed phase so it can never outrank a hover transform on a revealed element, and the universal clamp resets DELAY as well as duration - clamping only duration converts a stagger into a staircase of instant pops spread over the full stagger window. The delay reset is also what neutralises the stagger: JS writes only the inherited --reveal-delay custom property, and this clamp overrides the transition-delay that property feeds - on the element AND on the ::before / ::after that add it to their own lag, which is why the selector list is all three. Safe only because no other layer uses !important (block 0). */ @layer guards { @media (prefers-reduced-motion: reduce) { html.js [data-reveal]:not(.is-revealed) { opacity: 1 !important; transform: none !important; } /* THE POINTER LIGHT IS NOT DIMMED HERE, IT IS ABSENT. A light that chases the pointer is precisely what "do not move things at me" means, and it is the one thing on this site that moves without being asked twice: a reveal happens once per element and then stops, the light follows every flick of the wrist for as long as the page is open. Nothing else would do - the clamp below flattens transitions, and the lobes are moved by transform from a pointermove handler, which is neither a transition nor an animation and would sail straight through it. display: none also stops the compositor work and lets main.js skip building the pair at all. Layer, not !important: guards is later than components, so this outranks 6.26's opacity rules without touching the file's single-!important contract (block 0). */ .cursor-glow { display: none; } /* Same argument, same reason it cannot be left to the clamp: a scroll-linked transform is not a transition. The frame keeps its clip and its hairline; the picture simply stops drifting. main.js must ALSO stop publishing --parallax-y under this query; this rule is what makes it safe if it ever forgets. [ZOOM v11] `scale: none` IS NOW PART OF THIS RULE AND WAS NOT OPTIONAL. This line used to read `transform: none` alone and that single declaration did two jobs, because the overscan was a constant inside the same transform as the drift: killing the transform killed the crop with it, so a still page showed the photograph at its natural size rather than a permanent 4% one. 6.27 has had to move the overscan into its own `scale` property (6.28 needs `transform` free), and the moment it did, `transform: none` stopped reaching it. Without this second declaration a reduced-motion reader would have been left holding a 9% crop that buys them nothing - exactly the trade 6.27's gate (b) forbids. [PHOTO v16] AND THE FIRST DECLARATION IS NOW `translate: none`, BECAUSE THAT IS WHERE THE DRIFT LIVES. 6.27 moved it out of `transform` so 6.29's hover push could not multiply it; a guard that went on naming `transform` would have been three words of correct-looking text neutralising a property nothing declares any more, and the scrub would have survived under this query. Named for the property, checked in the browser: computed `translate` reads `none` on all three frames with the query on. `will-change: auto` IS THE THIRD DECLARATION AND IT CLOSES A LEAK THIS RULE USED TO LEAVE OPEN. 6.27 promotes every framed image with `will-change: translate` and calls the promotion "permanent by design: the scrub runs for the life of the page". Under this query the scrub does NOT run for the life of the page - the two declarations above freeze it and main.js's initParallax stops publishing --parallax-y - so what was left was one permanent compositor layer per framed image, on a desktop reader who has asked for less, for an element nothing will ever move. That is the same cost the reveal system's finish() is careful to hand back (it sets will-change: auto the moment an element has arrived, and s7.4 argues the release is load-bearing), so the standard already exists in this file and this rule was simply not applying it. Three properties, one rule, natural size and no layer, as it ships today. */ html.js [data-parallax] img { translate: none; scale: none; will-change: auto; } /* [ZOOM v13] THE ZOOM-OUT (6.28), AND WHY THE CLAMP BELOW IS STILL NOT ENOUGH ON ITS OWN. The clamp does neutralise animations - it is the one thing that separates this case from the scrub above, which is neither a transition nor an animation and can only be stopped in JS. But it neutralises them by collapsing animation-duration to 0.001s, and a 0.001s run of a `both`-filled animation does not leave the picture at rest: it SNAPS it to the end value and holds it there. WHAT THE REVERSAL FIXED HERE, AND IT IS WHY THIS NOTE IS NOW SHORT. Until today the end value was 1.19, so the clamp handed the readers most entitled to see no change at all the one framing nobody else ever rested at - a 9.5% crop per edge, reachable otherwise only by sitting through the 24 seconds of motion they had asked not to see. The end value is now 1.09, which IS 6.27's overscan and the frame every zoomed hero comes to rest on, so the clamp and this rule finally agree about which frame is the resting one: at worst the clamp leaves the picture exactly where a moving page leaves it, instead of somewhere no page does. The rule stays explicit anyway, because "the same crop as everyone else" is not "no crop", and because a guard should state its intent rather than inherit it from whatever an animation's `to` happens to be this month. HOW IT BEATS THE CLAMP, precisely: there is nothing to beat. The clamp marks animation-duration, animation-delay and animation-iteration-count !important and never touches animation-name; the shorthand here sets animation-name: none, which is uncontested, and an animation with no name does not run whatever its duration says. `scale` is not in the clamp at all - it is neither a transition nor an animation property - so the ordinary cascade decides it: same layer, later source position, and 0,1,1 against the clamp's 0,0,0. `scale: none` AND NOT `scale: 1.09`. Natural size is what a reduced-motion reader gets everywhere else on this site: the more specific rule above already gives it to every parallaxed hero, and below the 67rem gate or with JS off 6.27 declares no scale at any time, so there is no resting crop here to preserve. `scale: 1.09` would INTRODUCE one - 4.5% per edge on every page whose hero is a photograph (6.28 says why that set is named rather than counted), for precisely the readers this rule exists to protect. Smaller than the 9.5% the old end value threatened, and still a crop bought with no motion at all, which is the trade 6.27's gate (b) forbids by name. The more specific rule above says the same thing for the parallaxed case, so the two agree rather than race. */ .hero-media img { animation: none; scale: none; } /* [PHOTO v16] 6.29's HOVER PUSH, AND THE CLAMP GENUINELY DOES NOT CATCH IT - MEASURED, NOT ASSUMED, because the brief that ordered 6.29 asked for the check rather than the assumption. Under this query, hovering /real-estate's first card BEFORE this rule existed: transitionDuration 0.001s (so the clamp fires), transform `none` at rest, and matrix(1.028, 0, 0, 1.028, 0, 0) 120ms after pointerenter and for as long as the pointer stayed. The clamp collapses DURATION, and a 0.001s transition does not cancel a state change - it SERVES THE END VALUE INSTANTLY. That is the same failure the .hero-media rule directly above exists for, one property along, and it means a reduced-motion reader was getting the 2.8% step as a SNAP: the loudest possible form of it. SO THIS IS NOT NEW CAUTION, IT IS A REPAIR. Those three /real-estate cards have snapped on hover under this query since the site was built, invisible only because they were the site's only framed cards without a video (the six on the home page are already still here - see the note below). 6.29 would have extended the defect to every framed photograph on the site. `scale`, BECAUSE THAT IS THE PROPERTY 6.29 PUSHES. The [data-parallax] rule two above already says this for the two .feature-media figures whenever html.js is present and the attribute is on them; this rule covers .svc-card-media img, which carries no [data-parallax] and is missed by that selector entirely, and covers .feature-media img on the paths the other rule cannot reach (no script, or the attribute removed). Both say the same thing, so they agree rather than race. LAYER, NOT !important: guards is later than components (block 0), so this outranks 6.29's hover at any specificity without touching the file's single-!important contract. THE RING IS DELIBERATELY NOT NEUTRALISED. It is a colour, and the clamp will serve it in 0.001s, which is a colour change and not a movement. "Do not move things at me" is not "do not show me a red line", and removing it would take the whole of the firm's instruction away from a reader who asked only for the moving half of it to stop. */ .svc-card-media img, .feature-media img { scale: none; } /* [VIDEO v14] THE PRACTICE-AREA HOVER VIDEO IS ABSENT HERE, NOT FADED - the same distinction the pointer light gets four rules up, and for the same reason: the clamp below flattens TRANSITIONS, and what it would flatten here is the opacity fade, not the thing that moves. A 0.001s fade to a PLAYING video is the loudest possible answer to "do not move things at me" - it hands a reduced-motion reader the footage instantly instead of over 1.275s. display: none is the only declaration that reaches the motion itself, and it also stops the decode and the compositor work, which a dimmed video would go on paying for. LAYER, NOT !important, and NOT A SUBSTITUTE FOR THE JS GATE. guards is later than components, so this outranks 6.9a without touching the file's single-!important contract (block 0). main.js re-asks prefers-reduced-motion on the shared reducedMQ and pauses on a live change, which is the half that actually stops a clip already running; this rule is what makes the element vanish in the same instant rather than a frame later, and what covers the case where main.js has not been reached. [v15] THAT SENTENCE WAS ONLY HALF TRUE UNTIL v15 and the half that failed was this rule's problem too. main.js block 14 sat below the file's one early return, so a page LOADED under reduced motion never built the feature at all: turn reduced motion off mid-session and this display: none lifted, 6.9a faded an undecoded