From: Boris Zbarsky <bzbarsky@MIT.EDU>

Date: Thu, 18 Nov 2010 22:08:17 -0500

Message-ID: <4CE5EA21.8070106@mit.edu>

To: Brendan Kenny <bckenny@gmail.com>

CC: "www-style@w3.org" <www-style@w3.org>

Date: Thu, 18 Nov 2010 22:08:17 -0500

Message-ID: <4CE5EA21.8070106@mit.edu>

To: Brendan Kenny <bckenny@gmail.com>

CC: "www-style@w3.org" <www-style@w3.org>

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. -BorisReceived on Friday, 19 November 2010 03:08:51 UTC

*
This archive was generated by hypermail 2.3.1
: Wednesday, 7 January 2015 16:28:19 UTC
*