Re: [Matrix] restating the goals?

On Thu, Mar 21, 2013 at 3:25 PM, Benoit Jacob <jacob.benoit.1@gmail.com>wrote:

> 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.
>
> What if we called it CSSMatrix?
Canvas already references CSS and this class is targeted to CSS transforms.
Browsers already implemented it with their prefix (ie WebKitCSSMatrix)


> 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
>>
>>
>>
>