Re: Proposal: Motions along a path in CSS

> On 1 Sep 2014, at 9:08 am, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 
> On Sun, Aug 31, 2014 at 11:18 PM, Dirk Schulze <dschulze@adobe.com> wrote:
>> I uploaded a very early draft of motion path here http://dirkschulze.github.io/specs/motion-1/ for every one who is interested.
>> 
>> I did not include Shane’s proposal yet. I would still like to see some examples to understand it better.
> 
> Let me explain Shane's proposal a little more.
> 
> Motion-on-a-path is just a way of doing some relatively complex
> calculations that eventually resolve into, for a given amount of
> progress on the path, a translation and a rotation.  So, we can define
> this in translate-function terms, like:
> 
> motion(<'motion'>)
> 
> That is, it's a motion() function, which takes the same grammar as the
> 'motion' property - a shape, a progress, and a rotation directive.
> It's equivalent to a translate()/rotate() pair.
> 
> The 'motion' property, then, would just be a property-based variant of
> this, which inserts a motion() function into a specific spot at the
> beginning of the final transform list.  This has the nice benefits
> that it can be independently set and animated and cascaded without
> having to worry about any other transforms on the element.

I like this suggestion (and a strong +1 to Dirk's proposal overall).

One downside I don't like is that you'd have to duplicate a possibly long path in an animation. e.g.

from { transform: motion(<some path> 0%); }
to { transform: motion(<the same path> 100%); }

If there are 30 keyframes it gets more ugly. Could we come up with a way to avoid this?

(Could CSS variables help? Define a shape/path somewhere and refer to it in the motion() function?)

Dean

Received on Thursday, 4 September 2014 23:33:52 UTC