W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

Re: Call for Consensus - Selectors API to Candidate Rec

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 12 Feb 2009 21:52:49 -0800
Message-ID: <63df84f0902122152s7a494b74ra033401f9f9cb20a@mail.gmail.com>
To: WebApps WG <public-webapps@w3.org>

On Thu, Feb 12, 2009 at 4:14 PM, Cameron McCormack <cam@mcc.id.au> 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".
>> If this part of WebIDL is stable, we can go ahead and implement it, but
>> I see no obvious evidence of that from the WebIDL working draft.
> 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

Still not sure that I understand that chart. As I read it, firefox for
the namespaceURI parameter of DOMImplementation.createDocument treats
undefined as null (hence the 'N' in the second column). However I
would have really expected us to treat undefined as the string
'undefined'. I just did a simple test, but it seems to confirm this:

document.implementation.createDocument(undefined, 'tjo',

returns the string 'undefined'. Whereas

document.implementation.createDocument(null, 'tjo',

returns the null value (not the string 'null').

/ Jonas
Received on Friday, 13 February 2009 05:53:25 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:14 UTC