rendered-no-motion

Venue: check — No animation or transition in an image or document class — a still frame never plays them.

Rule

An image or document template’s CSS must carry no motion: no animation or transition declaration (including their longhands, transition-duration and the rest) and no @keyframes block.

Graded over the compiled stylesheet, so a transition-colors utility and a hand-written transition: opacity .2s are the same finding. The rule is scoped to the classes that capture a still frame — a class whose artifact can actually move does not carry it.

Reason

The capture takes one frame. A still image is a single rasterised moment and a PDF page is a static document, so an animation has no timeline to run on and a transition has no second state to run toward — there is no interaction to trigger one and no elapsed time for one to play over.

What that means in practice is worse than “the motion does not happen”: the artifact captures whatever the starting state was. A section that fades in from opacity: 0 captures at zero opacity — invisible content, in a deliverable that looks like it rendered fine everywhere else. A transition on a hover state captures the un-hovered value, which is usually what you wanted, so the failure is intermittent by construction and depends entirely on which property you animated.

Fix

Express the end state directly and delete the animation or transition. Whatever the motion was going to arrive at is what the artifact should have carried all along.

Before

<div className="animate-in fade-in opacity-0 transition-opacity duration-500">…</div>

The capture takes the first frame, so this ships an invisible block.

After

return <div className="opacity-100">…</div>;

The state the animation was travelling to, captured directly.

See also

• The CSS pipeline — how the compiled stylesheet is assembled and graded.
• template.ts — the output classes, and which of them capture a still frame.