W3C home > Mailing lists > Public > public-fx@w3.org > January to March 2013

Re: [Matrix] restating the goals?

From: Rik Cabanier <cabanier@gmail.com>
Date: Thu, 21 Mar 2013 16:47:57 -0700
Message-ID: <CAGN7qDD1JSJXTquALFTcr1t88vVQkp2kjFcNdAE_8_om5azr8A@mail.gmail.com>
To: Benoit Jacob <jacob.benoit.1@gmail.com>
Cc: Dean Jackson <dino@apple.com>, "public-fx@w3.org" <public-fx@w3.org>
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
Received on Thursday, 21 March 2013 23:48:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:45 UTC