Re: [css3-2d-transforms] animation of skewX(), skewY(), skew()

On Wed, Dec 2, 2009 at 6:27 PM, Brendan Kenny <bckenny@gmail.com> wrote:
> On Wed, Dec 2, 2009 at 6:15 PM, Dean Jackson <dino@apple.com> wrote:
>>>
>>> David's proposal would make a non-linear animation appear linear. The
>>> top left corner of your skewed box, for instance, would animate
>>> linearly (with respect to the transition function) from its skewed
>>> position back to 0, matching the rectangle above.
>>
>> Here's a testcase that shows what I mean in WebKit.
>>
>> [[[
>>
>> <style>
>>
>> div {
>> background-color: red;
>> position: relative;
>> width: 100px;
>> height: 100px;
>> }
>>
>> #a {
>> -webkit-animation: move1 2s infinite linear alternate;
>> }
>>
>> #b {
>> background-color:blue;
>> -webkit-animation: move2 2s infinite linear alternate;
>> -webkit-transform-origin: bottom left;
>> }
>>
>> @-webkit-keyframes move1 {
>> from { -webkit-transform: translateX(100px); }
>> to { -webkit-transform: translateX(0); }
>> }
>>
>> @-webkit-keyframes move2 {
>> from { -webkit-transform: skewX(-45deg); }
>> to { -webkit-transform: skewX(0); }
>> }
>>
>> </style>
>>
>> <div id=a></div>
>> <div id=b></div>
>>
>> ]]]
>>
>>>
>>> This is probably more useful, but my point above was that this is
>>> typically referred to as a shear, not the skew (specified with an
>>> angle) that the user asked for.
>
> Changing move2 to the following will give you the equivalent of
> David's proposal (what could be considered shearX(-1)):
>
> @-webkit-keyframes move2 {
> from { -webkit-transform: matrix(1,0,-1,1,0,0); }
> to { -webkit-transform: matrix(1,0,0,1,0,0); }
> }

I was thinking about the changed test case I gave here and realized it
shouldn't work differently at all (and maybe I'm catching up to why
this thread was started in the first place).

'matrix(1,0,-1,1,0,0)' is equivalent to 'skewX(-45deg)' and so
*should* animate the same, but the matrix decomposition algorithm in
section 7 of the current spec calls "skew" what should be called
"shear." Since webkit currently transitions using this method to
decompose, interpolates values linearly, and then recomposes with a
matching algorithm, it currently animates "in the space of the tangent
of the angles" for transforms specified by a matrix and animates "in
the space of angles" for transforms specified by a list of transform
functions.

As specified, it defaults to "matrix mode" if the transforms are
mixed, which can be seen by using Dean's test case with the following:

@-webkit-keyframes move2 {
from { -webkit-transform: skew(-45deg); }
to { -webkit-transform: matrix(1,0,0,1,0,0); }
}

I should probably just file a webkit bug here, but for the current draft
* if skew() is kept and animation is kept in angle-space (as is
specified in section 6, sub-sub-point 1), section 6 and 7 need to be
updated to correctly state that a shear is being calculated in the
unmatrix code and that it should be interpolated through atan()
(itself problematic).

* if skew() is kept and animation is moved to linear-space, obviously
the animation rules would need to be updated and it should be clear
that intermediate transition states will not correspond to what might
be the expected "numerically interpolated" angle.

* if shear() is added, animation would more naturally take place
linearly, but a combination of skew()s and shear()s animated using the
"Otherwise" clause in section 6 can only be animated one way or the
other, as there is no way to determine which is which once they are
concatenated.

As I said before, I agree that it's more natural to animate
"linearly." Moreover, directly exposing tan() in a user-accessible
function really just invites problems. For extremely skew()ed elements
the angle parameter starts to get rather long, to say nothing of
transitions like:

@-webkit-keyframes move2 {
from { -webkit-transform: skew(180deg); }
to { -webkit-transform: skew(0deg); }
}

shear() solves a lot of these problems. However, I know skew() comes
from the SVG spec, so I don't know where that leaves things.

Received on Friday, 11 December 2009 07:08:56 UTC