[whatwg] some areas of ambiguity in the canvas section

[Darin Adler]

A while back I did some work on WebKit's canvas implementation and I  
noticed a few things in the canvas section of Web Apps that I'd like  
to see specified so they don't end up different between implementations:

a) NAN arguments

For the graphics context functions that take floating point values, I  
think the specification should say what the expected behavior is for:

     1) NANs
     2) non-floating point values
     3) missing parameters

It's possible that (2) and (3) are really JavaScript-specific  
language issues. In WebKit's implementation, at least, the JavaScript  
binding layer turns values of the wrong type, strings that can't be  
converted into numbers, and missing parameters into NANs for  
parameters of floating point type. For interoperability, I'd like to  
see something that makes it clear what should happen in these cases,  
and I hope it's something that is the same for those three cases  
since that makes it easier to implement.

For example, should the moveTo function raise an exception if one of  
the values is NAN? If so, which exception? Or should it quietly do  
nothing?

The same question applies to setting graphics context attributes of  
floating point type.

b) excess arguments

I'd like some mention of what happens when functions are passed  
excess arguments. This is important to specify because it often  
happens by accident, and thus differences in behavior will cause  
differences in browser compatibility. My suggestion is that any  
additional parameters are ignored. And, for example, if a function is  
overloaded for 4 and 8 parameters, if you pass 7 parameters it will  
call the 4-parameter version.

c) changing width or height of canvas to the same value

I'd like the specification to mention what happens when the width  
attribute is set to a value, but it's the same value as before. The  
current text says, "If the width and height attributes are  
dynamically modified, the bitmap and any associated contexts must be  
cleared back to their initial state and reinitialised with the newly  
specified coordinate space dimensions." But it's not clear whether  
that's also true if the width attribute is re-set to the same value  
it already has. I think it should be reset, but what's important is  
that we specify one way or the other.

     -- Darin