W3C home > Mailing lists > Public > www-style@w3.org > August 2014

Re: Proposal: Motions along a path in CSS

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 29 Aug 2014 08:52:13 +1000
Message-ID: <CAAWBYDD2XAu=LVHB5iQuzqYo4EgSkvvYDdo6cj985RAmhWeNbQ@mail.gmail.com>
To: Dirk Schulze <dschulze@adobe.com>
Cc: www-style list <www-style@w3.org>
On Thu, Aug 28, 2014 at 6:59 PM, Dirk Schulze <dschulze@adobe.com> wrote:
> Hi,
> Animating an element along a path is one of the missing parts of CSS animations today. The intention of this mail is to get a discussion started and get a general feeling if people are interested in this kind of feature.
> Animations along a path is getting asked for for quite some time and supported in SVG with <animateMotion> (not in IE though).
> ## Currently there exist some libraries adding support for this kind of feature:
> * YUI http://yuilibrary.com/yui/docs/anim/curve.html
> * TweenJS http://www.createjs.com/Docs/TweenJS/classes/MotionGuidePlugin.html
> * And a lot less common used libraries.
> ## Other technologies beside SVG supporting Animation along a path are:
> * Adobe Flash,
> * and others
> ## The WebAnimations spec defines an JS interface to set up motion paths:
> http://dev.w3.org/fxtf/web-animations/#motion-path-animation-effects
> ## Proposal
> 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.

I like it!  Been wanting to do motion on a path for a long time, but I
didn't think of handling it with an explicit motion-position property
that can be transitioned; that's pretty clever.

> 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

What happens if you specify a <length> longer than the path length, or
negative?  Same with <percentage> outside of 0%-100%.

Are we going to have the same escape-hatch as SVG for implementations
to not exactly calculate path length, and allow authors to specify
one, or do we consider that a legacy allowance for old implementations
that's no longer needed?

> 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

Does this mean that if I don't want my element to rotate at all, just
follow the path, I can specify "0deg"?

What happens at the points where the gradient is discontinuous?  The
answer isn't really visible for <animateMotion>, as you pass the
discontinuity instantenously, but motion-position lets you sit exactly
on it.

> 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.
> ## Example:
> .box {
>         motion-path: polygon(0px 100px, 100px 50px, 200px 100px);
>         motion-rotation: auto;
>         transition: motion-position 3s;
> }
> .box:hover {
>         motion-position: 100%;
> }
> Elements with the class “box” will be positions to the initial position of the motion path. On hovering, the element will be transitioned along the motion path.
> ## Issues
> There are some obvious topics that need to be discussed. Should the element behave as a fixed positioned element and override other properties?

No, it seems most reasonable to do as you're currently doing, and
treat it as a translate/rotate transform prepended to the transform

> What about elements with different values for the display property and so on. These issues need to be discussed in the context of WebAnimations anyway.

What about them?

Received on Thursday, 28 August 2014 22:53:00 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:24 UTC