So, let’s take this from the beginning.
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
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);
// 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).
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
- 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.