Re: [whatwg] WebIDL and HTML5

On Tue, Aug 26, 2008 at 5:38 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> Garrett Smith wrote:
>>
>> There is no DOM method calld doStuff. Can you provide a concrete
>> example? Boris couldn't think of one either.
>
> Uh, what?  You never said, "I don't understand that this applies to all DOM
> methods that take a DOMString, so I'd like to have some specific examples."
>

I did ask. Here's what I wrote:

| Are there other examples for "if the argument is null or
| undefined..."?
|
| There are probably others but I can't think of them. I think the
| majority of the time that strings will want to go to ToString,
| booleans will want to go to ToBoolean.

> In any case, here's a simple example:
>
> javascript:try { alert(document.createElement(null).localName); } catch(e) {
> alert(e) }
>
> 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));

>> 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?

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

>
> 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"

document.body.style.color = null;

However, such applications that are already expecting such behavior
are already broken because they are relying on non-standard behavior
which is known to not work cross-browser. Setting style values to
invalid values will result in script errors in Internet Explorer.

document.body.style.color == "null"

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.


>> It is not something that can or should be generally relied upon
>> because it is not standardized and indeed works differently in
>> implementations.
>
> Yes.  The whole point is to standardize it.
>
>> Considering your argument for serializing null -> "" being the most
>> "sensible", I disagree.
>
> It's sensible in the context of the large number of DOM methods that treat
> the two as equivalent (again, all the *NS methods in DOM3 Core).
>
That would be a poor design choice, because it is inconsistent with
programmer expectation. Considering that string objects are objects
and not domString, new String("div") is an object. "div" is a string
value.

document.createElement( new String("div") );

- is not standardized. This would seem to create a "<div>" element,
but can't be expected to. Nor is:-

document.createTextNode(0)

Should this create a textNode "0" or ""?

I would argue that the former is a little more intuitive. And if the
programmer explicitly uses:-

document.createTextNode(null)

should probably create a text node with the value "null". It is harder
to debug null to "" but null to "null" is easy to debug.

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.

Generally, a domstring argument could go through some sort of string
conversion to get a string value. The conversion that it should go
through is the standard one defined by EcmaScript internal ToString.

Garrett

> -Boris
>

Received on Tuesday, 26 August 2008 16:12:59 UTC