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

Reply via email to