Bug 38953 – CSSMatrix value attributes (m11-m44) should be transposed (?)

• Status: UNCONFIRMED
• Component: CSS

[Brendan Kenny]

With Bug 38337 fixed, WebKitCSSMatrix is acting like a column-major matrix under multiplication. In that notation, the translation elements should be in the right-hand column, e.g. the x translation component would be in row 1, column 4 of the transformation matrix.

In recent nightlies (post http://trac.webkit.org/changeset/58584), the notation hasn't changed, still implying a row-major matrix:

var matrix = (new WebKitCSSMatrix()).translate(5);
matrix.m14; // 0
matrix.m41; // 5

The current 3D transform spec and WebKitCSSMatrix documentation give m<row><column>. The current preamble to TransformationMatrix.cpp makes this seem like a WON'T FIX issue -- that it just has to made clear that they are m<column><row> -- but maybe this is just an implementation note and not about exposing to Javascript.

[Chris Marrin]

Currently the implementation uses m<column><row>. The spec disagrees with this by saying "For instance m12 represents the value in the 2nd column of the first row" which implies m<row><column>. I believe m<column><row> is the justifiable order. Since this is a column major matrix, it seems reasonable that the column number comes first.

So I think we should leave the implementation as it is and just change the spec. Agreed?

[Brendan Kenny]

That makes perfect sense from the array/storage perspective. My only hesitation would be that in math and graphics texts it's the norm to have "column major" matrices (with vectors as columns and multiplied on the right) but refer to entries in the matrix as m_i,j where i is the row and j is the column.

That said, it's just notation. I'm fine either way as long as it's in the spec so other implementations will (some day) follow the same convention.

[Brendan Kenny]

FWIW another option is to avoid ambiguity and list the values as m0, m1, m2, ..., m15 (or m1 through m16) down each column in the style of opengl. It would also match the order of the "matrix3d(...)" transformation function.

[Ahmad Saleem]

@Matt - is it still applicable?