- From: Jim Ley <jim@jibbering.com>
- Date: Thu, 16 Mar 2006 20:58:57 -0000
- To: <public-webapi@w3.org>
"Bjoern Hoehrmann" <derhoermi@gmx.net> > So if you think we should > not define ordering, I'd rather hear why the downsides of defining > the order outweight the cited benefits cited benefits? The one that relates to stopImmediatePropogation is the only one given, I find it hard to say what the downsides are to things which haven't been given, like most stuff, there are no use cases. If we talking ideal specifications that contain everything everyone wants minutely specified in detail, then I'd like to see actual use cases in the specification, rather than the current nowhere at all. > and how similar effects can be achieved e.g. in XBL2 where > stopImmediatePropagation seems to be > pretty much required. In a new thread, ideally. I don't see the need to pre-empt what the Web Application Formats group might produce in the area, much better to wait until they produce requirements and then meet them (or why not just let them meet them themselves) as I've said previously I can't see the value in an ordering unless you also have the ability to insert first in the order - without either introspection or a specific method to do that, it's impossible, so I believe after the remove introspection decision from the f2f , it's impossible, this doesn't seem a good thing, as you can't actually know that the event you want to stopImmediatePropagation on is actually the first event listener attached, so you're still down to relying on the fact you've authored in a particular way. Without knowing the use cases for the various features I am not able to review if the features meet them, this has been a long problem, of course normally it's okay as I can just ignore them and assume their okay. If you want me to review DOM 3 events in its entirety, can I see some use cases? Maybe they're all in member space. stopImmediatePropagation is trivial to implement outside of XBL situations- as is event ordering, you simply don't attach multiple events but have just one listener - if the events are really so intertwined that they must be handled together then it's not obvious why an author would attach 2 listeners. This is of course not the case in a XML componentised language such as XBL2, but then the current DOM 3 events spec -groups already meet this use with the ordering defined _within a particular group_. I'm happy with that, it seems to meet this requirement of course like I say, I only know of it from a technical requirement - use cases are wholly missing. Jim.
Received on Thursday, 16 March 2006 21:00:19 UTC