Xbrowser Event Handling
On of the most powerful features of almost every Framework is x-browser Event management. This is important because standards dictate that you SHOULD ALWAYS separate implementation from design by leveraging the JavaScript DOM event management, instead of writing events inline. The problem arises from the browser wars, when the yahoos over at Microsoft decided to come up with a non-standard event model, making x-browser event management painful. Each Framework has their own implementation that wraps the two event systems, sometimes including additional bells and whistles, such as: scope adjustment, deferred loading, caching, cleanup, custom events, and more. However, the event management system of most Frameworks is so complex you have to wonder if it is all necessary and how coders managed events before Frameworks.
The reality is that most people do not need the extras, just a couple simple event handler functions that wrap the x-browser methods. Many programmers do not yet understand the power of the JavaScript event handlers. Therefore, often when I give advice to new coders and ask them how they handle x-browser events, I am usually greeted with blank stares. Most beginners do not take the time to fully understand JavaScript, because it is so simple to pick up and start working with. Plus, searching the net only overwhelms one with nearly endless examples of crap code, by people who also did not take the time to properly understand JavaScript and/or good design principles.
As I said at the beginning of this article, “You SHOULD be using JavaScript event handlers, instead of writing events inline.” Managing events is not all that complex, when you only need a plain interface wrapping the x-browser methods (just annoying). Here is the simplest way to manage events:
var attachFunc = '', detachFunc = ''; // Create the Event Function wrappers if (window.addEventListener) { // standards compliant method attachFunc = function(el, eType, fn, capture) { el.addEventListener(eType, fn, (capture)); }; detachFunc = function (el, eType, fn, capture) { el.removeEventListener(eType, fn, capture); }; } else if (window.attachEvent) { // microsoft compliant method attachFunc = function(el, eType, fn, capture) { el.attachEvent("on" + eType, fn, capture); }; detachFunc = function (el, eType, fn, capture) { el.detachEvent("on" + eType, fn, capture); }; } else { // event handlers unsupported attachFunc = function() {}; detachFunc = function() {}; }
This code sample will attach the appropriate event handling function to attachFunc and the appropraite event removal function to detachFunc. Put this anywhere in your code library before you start attaching events and it will simplify event management. I recommend you wrap this function into a namespace, such as “Event”, but you can use them as is. So anytime you want to attach an event (”click”, “keydown”, etc.) to an element, instead of writing something like “<a href=”#” id=”myAnchor” onclick=”someFunction();”>clickMe</a>”, you would write the following directly in your JavaScript code:
var link = document.getElementById("myAnchor"); attachFunc(link, 'click', someFunction);
You can safely ignore the capture option, unless you know what the capture phase is.
For some more information on x-browser event support, check out Peter Paul Koch’s article: Advanced Event Registration.

[...] Then any future time you call “getStartTime” you will always get the value of ‘t’ as the closure is now the definition of the Function. This pattern is incredible powerful when tuning your JavaScript, as: you do not need to define variables unless they are needed, those variables can exists as scoped (private) variables, and future calls to Functions using this pattern will be faster. We can apply this to “attachEvent” Function in last Friday’s article, Xbrowser Event Handling: [...]
Pingback by Lazy Function Definition Pattern | Matt Snider JavaScript Resource — October 3, 2007 @ 8:37 pm
[...] I will be using the “attachFunc” and “detachFunc” methods outlined in my X-Browser Event Handling [...]
Pingback by Event Package Part 1 | Matt Snider JavaScript Resource — October 18, 2007 @ 2:39 am