- From: liorean <liorean@gmail.com>
- Date: Tue, 5 Jun 2007 23:03:10 +0200
- 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 INDEX_SIZE_ERR. 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