I never seem to be able to discourage people from dragging the W3C into specialist topics that are outside its area of expertise. Let me try again.
Objection #1: The skew* methods are out of place there, because, contrary to the rest, they are not geometric transformations, they are just arithmetic on matrix coefficients whose geometric impact depends entirely on the choice of a coordinate system. I'm afraid of leaving them there will propagate widespread confusion about "skews" --- see e.g. the authors of http://dev.w3.org/csswg/css-transforms/#matrix-interpolation who seemed to think that decomposing a matrix into a product of things including a skew would have geometric significance, leading to clearly unwanted behavior as demonstrated in http://people.mozilla.org/~bjacob/transform-animation-not-covariant.html Objection #2: This DOMMatrix interface tries to be simultaneously a 4x4 matrices representing projective 3D transformations, and about 2x3 matrices representing affine 2D transformations; this mode switch corresponds to the is2D() getter. I have a long list of objections to this mode switch: - I believe that, being based on exact floating point comparisons, it is going to be fragile. For example, people will assert that !is2D() when they expect a 3D transformation, and that will intermittently fail when for whatever reason their 3D matrix is going to be exactly 2D. - I believe that these two classes of transformations (projective 3D and affine 2D) should be separate classes entirely, that that will make the API simpler and more efficiently implementable and that forcing authors to think about that choice more explicitly is doing them a favor. - I believe that that feature set, with this choice of two classes of transformations (projective 3D and affine 2D), is arbitrary and inconsistent. Why not support affine 3D or projective 2D, for instance? Objection #3: I dislike the way that this API exposes multiplication order. It's not obvious enough which of A.multiply(B) and A.multiplyBy(B) is doing A=A*B and which is doing A=B*A. Objection #4: By exposing a inverse() method but no solve() method, this API will encourage people who have to solve linear systems to do so by doing matrix.inverse().transformPoint(...), which is inefficient and can be numerically unstable. But then of course once we open the pandora box of exposing solvers, the API grows a lot more. My point is not to suggest to grow the API more. My point is to discourage you and the W3C from getting into the matrix API design business. Matrix APIs are bound to either grow big or be useless. I believe that the only appropriate Matrix interface at the Web API level is a plain storage class, with minimal getters (basically a thin wrapper around a typed array without any nontrivial arithmetic built in). Benoit 2014-05-30 20:02 GMT-04:00 Rik Cabanier <caban...@gmail.com>: > Primary eng emails > caban...@adobe.com, dschu...@adobe.com > > *Proposal* > *http://dev.w3.org/fxtf/geometry/#DOMMatrix > <http://dev.w3.org/fxtf/geometry/#DOMMatrix>* > > *Summary* > Expose new global objects named 'DOMMatrix' and 'DOMMatrixReadOnly' that > offer a matrix abstraction. > > *Motivation* > The DOMMatrix and DOMMatrixReadOnly interfaces represent a mathematical > matrix with the purpose of describing transformations in a graphical > context. The following sections describe the details of the interface. > The DOMMatrix and DOMMatrixReadOnly interfaces replace the SVGMatrix > interface from SVG. > > In addition, DOMMatrix will be part of CSSOM where it will simplify getting > and setting CSS transforms. > > *Mozilla bug* > https://bugzilla.mozilla.org/show_bug.cgi?id=1018497 > I will implement this behind the flag: layout.css.DOMMatrix > > *Concerns* > None. > Mozilla already implemented DOMPoint and DOMQuad > > *Compatibility Risk* > Blink: unknown > WebKit: in development [1] > Internet Explorer: No public signals > Web developers: unknown > > 1: https://bugs.webkit.org/show_bug.cgi?id=110001 > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
