Event handling in JavaScript - an alternative addEvent solution
Event handling in JavaScript has been an issue for many web developers, and countless of people have made their stab of solving it. When I wrote my post AJAX, JavaScript and accessibility some commenters were asking for a follow-up post explaining event handling in JavaScript. My idea here is to give you a basic background and to also tell you about a new and interesting solution.
So, let’s take this from the beginning.
What’s the problem with event handling in JavaScript?
The gist of the problems is, surprise, Internet Explorer (yeah, I know, it’s a shocker…). There is a W3C standardized event handling model that Microsoft doesn’t abide to, but they instead have created their own model (this is one of times I almost resort to actually supporting Dvorak’s The Great Microsoft Blunder, but that’s really a rant for another day…).
First, you never want to apply event handlers inline. Period. Second, normally you might want to apply several event handlers to the same event on an element without knowing (or needing to know) if there has already been assigned any, and also without overwriting any potential existing event handlers.
The solution for this was presented as far back as in 2001 by Scott Andrew LePera in his Crossbrowser DOM Scripting: Event Handlers, which uses the standard addEventListener method for web browsers who support it, and has a fallback for IE by using its proprietary attachEvent method. So far, so good.
The problem with Scott’s method, though, is that for IE you can’t use the this keyword in the function that receives the event. Normally, using the this keyword in a function regarding to an event should refer to the element the event occurred on. Unfortunately, in IE, it refers to the window object instead when using the attachEvent method.
Example code:
var oElement = document.getElementById("my-div");
// Note that the addEvent function referred to below is a custom function, not built-in
addEvent(oElement, "click", handleClick);
function handleClick(){
// This code below will fail because of IE's incorrect reference for the "this" keyword
var strElementId = this.getAttribute("id");
}
This is most likely due to IE only having one global event object, as opposed to the standard model where events are local and passed with the function call (for a more detailed write-up, read Peter-Paul Koch’s Advanced event registration models article, and for a more real-life scenario, read his addEvent() considered harmful; both good reads).
A competition
Eventually all this led to a addEvent() recoding contest where a lot of people contributed and a winner was announced. After that, there were some voices raised about the winner and his solution, and JavaScript hero Dean Edwards (amongst many others) released his version of addEvent.
Aarons Moore’s addEvent
Recently I was approached by a student of the name Aaron Moore at the Gonzaga University, politely asking me to take a look at his version of event handling. His addEvent is based on direct assignment, i.e. element.onclick = functionToCall;, and does not rely on the addEventListener or the attachEvent one. The function is interesting for a number of reasons:
- Better web browser compatibility.
- It supports, naturally, multiple event handlers.
- It supports the
thiskeyword. - It allows for cancellation of default event behavior.
- It easily allows for making a script to see what event handlers are registered to an element.
- You can specify in what order event handlers should run.
However, it unfortunately lacks a way to specify capturing phase.
I’m going to be honest here and admit that I, due to lack of time, haven’t tested Aaron’s solution extensively, but I thought it was an interesting angle to the solution, and from what I’ve seen so far, it looks very clever too. Therefore, I encourage you to take a look it, test it and read the explanation to his approach. Please give him feedback and comments so he can find any eventual flaws.
