- From: Chris Marrin <cmarrin@apple.com>
- Date: Mon, 17 Jan 2011 14:48:36 -0800
- To: Rik Cabanier <cabanier@adobe.com>
- Cc: Simon Fraser <smfr@me.com>, "www-style@w3.org" <www-style@w3.org>
Received on Monday, 17 January 2011 22:49:13 UTC
On Jan 13, 2011, at 12:22 PM, Rik Cabanier wrote: > Yes, > > > > Rotate is always around the transformation point. > > > > Rotate(a) is defined through the matrix: > > | cos(a) -sin(a) 0 | > > | sin(a) cos(a) 0 | > > | 0 0 1 | > > > > Rotate(a, b) would be defined as: > > | cos(a) -sin(b) 0 | > > | sin(a) cos(b) 0 | > > | 0 0 1 | I don't see a reason to have such a function. If an author wants to do such transformations, he can use matrix(). > > > > This type of animation is often used in Flash to give the appearance of an object that turns into view. > > > > Also, I believe that there should be a skew(x, y). > > The way the formulas are currently defined, there is no easy way to correctly do a shear in 2 dimensions since the second shear will impact the first one. > > There should either be a skew(x, y) or the recomposition logic should be rewritten. Again, that's what matrix() is for. A skew(x,y) primitive would always have the issue of ordering between x and y. I think the current primitives are plenty for allowing authors to construct matrices. ----- ~Chris cmarrin@apple.com
Received on Monday, 17 January 2011 22:49:13 UTC