CssStyle::clip_path is declared, exported in the JSON Schema with seven variants, and read by nothing. A scenario that sets it validates, renders, and looks exactly as though the property were absent.
$ grep -rn "clip_path" crates/*/src --include='*.rs' | grep -v "css/style.rs"
crates/rustmotion-core/src/engine/transition.rs:536: canvas.clip_path(&path.detach(), …)
crates/rustmotion-core/src/engine/transition.rs:579: canvas.clip_path(&path.detach(), …)
crates/rustmotion-components/src/svg.rs:261: canvas.clip_path(path, None, true)
All three are Skia's own Canvas::clip_path, unrelated to the CSS property. paint_pass.rs implements overflow: hidden and never reads .clip_path once. Every variant is affected — Inset, Circle, Ellipse, Polygon, Path — not one in particular.
Present since 676e49e (2026-05-07), the CSS renderer rework.
Demonstrated rather than reasoned: two full-size circles both declaring "clip-path": {"kind": "node-path", "id": "crack"} over a zig-zag path node render as two plain overlapping discs, with the zig-zag visible only where the discs do not cover it — exactly as an unrelated sibling node would look.
Why it reads as working
crates/rustmotion/skills/rules/timeline-sequencing.md:129 does list clip-path among the properties a timeline style state cannot animate. That is a narrow note about one feature's own limits, and it is the only mention anywhere. The exported schema advertises the property globally, with all its variants and their documentation, and that is what a generator reads.
What it blocks
The reference reel this chantier measured against builds its cracking stone as one gem drawn twice, each half clipped by a path following the crack, so the halves separate along a coherent break. overflow: hidden clips to a rectangle and cannot express that. Non-rectangular masking is the one drawing capability those reels use that this engine has no path to at all — and unlike the rest of #326's findings, the property to express it was already declared.
Scope
Wiring clip_path into paint_pass.rs beside the existing overflow: hidden handling. The NodePath { id } variant added by #332 additionally needs #328's dependency graph to resolve the referenced node's path, so that one variant depends on work that has landed; the other five do not and could go first.
CssStyle::clip_pathis declared, exported in the JSON Schema with seven variants, and read by nothing. A scenario that sets it validates, renders, and looks exactly as though the property were absent.All three are Skia's own
Canvas::clip_path, unrelated to the CSS property.paint_pass.rsimplementsoverflow: hiddenand never reads.clip_pathonce. Every variant is affected —Inset,Circle,Ellipse,Polygon,Path— not one in particular.Present since 676e49e (2026-05-07), the CSS renderer rework.
Demonstrated rather than reasoned: two full-size circles both declaring
"clip-path": {"kind": "node-path", "id": "crack"}over a zig-zag path node render as two plain overlapping discs, with the zig-zag visible only where the discs do not cover it — exactly as an unrelated sibling node would look.Why it reads as working
crates/rustmotion/skills/rules/timeline-sequencing.md:129does listclip-pathamong the properties a timeline style state cannot animate. That is a narrow note about one feature's own limits, and it is the only mention anywhere. The exported schema advertises the property globally, with all its variants and their documentation, and that is what a generator reads.What it blocks
The reference reel this chantier measured against builds its cracking stone as one gem drawn twice, each half clipped by a path following the crack, so the halves separate along a coherent break.
overflow: hiddenclips to a rectangle and cannot express that. Non-rectangular masking is the one drawing capability those reels use that this engine has no path to at all — and unlike the rest of #326's findings, the property to express it was already declared.Scope
Wiring
clip_pathintopaint_pass.rsbeside the existingoverflow: hiddenhandling. TheNodePath { id }variant added by #332 additionally needs #328's dependency graph to resolve the referenced node's path, so that one variant depends on work that has landed; the other five do not and could go first.