- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Mon, 25 Aug 2008 10:01:23 -0700
- To: "Boris Zbarsky" <bzbarsky@mit.edu>
- Cc: "Web Applications Working Group WG" <public-webapps@w3.org>
On Mon, Aug 25, 2008 at 8:02 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> Garrett Smith wrote:
>>>
>>> [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.
>>
>> Why such complexities?
>
> Because existing implementations sometimes treat null as meaning empty
> string and sometimes as meaning the string "null" and sometimes as meaning a
> special value that is not actually quite the same as the empty string. Note
> that some of this is required by some existing specifications.
>
> Similar for undefined.
>
> Expressing that in the IDL requires the above setup, unless you have a
> better proposal?
>
I already expressed my opinion, agreeing with Liorean. For domstring
arguments, call the internal ToString on the input would be the
general rule, unless otherwise stated. This would seem to cover the
majority of cases.
| I agree. We can see that IE does not always.
|
| javascript:void(document.body.style.color = { toString: function()
| { return "#900"; } })
> -Boris
>
Received on Monday, 25 August 2008 17:01:58 UTC