W3C home > Mailing lists > Public > www-svg@w3.org > December 2013

Re: new SVGMatrix() should return the identity matrix

From: Dirk Schulze <dschulze@adobe.com>
Date: Mon, 2 Dec 2013 15:04:35 -0800
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: Eric Seidel <eseidel@chromium.org>, www-svg <www-svg@w3.org>, Philip Rogers <pdr@chromium.org>, Stephen Chenney <schenney@chromium.org>, Erik Dahlstrom <ed@opera.com>
Message-ID: <9B4B88C1-368A-48D1-8FA8-F0B5CA1CFA13@adobe.com>

On Dec 2, 2013, at 10:32 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Sun, Dec 1, 2013 at 11:06 AM, Eric Seidel <eseidel@chromium.org> wrote:
>> I can understand the rational which may have lead to this current
>> design.  Since unlike the proposed (and now gone) CSSMatrix, SVGMatrix
>> takes floats as an argument.  If those arguments are missing,
>> presumably undefined is assumed and undefined evaluates to 0.  That's
>> definitely less magical to some set of JS ninjas than having the no
>> argument version give you the identity (at the cost of the no argument
>> version instead giving you a much less useful zero-matrix).
> 
> Yes, we want to try as much as possible to ensure that platform APIs
> work the same way as JS ones, and in general that means not doing
> argument-counting.
> 
> Since the simplest behavior for undefined (just convert it to a
> number, resulting in NaN) is useless, the second behavior of turning
> null/undefined into zero is obviously the best behavior for arbitrary
> undefined arguments.  We don't want a different behavior between
> DOMMatrix() and DOMMatrix(undefined), nor between DOMMatrix(undefined)
> and DOMMatrix(0).

I strongly disagree on this. At least without arguments, authors nearly always want to have the identity transformation matrix. That is what is currently specified[1]. Well at least it was before we used a different preprocessor. Of course, we could introduce a function called identity() which makes the matrix the identity matrix. However, this would nearly always be called by authors and seems to be a useless requirement. I even could think about support 6 or 16 value for setting the transformation function. This is actually very common anyway.

Eric, some clarifications: SVGMatrix will be ôreplaced" by DOMMatrix. DOMMatrix is designed after WebKitCSSMatrix and MSCSSMatrix. Therefore, DOMMatrix is the superset of all introduced matrices. SVGMatrix will be an alias to DOMMatrix to be backward compatible.

> 
>> I guess authors can learn to do:
>> 
>> var identity = new SVGMatrix(1, 0, 0, 1, 0, 0);
>> 
>> instead (assuming I even typed that correctly from memory?)
>> 
>> identity.scale(2);
>> 
>> in all their code.  Bleh.
> 
> We can just provide a static id() method that returns an identity
> matrix rather than a zero matrix.  DOMMatrix.id() is nearly the same
> as DOMMatrix(), but is explicit and doesn't interfere with our API
> design guidelines.
> 
> I think this is a useful thing to do.
> 
> ~TJ
> 

Greetings,
Dirk

[1] http://dev.w3.org/fxtf/geometry/#dom-dommatrix-dommatrix
Received on Monday, 2 December 2013 23:09:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:48 UTC