- From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Date: Fri, 13 Feb 2009 14:23:08 +0100
- To: WebApps WG <public-webapps@w3.org>
- Cc: Rune Lillesveen <rune@opera.com>
Cameron McCormack wrote: > Boris Zbarsky: >> On John Resig's tests in particular, every single failure in Gecko is >> due to a violation of this part of the API: >> >> Undefined=Empty >> >> This is using a WebIDL syntax from a working draft that we don't >> implement yet, and the current JavaScript DOM binding in Gecko always >> converts undefined in parameters to the string "undefined". > > I started (but did not finish yet) looking at all the uses of DOMString > in various web specs to see what the default behaviour should be for > both [Null] and [Undefined]. So far, it seems that stringifying > undefined to "undefined" is much more widely implemented: > > http://mcc.id.au/2009/01/string-handling/string-handling > > If that does end up being the more common behaviour, I’ll change the > default in Web IDL to be to stringify to "undefined" unless overridden, > and I would suggest Selectors API to use that behaviour, too. The following are reasons we ended up with the spec defining to stringify it to the empty string instead of "undefined". Initially, the spec didn't define any explicit behaviour, implicitly relying on whatever the default was. When the first few implementations were tested, there was a lack of interoperability between them. Each implementation stringified null and undefined to a different combintation of "null", "undefined" or empty string. So it was decided that this needed to be resolved by making the issue more explicit. At the time, we also had the NSResolver in place, and there were use cases that required return values of null, undefined and "" to all be treated as the empty string, meaning no namespace. This was so that JS authors didn't have to explicitly define the default namespace. e.g. function nsresolver(ns) { uri = {xht: "http://www.w3.org/1999/xhtml", svg: "http://www.w3.org/2000/svg"} return uri[ns]; } For resolving the default namespace, this would return undefined. And there were similar cases where it made sense for null or "" to be returned instead. This meant that null and undefined had to be stringified to "" instead of "null" and "undefined", respectively. In order to make the handling of null and undefined consistent throughout the API, it was also decided that passing null and undefined as the selector parameter should also stringify to the empty string. This also has the nice authoring benefit of throwing an exception when an author accidentally passes a undefined or null variable, which would most likely be a mistake. Having the exception would help with debugging the problem, whereas simply treating it as "null" or "undefined" strings would just fail to match any elements (unless there happened to be <null> and <undefined> elements in the document, which is rare) But now that the NSResolver has been removed, the consistency reasoning no longer really applies. The benefit to debugging still sort-of does, but it is certainly debatable. There are 2 problems with changing the spec now to use the default behaviour instead of defining the empty string: 1. We are getting ready to go to PR. It would be rather annoying to have to hold up this for much longer. Although I generally don't like letting bureaucratic issues like this get in the way of doing things, if it can be avoided. 2. We already have 2 implementations, Opera and WebKit, that implement the behaviour as defined, and Mozilla does it for null. IE8 still stringifies to "null" and "undefined", respectively. 3. If we do this for undefined, should we also do it for null? (i.e. undefied -> "undefined", null -> "null" instead of "") If we could do the change quickly and have all browsers commit to making this change relatively quickly, preferably before shipping, and then demonstrate interoperability, then it is theoretically possible. But I don't know. I've CC'd Rune, one of our developers, who can comment on whether or not we could or would make the change. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Received on Friday, 13 February 2009 13:23:48 UTC