Re: [Matrix] restating the goals?

Actually, I think we already reach a common ground in this discussion. And we are more discussing details of certain functionalities. And some data to current implementations may help:

I checked the behavior on WebKitCSSMatrix and MSCSSMatrix under certain conditions:

* Attributes do take unrestricted floats:

var m = new WebKitCSSMatrix() / MSCSSMatrix();
m.a = Math.NaN;

Does work in both implementations.

* m.scale(Math.NaN) does work

Returns Math.NaN on the multiplied elements of the matrix.

* m.inverse()

on WebKit returns a Matrix with NaN elements
on MS throws exception

And I checked implementations of SVGMatrix:

* Attributes do take unrestricted floats:

var m = svg.createSVGMatrix();
m.a = Math.NaN;

Does work in all implementations (IE, WebKit, Opera) but FF.

* m.scale(Math.NaN)

Does work in all implementations (IE, WebKit, Opera) but FF.

* m.inverse()

Does work if the matrix is not singular OR if the elements are NaN for Opera and WebKit. Otherwise throws.
Does not work if matrix is singular or if matrix has an element with NaN for IE and FF.

Actually, the behavior of SVGMatrix.inverse() is not consistently implemented enough for authors to rely on it. We actually might be able to break backward compatibility to SVG 1.1.


On Mar 21, 2013, at 3:01 PM, Dean Jackson <dino@apple.com> 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.
> 
> 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 proposal goes more to Transform and TransformList, which is different from Matrix but very valid as well.

Greetings,
Dirk

> 
> 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 22:30:18 UTC