docs(ui): correct the banner section to the shipped rotation behaviour #72

Merged
developer merged 1 commits from docs/banner-ui-accuracy into development 2026-06-16 05:57:14 +00:00
+12 -8
View File
@@ -215,14 +215,18 @@ a screen change does not replay the fade; only a real message advance fades. A *
round-robin** (`createScheduler`) picks the next message: campaigns compete by their weight (each
appears its weight share per cycle, evenly interleaved, not at random), and a campaign's own messages
advance round-robin. One message fades in (`fadeInMs`), holds `holdMs` (a message wider than the
strip pauses `edgePauseMs`, scrolls to its right edge at `scrollPxPerSec`, pauses, and repeats while
under `holdMs`), then — with more than one message — fades out (`fadeOutMs`), waits `gapMs`, and the
next fades in. The fade (opacity on a `.fadewrap` layer) is independent of the scroll (the inner
track's transform), so a long, scrolling message still fades at both ends. A lone message stays put
(a long one keeps scrolling). A **viewport size change** (e.g. a portrait↔landscape rotation)
re-measures the current message (`remeasureBanner`, debounced), so its scroll re-evaluates for the
new width. All timings are operator-set (`/_gm/banner-settings`). Under **reduce-motion** the fades
collapse to an instant swap
strip pauses `edgePauseMs`, scrolls to its right edge at `scrollPxPerSec`, pauses, and — while still
under `holdMs` — fades out, rewinds to the start hidden, then fades the **same** message back in to
scroll again), then fades out (`fadeOutMs`), waits `gapMs`, and the next fades in. The fade (opacity
on a `.fadewrap` layer) is independent of the scroll (the inner track's transform). **Every** cycle
boundary fades — a message change, a scroll rewind, and a **lone** message (which pulses out and back
in rather than sitting frozen) — so the rhythm is uniform. So the strip does not jump in height while
the message is momentarily gone during `gapMs`, it reserves one text line with an invisible spacer
and overlays the message absolutely. When a navigation remounts the view mid-scroll, the engine
**resumes the scroll from where it had reached** (`resumeScroll`) instead of restarting it at the
left. A **viewport size change** (e.g. a portrait↔landscape rotation) re-measures the current message
(`remeasureBanner`, debounced), so its scroll re-evaluates for the new width. All timings are
operator-set (`/_gm/banner-settings`). Under **reduce-motion** the fades collapse to an instant swap
and a long message does not scroll.
## Result / status iconography (`lib/result.ts`)