Re: [whatwg] Setting innerHTML to null or undefined

On Jun 4, 2007, at 7:52 PM, liorean wrote:

>
>
> On 05/06/07, Maciej Stachowiak <mjs@apple.com> 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).

I agree it should be very clearly specified, but you can't specify  
just a single rule. For historical reasons, different properties need  
different rules. We need to specify a couple of different type  
conversion rules and specify clearly which property uses which.

> - 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.)

Actually, it's important for compatibility and conformance with past  
specs to throw INDEX_SIZE_ERR for some (but not all) properties  
specced as taking unsigned but actually passed a negative value.

I just have to go back to my statement above. We need to investigate  
current browser behavior and what past specs say, and keep in mind  
that the same IDL type may in practice be mapped to a couple of  
different conversion behaviors for ECMAScript. You can't decide this  
based just on pure logicl

Regards,
Maciej

Received on Tuesday, 5 June 2007 06:14:10 UTC