- 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
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/
Received on Friday, 26 June 2009 01:07:47 UTC