Re: [Matrix] restating the goals?

On Thu, Mar 21, 2013 at 3:01 PM, Dean Jackson <> wrote:
> Since the discussion has exploded to the point of being difficult to follow, with a number of people expressing strong objections to the proposal, I was wondering if it was worth stopping to decide if we can at least agree on the goals at a very high level.
> - Have some way to express a CSS (and SVG) transformation in JS that is better than the current solution of the CSS OM (uses long strings which need to be parsed in/out)
> - Do this in a way that doesn't break existing content (i.e. we can't change SVGMatrix, as much as we'd love to). This could mean a completely new API.
> - Help developers do the common things with simple, performant code.
> When I look at the above, I wonder if the problem comes from this assuming to be a Matrix API. It's really just an API for the native transformations that exist in the platform. Is it possible to think of it as a way to accomplish a transformation in JS that corresponds to what you'd typically use CSS for? e.g.
> = "translate3d(10px, 10px, 10px) rotateY(1rad) scale(2)";
> Should be able to be expressed something like this:
> var t = new Transform();
> t.translate3d(10, 10, 10);
> t.rotateY(1);
> t.scale(2);
> element.transformMatrix = t;

I've so far been treating it exactly like this, but thank you for the
refocusing, as I suspect a good part of the conversation was spawned
by confusion over this point.

> This would mean all the inverse/decompose/etc stuff gets dropped, which is fine with me. Again, the target is our transformation implementation, not a general matrix library. If the transformMatrix property, or whatever it is called, accepted a Float32Array, then people could use whatever matrix library they want.

I think it's reasonable to push *just a little* bit further, so that
people can use this class, in JS, to accomplish the same things as CSS
transforms in an easy way (rather than being focused purely on
literally manipulating CSS transforms).  As such, inverting is still
useful (but there's definitely no reason to throw), and decomposition
*might* be (given that CSS transforms transition as a decomposed
matrix when they mismatch too hard, so if you want similar behavior in
JS, exposing this could be useful).

I totally agree with anything that accepts a Matrix also accepting a
properly-sized TypedArray.


Received on Thursday, 21 March 2013 22:14:31 UTC