fix: footer email reflow to zero under all four methods; reopen the skip-link residual as Q61

The footer mailto was the last recorded overflow: `info@smlcompany.ca` demanded
310px of min-content in a 224-243px column. One declaration —
`overflow-wrap: anywhere` on `.footer-contact a[href^='mailto:']`. `anywhere`
and not `break-word`, established with a negative control rather than from the
rule: only `anywhere` reduces min-content, and `break-word` injected in its
place failed the same 88 rows as the unfixed baseline.

Minimum-font-size 32 goes 88/352 -> 0/352. All four methods now read 0 of 352
(22 pages x 16 widths). Normal-settings identity: 0 differences across 8
metrics, with a positive control proving the comparison can detect one. It also
closed 57 element-level cases the page-level table reports as clean, hidden
inside `.wrap`'s 96px gutter.

The item-2 ruling is NOT applied, and this is the deviation to read first. The
acceptance rested on "no CSS mechanism can see minimum-font-size", which is
false: the font-metric units — `ch`, `ex`, `cap`, `lh`, `rlh` — read the used
font size and double, in property values, in `@media` and in `@container`. Only
`rem`, `em`, `ic` and `px` are blind. And the cost is not a convenience loss:
keyboard focus lands entirely behind the opaque header on 290 of 1,455 stops,
36 of them inside `#main`, which is WCAG 2.2 SC 2.4.11 at AA — the same level as
the 1.4.10 failure it was traded against. A build of fce89d4~1 measures 0, so
the header fix created it. Opened as Q61 with a verified candidate; docs/06
restored to unticked.

R20's gate is now a build failure rather than three prose cross-references,
which demonstrably did not gate it: with two articles published the build and
all five checks passed while both header defects shipped. SiteHeader throws.

R11's two majors (@astrojs/mdx 7->8, typescript 6->7) move to a new cutover-prep
group in docs/06 with the 19-pin currency sweep.

Two review rounds, eight findings, all resolved; four of round 2's five were
defects in round 1's own fixes. Stopped at two per D19.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Md3GndFqWPzK78xAoebsg5
This commit is contained in:
Pouya Lajevardi
2026-09-01 14:51:37 -04:00
co-authored by Claude Opus 5
parent fce89d46eb
commit ca1c2524e1
8 changed files with 960 additions and 98 deletions
+26 -8
View File
@@ -406,14 +406,32 @@ the layout the desktop nav was measured in. One of those reported **0** while th
other reported **944 px** on the same 22 pages, and the prose generalised the
zero.
⚠️ **AND THERE ARE THREE MECHANISMS, NOT TWO — the third is the one that defeats
every CSS conditional.** Measured 2026-09-01: Chrome's **"Minimum font size"**
*floors* computed font sizes instead of scaling them, so text enlarges while
`rem` keeps resolving at 16 px. A media query does not see it, and neither does a
container query — `@container` `rem`/`em` DO track the root element (that is the
one real difference from `@media`, and it is measured), but under a minimum-font-
size setting they still resolve at 16 px while `getComputedStyle` reports 32 px.
**So no query fires, and only used-value layout — wrapping — reflows.** That path
⚠️ **AND THERE ARE THREE MECHANISMS, NOT TWO — the third defeats the `rem`/`em`
FAMILY, which is not the same as defeating CSS.** Measured 2026-09-01: Chrome's
**"Minimum font size"** *floors* computed font sizes instead of scaling them, so
text enlarges while `rem` keeps resolving at 16 px. A media query in `rem` does
not see it, and neither does a container query — `@container` `rem`/`em` DO track
the root element (that is the one real difference from `@media`, and it is
measured), but under a minimum-font-size setting they still resolve at 16 px while
`getComputedStyle` reports 32 px.
⚠️ **BUT "NO CSS CONDITIONAL CAN SEE IT" IS FALSE, AND ASSERTING IT COST A
CONFORMANCE FAILURE.** *Corrected 2026-09-01, same day, by `adversarial-reviewer`.*
The **font-metric** units read the *used* font size and therefore double:
**`ch`, `ex`, `cap`, `lh`, `rlh`** all respond — in property values, in `@media`
**and** in `@container` (`ch` 10.608 → 21.216 px; `@media (min-width: 100ch)`
flips). Only `rem`, `em`, `ic` and `px` are blind. The false generalisation was
written into `docs/02`, `docs/06`, `global.css` and `tokens.css`, and it was then
used as the premise for accepting a **WCAG 2.2 SC 2.4.11 (AA)** failure as
unfixable — *"the only fix is JS"*. **The lesson is the shape, not the units: "no
mechanism can X" is a claim about every mechanism, including the ones you did not
enumerate.** Test the family you did not think of before writing "none", and
prefer "every construct I measured is blind, and here is the list" — which is
falsifiable and was what the measurement actually supported.
For *reflow* the conclusion is unchanged: **used-value layout — wrapping — is
still the right mechanism**, because it needs no threshold and no fitted constant.
That path
was the worst of the three: on one grid of 22 pages × 16 widths, **219 of 352
page-widths overflowed** against root-style's **175**, and it was the only one
failing at 320 px and 1024 px. **Always state the grid with the count** — two