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.
