max / quasi

0.64.0: the three renderers draw the wait they describe Phase 2 of wiki `loading-and-progress-standard`, all three surfaces in one pass because they are one reading and splitting them is how they diverge. quasi-immediate drew `ui.spinner()` for `Readiness::Pending` unconditionally: the only true rotating animation in the tree, and drawn identically whether the region was waiting on a measured payload or on nothing anyone could count. It draws the activity mark now, and a bar when something is watching delivery. quasi-tui's `busy_line` set `State::Disabled` and returned whatever the wait carried, so `Awaiting::of(41_943_040)` and `Awaiting::unmeasured()` produced identical output -- the amount was described, carried through the runtime, and dropped at the draw. The lock stays, which is rule 4; the mark is what it could not say. quasi-webview had been emitting `data-awaiting` for months with nothing styling either value. `makeover-webview` 0.60.0 draws it, and `AWAITING_JS` is the half neither of them could supply: `aria-busy` on the element while the request is in flight, and `--awaiting-share` from bytes the browser reports delivered. Not independent of htmx, unlike reveal, repeat and fill, so `without_htmx` drops it. The numerator is the host's on every surface. `Awaiting` carries the size of the payload and nothing can describe how much has arrived, because that is a fact about bytes in flight, so `View::delivered` is where it lands on the two native renderers and an XHR progress event is where it comes from in the browser. A wait nobody is counting draws the mark rather than an empty trough, and never a bar walking forward on elapsed time. Both native renderers gain `with_reduced_motion`. Neither surface has a `prefers-reduced-motion` to read, so the preference is the host's to obtain and it stills the mark rather than removing it.