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

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

The spec now states for [Null]:

  "Otherwise, if the argument to [Null]  is Null, then the value assigned
   to the attribute or passed as the operation argument will be the
   string "null".

That seems inconsistent with what you just wrote, and also inconcistent 
with [Undefined], where it states:

   "Otherwise, if the argument to [Undefined]  is Null, then the value
    assigned to the attribute or passed as the operation argument will be
    the null value."

Did you intend for both to say "... the operation argument will be the 
null value."?

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Received on Tuesday, 20 May 2008 11:21:34 UTC