This is the explanation page for the addEvent and removeEvent functions designed by Aaron Moore. On this page I will attempt to describe:
Here are the features that my event registration method provides:
I'm going to start my explanation by doing a quick run through of the javascript features which make this method possible.
element.numClicks = count; For the purpose of explanation, say we are trying to assign multiple handlers to element a's onclick listener. Here are the elements which make up my design:
a.onclick at all. Instead, a generic function is assigned, which knows the location of each specific handler which is needed to run onclick. This generic function works by looping through a series of function calls. a.onclick0, a.onclick1, a.onclick2, etc. In addition, a.onclick_num contains the number of handlers which have been assigned. The generic function uses a.onclick_num in it's loop condition, meaning if you set a.onclick_num to 0, you will effectively clear all event handlers from the listener. Since each function has been copied to a property on the object, this refers to the calling object. a.onclick1(e); This means that the event object (w3c dom) is available for event property collection. You can use it to find the mouse coordinates relative to the page onclick or the keycode data onkeypress. As far as I can tell, there is no requirement, however, that handlers specify the e argument. It will be ignored if it's not provided. Furthermore, the generic handler examines each specific handler's return value. If one of the handlers returns false, the generic function will return false, canceling the default behavior of a.onclick. To finish, here is a comparison of my method with the W3C and IE alternatives, namely:
addEventListener(), removeEventListener() attachEvent(), detachEvent() Also, with W3C and IE's functions, there is no way to know what handlers are registered. It would be a very simple task to write a function to check if a given handler is registered with my method. Also, it won't hurt to run add or remove when the handler is already registered or removed. Add will exit if it finds the function already assigned, and remove will do nothing if it doesn't find the function.
However, both of these alternatives support the ability to stop the propagation of events, which my method doesn't. The body handlers will always run when divs within the body are clicked, and there's no way to stop this. But with good design, this fact can be partially circumvented. Both IE and W3C support their own version of target in their event objects. By comparing this and target it is possible to determine if the handler's element was clicked, or if bubbling happened. In this way it is possible to shield a given handler from bubbling, which is often the purpose that the ability to stop propagation is used for.
Now let me compare my method with these two alternatives individually.
The specific differences between my method and the w3c's standard functions are small and insignificant. Here are the ones I've found.
First, PPK pointed out in the advanced model article on quirksmode that the w3c standard does not specify the order in which handlers will run. My method does. They will be run in the order they are assigned in.
Second, the addEventListener() function has a parameter for specifying whether the handler is run in the capturing phase or in the bubbling phase. My functions do not support this ability. I believe that a real world design which hinges on this functionality would be hard to find.
My functions have one crucial difference from the IE alternatives. They maintain the usefulness of 'this.' Knowing which element is calling the handler is an extremely powerful thing.
Tell me what you think of all this. If you find any flaws, a comment would be particularly appreciated. Thanks.