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

Brad Kemper
> On May 16, 2016, at 5:45 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
> 
>> On 05/16/2016 04:49 PM, Myles C. Maxfield wrote:
>> I was thinking about our resolution from last week to merge the
>> polar positioning properties from CSS Round Display[1] into
>> the Motion Path[2] properties.
>> 
>> The spec of CSS Round Display describes polar positioning as a
>> way to position an element. It doesn’t seem to mention the
>> orientation of the positioned element changing at all. This is
>> consistent with the green box in drawn in Example 8[3].
>> 
>> However, this is not true of motion path. In motion path, Example 1[4]
>> shows the orientation of the airplane changing to face the 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>?]!”
>> 
>> 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.
> 
> 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.
> 
> ~fantasai
> 

Round Display has 'transform: rotate(<angle> | polar-angle | polar-angle-reverse)', which allows the standard