Re: [css3-transform] definition of skewing

So we're saying that

SkewX(60deg) * SkewY(20deg) != SkewY(20deg) * SkewX(60deg) != SkewXY(60deg,
20deg)

So I cant get the equivalent of Skew(x,y) using a combo of Skew(x) and
Skew(y).
So why do we want to disallow it?

But the definition of Skew we're wishing for is

Skew(x,y) = [cos(y), sin(y), -sin(x), cos(x), 0, 0]

Even if we had Skew(x,y) = [1, tan(x), tan(y), 1, 0, 0] we'd need to scale
by a factor of (cos(y), cos(x))

So we can use a matrix equivalent to represent our skew.
Except when skew is animated by a sequence of keyframes. What we need is the
keyframe to linear interpolate our definition of skew and then calculate the
matrix from the skew. If we linear interpolate current CSS skew, we are
adding a non linear scaling of (cos(y), cos(x)). In order to resolve this we
will be forced to emulate this with additional keyframes to remove the non
linearity.

Dan
dclark@adobe.com

 


On 1/18/11 4:06 PM, "Chris Marrin" <cmarrin@apple.com> wrote:

> 
> On Jan 17, 2011, at 5:13 PM, Rik Cabanier wrote:
> 
> ...
>> Ř  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.
>> The issue is also with transitions/animations.
>>  
>> Also, why would skew(x, y) have an issue of ordering? The matrix would be:
>> | 1        tan(x)   0 |
>> | tan(y) 1          0 |
>> | 0        0         1 |
>>  
>> It doesnšt seem necessary to have a separate skewx/skewy since there is
>> usually no need to concatenate skewsŠ
> 
> skewX(60deg) skewY(20deg) gives you different results than skewY(20deg)
> skewX(60deg). Which order would skew(0deg, 20deg) use? If we leave it as
> skewX() and skewY() the author can choose
> 
> -----
> ~Chris
> cmarrin@apple.com
> 
> 
> 
> 
>

Received on Wednesday, 19 January 2011 01:47:02 UTC