Repository navigation
Animate clip-path: interpolate polygon, inset, circle and ellipse in keyframes #384
Description
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-pathis rejected:unknown animation property 'clip-path'. rules/clip-path.mdstates that it doesn't interpolate in atimelineeither.- Attributes of an inline
svgare 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
timelinestep'sstyle, with the step's transition easing.
Found in: reel 4
Activity
fix(paint): border-radius keyframes, border.style dashes, clip-path m…
fix(paint): animated border-radius, real dashed borders, and a clip-p…
LeadcodeDev commentedon Sep 27, 2026
#398 landed a working clip-path animation, but not the vocabulary this issue describes, so it stays open.
What shipped
swept by a scalar motion property,
clip_path_progress, through the ordinarykeyframesengine. 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 precedentkind: node-pathset, rather than a silent snap.It came out that way because the literal form needs
KeyframeValueinschema/animation.rsto grow aClipPathvariant andvalidate_schema.rs's exhaustiveAnimationEffectmatch 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
fromand oneto. 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,loopand 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.