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

> On May 17, 2016, at 12:08, Brad Kemper <brad.kemper@gmail.com> wrote:
> 
> 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. 

I thought we would be dropping transform: rotate(polar-angle) and transform: rotate(polar-angle-reverse) in favor of motion-rotation. I suppose we could go the other way around and drop motion-rotation in favor of keywords in the rotate function, but this looks less practical to me:
- if there's no motion-path (including a polar angle path), these keywords make no sense
- from a cascading point of view, the various motion-* things are independent of the rest of the transforms, and I'd like to keep it that way.
- Similarly, the various motion things are applied before the transforms, and I'd like to keep it that way.

 - Florian

Received on Wednesday, 18 May 2016 00:06:05 UTC