Re: [round-display] [motion-path] Orientation of elements due to merging polar positioning and motion path

> According to the text of the “motion-rotation” property[5],
>
> the polar-angle behavior can be achieved with “motion-rotation:
>
> 0deg;”. However, the syntax here doesn’t agree with the values’
>
> explanation in the spec text - the syntax should be:
>
> “[[ auto | reverse ]? <angle>?]!”
>
>
Thanks! Tracked as https://github.com/w3c/fxtf-drafts/issues/6


> Given that rectangular displays are much more common on the Web
>
> than round displays (and this will likely continue to the the
>
> case into the far future), the default behavior should be the
>
> motion path behavior. Therefore, the default value after the
>
> merge should be “auto”.
>
> While I agree we should fix the spec problems preventing this,
> I don't agree with your conclusion about the initial value.
> It is not always appropriate to rotate the element to fit the
> path -- sometimes you do want it to stay up; it is not always
> an airplane! It could very well be a set of photos spiraling
> into their final positions. Or many other such things. Imho
> having the motion-rotation property default to no rotation is
> a very sensible choice even ignoring the existence of polar
> positioning.
>
>
Agreed. An initial value of 0deg also matches the default for SVG motion
along a path.


> Also, I would suggest that the property values be
>  none | auto | reverse
> with the initial value as none, as I don't really see a use case
> for <angle> values here: a fixed rotation should be handled with
> the 'rotate' property.
>
>
You can't use the 'rotate' property in the general case. For example, if
you are translating away from the path too, then

motion-rotation: auto;
translate: 100px;
rotate: 20deg;

and

motion-rotation: auto 20deg;
translate: 100px;

will produce different results. The former will move the object 100px in
front of the path (in the current direction of the path) then rotate the
object by 20deg, whereas the latter will rotate it by 20deg (off the
current direction of the path) then move it 100px in its new heading.

Arguably both can be encoded in the general transform property (as
transform: translate(100px) rotate(20deg)
and
transform: rotate(20deg) translate(100px)
respectively, however the rotation angle was added to motion-rotation in
the first place for parity with SVG, so I'm reluctant to remove it
(remember, motion-path is also used to allow CSS animation of SVG elements
along paths).


> ~fantasai
>
>
> Round Display has 'transform: rotate(<angle> | polar-angle | polar-angle-reverse)',
> which allows the standard rotate transformation to be derived from the
> angle of the "path" (the path was a ray, whose angle was called
> polar-angle).
>

I think this is a mis-feature. We haven't added keywords to transform
functions anywhere else, and doing this forces the computed value of
transform to be dependent on the computed value of both motion-path and
motion-position. That's bad.

Furthermore, from an implementation perspective mixing property dependency
into transform is an absolute nightmare for making transform animations
performant (for example we still don't know how to do accelerated animation
of transforms specified with 'em' values because this adds a dependency on
font-size).


> I think we should extend this to work with motion path too, to consider
> the angle at whatever point of the path the element is on. The syntax would
> be 'transform: rotate(<angle> | polar-angle | polar-angle-reverse)', With
> the path keyword in there, the path angle at that point is just added to
> whatever angle is specified, to determine its final rotation.
>

Obviously, I think this is a bad idea :)

Cheers,
    -Shane

>
> <http://www.w3.org/TR/css-round-display-1/#rotate--rotate-angle--polar-angle--polar-angle-reverse>
>