- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 15 Mar 2006 05:43:08 -0800
- To: Jim Ley <jim@jibbering.com>
- Cc: public-webapi@w3.org
Jim Ley wrote:
>
> "Maciej Stachowiak" <mjs@apple.com>
>> It is better for interoperability if the order is defined instead of
>> arbitrary, code tested in one UA will be more likely to work in others.
>
> That is exactly what I mean by backwards compatibility, you're
> introducing stricter requirements in later UA's meaning that authoring
> to the spec breaks compatibility in DOM 2 implementations (because the
> author can now _rely_ on a particular ordering, rather than having to
> use the simple code methods to create an ordering)
Isn't that the case for every feature we are adding? That it means that
code written for DOM Level 3 will not necessarily work in DOM Level 2. I
don't see that as a problem. If it was I don't see the point in creating
a Level 3 at all.
> Without use cases for requiring an order, it shouldn't be done. It
> probably should've in 2, but wasn't presumably for reasons, what's
> changed about the reasons then?
I agree with this, we should have usecases for features we add.
>>> so should foo.onclick fire before or after foo.setAttribute
>>> ('onclick',... ) ? :-)
>>
>> Only one of them will fire, and whichever is set last wins. There's
>> no need to define relative ordering since you can't have both at the
>> same time.
>
> You can in some current implementations, and there's nothing in any
> current specification that disallows this.
The spec we are writing now, as proposed, disallows this. Do you think
that is a problem and will break existing content?
/ Jonas
Received on Wednesday, 15 March 2006 13:43:13 UTC