[JacobStephens2]

Summary

The static press line from #64 stays the source. main.js only steps it, and only when JavaScript runs and prefers-reduced-motion isn't reduce. The steps, buttons and terminal are hidden markup that the script reveals.

stepPressLine(section)                       # skipped with reduced motion; toggles off and on live
  IntersectionObserver(step markers, rootMargin -45% 0px -45% 0px)
    → render(n)                              # n = marker in the centre band, from the observer's own entries
  1–4 buttons → scroll instantly to marker n → render(n)
  render(n)                                  # sets the whole state, never a change from the last step
    lit unit (SVG + its column), aria-current on the buttons
    terminal = earlier units' lines (dimmed) + replay of unit n's lines, copied from the columns
  Pause / Play                               # stops or continues the replay and the cursor blink (WCAG 2.2.2)

 <section class="press">
   sec-head
+  .press-track               # 380vh while stepped; 4 hidden step markers
+    .press-stage             # position: sticky while stepped
       .press-frame (SVG)     # full width; the other units dim, the lit unit glows
+      .press-controls        # 1 · C … 4 · K (hidden until stepped)
       .press-cols            # stepped: only the lit unit's text, no lines
+      .press-term            # terminal + Pause (hidden until stepped)
   press-source, misprint

On wide screens, the press is full width and the lit unit's text and the terminal sit beneath it. On phones they stack. Scrolling stays native: no snap, no smooth scroll, and no scroll-linked animation, only 0.25s fades between steps.

There's one non-obvious fix. The observer callback follows the observer's own entries, not the live scroll position. A stress run of 300 random jump sequences found 3 stale steps when the callback read live positions: the observer only notifies on a change from what it last saw. After the fix, 600 of 600 sequences ended consistent.

Evidence

Chromium, 1440×900. From left to right: steps 1–4.

1 · C	2 · M	3 · Y	4 · K

Chromium, 390×844:

1 · C	2 · M	3 · Y	4 · K

The replay paused mid-unit (3 · Y):

• Before: the static press line from Press line, static: the full How a Run works diagram in HTML and SVG #64 only.
  After: a Playwright script (run outside the repo, since the site has no front-end tests) passed every check in Chromium and Firefox, at 1440×900 and at 390×844:
  • Scrolling to each step lights that unit and replays exactly its lines (1, 13, 18 and 10).
  • A fast scroll that jumps 1→4→2→3→1→4→3 ends on step 3 with a consistent state. A 20-notch mouse-wheel fling does too.
  • Buttons 3, 1, 4 and 2 each jump to that step, and a nudge of the scroll wheel afterwards agrees.
  • Pause holds the terminal at 3 lines for 1.5s, and Play resumes it (3 → 6 lines).
  • With reduced motion, and with JavaScript off, the full page renders pixel-identical to main, in both engines.
  • cargo test: all suites pass after merging origin/main.
• Not verified: Safari. Playwright's WebKit can't start on this host: it needs libjxl.so.0.8, which no Ubuntu or Debian archive ships, and there's no root access. The planned human acceptance pass should cover Safari, especially scrollTo({ behavior: "instant" }) and the sticky stage under iOS's collapsing toolbar (the stage uses 100svh).
• The share card is unaffected. docs/share-card/render.mjs clones the SVG out of .press, and all the dimming CSS is scoped under .press.is-stepped.

Merge Danger

Door: two-way

The change touches only site/ (HTML, CSS and one JS module). Reverting it restores the #64 version.

Blast Radius: home-page

The press section becomes about 3.8 viewport heights tall while stepped, which changes the page's scroll length. Readers with reduced motion or without JavaScript see no change.

Unaddressed findings

Standards

• Step as a bare 1-based integer, and the count of four in HTML, CSS and JS (possible Primitive Obsession / Shotgun Surgery): the press line is fixed content with four units. A fifth unit would need new SVG, a new column and a new button anyway.
• render mixes working out the state with writing it to the DOM (testability): the spec rules out front-end tests. Checks are by screenshots and the human acceptance pass.
• Two per-unit colour maps in CSS (--glow on SVG units, --ink on columns): these are different elements with different tokens. The glows use the "glows only" neon tokens. Sharing a key would mean adding classes to the SVG just for this.

Spec

• Safari unverified: WebKit can't run on this host (see Evidence). It's left to the planned human acceptance pass.
• Screenshots committed rather than attached: this follows the repo's docs/screenshots/issue-N/ convention from Home page walking skeleton: the proof-sheet hero with the install command #62, Press line, static: the full How a Run works diagram in HTML and SVG #64, Home page sections: workflow, what comes off the press, proof sheets, requirements, colophon #66 and The factory grows: the floor plan #67. The pull request embeds them.
• The terminal keeps earlier units' lines, dimmed: the lit unit's lines are always the newest ones and are scrolled into view. This reads as a real terminal, and a fast scroll still can't desync it, because render(n) rebuilds the terminal every time.
• The delivery pile lights at step 4, and the terminal has a blinking cursor: both are short state changes or decoration, and Pause stops the blink.
• The terminal shares the row beneath the press with the lit unit's text: the spec asks for the terminal beneath the press, inside the sticky area, and it is. The lit unit's description has to go somewhere, and putting it beside the terminal keeps the stage within one viewport, even at 1366×768.
• The replay plays once per step and doesn't loop: looping would be continuous motion. Play after the replay ends has nothing left to continue.

Closes #65

🤖 Generated with Claude Code