W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: Handling too few arguments in method calls

From: Cameron McCormack <cam@mcc.id.au>
Date: Fri, 26 Jun 2009 11:07:07 +1000
To: Aaron Boodman <aa@google.com>
Cc: public-webapps@w3.org
Message-ID: <20090626010707.GC8712@arc.mcc.id.au>
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

> 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

Cameron McCormack ≝ http://mcc.id.au/
Received on Friday, 26 June 2009 01:07:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:54 UTC