Re: [selectors-api] Stringifying undefined (was: Call for Consensus - Selectors API to Candidate Rec)

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