This issue was fixed in Internet Explorer 9.
A quick tutorial. Please be patient. JavaScripting has relied on events since its origin. To detect when something happens (such as when the page loads, or when the user clicks on a link), and to act accordingly. When an event is detected, a function is run, allowing you to put whatever code you need in there. This is good.
OK, so what happens when you want the same event to do something else? You overwrite the old function with a new function. Still works. But what if you still wanted to run the code of the first one? Well, you must add the code from that function to the code of the new one. OK, still not too hard. But what about when you want to go back to the original? Well, you re-create the original function.
OK, still doing fine, but what about when you want to add some more functionality to that same event. And more, and more. And now you don't need the second one any more, so you need to remove it. So you can write your own event handler management structure, that keeps a list of functions that are attached to each element for each event, stores them in an array, and runs each of them when the event is triggered ... Or, you could let DOM events do it all for you.
The standard has a simple way to add and remove event handling functions; addEventListener and removeEventListener. These can be attached to anything that could use the old event handlers, as well as several more, like DOM nodes, where you can check if new child nodes are added or existing nodes are removed or modified. It even allows you to define in what order elements should detect the same event. Should the link that is clicked detect the click before the DIV that it is inside detects it? Or should that be the other way around.
Well, you will never guess, IE does things its own way. At least this time it uses a different function name (attachEvent), making it a lot easier to check which syntax to use. It has some serious oversights. Firstly, you cannot specify an event detection order. You must simply accept the default. Secondly, you loose the ability to talk to the element that detected the event if more than one element detects it.
Are there any advantages to the IE model? No. It offers nothing that the standards model does not offer. But Microsoft chose to only implement their limited version, instead of the much more flexible standard version. Microsoft came up with their idea while the standard one was still being developed, but it was available for use before IE 5.5 was released. But unlike the other browsers, IE still does not support the standard one, it just supports its own version, limiting the possibilities. Why? Because they can.
We have already decided what we want to do, so even though you have all thought of a better way to do it, and you are all going to do it, we are not going to bother.
Demo: Click here to add a click event listener that will colour the test paragraph when you click it.
Demo: Click here to add a click event listener that will alert a message when you click the test paragraph.
Once you have selected one or both of the links above, click this test paragraph to see if the event listeners work. If you click both links, then both handlers should be run.
Workaround: If your script is unable to rely on older event models, use a combination of
addEventListener and attachEvent, and fall back to older models. Use
if( theElement.addEventListener ) {
theElement.addEventListener('click',myfunction,false);
} else if ( theElement.attachEvent ) {
theElement.attachEvent('click',myfunction);
} else {
theElement.onclick = myfunction;
}
Your code would need to take account of the fact that the 'this' keyword does not work properly using the IE model.