Re: [whatwg] Setting innerHTML to null or undefined

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

> On Jun 4, 2007, at 7:52 PM, liorean wrote:
> > 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).

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

Well, how about specifying a general rule when applicable and just
special casing those that out of compatibility reasons need to behave
differently?
Also, I think you need to add another compatibility category to the
list - how everything work together with the type system added in ES4.

> On Jun 4, 2007, at 7:52 PM, liorean wrote:
> > - 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.)

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

Well, IE doesn't throw INDEX_SIZE_ERR, the others do, so I guess there
is that compatibility argument. However, I'm not only concerned with
ES3 compatibility but also with how this is supposed to work in an ES4
environment using the more advanced type system you can find in ES4.

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

I'm not arguing for pure logic based spec where that is not compatible
with the real world, only when the real world hasn't taken a clear
stance one way or the other. I'm arguing for having the right thing
done when possible. Particularly since I would want the ES3 bindings
to be fully forward compatible with the ES4 types so that
implementations of for example CharacterData.substringData could use
an ES4 signature of:
    CharacterData.substringData(offset:uint, count:uint):String
and still have correct handling of negatives.
-- 
David "liorean" Andersson

Received on Tuesday, 5 June 2007 13:30:03 UTC