W3C home > Mailing lists > Public > public-webapi@w3.org > June 2007

Re: [whatwg] Setting innerHTML to null or undefined

From: liorean <liorean@gmail.com>
Date: Tue, 5 Jun 2007 23:03:10 +0200
Message-ID: <cee13aa30706051403q4b85cdf0w110c5631fd77a5f7@mail.gmail.com>
To: "HTML WG" <public-html@w3.org>, "Web APIs WG (public)" <public-webapi@w3.org>

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

> On Jun 5, 2007, at 6:29 AM, liorean wrote:
> > Well, IE doesn't throw INDEX_SIZE_ERR, the others do, so I guess there
> > is that compatibility argument.

On 05/06/07, Maciej Stachowiak <mjs@apple.com> wrote:
> IE's DOM behavior is so divergent from the standard in so  many areas
> that most sites and JS libraries have two separate code paths for
> much of their scripting logic.

I've written plenty of DOM code in my life, so no argument about that.
Generally the problem isn't interface implementation differences that
are so large that you have to fork the code but rather entirely
different interfaces for some things. The prime example would be the
events systems, where attachEvents looks like it was maybe the initial
idea that eventually grew into addEventListener. But even the DOM0
events system is radically different between Trident and the original
Netscape one...

> On Jun 5, 2007, at 6:29 AM, liorean wrote:
> > 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:
> Given ES4's compatibility goals, their DOM bindings need to behave in
> a functionally equivalent way to ES3 bindings.

And that's why I want the ES3 bindings to, if possible, be equivalent
to the conversions you would get using the ES4 type annotations.

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

> On Jun 5, 2007, at 6:29 AM, liorean wrote:
> > 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.

On 05/06/07, Maciej Stachowiak <mjs@apple.com> wrote:
> Using this type signature would break compatibility with ES3 I guess,
> since it would cause an implicit type conversion before the function
> is called. In ES4 you *could* model some of these things with types
> that inherit from the basic types but have different conversion rules

The ES3 conversion I described does not give results that are any more
incompatible with current browser implementations in this case than
the browsers themselves.
(See Cameron's tests, in particular for this case number 022)
For all these the count is 1, testing different offsets:

Gecko behaviour is identical to what would have been achieved if
specced as ToInt32(offset) with a negative offset throwing an

Presto behaviour is identical to Gecko except for also throwing
INDEX_SIZE_ERR for an offset of Infinity. (Which would mean that
what's actually happening is that substringData actually takes a float
offset, determines Infinity is over the length of the CharacterData
and throws accordingly.)

WebKit behaviour looks like ToNumber(offset) followed by throwing a
TYPE_MISMATCH_ERR if not equal to the returns of ToInt32(offset), and
throwing INDEX_SIZE_ERR if negative.

Trident behaviour is identical to Gecko except that it throws a
different error from INDEX_SIZE_ERR for negative numbers.

The behaviour of ToUInt32(offset) is identical to the result of the
ES4 signature I listed. It will have behaviour practically identical
to Gecko except for:
- It wraps around. For example (-0xfffffff0 >>> 0) is 16. This gives
unexpected numbers for some cases.
- It doesn't throw anything at all on negatives.

The behaviour of ToUInt32(offset) and throwing an ES3 TypeError if
that is not equal to ToNumber(offset) gives errors for all the cases
that WebKit currently gives errors. The difference is that all those
errors would be ES3 TypeError. This is the exact constraint used for
ES3 array lengths.

The behaviour of ToInt32(offset) and throwing an INDEX_SIZE_ERR if
that is not equal to ToUInt32(offset) is identical to Gecko behaviour
*as far as I can determine*.

The behaviour of ToInt32(offset) and throwing an INDEX_SIZE_ERR if
that is not equal to ToUInt32(offset) and throwing a TYPE_MISMATCH_ERR
if that is not equal to ToNumber(offset) is identical to WebKit
behaviour *as far as I can determine*

On 05/06/07, Maciej Stachowiak <mjs@apple.com> wrote:
> - I don't recall if inheriting from String or numeric types is
> allowed in ES4.

You can't inherit from the machine types int, uint. But you can
inherit from String, Number etc.
David "liorean" Andersson
Received on Tuesday, 5 June 2007 21:03:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:23 UTC