Re: [WebIDL] Passing null and undefined to DOMString things

It sounds like a bad idea to me that the default behavior for DOMString 
should be that null is converted to "null". I can't think of a single 
case where that is what you want to do.

Granted, this is partially due to a javascript spec "bug", null really 
should have serialized to "" rather than "null".

Since DOM Level 1 DOMStrings have had null as a legal value, so when 
passing null to a string argument there is usually no need to do any 
conversion.

When passing null to a [NotNull] string argument I think we should do 
the same thing as when passing null to any other [NotNull] argument, 
which IMHO should mean throwing.

Though looking at the spec it no longer looks possible to say that a 
function excepting an object doesn't want null. Was that removed or was 
it never there? I thought that was how this whole thing started, so that 
we could for example mark up that Node.appendChild does not accept null 
as a valid argument.

/ Jonas

Cameron McCormack wrote:
> 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.
>

Received on Tuesday, 27 May 2008 22:41:17 UTC