Re: [CSS-transforms] rotate(<angle>[, <translation-value>, <translation-value>])

Hi Rik,

On Feb 16, 2012, at 12:51 PM, Rik Cabanier wrote:

I think the user would expect to get the animated values back.

As long as there is an easy and consistent way to do the 'unmatrix', I guess it's not a big deal (Although angles>180deg will not survive)

My original question also still stands:
@keyframes myrotate{
from{ transform: none}
to { transform: rotate(45deg, 10px, 10px); }
}

Wouldn't you expect that the animation is always around (10, 10)? I admit it's an edge case that is easily worked around…
Well, the initial value would be rotate(0,0,0). Therefore no. If you want to always have the animation around (10,10) , you would need to define it in 'from'.

-Dirk


Rik

On Thu, Feb 16, 2012 at 10:13 AM, Aryeh Gregor <ayg@aryeh.name<mailto:ayg@aryeh.name>> wrote:
On Thu, Feb 16, 2012 at 12:20 PM, Chris Marrin <cmarrin@apple.com<mailto:cmarrin@apple.com>> wrote:
> But I don't think the spec requires a matrix, does it? We have an open bug
> in WebKit to do a better job of returning the original sequence of transform
> functions when possible.

getComputedStyle() returns a string of the form "matrix(...)" or
"matrix3d(...)" in all cases.  Very possibly this isn't desirable,
since it means resolved and computed values are different.  But it's
what all browsers do, quite interoperably.  (IE10 seems a bit
aggressive in returning matrix3d(), and Firefox until just a few days
ago added "px" where it shouldn't have, but that's about it.)  Is
anyone really interested in changing behavior when we already have
*four* independent interoperable implementations?