- From: Philippe Le Hegaret <plh@w3.org>
- Date: 05 Feb 2003 15:59:13 -0500
- To: "Alexander J. Vincent" <ajvincent@hotmail.com>
- Cc: WWW DOM <www-dom@w3.org>
On Wed, 2003-02-05 at 10:58, Alexander J. Vincent wrote: > In recent weeks, I have tinkered with DOM Level 2 Traversal, and have > discovered much fun to be had with NodeFilter objects. Yet, when I need to > register an EventListener on an EventTarget, I find I must often use > conventional DOM Core techniques to determine if the currentTarget or target > of an Event the EventListener receives are appropriate for that > EventListener. > > This is very inconveinient. > > I would suggest adding new methods for "filtered" EventListener objects. > They would correspond to the addEventListener and removeEventListener > methods, but with two additional NodeFilter arguments for the Event object's > target and currentTarget properties. Such addition would only be useful for the capture and bubbling phases, isn't it? When the document is on at the AT_TARGET phase, the currentTarget is the same as target, and the event listener must have been registered on the target anyway. Are you attaching listeners that are generic and, in that case, needs to check for the target before doing processing? Can you provide some use cases? > Because quite often only one of the two properties may matter, it would > become necessary to suggest a special NodeFilter which always returns > NodeFilter.FILTER_ACCEPT. This would allow the target property to be > insignificant while the currentTarget is significant, or vice versa. > > Opinions? A list of use cases would be useful to better understand your needs. A simpler solution than node filtering migh be enough. Philippe
Received on Wednesday, 5 February 2003 15:59:15 UTC