Practical decision guide
5 min read
Updated
Animate a confirmation with a static alternative
Choose useful state feedback, optional animation and a readable fallback without losing the result.
Direct answer
Establish the result in text and state first, then add optional motion to explain the change. “No motion” excludes animation; “with a static alternative” permits animation only when the preference allows it. Pausing midway is not a static fallback: the final information must remain available immediately.
01
Name the information
For a saved setting, the information is the server-confirmed value and its saved status. A checkmark animation cannot establish persistence. Keep a readable result even if the animation never starts.
Choose a transition only if it explains a change of state, position or relationship. Decorative movement must not delay a next action or be required to understand success.
- animate a confirmation with a static alternative
- animation with reduced motion fallback
For a saved setting, the information is the server-confirmed value and its saved status. A checkmark animation cannot establish persistence. Keep a readable result even if the animation never starts. Choose a transition only if it explains a change of state, position or relationship. Decorative movement must not delay a next action or be required to understand success.
02
Choose timing or a spring
Easing shapes a time-based interpolation. A spring expresses a physical response and can overshoot. Use the existing labs to compare them on the same change rather than selecting the bounciest effect by appearance.
A reduced-motion preference is a request to reduce nonessential movement. For this confirmation, choose an immediate static result. That decision is editorial for this task, not a claim that every animation is forbidden by the media feature.
Easing shapes a time-based interpolation. A spring expresses a physical response and can overshoot. Use the existing labs to compare them on the same change rather than selecting the bounciest effect by appearance. A reduced-motion preference is a request to reduce nonessential movement. For this confirmation, choose an immediate static result. That decision is editorial for this task, not a claim that every animation is forbidden by the media feature.
03
Example: save notification settings
After confirmed save, render “Settings saved” beside the updated value. With motion allowed, optionally fade in a decorative indicator. With reduced motion, render the same final text and indicator without a transition.
Provide a manual static option when appropriate and listen for preference changes during playback. Cancel the animation and settle at the meaningful final state; do not leave an invisible success label at opacity zero.
After confirmed save, render “Settings saved” beside the updated value. With motion allowed, optionally fade in a decorative indicator. With reduced motion, render the same final text and indicator without a transition. Provide a manual static option when appropriate and listen for preference changes during playback. Cancel the animation and settle at the meaningful final state; do not leave an invisible success label at opacity zero.
04
Keep cancellation honest
Stopping animation changes presentation, not the save operation. Distinguish Pause animation from Cancel request. On unmount, release playback and event listeners so a reopened panel does not accumulate animations.
If the animation API is unavailable, expose the final content immediately. A loading shimmer must also stop once loading ends; its static skeleton is still a waiting state, not a completed result.
Stopping animation changes presentation, not the save operation. Distinguish Pause animation from Cancel request. On unmount, release playback and event listeners so a reopened panel does not accumulate animations. If the animation API is unavailable, expose the final content immediately. A loading shimmer must also stop once loading ends; its static skeleton is still a waiting state, not a completed result.
05
Verify both paths
Run the same task with motion allowed, reduced from the start and changed while running. Also simulate unavailable animation support. In each case verify text, next action, focus and final visual state.
No console error does not prove comfort or GPU efficiency. Keep motion optional and document unmeasured effects instead of presenting a desktop demo as universal device qualification.
Run the same task with motion allowed, reduced from the start and changed while running. Also simulate unavailable animation support. In each case verify text, next action, focus and final visual state. No console error does not prove comfort or GPU efficiency. Keep motion optional and document unmeasured effects instead of presenting a desktop demo as universal device qualification.
Keep this
Verify in your product
- 01Success exists without animation.
- 02No-motion requests stay static.
- 03System and manual preferences are honored.
- 04Cancellation settles at the final state.
- 05Unmount releases playback.
- 06Unsupported APIs preserve the result.
Primary sources
Technical claims in this guide connect to first-party specifications and documentation.
- prefers-reduced-motion (opens in a new tab)MDN · Primary reference for the documented mechanism. The worked scenario and decision checklist are original SkillCodex editorial guidance, not a certified implementation.
- Understanding status messages (opens in a new tab)W3C WAI · Primary reference for the documented mechanism. The worked scenario and decision checklist are original SkillCodex editorial guidance, not a certified implementation.
Continue
Related guides and tools
Understand → Recognize → Choose → Compare
Pack for your agent
Pre-written instruction by SkillCodex — your request is neither sent nor used to adapt this text; no content is generated, and copying executes nothing.
Implement correctly
Apply “Animate a confirmation with a static alternative” step by step
# Apply the “Animate a confirmation with a static alternative” guide in your agent ## Objective Establish the result in text and state first, then add optional motion to explain the change. “No motion” excludes animation; “with a static alternative” permits animation only when the preference allows it. Pausing midway is not a static fallback: the final information must remain available immediately. ## Prerequisites - Inspect the repository, documentation, and existing conventions. - Confirm the need matches the guide scope: Choose useful state feedback, optional animation and a readable fallback without losing the result. - Preserve the correct decisions already in place. ## Guide steps - 1. Name the information — For a saved setting, the information is the server-confirmed value and its saved status. A checkmark animation cannot establish persistence. Keep a readable result even if the animation never starts. Choose a transition only if it explains a change of state, position or relationship. Decorative movement must not delay a next action or be required to understand success. - 2. Choose timing or a spring — Easing shapes a time-based interpolation. A spring expresses a physical response and can overshoot. Use the existing labs to compare them on the same change rather than selecting the bounciest effect by appearance. A reduced-motion preference is a request to reduce nonessential movement. For this confirmation, choose an immediate static result. That decision is editorial for this task, not a claim that every animation is forbidden by the media feature. - 3. Example: save notification settings — After confirmed save, render “Settings saved” beside the updated value. With motion allowed, optionally fade in a decorative indicator. With reduced motion, render the same final text and indicator without a transition. Provide a manual static option when appropriate and listen for preference changes during playback. Cancel the animation and settle at the meaningful final state; do not leave an invisible success label at opacity zero. - 4. Keep cancellation honest — Stopping animation changes presentation, not the save operation. Distinguish Pause animation from Cancel request. On unmount, release playback and event listeners so a reopened panel does not accumulate animations. If the animation API is unavailable, expose the final content immediately. A loading shimmer must also stop once loading ends; its static skeleton is still a waiting state, not a completed result. - 5. Verify both paths — Run the same task with motion allowed, reduced from the start and changed while running. Also simulate unavailable animation support. In each case verify text, next action, focus and final visual state. No console error does not prove comfort or GPU efficiency. Keep motion optional and document unmeasured effects instead of presenting a desktop demo as universal device qualification. ## Acceptance criteria — Verify in your product - Success exists without animation. - No-motion requests stay static. - System and manual preferences are honored. - Cancellation settles at the final state. - Unmount releases playback. - Unsupported APIs preserve the result. ## Guardrails - Show the proposed changes before any external action. - Do not publish, send, delete, pay for, or change remote state without explicit authorization. - Preserve unrelated changes and stop if the scope becomes ambiguous. ## Output format - Outcome or verdict. - Files or actions involved. - Checks run and observable evidence. - Remaining blockers or limitations.
- Requires · The real project context: repository, documentation, and existing constraints
Why it works
- The steps come from a published, sourced guide, not improvisation.
- The checklist turns advice into verifiable criteria.
- The declared scope keeps the guide within its evidence.
Try next
Anchor the guide in the project
# Anchor the guide in the project ## Objective Turn the applied steps into durable repository conventions. ## Checks - Link each decision made to the guide step that justifies it. - Add the checklist to the relevant reviews. - Record out-of-scope cases for the neighboring guides. ## Guardrails - Show the proposed changes before any external action. - Do not publish, send, delete, pay for, or change remote state without explicit authorization. - Preserve unrelated changes and stop if the scope becomes ambiguous. ## Output format - Outcome or verdict. - Files or actions involved. - Checks run and observable evidence. - Remaining blockers or limitations.
sha256:cb088fd812ef27a0fa8bfdee00b2595a32d7fce9bbdd18f55f438eec024fa8b9
Diagnose a problem
Diagnose a “Animate a confirmation with a static alternative” guide gap
# Diagnose a failed application of the “Animate a confirmation with a static alternative” guide ## Observed symptom [DESCRIBE THE SYMPTOM HERE] ## Observable checks - Replay the steps in order and note the first one that diverges: - 1. Name the information — For a saved setting, the information is the server-confirmed value and its saved status. A checkmark animation cannot establish persistence. Keep a readable result even if the animation never starts. Choose a transition only if it explains a change of state, position or relationship. Decorative movement must not delay a next action or be required to understand success. - 2. Choose timing or a spring — Easing shapes a time-based interpolation. A spring expresses a physical response and can overshoot. Use the existing labs to compare them on the same change rather than selecting the bounciest effect by appearance. A reduced-motion preference is a request to reduce nonessential movement. For this confirmation, choose an immediate static result. That decision is editorial for this task, not a claim that every animation is forbidden by the media feature. - 3. Example: save notification settings — After confirmed save, render “Settings saved” beside the updated value. With motion allowed, optionally fade in a decorative indicator. With reduced motion, render the same final text and indicator without a transition. Provide a manual static option when appropriate and listen for preference changes during playback. Cancel the animation and settle at the meaningful final state; do not leave an invisible success label at opacity zero. - 4. Keep cancellation honest — Stopping animation changes presentation, not the save operation. Distinguish Pause animation from Cancel request. On unmount, release playback and event listeners so a reopened panel does not accumulate animations. If the animation API is unavailable, expose the final content immediately. A loading shimmer must also stop once loading ends; its static skeleton is still a waiting state, not a completed result. - 5. Verify both paths — Run the same task with motion allowed, reduced from the start and changed while running. Also simulate unavailable animation support. In each case verify text, next action, focus and final visual state. No console error does not prove comfort or GPU efficiency. Keep motion optional and document unmeasured effects instead of presenting a desktop demo as universal device qualification. ## Possible causes - A step was skipped or executed out of order. - The actual need falls outside the guide scope. - A checklist criterion was never verified. ## Bounded fixes - Redo only the diverging step and what depends on it. - Document the gap if the guide scope does not cover the need. ## Final verification — Verify in your product - Success exists without animation. - No-motion requests stay static. - System and manual preferences are honored. - Cancellation settles at the final state. - Unmount releases playback. - Unsupported APIs preserve the result. ## Guardrails - Show the proposed changes before any external action. - Do not publish, send, delete, pay for, or change remote state without explicit authorization. - Preserve unrelated changes and stop if the scope becomes ambiguous. ## Output format - Outcome or verdict. - Files or actions involved. - Checks run and observable evidence. - Remaining blockers or limitations.
- Requires · The real project context: repository, documentation, and existing constraints
Why it works
- The diagnosis replays ordered steps instead of searching at random.
- Fixes stay bounded to the first real divergence.
- The checklist serves as a reproducible final verification.
Try next
Prevent the next drift
# Prevent the next drift ## Objective Turn the first diverging step into an explicit project check. ## Checks - Add a focused check on the step that diverged. - Verify the checklist on a second real case. - Document the scope limit you hit. ## Guardrails - Show the proposed changes before any external action. - Do not publish, send, delete, pay for, or change remote state without explicit authorization. - Preserve unrelated changes and stop if the scope becomes ambiguous. ## Output format - Outcome or verdict. - Files or actions involved. - Checks run and observable evidence. - Remaining blockers or limitations.
sha256:9d460b66d5093e40bede55b277c39670dc8f26c4126d2ccb6af6ede8d9a4c00c
Pack digest: sha256:c7fc9f09fc7537f603be33a957b625523ebf6ac2b160dda761c539e79ac5a9ff