Animate clip-path: interpolate polygon, inset, circle and ellipse in keyframes

[LeadcodeDev]

Context

In the reel 4 reference, the dark wall of a neon room keeps changing silhouette while the camera moves: its cut corners slide from the top to the bottom, open, then close. The whole identity of the set rests on that living frame. Since #339, a static clip-path renders. Animating it isn't possible.

What happens

• In keyframes, clip-path is rejected: unknown animation property 'clip-path'.
• rules/clip-path.md states that it doesn't interpolate in a timeline either.
• Attributes of an inline svg are frozen too.

The only option left is a crossfade between two walls, which shows a double chamfer mid-fade, or transforms, which move the shape without deforming it.

Proposed vocabulary

{ "property": "clip-path", "easing": "ease_in_out", "keyframes": [
  { "time": 0, "value": { "kind": "polygon", "points": [[320,0],[1600,0],[1920,320],[1920,1080],[0,1080],[0,320]] } },
  { "time": 2, "value": { "kind": "polygon", "points": [[0,0],[1920,0],[1920,780],[1620,1080],[300,1080],[0,780]] } } ] }

• polygon: point-by-point interpolation when both values have the same vertex count. Otherwise, a validation error naming the two counts.
• inset, circle, ellipse: field-by-field interpolation.
• Two different kinds: a validation error.
• The same values usable in a timeline step's style, with the step's transition easing.

Found in: reel 4

[LeadcodeDev]

#398 landed a working clip-path animation, but not the vocabulary this issue describes, so it stays open.

What shipped

"clip-path": { "kind": "morph", "from": { … }, "to": { … } }

swept by a scalar motion property, clip_path_progress, through the ordinary keyframes engine. Polygon (equal vertex counts), inset, circle and ellipse all interpolate. A kind or vertex-count mismatch prints to stderr and leaves the node unclipped — the same precedent kind: node-path set, rather than a silent snap.

It came out that way because the literal form needs KeyframeValue in schema/animation.rs to grow a ClipPath variant and validate_schema.rs's exhaustive AnimationEffect match to learn it, and both were outside the workstream's file ownership. Reporting the wall instead of reaching across it was the right call there.

What is still missing

The spelling. This issue asks for property: "clip-path" with keyframes carrying shapes. That is not what an author writes today.

More than two shapes. A morph has exactly one from and one to. A three-stage silhouette needs stacked nodes.

The open question

Finishing the literal form is reachable — the blocking files are ordinary. The question is whether a second spelling for the same capability earns its keep, or whether the scalar-driven morph is simply the better design and this issue should be re-scoped to "morph chains of more than two shapes".

Worth an opinion before more code: the current form gets easing, spring, loop and per-keyframe easing for free precisely because it is an ordinary scalar track, and a shape-valued keyframe would have to re-earn all of that.