Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I could not care less about your system being callback, event or lambda-calculus based. For the bit you expose here, it seems rather well-written and promises to do a good job (although I'm curious about how you handled <code>removeEvent()</code> ;)).</p> <p>However, I have a few remarks about your implementation:</p> <ul> <li>it is unnecessary to check on which browser you execute each time you add an event handler.</li> </ul> <p>I am amazed at the number of people accepting the practice of checking existence of properties each time they are about to call them. Noone will swap your IE for a FF in the middle of a function call (and anyone stupid enough to define a <code>document.addEventListener</code> property other than an actual ECMA-5 replacement deserves to be flogged to death, if you ask me), so check which platform you're on at start and be done with it, like so:</p> <pre><code>if (doc.addEventListener) { addEvent = // ... freeEvent = // ... } else if (doc.attachEvent) { addEvent = // ... freeEvent = // ... } /* etc. */ </code></pre> <ul> <li>you offer an unified interface to attach a handler but, depending on the browser your code will execute on, the actual handler will behave differently.</li> </ul> <p>In IE8-, for instance, the target of the event will not be available the same way as in ECMA-5 conventions.</p> <p>If you want to offer a real cross-browser interface, you should provide an unified execution context to the event handlers. This could include a "cancel" function that would translate to something like:</p> <pre><code>cancel = function (e) { e.returnValue = false; }; // IE8- cancel = function (e) { e.preventDefault(); }; // ECMA-5 </code></pre> <p>you should also restore <code>this</code> to the target object under IE8-, and unify the <code>target</code> and <code>event.target</code> semantics.</p> <p>If you really want to be nice to programmers, you could also tackle a few oddities, like</p> <ul> <li>the load event not firing in IE8- when an image is already cached</li> <li>the absurdly complicated mouse wheel report system</li> </ul> <p>and probably a few others.</p> <p>The way I did it for my own purposes was to have a wrapper generated around the actual handler, that could take care of all the platform pecularities and establish a consistent execution context before calling the actual user code.</p> <p>A last remark: except for the beauty of it, I am not quite sure it is still necessary to support Netscape4-style events. But that is a matter of faith, so...</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload