A Different CSS Motion Path

Jan 2, 2017

When I first heard about the Web Animations API a few years ago, the most exciting piece was the promise of support for motion path animations - so that we could move/translate elements along a defined path instead of the linear default.

SVG has had this for years in most browsers, but the ability to use this with any DOM element brought new possibilities. A lot changed after the initial announcement, and a lot more has changed again, and there are a lot of exciting things to come from this spec. To see some examples of the current spec, see my demos and others' demos in Chrome 55+ or Opera 42+.

For now, I want to discuss what I had originally hoped the CSS Motion Path module would be (using CSS + SVG animations to illustrate, since this doesn't really exist).

How I Imagined CSS Motion Path #

Instead of defining a path for an element and then animating its offset value to create motion along the path, I feel my ideal CSS Motion Path would tie more into existing transitions/animations.

Take a normal translate #

For example, take a basic translation animation with a 2000ms duration with linear easing and an infinite iteration count via transform: translate(25rem, 7.5rem):

... and a path from SVG #

Add a property to specify the path #

For example:

translate-path: path("M0,100 C200,0 200,200 300,0")

Let the browser map the points #

This is where I would pass the hard stuff to the browser (and why I understand this is a complicated issue). Assuming this could be achieved well, I'd expect the path to be rotated and scaled such that its start and end points match the start and end points of the translation.

So with the following CSS:

.circle {
animation: go-forth 2000ms 0ms infinite linear;
translate-path: path("M0,100 C200,0 200,200 300,0");
}
@keyframes go-forth {
100% { transform: translate(25rem, 7.5rem); }
}

We could have the following animation (second dot is the reference of the default translation):

Then if we only change the start and end points of our translation to be further apart and from the top/right to the bottom/left (with no change to anything related to the path) such as by changing our keyframes to:

@keyframes go-forth {
100% { transform: translate(-26rem, 52rem); }
}

We'd have:

There are several use cases for the current spec, and in many ways I'm glad it is how it is. There's still a part of me, though, that finds more value in what I've just described. I will certainly admit that might just be due to habit - being used to animating transforms for the last several years.