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

On 11/19/10 1:26 PM, Chris Marrin wrote:
>> To clarify, what you're saying is "The syntax should have no units, but the semantics should be that the number is treated as if it had units of px".  Or something.  The current 2d transform spec actually doesn't define what the heck the matrix() syntax means for nonzero e and f, except by linking to SVG.  In SVG there is in fact a privileged unit: user units; so in SVG assuming that e and f are given in user units makes sense. In fact, in SVG you always have to use user units in all the transform stuff (including in translate()).  You can't use other units even if you wanted to.
>
> I'm not sure what "user units" are in SVG.

SVG has this concept of a current coordinate system.  This is just a 
mathematical coordinate system on the plane; it has an origin, an x 
axis, and a y axis (which may not even be at right angles to each other 
if angles are measured in the original coordinate system of the 
document, but are presumably defined to be orthogonal in the current 
coordinate system itself; I don't think the SVG spec actually makes this 
clear).  A distance of "1" along the x axis or along the "y" axis is 
whatever it is and may not actually be the same distance in practice. 
Think an actual pair of axes drawn on top of the page.

The values of the transform attribute in SVG are values in this 
coordinate system.  So for example, the translation is in user units. 
You _cannot_ translate by "1in", say.  You can only translate by some 
multiple of whatever the current coordinate system's units are.

Further, what the transform describes is just how to set up a new 
coordinate system, and nothing more.  So something like:

   transform="scale(0.5) translate(100, 100)"

means "Set up a new coordinate system, whose center is at (100,100) in 
the old coordinate system and whose x-unit is half the x-unit of the old 
coordinate system and y-unit is half the y-unit of the old coordinate 
system".  This new coordinate system then becomes the current coordinate 
system.  Thus for every element there is a current coordinate system 
active when the element is being rendered.  In addition to transforms, 
viewBox attributes can also affect the current coordinate system.

Lengths in SVG are then defined by reference to the current coordinate 
system when the length is being resolved.  For example, "1px" is defined 
as 1 coordinate system unit in the current coordinate system.

It actually does all end up working out.  When you paint, you paint on 
your typical coordinate grid, and then that grid is transformed into 
your actual user coordinate system (using the CTM), taking your drawing 
with itself, etc.

> But yes, I believe units should not be allowed in the matrix() function syntax. Certainly values being produced in the matrix operations have _some_ units, I think we just have to agree what those units are.

OK, what are they?  And again, I think allowing units in translate() but 
not in matrix() is really weird.  For one thing, I'm failing to come up 
with a self-consistent model of how transforms work in that world...

> This brings up a glaring problem with CSSMatrix. When you construct one, it is not associated with any element, so you can't use an element's style to convert units. Today, when we encounter the above CSSMatrix constructor I believe we just convert 50% to a value of 50 or something equally arbitrary. We should probably amend CSSMatrix to allow an element to be passed to the constructor. This brings up the next sticky issue of what happens when, for instance, the client size of the element changes. Do values in the CSSMatrix change? Madness!

Agreed.  Why are we allowing percentages here again?  ;)

-Boris

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