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

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

Rik

On Thu, Feb 16, 2012 at 10:13 AM, Aryeh Gregor <ayg@aryeh.name> wrote:

> On Thu, Feb 16, 2012 at 12:20 PM, Chris Marrin <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?
>