- From: John Ky <hand@syd.speednet.com.au>
- Date: Thu, 12 Oct 2000 05:13:48 +1000
- 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. Thanks -John
Received on Wednesday, 11 October 2000 14:14:51 UTC