Re: Proposal: Motions along a path in CSS

>
>
> I would like to propose adding a declarative version for motion path that
> has a similar behavior as SVG’s <animateMotion> and would be based on the
> underlying technique of WebAnimations.
>

+1.


> These are the properties and the proposed values:
>
> motion-path: <basic-shape> | <url> | none
>
>         * basic-shape will be extended by the path() function which takes
> an SVG Path string.
>         * initial: none
>
> motion-position: <length> | <percentage>
>
>         * The current position on the specified path or shape. Basic
> shapes need to specify the initial position 0.
>         * initial: 0
>
> motion-rotation: auto | reverse | <angle>
>
>         * ‘auto’ rotates the element dependent on the gradient at the
> current position on the path
>         * ‘reverse’ does the same as ‘auto’ but rotated by 180deg.
>         * <angle> a rotation applied to the element and keeps the rotation
> consistent along the animation.
>         * initial: auto
>
> motion: <motion-path> && <motion-position> && <motion-rotation>
>
>         * The shorthand for the motion longhands above.
>
> Motion animations are pre-multiplied to other transformations and apply
> before the ’transform’ property. Setting up the animation allows
> implementations to composite the element into the scene and push animations
> off the main thread into the compositing thread. Just like animated CSS
> Transforms.
>


This does not match the Web Animations mechanism. Web Animations defines
motion path animations as just another way of generating a transform.
Hence, motion path animations and other transform animations are combined
together in the same order as all other same-property animations are.

Concretely:

new AnimationGroup([
    new Animation(target, [{transform: ..., }], ...),
    new Animation(target, new MotionPath(..., {composite: add}), ...),
    new Animation(target, [{transform: ..., composite: add, }], ...)

Dirk's approach:
motionPath will apply before both transform animations.

Web Animations approach:
motionPath applies after the first transform animation and before the
second one (i.e. they match definition order).

If the CSSWG wants to take Dirk's approach we should harmonize the Web
Animation definition before there are any shipping implementations.

There are advantages and disadvantages to both:

Dirk's approach means we don't need a separate MotionPath object in Web
Animations, and also means that at some point in the future animation of
the path itself could be supported.

The existing Web Animations approach means that transform and motion path
animations can be ordered by the author, which provides a lot more
flexibility.

SO! Why not have the best of both worlds, and define a new
motion(<'motion'>) transform list function as well?

Cheers,
    -Shane
P.S. The motion property (with fixed application order) should continue to
exist. Except we should call it shmotion, of course.