Open Bug 683051 Opened 9 years ago Updated 6 years ago
Make new moz* canvas attributes Web
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.
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|.
Yeah, if webidl won't allow array attributes, then having a getter and setter seems like the way to go....
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.
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.
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.
(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.
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.
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.
You need to log in before you can comment on or make changes to this bug.