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

On Wed, Nov 17, 2010 at 6:18 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 11/17/10 8:32 PM, Brendan Kenny wrote:
>>
>> I just mean the matrix is a manipulation of a space, which must have
>> units because you are specifying points to be transformed using them.
>
> Why?
>
> In particular, thinking of affine transforms as operations on P^2 involves
> thinking of your 2-element vectors as vectors in homogeneous coordinates.
>  The particular way you do that defines what your matrix means, right?
>
> And in particular, there's no particular reason that the different
> coordinate axes in the homogenous coordinate space need to have the same
> units.  In practice, you could define that they're all lengths and that all
> 2-element vectors map to the plane at z = 1px, but that's an arbitrary
> choice.  You could just as easily define the plane as mapping to z=2px,
> z=1em, or as mapping to z=1 and require that the corresponding matrix
> entries have dimensionality of length.  For purposes of using homogeneous
> coordinates, this really doesn't matter as long as you're consistent.

This is the basis of my comments, but you state it more clearly. In
terms of homogeneous coordinates, the two approaches are different
only in which way a multiply is associated; it's not a question of
purity and contentment, it's just a question of convenience and
intuition for authors, as you say.

> The only question is what will be most convenient and intuitive for authors.
>  How many authors are familiar with homogeneous coordinates on P^2 in the
> first place?  How many will think of this entirely as transformations on the
> plane?  For the latter, having a translation vector that you can specify as
> an actual translation with CSS units is very useful, I think.

Absolutely, but I think in almost all cases the translate function is
a better option for that. 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.

That's the benefit of the convention of choosing w=1px (or whatever
unit the other coordinates are in): 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), 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>. Using the transform function _list_ lets the
browser do this for the author at a more appropriate time, so it seems
like that use case should rely on the translate function.

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

>> As I said though, it's also typical to think of an affine transform as
>>
>> (linear transform)*point + (translation vector)
>>
>> in which case the translation vector has to have units. I just think
>> that if an author is using the matrix function (instead of the
>> translate function), they are more likely thinking in the former way,
>> not the latter.
>
> I would be pretty surprised by that, actually.  I would welcome data on
> whether typical authors are actually familiar with projective geometry,
> though.

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.

> -Boris
>
> P.S.  Note that I fully expect most uses for the matrix function to come
> from things like reading computed values out of transitioning or animating
> elements, or from some sort of script-generated stuff; I don't see anyone
> hand-authoring matrix().

Received on Friday, 19 November 2010 02:37:22 UTC