- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 2 Dec 2013 13:32:22 -0800
- To: Eric Seidel <eseidel@chromium.org>
- Cc: www-svg <www-svg@w3.org>, Philip Rogers <pdr@chromium.org>, Stephen Chenney <schenney@chromium.org>, Erik Dahlström <ed@opera.com>
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 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
Received on Monday, 2 December 2013 21:33:08 UTC