- From: Anne van Kesteren <annevk@opera.com>
- Date: Sun, 19 Mar 2006 22:23:40 +0100
- To: "Web APIs WG (public)" <public-webapi@w3.org>
On Sun, 19 Mar 2006 15:20:38 +0100, Jonas Sicking <jonas@sicking.cc> wrote: >> [...] I think >> solving Anne's pain is easier and more useful. > > I guess i'm trying to solve both, but the latter is more important. But > I would say "content and implementations" rather then just > implementations. > > I'm arguing that making onreadystatechange an EventListener will not > solve the pain of different implementations (and content) doing > different things. First of all IE does not support this and it is highly > unlikly that it would in any resonable amount of time. Especially given > that it doesn't support W3C DOM Events. Sure, but does that mean new implementions should not do it that way either? > And since hardly any content relies on it being an EventListener we're > not helping implementations either. We are. Telling them what it "eventually" will be helps them implementing it right from the start. Instead of having to revise the implementation for version 2.0. > The only advantage I can see is API 'clean-ness'. This is definitely an > important thing when defining new features, but here I value > compatibility higher. Try to see it as if we're defining a new feature. It should be clear to implementors what they have to do without too many open questions or things that might change in a revision. That some of the aspects of this new feature have some implementations already and that they don't interoperate "on this and that point" can be put in an appendix imho. -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/>
Received on Sunday, 19 March 2006 21:23:48 UTC