Re: [whatwg] Setting innerHTML to null or undefined

[Sorry for the double of this post to those who are members of both
public-html and public-webapi]

On 02/06/07, Anne van Kesteren <> wrote:
> For .innerHTML = null Opera and Internet Explorer act as if the literal
> string "null" was used. Firefox acts as if "" was used.
> For .innerHTML = undefined Opera, Firefox and Internet Explorer act as if
> the literal string "undefined" was used.

On 6/4/07, Jonas Sicking <> wrote:
> I'd really dislike having to have this one property behave differently
> than other text properties in the DOM. How do opera/ie deal with other
> text properties like .src, .id, .textContent?

On 05/06/07, Michael A. Puls II <> wrote:
> For .src and .id, IE and Opera set "null".
> Opera does the same for textContent.
> For .src, this obviously means that IE and Opera will then return the
> directory of the page + "null" where as FF will return the URI to the
> page.

On Jun 4, 2007, at 5:45 PM, liorean wrote:
> Seems to me like they are simply using the ECMAScript ToString
> algorithm, unless I'm mistaken. That's probably a good thing to
> specify for this, too.

On 05/06/07, Maciej Stachowiak <> wrote:
> 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.

I know. But I think this should be very clearly specified in the DOM
specification and ECMAScript bindings, and more specifically I think
that the correct way to specify it is as follows:

Type conversions should follow the rules used for the specific
language. In the case of ES3:
 - If the DOM requires a DOMString, since DOMString is mapped to ES3
String, the type conversion should be through ToString(value).

- If the DOM requires an unsigned long, the ES3 spec way of handling
this is to take ToNumber(value) and compare it to ToUInt32(value). If
not equal an ES3 TypeError should be thrown, if equal the return value
from ToUInt32(value) should be cast from Number to UInt32. (This
conversion is on the ES3 side of the function call, so for example
CharacterData.substringData would not throw INDEX_SIZE_ERR on negative
offset or count since the language conversion would already have
failed before the function was entered.)

- If the DOM requires a boolean, there's two possibilities:
  1. It's a TypeError if the value is not a Boolean. (I.e. a strict comparison.)
  2. The DOM is sent the return value of ToBoolean(value).
I don't have enough data on browser behaviour to say if either
conversion is the most appropriate in general or if this have to be
dealt with in the ECMAScript bindings on a per case basis. I suspect
the latter.

- If the DOM requires a Node*, a TypeError should be thrown if the
value is neither null nor an object that has one of the following
  1. It's [[Class]] internal property has a value of "Node".
  2. It's [[Class]] internal property contains a type that also has to
implement the Node interface.
  3. It's [[Class]] internal property contains a derived type of the
Node interface object.
Also, and this is an area the DOM specifications are very bad at
defining, all uses of Node type should specify the exact handling of
null values.

* Which seems to be a nullable type if you read the DOM spec a bit.
The spec really should make sure to specify the types it uses more
exactly, especially whether types are nullable or not.

- Analogous for other DOM interface types.

On 05/06/07, Maciej Stachowiak <> wrote:
> I think this overlaps with the Web API group's DOM bindings for
> ECMAScript project.

Yes it does, so I added WebAPI as CC.
David "liorean" Andersson

Received on Tuesday, 5 June 2007 02:52:24 UTC