`, the exact component .scr-title and .scr-name
already carry as --scr-text-head (k-kit.jsx:389-391 — head-face, weight
800, no letter-spacing beyond NameTitle's own flat 0.01em, which this file
already treats as untracked). Board 31 measuring the line at 22px tall (a
20px face on NameTitle's own 1.08 line-height, ≈21.6px) confirms it, not
the 24px-line-height caption the brief guessed.
This paragraph used to end by arguing that text-transform had to be written
out beside the font — `font:` is a shorthand and cannot carry it — so that
this head-face moment would not render in sentence case "against what the
component does". The kit line it cited does say uppercase; the app's own
component no longer does, and sentence case is now exactly what the
component does. See .scr-name. */
.scr-veil {
position: absolute; inset: 0; z-index: 2;
display: flex; flex-direction: column; align-items: center; justify-content: center;
gap: var(--sp-16); padding: 0 var(--sp-24);
text-align: center;
background: color-mix(in srgb, var(--k-color-stone) 92%, transparent);
}
/* Sentence case — see .scr-name for why the uppercase left. */
.scr-veil-head {
font: var(--scr-text-head); color: var(--k-color-ink);
}
/* The paragraph under the head (k-screens2.jsx:293): a plain div, K.muted —
not the Hint component, so it does NOT take --k-color-faded the way the
line below it does. The task brief's own markup names this .scr-foot
twice, once here and once for the trailing note — the THIRD time this
plan has named a class that was never built (task-9-brief.md named the
same one; progress.md's "PLAN DEFECT" entry for Task 9 traces the first
two). This is the first genuine use of the name: .scr-para (Task 9) does
not fit — its own sp-12/sp-16 padding is sized for a paragraph sitting
directly under a Bar inside a sheet, and stacking that padding on top of
.scr-veil's own sp-24 side inset and sp-16 flex gap would pinch the text
narrower and space it looser than the board shows. */
.scr-foot { font: var(--text-caption); color: var(--k-color-muted); }
/* The trailing note (k-screens2.jsx:296) IS the Hint component, so it takes
.scr-hint as built for beat 0 — same component, same --k-color-faded,
same bare --text-caption. Its own margin-top: --sp-4 stacks on top of
.scr-veil's sp-16 gap for this one pair; a few extra px between the
button and the note reads as intentional (the source itself gives that
pair a wider gap than any other in the overlay) rather than a bug worth a
third gap value in a file that otherwise leaves the flex gap alone. */
/* The button pair (k-screens2.jsx:294-295, two full-width Btns) reuses
.scr-actions/.scr-actions--col/.scr-btn/.scr-btn--go verbatim (Task 9
built the same column pair for "Back up my data" / "Restore from
backup"). Both of .scr-actions' own defaults fight this context, though:
its `margin` assumes normal document flow, and .scr-veil's own
`align-items: center` (needed so the head/foot/hint text can be
centre-narrower than the canvas) shrinks any flex child to its own
content width by default, which would leave two half-width buttons
floating side by side instead of one stacked full-width pair. Scoped to
this one ancestor rather than a third .scr-actions modifier, since no
other screen nests the action pair inside a centred flex column. */
.scr-veil .scr-actions { margin: 0; align-self: stretch; }
/* ==================================================================
BEAT 0's LOOP
Spec: docs/superpowers/specs/2026-08-04-site-beat0-loop-design.md
ONE duration and percentage keyframes, all infinite, all on the same
clock — no JS sequencing, so no two acts can drift apart. Declared
only under .is-playing: an inactive screen has no `animation` property
at all, so the browser has nothing to run, and replay is free.
The act boundaries, and why each is where it is. Task 3 lengthened the
loop from 10s to 12.5s and rewrote every percentage below so that not one
act's milliseconds moved — the ms column is what is load-bearing, the %
column is just where that ms lands on the new, longer clock:
0 → 7.2% 0 → 900 Instagram types in
7.2 → 9.6% 900 → 1200 hold
9.6 → 11.2% 1200 → 1400 the Home address "+ add" ghost leaves
11.2 → 19.2% 1400 → 2400 Home address types in
19.2 → 23.2% 2400 → 2900 hold — THE CARD IS COMPLETE
23.2 → 30.4% 2900 → 3800 the switch, over --swap-in
30.4 → 36.8% 3800 → 4600 hold
36.8 → 41.6% 4600 → 5200 Social ruled off
41.6 → 47.2% 5200 → 5900 Personal ruled on
47.2 → 51.2% 5900 → 6400 the well opens
51.2 → 56% 6400 → 7000 HOME's own toggle turns on
56 → 90.4% 7000 → 11300 hold — 4.3s, the frame to read
90.4 → 100% 11300 → 12500 back to the resting card
23.2% (2900ms) is where the switch starts, and that number is measured,
not reasoned. On narrow the loop is armed at 1150ms and the phone leaves
at HERO_HOLD_MS 4000ms: a visible budget of 2850ms, and the last frame
with the phone actually on screen was measured in Chromium at loop
2833ms. The card finishes typing at 2400ms, so a phone visitor now
watches it sit COMPLETE for the ~430ms it has left, and the switch
begins about 50ms after the phone has gone. Lengthening the loop to
12.5s did not change either number, because every act kept its
milliseconds — that is the whole point of doing it this way instead of
picking new percentages by eye, and it is what
scripts/site-screens.test.mjs's "keeps every act's milliseconds when the
loop's length changes" guards.
Two earlier drafts got this wrong by reasoning about it. The first ran
the two typed fields to 3200ms, which would have taken the phone off
screen mid-word. The second finished them at 2400 and started the switch
at 2600, on the sentence "2600ms leaves 250ms of settled card before the
exit" — but 2600 is where the switch BEGINS, so those 250ms were the
crossfade, not a settled card. Measured at the last visible frame: card
face 0.31, Elena's face 0.69, two app screens superimposed, illegible.
Two numbers reasoned to and one measured; only the measured one held.
THE CONSEQUENCE, so it is not rediscovered: a phone never sees Elena's
panel. The switch and both rulings are wide-viewport acts. What narrow
gets is the card filling itself in and then holding, complete — which is
the honest half of the story to show in 2.85 seconds. The rejected
alternative was lengthening HERO_HOLD_MS to ~4700ms so phones saw the
whole switch; it costs 700ms before the site's thesis and was ruled
against. Arming narrow earlier was also rejected: it would type the
fields while the device was still rising, which is the motion-on-motion
the arming seam exists to prevent.
And the loop is slow on purpose. Over a third of it (4.3s of 12.5s) is
the reading hold. On wide viewports this runs beside the site's opening
sentence, and a cycle competing with a sentence is what the page's
motion law exists to prevent. */
:root { --scr-loop: 12.5s; }
/* steps(), so the reveal reads as typing rather than as a wipe. clip-path
percentages are font-independent — a width animation would need the
rendered text width, which changes with --screen-scale. No caret: at
scale 0.7 a 1px bar renders sub-pixel and reads as dirt.
RECORDED, OWNER-RULED, LEFT AS IS (final review of the beat-2 handoff,
2026-08-04): the RESTING state of .scr-type / .scr-type--typed /
.scr-ghost--replaced — no .is-playing, so no `animation` property at all —
is unclipped: the card draws @sam.makes and every other typed field
complete, deliberately, so reduced motion (which never arms .is-playing)
reads as a normal, fully-drawn card rather than one frozen mid-type. That
resting frame is NOT this keyframe's 0% (`inset(0 100% 0 0)`, fully
clipped) — so every arrival at beat 0 shows the same two-step reveal
whether or not the reader has seen it before: the crossfade lands a
complete card, ARM_CROSS (900ms) later .is-playing arms and the animation
restarts from its own 0%, and the card blanks the same fields it just
showed before retyping them. Measured identical on all three routes into
beat 0 — from a stanza, from beat 4, from a veiled chapter opening —
+860ms clip:none/opacity ~1 (a fully-drawn card), +940ms
inset(0 100% 0 0) (blanked, retyping). The stanza route only makes the
hold more conspicuous, because .is-on is retained across a stanza so the
card pops in already at full opacity instead of fading in during the
wait. Do not "fix" this by moving the 0% frame or shortening ARM_CROSS —
both were deliberate, for reasons stated above and at ARM_CROSS's own
declaration in index.html, and the owner ruled: leave the behaviour,
correct the record. (The ledger that once called this latent and
unreachable by ordinary scrolling was wrong — it is live on every
arrival, and was already deployed when that was written.) */
@keyframes scr-type-in {
0% { clip-path: inset(0 100% 0 0); }
7.2% { clip-path: inset(0); }
90.4% { clip-path: inset(0); }
/* Reset while the card face is still at opacity 0 (it fades back in from
90.4%), so the empty card is what arrives, not a card being emptied. */
90.41%, 100% { clip-path: inset(0 100% 0 0); }
}
@keyframes scr-type-in-late {
0%, 11.2% { clip-path: inset(0 100% 0 0); }
19.2%, 90.4% { clip-path: inset(0); }
90.41%, 100% { clip-path: inset(0 100% 0 0); }
}
@keyframes scr-ghost-out {
0%, 9.6% { opacity: 1; }
11.2%, 90.4% { opacity: 0; }
90.41%, 100% { opacity: 1; }
}
.screen.is-playing .scr-face--card .scr-type {
/* @sam.makes is 10 characters — the convention is character count, same as
scr-type-in-late's steps(16) below for "14 Ashgrove Road" (16 chars).
Cosmetically invisible either way: clip-path steps are proportional to
the element's WIDTH, not to glyphs, so an off-by-one here never showed. */
animation: scr-type-in var(--scr-loop) steps(10) infinite;
}
.screen.is-playing .scr-face--card .scr-type--typed {
animation: scr-type-in-late var(--scr-loop) steps(16) infinite;
}
/* --replaced, not .scr-ghost: the card face carries TWO "+ add" ghosts, Home
address and Emergency contact, and the bare class took both. Measured in
Chromium at 390x844, 360x640, 834x1194 and 1440x900 — from 1400ms to 8800ms
of every loop, 7.4 seconds out of 10 (the loop was 10s then; the same
1400→11300ms window is now 9.9s of the current 12.5s), the Emergency
contact row rendered its label with nothing beside it, because nothing
types in there to take the ghost's place. The act table moves the ghost a
typed value replaces, and that is what the class now says. */
.screen.is-playing .scr-face--card .scr-ghost--replaced {
animation: scr-ghost-out var(--scr-loop) linear infinite;
}
/* The switch. --swap-in is the page's own crossfade duration, and
23.2→30.4% of the 12.5s loop is exactly that 900ms — unchanged from the
10s loop's 29→38%, because Task 3 retimed every percentage so the
milliseconds would not move. It starts at 2900ms (23.2%), not 2600ms,
so that on narrow the phone leaves DURING the hold rather than during
this crossfade; see the act table above. */
@keyframes scr-face-out {
0%, 23.2% { opacity: 1; }
30.4%, 90.4% { opacity: 0; }
100% { opacity: 1; }
}
@keyframes scr-face-in {
0%, 23.2% { opacity: 0; }
30.4%, 90.4% { opacity: 1; }
100% { opacity: 0; }
}
.screen.is-playing .scr-face--card { animation: scr-face-out var(--scr-loop) var(--swap-ease) infinite; }
.screen.is-playing .scr-face--seen { animation: scr-face-in var(--scr-loop) var(--swap-ease) infinite; }
/* The two rulings. Both are a crossfade between the two nodes the markup
already carries — never a re-tint, because the on/off recipes come from
the generated skin and differ in shadow layer count as well as colour.
36.8→41.6% and 41.6→47.2% (600ms and 700ms of the 12.5s loop, unchanged
from the 10s loop's 46→52% and 52→59%): sequential, not simultaneous, so
the eye follows one decision at a time rather than watching a row of
switches flick. Both moved 300ms later with the switch; they are still
600ms and 700ms wide. */
@keyframes scr-rule-off { /* --b (the off node) comes up */
0%, 36.8% { opacity: 0; }
41.6%, 90.4% { opacity: 1; }
100% { opacity: 0; }
}
@keyframes scr-rule-on { /* --b (the on node) comes up, later */
0%, 41.6% { opacity: 0; }
47.2%, 90.4% { opacity: 1; }
100% { opacity: 0; }
}
/* Social and Personal are named by POSITION here, not a new class. Inside
.scr-face--seen's .scr-payload every direct child is a , and
:nth-of-type counts siblings of the same TAG, not the same class — so an
index here is a count of DIVS, and any div that is not a .scr-cont still
takes a number.
Re-derived in the browser on 2026-08-17 and CORRECTED. This comment used to
describe a seven-div sequence with an always-shared Name/Phone well sitting
between Basics and Social, and concluded "Social is the 4th div, Personal
the 5th". That well was deleted when Basics was collapsed to its summary
line (see the markup's own note: 66px the app does not spend here, and the
61px that pushed this face past its body). The selectors were corrected with
it; the prose was not, and has been describing a layout the page has not had
since. The live sequence, read off the rendered DOM:
div 1 .scr-bar
div 2 .scr-cont Basics
div 3 .scr-cont Social ← :nth-of-type(3)
div 4 .scr-cont Personal ← :nth-of-type(4)
div 5 .scr-open the well Personal opens
div 6 .scr-cont Important
The trap the old note was pointing at is still real and has just moved:
`.scr-cont:nth-of-type(5)` reads like "the fifth container" and matches
NOTHING, because div 5 is the well and is not a .scr-cont. Nothing below
addresses Important; prefer a class over a position for any new row. */
.screen.is-playing .scr-face--seen .scr-cont:nth-of-type(3) .scr-toggle--b,
.screen.is-playing .scr-face--seen .scr-cont:nth-of-type(3) .scr-sub--b {
animation: scr-rule-off var(--scr-loop) var(--swap-ease) infinite;
}
.screen.is-playing .scr-face--seen .scr-cont:nth-of-type(4) .scr-toggle--b {
animation: scr-rule-on var(--scr-loop) var(--swap-ease) infinite;
}
/* The middle state: the container is on and nothing is shared yet. It is the
only frame in the loop that says the container gate and the field switch are
two decisions — which is exactly what the app's onCount does
(src/features/contacts/detail-parts.tsx:77), and what a single "1 of 2" the
moment the container flips would have quietly denied. */
.screen.is-playing .scr-face--seen .scr-cont:nth-of-type(4) .scr-sub--b {
animation: scr-sub-interim var(--scr-loop) var(--swap-ease) infinite;
}
/* The --a nodes fade out as their --b partners arrive. Same keyframes, so
the pair cannot drift; opacity is the only thing that differs. */
.screen.is-playing .scr-face--seen .scr-cont:nth-of-type(3) .scr-toggle--a,
.screen.is-playing .scr-face--seen .scr-cont:nth-of-type(3) .scr-sub--a {
animation: scr-rule-on-out var(--scr-loop) var(--swap-ease) infinite;
}
.screen.is-playing .scr-face--seen .scr-cont:nth-of-type(4) .scr-toggle--a,
.screen.is-playing .scr-face--seen .scr-cont:nth-of-type(4) .scr-sub--a {
animation: scr-rule-off-out var(--scr-loop) var(--swap-ease) infinite;
}
@keyframes scr-rule-on-out { /* partner of scr-rule-off (36.8→41.6%) */
0%, 36.8% { opacity: 1; }
41.6%, 90.4% { opacity: 0; }
100% { opacity: 1; }
}
@keyframes scr-rule-off-out { /* partner of scr-rule-on (41.6→47.2%) */
0%, 41.6% { opacity: 1; }
47.2%, 90.4% { opacity: 0; }
100% { opacity: 1; }
}
/* ---- The well opens, and one field is switched --------------------------
grid-template-rows is the only thing in this loop that animates LAYOUT.
Everything else is opacity and clip-path, deliberately. The cost, stated
rather than discovered: layout on one 332x738 canvas subtree for 500ms
opening and 1200ms closing out of every 12500ms — a 14% duty cycle over
about eleven boxes. Taken because the alternative is a max-height magic
number, and because a subtree this small on a cycle this slow is not what
a phone's battery notices. */
@keyframes scr-open {
0%, 47.2% { grid-template-rows: 0fr; }
51.2%, 90.4% { grid-template-rows: 1fr; }
100% { grid-template-rows: 0fr; }
}
/* The caret turns with the well it opens. detail-parts.tsx:100 —
`transform: [{ rotate: expanded ? '90deg' : '0deg' }]` — and #k-i-chevron
points RIGHT at rest, so a quarter turn lands it pointing DOWN, which is the
only thing on the row that says which container's fields are the ones on
screen. Beat 0 opened Personal's well for 43% of every loop with its caret
still lying on its side; the reader was being shown an open drawer under a
closed handle (owner, 2026-08-17).
Identical stops to scr-open, not approximate ones: the handle and the drawer
are one gesture in the app, where the same `expanded` drives both. */
@keyframes scr-caret-open {
0%, 47.2% { transform: rotate(0deg); }
51.2%, 90.4% { transform: rotate(90deg); }
100% { transform: rotate(0deg); }
}
@keyframes scr-field-on { /* the --b (on) node comes up */
0%, 51.2% { opacity: 0; }
56%, 90.4% { opacity: 1; }
100% { opacity: 0; }
}
@keyframes scr-field-on-out { /* its --a (off) partner goes down */
0%, 51.2% { opacity: 1; }
56%, 90.4% { opacity: 0; }
100% { opacity: 1; }
}
/* Up when the container is ruled on, down again when HOME is switched on. */
@keyframes scr-sub-interim {
0%, 41.6% { opacity: 0; }
47.2%, 51.2% { opacity: 1; }
56%, 100% { opacity: 0; }
}
.screen.is-playing .scr-face--seen .scr-open {
animation: scr-open var(--scr-loop) var(--swap-ease) infinite;
}
/* Personal's caret — the same nth-of-type(4) every other Personal rule uses.
Scoped to the svg, not the .scr-caret key, because the app rotates the icon
inside the button and leaves the button itself square to the world. */
.screen.is-playing .scr-face--seen .scr-cont:nth-of-type(4) .scr-caret svg {
animation: scr-caret-open var(--scr-loop) var(--swap-ease) infinite;
}
.screen.is-playing .scr-face--seen .scr-well--fields .scr-toggle--b,
.screen.is-playing .scr-face--seen .scr-cont:nth-of-type(4) .scr-sub--c {
animation: scr-field-on var(--scr-loop) var(--swap-ease) infinite;
}
.screen.is-playing .scr-face--seen .scr-well--fields .scr-toggle--a {
animation: scr-field-on-out var(--scr-loop) var(--swap-ease) infinite;
}
/* ==================================================================
BEAT 2 · THE CHANGE ARRIVES ON SOMEONE ELSE'S PHONE
Spec: docs/superpowers/specs/2026-08-04-site-beat2-handoff-design.md
6.1s per cycle, looping, after a 2s read delay. Beat 0's loop repeats
because it is a demonstration you can join at any point; this loop repeats
for a different reason — the event it shows is one-way, and phone B's own
exit (below) is what makes replaying it possible without un-happening it.
0 → 8.2% 0 → 500 B slides in
8.2 → 80.3% 500 → 4898 the cycle proper — both phones present; A types, B follows
80.3 → 88.5% 4898 → 5399 B slides out
88.5 → 100% 5399 → 6100 A's rows dip, reset unseen, and come back on the old values
--scr-read is the 2s the reader spends with phone A alone and the note
still up, before the first cycle starts. Every cycle after the first runs
the table above back to back, with no gap between one 100% and the next 0%.
The arrival is DESKTOP's. The room it needs is the note's column, and
the tablet band has no third column at all. Both band queries hide it. */
/* One cycle. 6.1s carrying twice the content the 6s one-shot carried, bought by
overlapping phone B's flips against phone A's next edit (see the act table in
the spec) rather than by rushing either.
--scr-read is the delay before the FIRST cycle. .arrival occupies the note's
column, so a permanently-present phone B means a permanently-hidden note —
and beat 2's note is "No re-sending. No 'hey, new number'.", the claim the
beat demonstrates. Two seconds is the reader arriving and reading it with
phone A alone, exactly as on every other beat; then it yields, B slides in,
and the loop runs for as long as they stay. Letting the note return during
each rest was rejected: 700ms per cycle is a blink. */
:root { --scr-handoff: 6.1s; --scr-read: 2s; }
/* ---- Phone A types -----------------------------------------------------
clip-path with steps(), the same mechanism as beat 0's scr-type-in: the
percentages are font-independent, where a width animation would need the
rendered text width and that changes with --screen-scale.
DELETING is the same keyframe backwards. Values are right-aligned
(.scr-was and .scr-value both sit at right: --sp-16), and inset(0 X% 0 0)
clips from the right — which is the direction backspacing shortens text.
Every keyframe below ends at 100% exactly where it began at 0%, so the cycle
has no seam. The state each row is left in after its change is held until
91.8%, then reset at 93% — under cover of the row dip in scr-a-reset, which
runs while phone B is off screen. */
@keyframes scr-a-phone-del {
0%, 12.3% { clip-path: inset(0); }
17.2%, 91.8% { clip-path: inset(0 100% 0 0); }
93%, 100% { clip-path: inset(0); }
}
@keyframes scr-a-phone-type {
0%, 17.2% { clip-path: inset(0 100% 0 0); }
30.7%, 91.8% { clip-path: inset(0); }
93%, 100% { clip-path: inset(0 100% 0 0); }
}
@keyframes scr-a-addr-del {
0%, 35.2% { clip-path: inset(0); }
40.2%, 91.8% { clip-path: inset(0 100% 0 0); }
93%, 100% { clip-path: inset(0); }
}
@keyframes scr-a-addr-type {
0%, 40.2% { clip-path: inset(0 100% 0 0); }
50.1%, 91.8% { clip-path: inset(0); }
93%, 100% { clip-path: inset(0 100% 0 0); }
}
/* The reset, and the only thing that hides it. Two rows out of eleven dip —
the same restraint beat 8 uses, where only the differing nodes cross and
everything else holds still — while phone B is sliding out and the reader's
eye is following it. */
@keyframes scr-a-reset {
0%, 88.5% { opacity: 1; }
91.8%, 95.1% { opacity: 0; }
100% { opacity: 1; }
}
/* ---- Phone B receives ---------------------------------------------------
B crossfades where A types, and the difference is the point: A is being
edited by a person, B is being updated by the relay. A typing animation on
B would claim Elena retyped Sam's number herself.
Each flip starts AFTER A has finished the matching field — 32.8% against A's
30.7%, 54.5% against A's 50.1%. Cause, then effect. The points between them
are the beat's whole argument.
The address lag was 1.5 points until 2026-08-17 and is 4.4 now. That is a
consequence of the handover below being longer, not a second decision: the
number's own change does not settle until 47.5%, and starting the address at
51.6% would have overlapped the two. Wider is not worse here — cause before
effect is the claim, and more air between them states it more plainly.
The reset sits at 90%, which is inside the window where B is off screen
(out at 88.5%), so B needs no dip of its own. */
/* HANDOVER, NOT CROSSFADE — changed 2026-08-17, owner: "the old info on the
small phone should actually disappear before it's replaced with the new one.
Right now it's too fast, we hardly see the changes."
Both values sit in the same cell (.scr-was and .scr-value are both pinned
right: --sp-16), so a crossfade puts two strings of digits on top of each
other for the whole of it. At the old 451ms that overlap was most of what
the reader saw: not a number changing, a number smudging. Nothing was
mistimed — the two keyframes were exact mirrors, which is precisely what
made them wrong.
So each field now runs OUT · EMPTY · IN, 300ms apiece, and the empty middle
is the point: for 300ms the row shows its label and no value at all, which
is the frame that says the old one is gone. 900ms a field against 451ms.
ms are into the 6.1s handoff, which itself starts --scr-read (2s) after the
beat arms — so add 2000 to compare against anything measured off the page.
% ms phone address
32.8 2001 old fades out
37.7 2300 (row empty)
42.6 2599 new fades in
47.5 2898 settled
54.5 3325 old fades out
59.4 3623 (row empty)
64.3 3922 new fades in
69.2 4221 settled
The addr flip moved 51.6% → 54.5% to keep a beat between the two fields:
with both changes twice as long, back-to-back they read as one continuous
event rather than two things arriving. 427ms between them now, against the
old 695ms — shorter, but the reader is no longer being asked to catch a
change that is already half over. B still holds the finished card for 677ms
before it starts leaving at 80.3%. */
@keyframes scr-b-phone-was {
0%, 32.8% { opacity: 1; }
37.7%, 88.5% { opacity: 0; }
90%, 100% { opacity: 1; }
}
@keyframes scr-b-phone-now {
0%, 42.6% { opacity: 0; }
47.5%, 88.5% { opacity: 1; }
90%, 100% { opacity: 0; }
}
@keyframes scr-b-addr-was {
0%, 54.5% { opacity: 1; }
59.4%, 88.5% { opacity: 0; }
90%, 100% { opacity: 1; }
}
@keyframes scr-b-addr-now {
0%, 64.3% { opacity: 0; }
69.2%, 88.5% { opacity: 1; }
90%, 100% { opacity: 0; }
}
/* The note steps aside once and stays aside — see --scr-read. It returns when
the reader leaves the beat, not between cycles. */
@keyframes scr-note-yield {
0% { opacity: 1; }
100% { opacity: 0; }
}
/* B arrives from the right and leaves the same way, once per cycle. translate
rather than a width or a margin: it composites, and it cannot disturb the
argument column's layout on its way in.
Its exit is load-bearing. A one-way event cannot simply repeat — replaying
"the number changed" means un-changing it — so B leaving at 88.5% is both the
end of a cycle and the cover under which phone A's rows reset at 93%. */
@keyframes scr-arrive {
0% { opacity: 0; transform: translateX(var(--sp-24)); }
8.2%, 80.3% { opacity: 1; transform: translateX(0); }
88.5%, 100% { opacity: 0; transform: translateX(var(--sp-24)); }
}
/* Phone A only. The arrival carries the same two marker classes and must NOT
type — it receives, it does not edit — so every selector here is scoped
through .screen, which the arrival is not inside.
`backwards` on every one of these is load-bearing, not decoration. These
animations are delayed by --scr-read, and .scr-was is statically
`opacity: 0` (its resting state, so reduced motion shows the new value, not
the old one). Without `backwards`, that static opacity is what renders
through the whole delay: the OLD value would stay invisible and only the
new one would show, so the beat would open already changed, its argument
gone before the reader has read the note. `backwards` holds each node at
its own 0% instead, which is the card exactly as it was. */
.screen.is-playing[data-screen="edited"] .scr-chg--phone .scr-was {
animation: scr-a-phone-del var(--scr-handoff) steps(15) var(--scr-read) infinite backwards,
scr-a-reset var(--scr-handoff) var(--swap-ease) var(--scr-read) infinite backwards;
}
.screen.is-playing[data-screen="edited"] .scr-chg--phone .scr-value:not(.scr-was) {
animation: scr-a-phone-type var(--scr-handoff) steps(15) var(--scr-read) infinite backwards,
scr-a-reset var(--scr-handoff) var(--swap-ease) var(--scr-read) infinite backwards;
}
.screen.is-playing[data-screen="edited"] .scr-chg--addr .scr-was {
animation: scr-a-addr-del var(--scr-handoff) steps(16) var(--scr-read) infinite backwards,
scr-a-reset var(--scr-handoff) var(--swap-ease) var(--scr-read) infinite backwards;
}
.screen.is-playing[data-screen="edited"] .scr-chg--addr .scr-value:not(.scr-was) {
animation: scr-a-addr-type var(--scr-handoff) steps(11) var(--scr-read) infinite backwards,
scr-a-reset var(--scr-handoff) var(--swap-ease) var(--scr-read) infinite backwards;
}
/* The note and the arrival are OUTSIDE the device, so the armed screen cannot
be an ancestor of either. :has() is what connects them, and it keeps the
state in the DOM rather than adding a body class that would be a second
copy of something already true. */
.stage:has(.screen[data-screen="edited"].is-playing) .note {
animation: scr-note-yield var(--swap-in) var(--swap-ease) var(--scr-read) 1 both;
}
/* `backwards` for the same reason as phone A's: through the --scr-read delay
these hold their own 0%, which is B standing off-screen with the OLD values
underneath. Without it B renders its static state during the delay — visible,
on the new number — and the first frame gives away the ending. */
.stage:has(.screen[data-screen="edited"].is-playing) .arrival {
animation: scr-arrive var(--scr-handoff) var(--swap-ease) var(--scr-read) infinite backwards;
}
/* Phone B rests VISIBLE, and this hook is .is-on rather than .is-playing on
purpose. Reduced motion never arms .is-playing (see the head of this file),
and even where the class does land, this file's animations are killed by
`animation: none !important` — so a reader with motion off would otherwise
get phone A alone, which was the old behaviour and is now wrong, because the
second phone IS the beat.
What they see instead is a coherent still: two people, one card, the same new
number and address on both. The argument without the motion.
MEDIA-SCOPED, and it was not at first. .is-on lands at the beat change and
.is-playing 900ms later (setScreen's handover, index.html ~2123), so with
motion ON this rule owned phone B for that whole gap: it stood at full
brightness in its resting place, then blinked out when `backwards` handed the
animation its 0% frame, then slid in properly two seconds later. Sampled per
frame at 1440x900, arriving the way a reader does — 0ms opacity 0, 125ms
opacity 1.00 with the veil still at 1.00, 1025ms opacity 0, entrance from
3040ms. The reader saw the ending of the beat before its beginning, while the
chapter's own text was still travelling to its column.
Reduced motion is the only state that needs a resting opacity, because it is
the only one where no animation will ever supply one. With motion, the base
`opacity: 0` at index.html:149 holds until scr-arrive brings B in — which is
what the `backwards` fill above is for. */
@media (prefers-reduced-motion: reduce) {
.stage:has(.screen[data-screen="edited"].is-on) .arrival { opacity: 1; }
}
.stage:has(.screen[data-screen="edited"].is-playing) .arrival .scr-chg--phone .scr-was {
animation: scr-b-phone-was var(--scr-handoff) var(--swap-ease) var(--scr-read) infinite backwards;
}
.stage:has(.screen[data-screen="edited"].is-playing) .arrival .scr-chg--phone .scr-value:not(.scr-was) {
animation: scr-b-phone-now var(--scr-handoff) var(--swap-ease) var(--scr-read) infinite backwards;
}
.stage:has(.screen[data-screen="edited"].is-playing) .arrival .scr-chg--addr .scr-was {
animation: scr-b-addr-was var(--scr-handoff) var(--swap-ease) var(--scr-read) infinite backwards;
}
.stage:has(.screen[data-screen="edited"].is-playing) .arrival .scr-chg--addr .scr-value:not(.scr-was) {
animation: scr-b-addr-now var(--scr-handoff) var(--swap-ease) var(--scr-read) infinite backwards;
}
/* ---- The 0.5.0 fidelity pass ------------------------------------------
Everything below came from putting each screen next to its device capture
in docs/ui-kit/0.5.0/ one to one. The kit's diff covered what CHANGED in
the app since these screens were built; this covers where the replica was
simply wrong, most of it since the day it was written.
Sizes stay on the generated scale and colours stay on --k-color-*, so
nothing here can fork the skin. The glyphs are the one exception by
necessity: the app's are a native icon set, so these are drawn from the
captures, inherit currentColor, and claim to be nothing more than the same
subjects at the same weight. */
/* The sprite itself never paints — only its