Repository navigation
design(reduced-motion): an in-place value change applies at once on any pointer (DR2) - #8645
Conversation
…ny pointer (DR2, DEC-3)
|
/approve-spec 0cc0f86 |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
AI review status for this pull request.
|
PR Analysis Report
|
There was a problem hiding this comment.
This needs one change before approval: the DR2 value exception and DEC-3 are owner-approved for this head, but the record now contradicts itself. The State representation row for a coarse pointer (docs/design/reduced-motion.md:58) still requires an opacity cross-fade for every change, and User intent says every touch-screen change cross-fades, while the new DR2 sentence and the "DR2 values" row say an in-place value change must not cross-fade. Adding the exception to that row, for example "Opacity-only cross-fade of 200 ms or less (DR2); an in-place value change applies at once (DR2)", and qualifying the User intent sentence the same way resolves it.
[Automated review]
| under Reduce Motion. An in-place value change, such as a progress fill's length or | ||
| another continuous value, does not cross-fade: under reduced motion it | ||
| applies at once on any pointer, with no added element (DEC-3). |
There was a problem hiding this comment.
This exception is not carried into the State representation table: its coarse-pointer row (line 58) still requires an opacity cross-fade for every change, and User intent (lines 33–35) says every touch-screen change cross-fades. Adding "an in-place value change applies at once (DR2)" to that row keeps the table and DR2 in agreement.
|
/approve-spec 1d0b51e |
There was a problem hiding this comment.
This looks ready from a spec standpoint: the DR2 value exception, the matching User intent and state-row wording, the "DR2 values" check and DEC-3 are approved by an engineering owner for this head, and the record no longer contradicts itself. One optional clarity tweak: the "DR1, DR3" verification row's "The same components" now sits directly under the new ProgressBar row, so naming the DR1, DR2 components there would prevent misreading it. #8613 and #8479 also edit the same DR2 line and verification table, so whichever lands later will need a manual merge.
[Automated review]
| | DR1, DR2 | Real-browser computed animations under reduced motion, coarse pointer | Layer entrance and exit (Tooltip, Popover, menu); Dialog; modal BottomSheet; a presentation switch | An animated transform, size, or position; a spring; a property other than opacity; over 200 ms; a change with no cross-fade | | ||
| | DR2 momentum | Real-browser computed animations under reduced motion after a touch throw | A flick that coasts and settles at an edge; a release that snaps to a detent, dismisses, or pages to a target | A coast replaced by a cross-fade or stopped at release; a snap, dismissal, or page that travels instead of cross-fading | | ||
| | DR2 values | Real-browser computed animations under reduced motion, coarse and fine pointer | A determinate ProgressBar's fill and another continuous value changing in place | A value that animates, cross-fades, or adds an element under reduced motion fails | | ||
| | DR1, DR3 | Real-browser computed animations under reduced motion, fine pointer | The same components | Any animated property, or a frame where the change is partly applied | |
There was a problem hiding this comment.
Optional: "The same components" now sits directly under the new DR2 values row, which names ProgressBar. By the contract pairing it still means the DR1, DR2 row's layers, Dialog, modal BottomSheet and presentation switch; naming them here, or moving the DR2 values row below this one, keeps the fine-pointer check from being read as covering only the ProgressBar fill.
…ient at once The spokes' gradient changes where it is, so under reduced motion it is an in-place value change: it applies at once on any pointer, with no added element (design:reduced-motion DR2 and DEC-3, meta#8645). The trigger no longer cross-fades a copy of the spokes under Reduce Motion; the stepping gradient shows at once, as a refresh begun without a pull already does. The cross-fade's keyframes lose their Reduce Motion branch, and with it the reduced-motion fade import. A unit test and a Chromium interaction test pin it: under Reduce Motion with a finger, the trigger adds no copy and nothing cross-fades. Both failed against the copy's 200 ms fade.
Main's reduced-motion record (with meta#8645's in-place value rule) is kept; this branch re-applies only its own two edits: the DR1 sentence that lets a dip land its travel as one step while transparent, and the DR1, DR2 row's failure signal. # Conflicts: # docs/design/reduced-motion.md
Decided (Cindy, 2026-10-26, D36 = a).
User impact
Under Reduce Motion, a progress bar's fill and similar values jump straight to the new value on every device, instead of cross-fading two lengths on a phone. That avoids an extra element and leaves no residual motion.
Change:
design:reduced-motionWriting rubric results