Chris Jones [:cjones] inactive; ni?/f?/r? if you need me Reporter
	Description • 13 years ago

Cameron pointed out http://dev.w3.org/2006/webapi/WebIDL/#idl-sequence today, which forbids JS arrays as attributes.  mozCurrentTransform, mozCurrentTransformInverse, and mozDash are all JS-array attributes.  Whups!

The simplest fix here is probably to make explicit get/set functions.  I would rather not add an interface for the canvas transform or dash objects.

This needs to be fixed (and pdf.js!) before we pitch these for standardization.

	Chris Jones [:cjones] inactive; ni?/f?/r? if you need me Reporter
	Comment 1 • 13 years ago

Howdy folks: these new canvas interfaces have gone too long without being proposed to whatwg.  I started to write the proposal today, but I forgot about this bug.  But question:

for what's currently implemented in Gecko as

  attribute jsval fooArray;

where getting |fooArray| returns a freshly-allocated array, is there a better pattern for fixing this than

  jsval getFooArray();
  void setFoorArray(jsval);

?  That seems ugly to me, but definitely superior to defining a FooArray interface with a single instance as the mutable property |fooArray|.

	Boris Zbarsky [:bzbarsky]
	Comment 2 • 13 years ago

Yeah, if webidl won't allow array attributes, then having a getter and setter seems like the way to go....

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 3 • 13 years ago

Given we've already got setTransform, what if we just added a getTransform that returns an SVGMatrix (DOMSVGMatrix in Gecko)?

SVGMatrix has an inverse() method that returns the inverse so a separate getTransformInverse is probably not necessary.

Do we set mozCurrentTransformInverse? If so, I'd just add a setTransform overload that takes an SVGMatrix and call setTransform(matrix.inverse()).

It might also make sense to have an SVGMatrix constructor that takes six float parameters.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 4 • 13 years ago

I guess I'm saying that using SVGMatrix instead of an array seems like a good solution, and the fact that it has an inverse() method means we probably don't need separate canvas methods for inverses.

	Chris Jones [:cjones] inactive; ni?/f?/r? if you need me Reporter
	Comment 5 • 13 years ago

It seems somewhat weird for canvas to use basic SVG datatypes.  I suspect that will be a bikeshedfest in standards bodies.

Doesn't that also incompatibly change the definition of setTransform()?  Or do you have a magic-sauce API in mind that does the right thing with either variant.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 6 • 13 years ago

(In reply to Chris Jones [:cjones] [:warhammer] from comment #5)
> It seems somewhat weird for canvas to use basic SVG datatypes.  I suspect
> that will be a bikeshedfest in standards bodies.

I don't think so. SVGMatrix already exists, the only question is whether to use it here or not, and I can't see the SVG WG objecting to that.

> Doesn't that also incompatibly change the definition of setTransform()?  Or
> do you have a magic-sauce API in mind that does the right thing with either
> variant.

I think we can overload setTransform here.

	Chris Jones [:cjones] inactive; ni?/f?/r? if you need me Reporter
	Comment 7 • 13 years ago

Proposals sent off to whatwg

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-November/033744.html
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-November/033745.html

Will do follow-up cleanups here when those stabilize.

	Cameron McCormack (:heycam)
	Comment 8 • 13 years ago

BTW, we discussed during the FX taskforce meeting this week (the joint CSS/SVG group) merging SVGMatrix and CSSMatrix at some point soon (they are mostly compatible).  Dean Jackson is going to write up a proposal for doing so, but I'm not sure what the timeframe is there.  Either way, I think using SVGMatrix for currentTransform is fine.