Re: [whatwg] WebIDL and HTML5

Garrett Smith wrote:
>> In some UAs that alerts "null", in some it throws an exception because
>> createElement("") is not valid.  Just try it.
>>
> 
> Using ToString, the following result would be obtained:
> 
> // ERROR
> document.createElement("");
> 
> // create a "<null>" element.
> document.createElement(null);
> 
> // Create an "<a>" element.
> document.createElement( { toString: function(){ return "a"; }} );
> 
> document.createElement( new String("div") );
> 
> To simulate the ToString effect, use String( arg ); (do not use new
> String(arg));

Exactly, this shows that converting null to "null" is undesirable for 
some functions.

>>> No, but there should be a need to call ToString.
>> The thing is, ToString is lossy.  Once called, there is no way to tell apart
>> "null" and null.  However, there are DOM methods which require different
>> behavior for the two (e.g. createElementNS and so forth, which I did
>> explicitly mention earlier, contrary to your "counldn't think of one either"
>> business).
> 
> After the method createElement(null) is called, there will be no need
> to tell apart null and "null". I see that. Why is that a problem?

Not sure what you are saying here.

> You said that null -> "null" is "lossy". I don't think that's a valid
> argument. null -> "" is even more "lossy".

Both conversions are lossy yes. The correct solution is to do no 
conversion. As I've stated many times, null is a valid value for 
DOMString and so no conversion is needed in the general case.

However for some function *implementations* treating giving null and "" 
as an input argument will yield the same result, such as createElement.

>> Similarly, there are DOM methods that require different behavior for null
>> and "".  Specific examples include the proposed DOM style set APIs,
>> DOMImplementation.createDocument. There are also cases where returning null
>> and returning "" are not equivalent.  inputEncoding is an example.
> 
> null and "" are not equivalent. Setting a style to have the value null
> should probably convert the value to "null"

What do you base that on? Can you point to any specs that state that 
that is the correct thing, or any webpages that expect that behavior?

> Internet Explorer is more strict in that it requires a string value,
> and won't call ToString. It would be useful to have the method call
> ToString, because that way an object with a toString method could be
> used for setting values:
> 
> <script>
> var colorObject = {
>   r : 16, g: 255, b: 16,
>   toString : function() {
>     return "rgb(" + this.r + "," + this.g + "," + this.b+")"; }
> }
> 
> document.body.style.backgroundColor = colorObject;
> </script>
> 
> It would seem somewhat expected that the colorObject's toString would
> be called. The object's toString method would be called from the
> internal ToString method.

I agree it seems useful to use ToString as a conversion method when an 
argument of type DOMString is passed something that isn't a valid 
DOMString value.


> Null is not the same as no value. Null is a type, having one value:-
> null. The value null is a primitive value in EcmaScript. It is the
> only member of the Null type.

As far the the DOM spec goes the value null is a bit special. It isn't 
simply a value valid for the Null type. null is also a valid value for 
many other types. For example Node.insertBefore takes as a second 
argument a Node, however passing null is a valid value to pass. So null 
is a valid value for the type Node.

I argue that there is very strong indication in the spec that null is 
also a valid value for the type DOMString. Camerons mail also supports this.

/ Jonas

/ Jonas

Received on Tuesday, 26 August 2008 19:15:35 UTC