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

> On May 17, 2016, at 5:05 PM, Florian Rivoal <florian@rivoal.net> wrote:
> 
> 
>> On May 17, 2016, at 12:08, Brad Kemper <brad.kemper@gmail.com> wrote:
>> 
>> 
>> 
>> 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)

We didn't resolve one way or another about those. 

> 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,

That's what I'm suggesting. I liked the idea of extending transform:translate() with a new value, rather than having a separate property that does the same thing. 

> but this looks less practical to me:
> - if there's no motion-path (including a polar angle path), these keywords make no sense

My syntax modification makes no less sense that the 'transform: rotate(polar-angle)' syntax that we had resolved on previously. It just makes it a little more versatile, so that we don't need a completely separate rotation transformation property that is just for paths. 

If there's no motion-path, then motion-rotation as a property doesn't make any more sense. I don't see how moving it from a separate property to a value of an existing property decreases the sense it makes. I think it is simpler for authors to always use transform: rotate() when they want to rotate. 

The 'path' keyword for rotate() would just be 0deg if there was no path, so it'd add nothing to the angle, and would be the same as leaving it off in that case. 

> - 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.

That's not what it sounds like to me from Shane. It seems like they all get thrown into the matrix in one order or another.

> - Similarly, the various motion things are applied before the transforms, and I'd like to keep it that way.

Why? It simpler to do all the rotating at once. The fact that motion-path and motion distance are done before the transforms is what enables the angle of the point on the path can be known prior to applying transform: rotate().

Received on Wednesday, 18 May 2016 05:05:17 UTC