On Fri, May 30, 2014 at 9:00 PM, Benoit Jacob <jacob.benoi...@gmail.com> wrote:
> 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 > Many people think that the skew* methods were a mistake. However, DOMMatrix is meant as a drop-in replacement for SVGMatrix which unfortunately has these methods: http://www.w3.org/TR/SVG11/coords.html#InterfaceSVGMatrix I would note though that skewing is very popular among animators so I would object to their removal. > 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? > These objections sound valid. However WebKit, Blink and Microsoft already expose CSSMatrix that combines a 4x4 and 2x3 matrix: https://developer.apple.com/library/safari/documentation/AudioVideo/Reference/WebKitCSSMatrixClassReference/WebKitCSSMatrix/WebKitCSSMatrix.html and it is used extensively by authors. The spec is standardizing that existing class so we can remove the prefix. > 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. > The "by" methods do the transformation in-place. In this case, both are A = A * B Maybe you're thinking of preMultiply? > 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). > We already went over this at length about a year ago. Dirk's been asking for feedback on this interface on www-style and public-fx so can you raise your concerns there? Just keep in mind that we have to support the SVGMatrix and CSSMatrix interfaces. > 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
