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

Sorry, didn't mean to hit "send" yet...




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 rotate transformation to be derived from the angle of the "path" (the path was a ray, whose angle was called polar-angle). 

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. 

Thus, if you have an airplane picture that points to the right, and a path that is at 45deg (that is, up and to the right), then 'transform: rotate(-90deg path)', would rotate the airplane 45deg - 90deg . Which is to say, it would be pointed at a 45deg angle too. If the path was pointed downward (motion-path: 180deg), then the plane would be rotated 180 - 90 = 90deg (clockwise), thus pointed down. 

If you had clock numbers whose baselines should be perpendicular to the ray, such that their bottom is toward the center of the clock, you would do this with 'transform: rotate(0deg path)'. Thus, the 12 o'clock position corresponds to a 0deg path, and there is no rotation. The 6 o'clock position corresponds to a 180deg path, and element is upside down. 

With this, no 'reverse' key word is needed, you just add 180 to your non-reversed angle to get it. 

This also gives you 'transform-origin' for free. You don't need 'motion-origin' to replicate that functionality.