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/
