# Re: [css3-2d-transforms] Interop: matrix() values e,f <number> or <length>

```On 11/18/10 9:36 PM, Brendan Kenny wrote:
> Absolutely, but I think in almost all cases the translate function is
> a better option for that.

Sure, but various CSSOM apis (e.g. computed style on a transitioning
element) will spit out matrix().

> Most matrix transform functions will
> probably be generated from a calculation of some sort, and it's not
> clear to me how one would even calculate, for instance, a rotation
> applied to a translation specified in one of the available units
> without knowing the scale factor between the two at calculation time.

I'm not sure what the issue there is, actually...  Applying a rotation
to a translation Just Works.  Here's an example:

(  cos(x)  -sin(x)  0 ) ( 1   0   2em )
(  sin(x)  cos(x)   0 ) ( 0   1   3ex )
(   0        0      1 ) ( 0   0    1  )

That's applying a rotation by x to a (2em, 3ex) translation.  Just doing
out the multiplication gives us:

( cos(x) -sin(x)  2em*cos(x) - 3ex*sin(x) )
( sin(x)  cos(x)  2em*sin(x) + 3ex*cos(x) )
(   0        0               1            )

You don't need to know any scale factors...  You _do_ need to be able to
always in the same unit, you can make the unit implicit in calculations
like this, and then the addition is easy.  If you do want to support
arbitrary units all through your calculation, you need to have
addition-with-unit and do unit conversions as needed (not rocket science
either, actually, since you can use the CSSOM to do unit conversions for
you).

> That's the benefit of the convention of choosing w=1px (or whatever
> unit the other coordinates are in)

The "other coordinates" aren't in any particular units.  That's the
while point!

And in particular, the transformation matrix is never applied to
unitless anything, conceptually.  It's applied to lengths (or more
precisely to pairs of lengths).

> as long as there is a uniform scale between each unit of measurement, the values in the matrix can
> stay exactly the same. If the units are non-uniform along different
> axes (e.g. percentages in a non-square element)

No one is talking about percentages.  The proposed syntax is a CSS
length, which is a number followed by a CSS unit (px, em, ex, cm, in,
mm, etc).  Percentages aren't CSS units.

> any user trying to calculate a concatenated transform would need to
figure out the
> non-uniform scale from pixels (or ems or whatever) to the non-uniform
> space and apply the scaling manually...or every value in matrix()
> needs to be a<length>.

I don't follow this last part.  How can it possibly make sense to make
the linear part of the matrix have length units, when it's being
multiplied by lengths (whereas the translation part is being _added_ to
lengths)?  Unit analysis failure, sorry.  ;)

> It is the end of the day and CSS units aren't my forte, so please
> correct me if I'm missing something.

I think you are, but I can't quite pin down what it is....

> I'm sure such authors will be a tiny minority. On the other hand, if
> anyone copies and pastes a matrix from any kind of graphics text, it's
> all but certain that units won't be included.

True; all such texts assume a predefined coordinate system.  CSS doesn't
have one.

-Boris
```

Received on Friday, 19 November 2010 03:08:51 UTC