[whatwg] some areas of ambiguity in the canvas section
Darin Adler
darin at apple.com
Sat May 5 08:37:59 PDT 2007
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
More information about the whatwg
mailing list