- From: Anne van Kesteren <annevk@opera.com>
- Date: Fri, 04 Mar 2011 13:19:04 +0100
- To: "Bjoern Hoehrmann" <derhoermi@gmx.net>
- Cc: www-dom@w3.org
On Tue, 01 Mar 2011 21:01:04 +0100, Bjoern Hoehrmann <derhoermi@gmx.net> wrote: > * Anne van Kesteren wrote: >> http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-flow >> says "As the final step of the event dispatch, for reasons of backwards >> compatibility, the implementation must reset the event object's >> internal-propagation and default-action-prevention states." > > This is the result of issues 20 and 35 in the former WebAPI Working > Group where you will find test cases and data and opinions on this. http://www.w3.org/2006/webapi/track/issues/35 has a public view and does seem to reach a similar conclusion. Namely that behavior is not very much the same and we can probably do "whatever". It does not explain, as far as I can tell, "for reasons of backwards compatibility". I have also read through http://www.w3.org/2005/06/tracker/webapi/issues/20 and http://www.w3.org/2005/06/tracker/webapi/issues/35 and the few emails associated with them. They also seem to reach similar conclusions. > I do note that in order to adequately test this you would also have > to check, say, implementation-generated events versus synthesized > ones, and modifying these states from within handlers rather than > before dispatching them the first time. Feel free to be inspired by > the member-only test code I submitted for these issues if they are > useful. Both Glenn and I have played around with that as well, getting much the same result as you back then. >> As far as I can tell this is not implemented this way. Propagation is >> not reset in either Opera or WebKit (it is in Gecko). > >> So it appears that there is no backwards compatibility issue here. > > Clearly if Firefox behaves in a certain way here then doing some- > thing else might break deployed code that works today in Firefox, > so it would seem there is indeed a compatibility issue there. Between browsers, yes. But "backwards compatibility" is generally used as a term meaning the "wider web relies on this behavior" which I do not think is established here, especially since Gecko does not do this for the "canceled flag". The "canceled flag" is the most problematic I think. I would prefer it if defaultPrevented remains to make sense after the event is dispatched. But given that most browsers do not reset these flags it seems we can get away with only unsetting them when initEvent() is invoked. >> Having said that, something to reset these flags might be nice so event >> objects can be reused. Or do we always want people to create new event >> objects? Maybe invoking initEvent() should reset these flags? As >> invoking initEvent() can also change the nature of it being cancelable. > > I would regard it as a bad practise to use the same event object > multiple times; semantically event objects are event instances, > and an instance of an event is unique. And you would be relying on > hidden state, which is unreliable, as you can see here. Do note > that these questions have also been discussed in the issues above, > at least as I recall them. Unsetting these flags would not just be for re-dispatching, but would also allow you to reconfigure it before dispatching has taken place at all. I agree re-dispatching is dubious, but we have to define how it works. I think based on the information in the older issues that we should change the model so that these three flags are only ever reset for initEvent() and otherwise never. I will change DOM Core to match that. I hope that works for everyone. -- Anne van Kesteren http://annevankesteren.nl/
Received on Friday, 4 March 2011 12:19:40 UTC