[WebIDL] Passing null and undefined to DOMString things

I’ve made DOMString an intrinsic type in the IDL now (to avoid the
“polite fiction”, as Maciej put it ☺).  I’ve also replaced [NoNull]
with [Null] and [Undefined], which can be used to specify how null and
undefined are treated when passed as an operation argument or assigned
to an attribute.

  http://dev.w3.org/cvsweb/~checkout~/2006/webapi/Binding4DOM/Overview.html?rev=1.73&content-type=text/html;%20charset=utf-8#idl-DOMString
  http://dev.w3.org/cvsweb/~checkout~/2006/webapi/Binding4DOM/Overview.html?rev=1.73&content-type=text/html;%20charset=utf-8#Null
  http://dev.w3.org/cvsweb/~checkout~/2006/webapi/Binding4DOM/Overview.html?rev=1.73&content-type=text/html;%20charset=utf-8#Undefined


Cameron McCormack:
> > [treating null as ""]

Maciej Stachowiak:
> It needs to for many standard DOM methods. Most core DOM methods that  
> take namespaces treat a null namespaceURI or prefix parameter the same  
> as the empty string, not the same as the string "null".

I still think that for namespace URIs, the null value is what represents
no namespace, while "" can just be used as an alias for this.  This is
what DOM 3 Core says:

  Applications should use the value null as the namespaceURI  parameter
  for methods if they wish to have no namespace. In programming
  languages where empty strings can be differentiated from null, empty
  strings, when given as a namespace URI, are converted to null. This is
  true even though the DOM does no lexical checking of URIs.
   — http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#Namespaces-Considerations


Maciej Stachowiak:
> > I think DOM properties (and sometimes methods and function arguments) 
> > vary on this. Some use the raw ECMAScript ToString algorithm. Others 
> > additionally map the null value to the empty string instead of "null". 
> > Still others map the undefined value to "undefined". Some do both. I am 
> > pretty sure that for compatibility reasons you can't just do the same 
> > for each, so we may as well just define and test the legacy behavior for 
> > each one. Whatever is most common can be the default, and others can be 
> > marked up in the IDL appropriately.

Ian Hickson:
> For both DOMString attributes and DOMString arguments, we have the 
> following ways to handle null and undefined:
…
> I think what we need is for WebIDL to have annotations for these cases, 
> which can be prefixed in front of any occurance of "DOMString" in any IDL 
> block, and then we can work down the APIs and check each DOMString 
> occurance and work out which the UAs are doing. Say:
> 
>    [Null=Null, Undefined=Null]
>    [Null=Null, Undefined=Empty]
>    [Null=Empty, Undefined=Empty]
>    [Null=Null, Undefined=String]
>    [Null=Empty, Undefined=String]
>    [Null=String, Undefined=String]
> 
> ...so that we can do, e.g.:
> 
>    Window open([Null=String, Undefined=String] in DOMString url,
>                [Null=String, Undefined=Empty] in DOMString name,
>                [Null=Empty, Undefined=Empty] in DOMString features);
> 
> ...or whatever is appropriate.

I have replaced [NoNull] with [Null] and [Undefined].  The default
behaviour for both null and undefined is to stringify, since that seemed
to be most common in some (not completely extensive) tests that I did:

  http://mcc.id.au/2007/05/binding-tests/tests/test.pl?id=061
  http://mcc.id.au/2007/05/binding-tests/tests/test.pl?id=062

So now you can specify [Null=Null], [Null=Empty], [Undefined=Null],
[Undefined=Empty].  You cannot specify stringification though; that’s
just the behaviour if the extended attribute is omitted.

Although stringifying null to "null" is more common than passing it
through, I sort of feel like [Null=Null] should be the default, since I
still think of null being one of the values in the DOMString type.  But
at least as it is now, the two extended attributes are consistent (they
both take either Null or Empty).


Cameron McCormack:
> > Should the Bindings spec require that the constructor return an object
> > that implements that interface?

Anne van Kesteren:
> That would make sense I think.

That’s done now.

> Also, when will Web IDL define all the DOMString versus null versus  
> undefined thingies? XMLHttpRequest needs some of that too.

As above.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Tuesday, 20 May 2008 11:05:04 UTC