W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2003

Re: DOM 3 Events: EventListeners and NodeFilters?

From: Philippe Le Hegaret <plh@w3.org>
Date: 24 Mar 2003 13:10:02 -0500
To: "Alexander J. Vincent" <ajvincent@hotmail.com>
Cc: WWW DOM <www-dom@w3.org>
Message-Id: <1048529401.7787.45.camel@jfouffa.w3.org>

Alexander,

based on the fact that your needs can be achieved with the current
solution provided by Events and Traversal, we decided not to address it
in DOM Level 3 Events.

Let us know if you agree (or not) with the decision,

Philippe
Recorded at:
http://www.w3.org/2002/07/DOM-Level-3-Events-issues/all.html#alex1

On Wed, 2003-02-05 at 20:22, Alexander J. Vincent wrote:
> >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?
> 
> Firstly, I want to admit an oversight -- I could just as easily write a 
> NodeFilter to accept the Event object and return FILTER_ACCEPT or 
> FILTER_REJECT based on the target and currentTarget properties.  We'd then 
> need only one extra argument, not two.
> 
> A use case?  Consider an HTML form, where one group of input elements in a 
> table have one class, and another group of input elements in the same table 
> have another class.  (Say, a table of namespace URIs and prefixes.)  With a 
> little scripting and some elbow grease, you could make sure each URI 
> corresponds to an appropriate prefix.  (I'm doing something very similar in 
> developing a widget for Mozilla's DOM Inspector to create nodes.)
> 
> If the user enters into a field, it would be wise to figure out which column 
> (URI column or prefix column) he or she is altering.  In HTML we have the 
> oninput event handlers, but it would be easier and less code-intensive to 
> file an event listener on a common ancestor.
> 
> It's even more significant when the form also has input fields which are not 
> part of the table.  A NodeFilter (or conventional DOM Core) can easily sort 
> out which to apply the event listener to.
> 
> Incidentally, the DOM 3 Events WD includes new methods for namespaced events 
> -- an interesting concept.  A NodeFilter operating on the Event object could 
> check the namespace URI of the Event object just as easily.
> 
> Alex Vincent
> Vallejo, CA
> 
> _________________________________________________________________
> Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
> http://join.msn.com/?page=features/junkmail
Received on Monday, 24 March 2003 13:10:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:56 GMT