W3C home > Mailing lists > Public > public-webapi@w3.org > April 2006

Re: ISSUE-77: DOM3EV: Effect of evt.currentTarget.add/removeEL

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Sun, 23 Apr 2006 13:35:53 +0200
To: Jonas Sicking <jonas@sicking.cc>
Cc: Web APIs WG <public-webapi@w3.org>
Message-ID: <m0pm42h1f6u2f2ttbtleq5p2d0t07nbde9@hive.bjoern.hoehrmann.de>

* Jonas Sicking wrote:
>I agree, i think having add and remove behave the same would be a good 
>idea. I'm not sure if we can actually change this though if the DOM L2 
>spec is indeed clear on the behaviour.

It certainly possible to change the specification, but we indeed need to
consider the impact of such a change. Deferred addition of listeners on
the current target is implemented reasonably well across implementations
(including that the added listener is invoked when the listener that
adds it dispatches a new event, causing reentrance into the model), so
that's not a good candidate to change. What does not work well across
implementations is removing the listener from the current target, as I
described in the issue.

>Another argument against deferred notification is that it might be 
>confusing that a removed listener can still be notified.

Yes, though it might be equally surprising that listeners on nodes that
have been removed might still be triggered even if the nodes have been
removed from the document.

>Also, does the spec say anything about what happens if listeners are 
>added or removed on any other EventTarget that is about to get notified 
>by the current Event? I couldn't find where in the spec it describes any 
>of this.

I think the draft and DOM Level 2 Events attempt to say this, yes. It
could be improved though, I'm looking into that, hence this issue.
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
Received on Sunday, 23 April 2006 11:42:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:21 UTC