Re: Proposal: Motions along a path in CSS

On Aug 29, 2014, at 4:23 AM, Shane Stephens <shans@google.com> wrote:
> 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).

I wouldn’t necessarily say that both concepts are incompatible to each other. WebAnimations would just be more powerful in this case. I think it is ok to have a JS implementations that allows you to go beyond the ~80% use cases.

> 
> 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.

Yes to the last point. It is a bit crazy to animate the path, but I did it for <animateMotion> in a presentation once. CSS Shapes already defines how to animate basic shapes. motion-path would just need to allow animations. Initially, I would be fine with not allowing it though and pick it up at a later point.

> 
> 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?

Can you give us an example how it would look like please?

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

Apologize! My mistake. Of course it should be shmotion ;)

Greetings,
Dirk

Received on Friday, 29 August 2014 06:58:41 UTC