- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 12 Feb 2009 21:52:49 -0800
- 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', null).documentElement.namespaceURI returns the string 'undefined'. Whereas document.implementation.createDocument(null, 'tjo', null).documentElement.namespaceURI returns the null value (not the string 'null'). / Jonas
Received on Friday, 13 February 2009 05:53:25 UTC