Re: [Matrix] restating the goals?

A large part of the conversation in the other thread has been between
people pointing technical flaws in this spec and people pointing out
compatibility requirements with SVGMatrix or other APIs already suffering
from the same flaws. See e.g. the discussion about whether inverse() should
throw.

I posted a suggestion about how to unblock this to the public-webgl thread;
let me repost it here. Basically, I think that it would be far easier to
accept something bad but forced by legacy compatibility requirements, if
that was clearly expressed, e.g. by renaming this to DeprecatedMatrix.

Here's what I sent to public-webgl:

As long as the current badness is called SVGMatrix, I have some level of
hope/confidence that it won't spread too much outside of code really using
SVG, because using something named SVGMatrix for something that has nothing
to do with SVG would sound like a hack and raise red flags in many
developers' heads, or even, not occur to them.

But the moment you introduce a new W3C spec (even a working draft) in 2013
(so it doesn't look like old cruft) and have it called "Transformation
matrix interface" and have it expose an interface that goes by the sweet
name of "Matrix" and have existing Web-facing APIs updated to interface
with it --- suddenly the natural, default reaction to it is to assume that
it's recommended to use, that it's the blessed Matrix API of the Web.

If you renamed this Matrix interface to DeprecatedMatrix I would find it
much easier to accept that we need this because of existing sadness in SVG
or elsewhere.


Benoit



2013/3/21 Dean Jackson <dino@apple.com>

> 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.
>
> element.style.transform = "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;
>
> 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.
>
> Or, to give an example on the goals (copied from another message):
>
> Improve this code:
>
> function rotateMyObject(element, delta) {
>   var currentTransform = window.getComputedStyle(element).transform;
>   // ouch, that's a matrix string... i need to somehow convert it to an
> object i can use
>   // ... time passes
>   var currentTransformMatrix; // I've converted it to something useful now
>   // now I need to rotate it...
>   // I either use some library or do it by hand
>   // ... time passes
>   // ok... now to set the transform...
>   element.style.transform = "matrix3d(" + currentTransformMatrix.array[0]
> + ", " ......
>   // note the above will have to go through the CSS parser, etc
> }
>
> Into something as simple as this:
>
> function rotateMyObject(element, delta) {
>   element.style.transformMatrix =
> window.getComputedStyle(element).transformMatrix.rotate(delta);  // API
> completely invented here
> }
>
> Honestly, I don't really care what the solution is (Typed arrays, new
> objects, elephants...)
>
> Dean
>
>
>