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 
add things like 2em*cos(x) and 3ex*sin(x).  If all your translations are 
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