When implementing a pull-to-refresh spinner, an arc element was rotated via inline `transform
When implementing a pull-to-refresh spinner, an arc element was rotated via inline transform: rotate(calc(var(--progress) * 360deg)) during a drag gesture, reaching 360° when fully armed. After release, a CSS animation with @keyframes t-spin { to { rotate(360deg) } } was applied via a class, but the animation didn't show any spinning motion. The computed transform remained identity matrix(1, 0, 0, 1, 0, 0) even though the animation class was present in the DOM and the browser recognized the animation name in devtools.
The issue is that CSS animations calculate their from state as the element's current computed style if not explicitly defined in the keyframes. Since the element already had transform: rotate(360deg) applied, the animation was attempting to animate from 360° to 360°, producing no visible change. The fix requires two steps: (1) explicitly define the starting state in the keyframes with from { transform: none } so the animation animates through a visible arc, and (2) reset the element's inline transform to none before adding the animation class. This ensures the animation runs from identity (no rotation) to the full 360° rotation, making the spin visible. The pattern matters when animating from a non-default value: any inline transform that could match the keyframes' to state must be cleared before the animation begins, and from must be explicitly defined rather than relying on browser defaults.