- From: Jim Ley <jim@jibbering.com>
- Date: Tue, 14 Mar 2006 22:21:14 -0000
- To: <public-webapi@w3.org>
"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)
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?
> That's an interesting idea but clearly requires the ordering to be
> defined
Certainly, however I don't see anything else that does, so without that,
there's no need.
>> 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.
Jim.
Received on Tuesday, 14 March 2006 22:22:13 UTC