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

Re: [whatwg] Setting innerHTML to null or undefined

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 5 Jun 2007 09:50:39 -0700
Message-Id: <7E603E3A-2FEE-4934-A976-09909470F175@apple.com>
Cc: HTML WG <public-html@w3.org>, "Web APIs WG (public)" <public-webapi@w3.org>
To: liorean <liorean@gmail.com>


On Jun 5, 2007, at 6:29 AM, liorean wrote:

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

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.

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

Given ES4's compatibility goals, their DOM bindings need to behave in  
a functionally equivalent way to ES3 bindings.

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

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  
- I don't recall if inheriting from String or numeric types is  
allowed in ES4.

Regards,
Maciej
Received on Tuesday, 5 June 2007 16:51:03 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:45 UTC