Review Animations

Reviewing Animations

Review only animation and motion behavior. Report only: do not edit source, install packages, or turn an aesthetic preference into a deterministic failure. Use code-review for general source defects and frontend-design only after the user separately authorizes implementation.

Read references/standards.md when a finding needs a concrete curve, duration, spring, gesture, performance, or accessibility starting point. Treat those values as craft criteria that require product context and current evidence.

Evidence Boundary

Inspect the relevant diff, source, rendered interaction, frequency, input mode, motion preferences, and product motion system. Cite file:line when source is available; otherwise anchor the finding to a route, component, state, viewport, or recording.

Separate observed behavior from inference. Do not claim dropped frames, compositor behavior, browser support, accessibility conformance, or interaction frequency without evidence. When feel is uncertain, request slow-motion, frame-by-frame, profiling, or real-device verification instead of guessing.

Review Criteria

Apply only criteria relevant to the interaction. A clue becomes a finding only when evidence connects it to user feedback, continuity, comprehension, efficiency, accessibility, performance, or product cohesion.

1. Purpose. Motion should orient, explain state, provide feedback, preserve continuity, or prevent a jarring change.
2. Frequency. Repeated and keyboard-driven actions usually need less motion than rare or explanatory moments.
3. Easing and timing. Response should begin promptly and settle at a pace appropriate to the element, consequence, and product.
4. Origin and physicality. Trigger-anchored surfaces should preserve the spatial relationship to their source; avoid motion that appears to come from nowhere.
5. Interruptibility. Rapidly triggered or gesture-driven motion should retarget from its current state without visible jumps.
6. Property cost. Investigate layout, paint, style-recalculation, and main-thread work; verify with profiling before making a performance claim.
7. Accessibility. Provide a non-vestibular alternative for movement and gate hover-only motion to suitable input modes.
8. Asymmetry. Deliberate input and system response may need different timing; symmetry is not automatically wrong.
9. Cohesion. Motion should match the component, task, platform, and established product language.
10. Deletion. Prefer removing motion that has no supported purpose or whose cost exceeds its value.

High-Signal Checks

Investigate these when present, but confirm context before reporting:

• transition: all, layout-property animation, or broad parent CSS-variable updates;
• scale(0), center-origin trigger surfaces, or pure fades that lose spatial continuity;
• long or delayed response on frequent or keyboard-driven actions;
• keyframes that visibly restart during rapid retriggering;
• missing reduced-motion handling on movement;
• hover motion without pointer/input gating;
• large simultaneous entrances that delay interaction;
• version-sensitive library acceleration claims made without current documentation or profiling.

Remedial Preference

Recommend the smallest coherent correction:

1. delete motion without a supported purpose;
2. reduce distance, duration, frequency, or animated properties;
3. correct easing, origin, spatial path, or interruption behavior;
4. use the project's existing motion primitives before adding a library;
5. add reduced-motion and appropriate input-mode handling;
6. profile before proposing performance-specific rewrites.

Required Output

Use one findings table, ordered by impact and confidence:

After the table, state one of:

• Evidence-backed motion findings remain, followed by the highest-risk unresolved check.
• No evidence-backed motion finding found, followed by any material evidence gap.

Do not issue a merge approval or block from taste alone. Deterministic tests, accessibility checks, profiling, and project requirements outrank this review.