- From: David Brownell <david-b@pacbell.net>
- Date: Sat, 25 Mar 2000 07:30:06 -0800
- To: Raph Levien <raph@levien.com>
- Cc: www-dom@w3.org, Philippe Le Hegaret <plh@w3.org>, Tom Pixley <joki@netscape.com>, Tim Janik <timj@gtk.org>
Raph Levien wrote: > > As a result of a conversation between Philippe Le Hegaret, Tim > Janik, and myself yesterday, I am sending this mail to propose a > change in the semantics of removeEventHandler. Briefly, the current > semantics call for the handler to be invoked in some cases after it is > removed. I propose that it should not be. Well, I always found its current specification to be a bit strange, in part because it was unmotivated. Before changing it I'd like to hear the rationale: why was it originally specified that way? Use cases motivating the current behavior would be a good start. > Thus, I propose the following modification to the specification. > The current language in the description of removeEventListener reads: > > "If an EventListener is removed from an EventTarget which is > currently processing an event the removed listener will still be > triggered by the current event." > > This should be changed to read "will not be triggered by the > current event". Further, the statement, "an event listener will never > be invoked after it is removed" should be added as a global invariant. There's also the "add a listener" case too ... basically it's now set up so that event delivery should snapshot the listeners that will be called for targets at each level of event dispatch. If the spec were to change (not something I tend to want in this area) then the "add a listener" case needs to be addressed too. - Dave
Received on Saturday, 25 March 2000 10:30:09 UTC