W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2000

Re: event capture and bubbling

From: John Ky <hand@syd.speednet.com.au>
Date: Thu, 12 Oct 2000 05:13:48 +1000
Message-ID: <009c01c033b7$6577ddc0$0400a8c0@NEWHOGGY>
To: <www-dom@w3.org>
> At this time there is no independent ability to suppress the Capture or
> At-Target phases. Default can be suppressed by invoking
> Event.preventDefault, but I believe that has to be done from a handler
> since it gets reset each time the event is dispatched. If you've got a use
> case for making this more flexible, please submit it for consideration in
> future revisions of DOM Events.

Actually, I am not sure if I should take that back.

I had first thought that my the event listeners I've written are only
interested in the At-Target phase.  I've come to realise that this
isn't quite the case.

My event listeners are registered on nodes so that when a new
node is inserted onto that node, the event listener would add
new eventlisteners to the new child.  This allows me to
recursively define rules that apply to a whole document as
the document is built.

I perform the following check to ensure that my event listener
only acts on a direct child:

if (event.currentTarget.parentNode != event.target)

My argument before was that some use cases will benefit greatly
in performance by having a class of event registration that only
responds to the At-Target phase and I had believed my application
fell under that category.

Now I know I may be slightly mistaken.  My application is
incapable of making use of such a facility given the current
set of Mutation Events.

It may still benefit from this facility if there existed some Mutation
Event perhaps called "DOMChildInserted", which has the parent
as the target and the child as the relatedNode.

It sounds simple enough to add additional Mutation Events, but
I am also concerned that a larger set of Mutation Events will
incur a larger intrinsic overhead in DOM operations.

My views on this issue are for the moment inconclusive.


Received on Wednesday, 11 October 2000 14:14:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:07 UTC