Aaron Boodman:
> But there is also an issue of legacy code. I brought this issue up in
> a webkit bug awhile ago, and one concern from the webkit developers
> was that introducing an exception would almost certainly "break"
> sites. My opinion is that those sites are almost certainly already
> broken.
I would worry about that, too. The amount of brokenness it experiences
because of a change to using exceptions could be far greater than it is
currently.
> As a simple example, consider the setAttribute() method. Both
> arguments are required, but in WebKit, if you don't pass either value
> it is coerced to string. So if we take a simple attribute like
> "title":
>
> someElement.setAttribute("title"); // throws in Firefox, sets title
> to "undefined' in WebKit
>
> Philosophically, I want to say that pages that are passing too few
> arguments to DOM APIs are already broken, just in less obvious ways.
> Breaking in more obvious ways would be better.
So we could change this to be:
interface Element {
void setAttribute(in DOMString name, [Optional] in DOMString value);
…
};
to keep setAttribute("title") working, but I think making the
optionalness of the argument to other language bindings in this case
isn’t a good idea. Also in this particular case it doesn’t seem like it
would be needed for web compatibility, if Firefox and Opera can get away
with throwing here.
If there’s a real need to allow some arguments on particular operations
in ECMAScript to be optional, and coerced from an undefined value, then
we can introduce an ECMAScript-specific extended attribute that permits
this. But in general I agree that it would be better if we could remain
strict.
--
Cameron McCormack ≝ http://mcc.id.au/
