UI Motion That Compiles to Plain CSS, With No Runtime
Most motion tooling produces a video and a paragraph of instructions.
The useful output is the animation itself, in a form the page can run with nothing installed.
Short answer
Keyframe each property independently instead of picking a preset, then compile the timeline to plain CSS with no runtime. Opacity, position, scale, rotation, blur and colour as separate tracks is what makes a card that fades while it rises and settles expressible, and what makes the handoff the animation rather than a note about it.
What this covers
- Opacity, position, scale, rotation, blur, colour and background each keyframe independently, which is what makes a card that fades while it rises and settles expressible as three curves rather than one preset.
- Play and scrub drive the real preview through the browser's own animation engine, so what you are watching is the animation at the frame you scrubbed to, not a rendered approximation.
- Motion edits are live edits and never reload the canvas, because reloading would tear down the running animation in the middle of the change being made.
- Every edit re-bakes a compiled block of pure CSS: no runtime, no animation library, no JavaScript on the page, so a shared prototype animates for a viewer with nothing installed and the handoff is the animation rather than a description of it.
What makes motion tooling shippable
- Each property keyframes on its own, so a fade and a rise are not one preset.
- The preview is the animation, not a video of it.
- Editing does not restart what you are editing.
- The output runs with nothing installed.
- A shared link animates for someone who has never heard of the tool.
The timeline
The Design surface's bottom dock is a motion timeline in the shape you would expect from an animation tool: a time ruler, a playhead, a bar for every animated element, and, when a layer is selected, one track per animated property beneath it.
Opacity, position, scale, rotation, blur, colour and background each keyframe independently. That is the model that makes real motion possible. A card that fades while it rises and settles is three curves with different timing, not one preset with a duration, and any tool that only offers the preset will produce motion that looks like a template.
Each track carries its own keyframes, a previous and next control, an inline value editor, and a marker at the playhead when you are between two keys rather than on one.
It plays the real thing
Play and scrub drive the actual preview through the browser's own animation engine, so what you are watching at any frame is the animation rather than a render of it.
Motion edits are live edits and never reload the canvas. That sounds like an implementation note and it is the difference between a usable timeline and an unusable one: reloading mid-edit tears down the running animation, and you lose the thing you were adjusting every time you adjust it.
What comes out is CSS
Every edit rewrites the motion source and re-bakes it into a compiled block of pure CSS. No runtime, no animation library, no JavaScript on the page that renders it.
That matters in two places at once. A shared prototype animates for a viewer who has installed nothing, because there is nothing to install. And the handoff to code is the animation itself rather than a description of it: a developer receives keyframes to paste, not a note that says fades in, 300ms, ease out and leaves them to re-derive the curve.
The [motion documentation](/docs/design/motion) covers the timeline and the compilation, and [design to code](/docs/design/code-handoff) covers what else travels with it.