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

On Fri, Feb 13, 2009 at 5:23 AM, Lachlan Hunt <lachlan.hunt@lachy.id.au> wrote:
>
> 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.

I'm not sure I agree with this reasoning. This also results in that
the 'foo' and 'cheesedoodles' prefixes are resolved to the default
namespace, is that really desired? I'd rather say that the code should
be written as:

function nsresolver(ns) {
 uri = {xht: "http://www.w3.org/1999/xhtml",
       svg: "http://www.w3.org/2000/svg"
       "": ""};
 return uri[ns];
}

and make undefined stringify to 'undefined'. The result then is that
unknown prefixes will resolve to 'undefined' which will match nothing,
whereas the empty prefix would be resolved to the null namespace. This
would also map nicely to if you want the default namespace to be
something other than the null namespace, simply do something like

function nsresolver(ns) {
 uri = {xht: "http://www.w3.org/1999/xhtml",
       svg: "http://www.w3.org/2000/svg"
       "": "myNamespace"};
 return uri[ns];
}

/ Jonas

Received on Wednesday, 18 February 2009 18:59:11 UTC