Re: [motion-path] More natural names for 'auto' and 'reverse'

On Mon, Jun 22, 2015 at 2:27 PM Amelia Bellamy-Royds <
amelia.bellamy.royds@gmail.com> wrote:

> My main concern with the keyword `reverse` is that, in the shorthand
> property, it would be unclear what it applies to.  If I was not already
> familiar, I would assume that it meant travel along the path starting at
> the end and moving back to the beginning.
>
> Auto-reverse isn't much better on that point, but at least has the benefit
> of consistency with an existing spec.  However, I can't say I've ever used
> that option in SVG, and I *have* had need of the auto+angle option, so I
> wouldn't be disappointed if auto-reverse didn't make the cut at all.
>
> Keywords also complicate the animatability of the property.  And since
> this property is all about animation, that should be a significant factor.
> The spec doesn't have details on how these values will be interpolated.
> I'm assuming that a transition from `auto` to `auto 180deg` would be
> perfectly natural, by treating the first one as `auto 0deg`.  You would
> have to decide if the same transition applies for `auto` to `auto-reverse`.
>

It does - 'reverse' is treated as an alias for 'auto 180deg'.


> Think of the following keyframes sequence
>
> 0% {motion-offset: 0;}
> 40% {motion-offset: 100%;}
> 50% {motion-offset: 100%; motion-rotation: auto-reverse;}
> 90% {motion-offset: 0; motion-rotation: auto-reverse;}
> 100% {motion-offset: 0; motion-rotation: auto;}
>
> In other words, drive to the end of the path, then turn around in place
> and drive back along the other side of the line, then turn around again at
> the beginning.  So long as this works logically, I'm okay with auto-reverse
> being a shorthand for auto 180deg.
>

This works in our implementation.

(Whether you should be able to transition from auto to a fixed angle is a
> whole other question, of course!  It would be neat if you could, but it
> would definitely complicate things.).
>

One major issue is that you can't represent intermediate states without
losing information. At the moment in Chrome, animations from <angle>
to/from <keyword> <angle> flip at 50%.

Cheers,
    -Shane


>
> Best,
> ABR
>
> On 21 June 2015 at 21:32, Shane Stephens <shans@google.com> wrote:
>
>> Hi list,
>>
>> Issue 2 of the motion-path specification requests more natural names for
>> ‘auto’ and ‘reverse’. This is in the context of the motion-rotation
>> property: http://dev.w3.org/fxtf/motion-1/#motion-rotation.
>>
>> A specification of ‘motion-rotation: auto’ causes the targeted element to
>> rotate so that its horizontal axis is aligned with the tangent to the
>> motion path. This matches the SVG definition for animateMotion elements’
>> rotate attributes:
>> http://www.w3.org/TR/SVG/animate.html#AnimateMotionElement.
>> (rotate=”auto” has the same behavior).
>>
>> ‘motion-rotation: reverse’ causes the targeted element to rotate so that
>> its horizontal axis is aligned opposite to the tangent of the motion path.
>> This is specified in SVG as rotate=”auto-reverse”.
>>
>> Additionally, motion-rotation takes an angle (by default, 0deg) which
>> applies on top of any automatic rotation.
>>
>> Does anyone have suggestions for better names than ‘auto’ and ‘reverse’,
>> or do these names seem reasonable? Would it be best to align with SVG and
>> use 'auto' and 'auto-reverse'?
>>
>>
>> It's also true that 'reverse' provides identical behavior to 'auto
>> 180deg'. Should we provide just 'auto', in the interests of brevity?
>>
>> Cheers,
>>    -Shane
>>
>
>