[css-transforms-1] Error in prose describing order of multiple transform function

[smfr]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29110:

http://www.w3.org/TR/2013/WD-css-transforms-1-20131126/#transform-rendering
states in Example 4:

| transform: translate(80px, 80px) scale(1.5, 1.5) rotate(45deg);
| }
|
| This transform moves the element by 80 pixels in both the X and Y directions,
| then scales the element by 150%, then rotates it 45° clockwise about the Z axis.

This is technically incorrect. It should read

"This transform rotates the element 45° clockwise about the Z axis, then scales the element by 150%, then moves it by 80 pixels in both the X and Y directions."

And further:

| Note that the scale and rotation operate about the center of the element,
| since the element has the default transform-origin of 50% 50%.

This is very misleading in this context, since it implies that the translation affects the transform-origin too, which it doesn't.

Similar issue in http://www.w3.org/TR/2013/WD-css-transforms-1-20131126/#transform-function-lists :
| [...] a nested set of transforms is equivalent to a single list of transform functions,
| applied from the outside in.

I'm not sure what that even means. Would "applied from the inside out" be more appropriate?
Mathematically, we're talking about the fact that for all x, we have (f o g)(x) == f(g(x)). Now, are we applying f and g "from the inside out" or "from the outside in"? Or is there a better way to put it? I feel like there should be.

[smfr]

Need to also ensure that https://www.w3.org/mid/509FCC62.5080101@mit.edu is satisfied.

[samjross]

I came here to express that this issue is causing confusion. This stackoverflow question illustrates that people are seeing the documentation and getting confused about the order of operations.

[smfr]

I think the mental ordering you use depends on whether you're used to thinking about matrix math.

<div style="translate(80px, 80px) scale(1.5, 1.5) rotate(45deg)"></div>

gives the same result as:

   <div style="transform: translate(80px, 80px)">
        <div style="transform: scale(1.5, 1.5)">
            <div style="transform: rotate(45deg)"></div>
        </div>
    </div>

and since ancestors are painted before descendants, describing this in terms of the translate being applied first makes sense. Someone designing this in a tool would first translate, then scale, then rotate.

[smfr]

Maybe, as suggested in https://lists.w3.org/Archives/Public/www-style/2011May/0633.html, the spec should talk more about how transforms affect coordinate systems, rather than coordinates.

[samjross]

@smfr when you reverse the order of transformations, it becomes quite clear which order the transformations happen in. Take a look at this jsfiddle You can explain the blue shape arguably forward and backward, but you cannot explain the orange shape with forward application of the rules.

[smfr]

How about something like this:

-This transform moves the element by 80 pixels in both the X and Y directions, then scales the element by 150%, then rotates it 45° clockwise about the Z axis. Note that the scale and rotation operate about the center of the element, since the element has the default transform-origin of ''50% 50%''.
+This transformation translates the local coordinate system by 80 pixels in both the X and Y directions, then applies a 150% scale, then a 45° clockwise rotation about the Z axis. The impact on the rendering of the element can be intepreted as an application of these transforms in reverse order: the elements is rotated, then scaled, then translated.

[smfr]

I'm lost in row-major vs. column-major and pre- vs post-multiply confusion here. I think, if we consider the matrices to be in column-major order (which is indicated by the order of arguments to matrix() and matrix3d() that "concatenate" means post-multiply.

I'm also confused by this figure in SVG: https://www.w3.org/TR/SVG/images/coords/MatrixMultiply.png where it talks about mapping from new to old coordinate systems with the column vector on the right.

[smfr]

Prose updated, but still needs mathy edits.

[dirkschulze]

@smfr IMO for pre- post-multiply we should reference the geometry spec [1] and make sure we are consistent across the spec. Do you still think we should clarify what column-major order is? IMO it is a mathy term already. Might at least partly be related to #924.

[dirkschulze]

I am adding the definition of pre-multiply, post-multiply and multiply from Geometry to CSS Transforms.

The graphics that @smfr mentions tries to explain where any point in the coordinate space of a transformed element actually would be in the elements parent coordinate space. I agree that this might not be obvious on the first view.

The same way, the nested transform section shows how any point in the coordinate space of an element can be transformed (by post-multiplying all subsequent transformations) into the coordinate space of any ancestor element.

Example 4 is example 3 now. I changed the text a little bit so that it obvious that the first sentence is explaining how the result looks like visually.

The complicated part is the part about "rendering". I think here we should do the same as SVG does and explain (maybe with formulas in a normative section) how any point in the current coordinate space can be mapped to the coordinate space of an ancestor.

The section that @smfr mentions with "inside out" should be changed to reflect what SVG says. I am going to do some edits and put it for review into the spec.

Though, post-multiplied is specified now, I need to go over the individual instances to check that the terms are used correctly. I am unsure about that currently.

[dirkschulze]

Ok, just did the math. The reverse transform list is exactly the wrong way. Should be:

1. Multiply from ancestor to descendant from left to right per transform list.
2. Multiply transform with the point.

Will do the edits tomorrow.

[dirkschulze]

Multiplication order in general should be clarified in the spec now. Leaving the issue open for now because I am considering to pull back more math from SVG 1.1.

[dirkschulze]

Did add clarification The Transform Rendering Model. Please review.