The first parameter is the name of the event, without the “on” prefix, the second is a function reference or anonymous function and the third is capture phase (i.e. if the event should be caught coming down from the element’s parent, or when bubbling up from a child element or itself).

Internet Explorer event implementation

Microsoft decided, a long time ago, to take their own route, and instead use something called attachEvent. The above example would look like this with code adapted to IE:

The first parameter is the name of the event, but with the “on” prefix, and the second is a function reference or anonymous function.

Microsoft’s event handling is filled with shortcomings, where some of the more serious are:

Just one global event object, instead of local objects per event.

When using the attachEvent method, the keyword this in the event handling function refers to the window object, and not the HTML event it actually occurred on.

No support for capture phase.

Different syntax, with requiring the “on” prefix for the event in question.

It has actually been so bad, that there was a competition online called the addEvent() recoding contest, to find the most suitable approach to get a common syntax and fixes for the IE bugs. When hobby web developers have to fix the faulty native implementation in a web browser, something is really really wrong.

What happens with Internet Explorer 8?

Every web browser has had proper event handling since about 2001, whereas Microsoft was already back then stuck with their beast of shame, IE 6. Fine, I’ll live with that, However, that they didn’t fix this in IE 7, since it’s one of the major scripting flaws in IE, was beyond me.

However, for IE 8, they said, they were add and repair a lot of JavaScript features. So ok, I waited. And the first IE 8 beta came along and, lo and behold, it even had support for the Selectors API (a working draft from December 2007)! Great, finally, I thought, Internet Explorer is catching up to the rest of the world.

But then I tested it for a while longer, and I soon realized, to my horror, that they had omitted standardized event handling in IE 8 as well! Again! Outrageous!

By design? Crap, by design? I always thought they knew of their shortcomings and acknowledged them, but were to fix them eventually – however, that statement is rather spitting in the face of developers, openly stating that they know it sucks, and that’s just the way they want it.

Fix it, or don’t release it

I think Microsoft should realize that web developers, although angered, have had a lot of patience with Internet Explorer. Lots of things were missing with IE 7, but people said, “sure, at least they’re trying now”. I felt the same way, they showed that they actually intended to make things better and were about to try to finally deliver a working product.

Lots of famous bloggers and developers, not the very least least JavaScript developers, have supported them, spoken for them and defended them along the way, stating that they’re getting there, one step at a time. But surely, even they must have had enough by now?

When Microsoft intentionally continue to neglect a W3C recommendation from 2000, but implement features from just a draft from 2007, what kind of message do they send out? Personally, I’ve had it.

Here here Robert. It gets very hard to defend a company when they choose to make our lives harder, as opposed to being stuck with it or trying to improve features like this that affect a wide cross section of the developer community. While its a lot of work for them, the alternative is an ongoing struggle for everyone else.

One argument they could have is that with the widespread usage of JS libraries, and even a shed load of individual functions/solutions around this particular bug in widespread usage it wasen't one of the main bugs to fix.

Just trying to think as they might, fix something that's completely broken (or unimplemented) or fix something to which there are already numerous known work arounds for……

What we, the developers can do is to spread the word of dissatisfaction. The louder, the better. It went well on the Version Targeting issue; Microsoft and the IETeam noticed that the whole internet, even Lemours, went crazy and changed their mind.

The Version Targeting issue was extreme, but it also learned us that even Microsoft can change.

I will try to find time to blog about this tonight, and I think the rest of Robert's readers should do the same if they have a blog.

Interesting thinking. While I agree to some point, no JavaScript library event implementation is perfect, and it will never be able to truly compete with native support.

One way for them to go would be to continue to support <code>attachEvent</code> for backwards compatibility (for code that doesn't use proper object detection), while at the same time implement <code>addEventListener</code> as well.

JMG,

Nope, none of that either, as far as I know.

Anders,

Most definitely! While the scope of this issue might not match the version targeting thing, it's still very important that everyone spread the word and express their opinion, blog about it etc.

Don't forget that with IE8+ you have to opt-in to get non IE7 handling of your page, so that is not going to be much of a factor.

Robert,

Microsoft implemented attachEvent first in IE5 well before the DOM2 specs. The W3C could have used the same implementation but no, they had to add event capturing which hardly ever gets used by anyone.

Also you seem to have the common misconception that the evt argument in your attachEvent example is not going be set to the event object, which is not the case.

Well, W3C could have used it, although it was broken in implementation (with the <code>this</code> keyword reference). Microsoft is in that group too, so I'm sure it was discussed and then disregarded in unity.

Also, event capturing might not be vital, but why not offer it as well for those who want it?

With the <code>attachEvent</code> example, I meant that no actual local event object was available, but the global is.

On the contrary, I'm afraid it is. I guess it's not such a trivial thing to do. It must be needing some (heavy) modifications to the JS engine, which would introduce many bugs, which would delay IE8, which is not acceptable. Hence the Â« by design Â» bug close.

JS libraries are fixing the problem, and more (eg: memory leaks). Since it works 'OK', Microsoft must be asking for IE8 to implement new high-end features for IE8, so it's not too slow compared to Firefox & Safari (eg: elements selectors) and doesn't feel too retarded.

The problem is such an issue is what makes IE to suck to developers. But who cares? Users will be happy — and developers will continue to rely on libraries to write JS.

It's certainly acceptable to me … even with the first birthday of IE7 over and done with, we're still waiting for IE6 numbers to drop.

I can wait another six months for IE8, no problems there… we already waited 6 years for IE7 😉

It might be unacceptable to Microsoft to ship IE8 a bit later ….

But let's face it, after so many years of blatant disregard for the development community, it should come as no surprise to anyone that Microsoft cares very little for the enormous financial burden they place upon us (developers, ISV's, businesses) by continuing to publish half-arsed software.

What makes the IETeam looks stupid is the fact that they have spoken of IE8 as the salvation from serious JavaScript bugs. With that in mind, it is much harder to forgive them for letting this serious bug go.

They're not going to change it, you know. 😉 The whole point is to be different/special/confusing and lock users/developers into their specific way of doing things, since they hold the majority.

On the other hand, I just heard Firefox has reached 20% of the browser market, so maybe IE's days as being the de-facto "standard" will one day be replaced by messages like "This website does not work with Internet Explorer. Please navigate to this page using a different web browser."

This is essentially Microsoft moving at their usual, natural pace. They move on their own time and don't care if they're sitting on anyone else's. Internet Explorer 7 is an improvement over IE6, but only so much as to be an aggravating umpteenth browser to support, and not enough to make much of a marked improvement. They make mind boggling decisions that damn near bring me to tears. Microsoft has no incentive to do anything the way anyone but Microsoft wants them to be done. This is why monopolies are such a big deal…

I would like to think we're in a time where Microsoft finally has something on the line. They have lost tremendous amounts of market share to Firefox and Safari (to a lesser extent), plus we may well have a strong new competitor from Google, yet it still seems like they're waiting until the bullet casings hit the floor before they decide to move.

Internet Explorer 8 has consistently promised to be the beginning of Microsoft's rebirth as a friendlier, more responsible company. I have been enamored with the thought that has been put into the Windows 7 UI and how constructive they have been of their criticisms of Vista's weak points, but it always seems like there's a catch. For every success Microsoft has, there's another whopping failure, and IE8 has epitomized this. It wasn't until pressure was put on it that it decided to release IE8 with Standards mode enabled, and it only does enough to pass the Acid2 test, and fails Acid3 horribly. You can say what you want about these tests, but IE8 thus far mangles my sites. It seems more like an evolutionary upgrade to IE7; they get a little closer to compliance, but not enough to make this a worthwhile release. This is Microsoft's opportunity to steal back what they're losing, and they're just doing what they do best: waiting for the last nail in the coffin. Someone needs to light a damn fire under their ass.

How loathable the MS attitude is in this case, they also paved the way for a bunch of fantastic frameworks. These address far more issues beyond pure IE problems, and brought us things like easy to implement tabboxinterfaces and the like. In a twisted way we should praise them for this feat 😉

Second, what would greatly improve the end user experience is that instead of workarounds, which will always be a performance as well as code risk, it would work the way it should right out of the box.

Not really sure I follow your logic there, though. If it can be achieved with workarounds, there's no need to implement it? In that case, why support the Selectors API? Lots of JavaScript libraries have already implemented it through JavaScript, and with CSS 3 support as well, which won't be in IE 8.

I'm not saying, "Don't implement". What I'm saying is that nothing is that badly broken. Let's not get hyperbolic over relatively small issues. Like all of us, the IE team has to set it's priorities. And headings like "fix it or don't release it." seem to me extreme for no good reason. And for those who may read your blog and are not informed about what is being discussed, it creates the wrong impression. There may be smoke, but there really is no fire.

I, too, am inconvenienced by IE's lack of support as are all developers but outside of wasted bytes – which we would have to live with for years anyway to preserve backward compatibility – there's not a lot of harm being done.

Or, at least, you haven't provided me with any concrete examples of real import.

Frankly, I could cite things that IE has and has had for many years that are quite useful but demanding that FF or Opera, or Webkit support it or go fly a kite doesn't do anybody any good, does it?

The difference is that this event handling is an established standard, and something was along with creating, as opposed to their own implementations who are just closed-source and created in the dwellings of Redmond.

Besides, anything real useful in practice, like <code>XMLHttpRequest</code>, was implemented by all other web browser vendors, since it was a good thing.

However, as mentioned above, I think it's vital for any product to fix the frickin' basics, before just focusing and more and features. In the end, though, I'm sure I can't convince you – you're entitled to your opinion as I am to mine.

IMHO Internet Explorer completely lacks the event model as defined in w3c. No mutation events. One global event object. No capturing etc. Same with SVG, they're not really keen on implementing a standard. I agree with the statement. Don't release it. Further more I'd love to see the new JavaScript 1.7 and 1.8 Array methods.

Apparently IE8 implements DOM prototypes (ie. HTMLDocument, Element), which means we can create Element.prototype.addEventListener for instance, just like I did in a previous comment. DOM event handling won't be there, but at least fixing emulating it somehow will be easier.

BTW, another thing beyond my comprehension is how did they come to the method name – "attachEvent". I know it is just a sub-minor detail compared to how the method is but the name even doesn't describe what this crippled method actually does.

As of February 2009 the browser market share is distributed like this:

– Browsers that respect standards (fx, chrome, safari, opera): 54.7%

– Internet Explorer (6+7+8): 44.8%

I for one have lost all patience with IE. In january 2008 IE had a 54.7% of the market (similar to the w3-compatible browsers as of this month), while the browsers that respected the w3 specs had 39.7% of the market.

– IE has lost 10.1% of the market in ONE year

– The good browsers gained 15% during that same year

Firefox/Mozilla alone gained about 40% of the market within about four years!

I'm currently working on the hugest project to date, and I will be making a very bold move: leaving IE to its own devices. I will not write compatible css or javascript. I'm very capable of it, but I REFUSE TO DO IT ANY LONGER.

I'm aware of how this can affect me, though I don't really care. I will be presenting users with a very informative page explaining why, supported by stats, etc.

I want an IE that is w3-compliant, or no IE at all. This sort of boldness en masse will have such dire consequences for IE, which I would shamelessly revel in.

I know for a fact that if most Web developers could integrate their "political" stance into their projects, they would. And by this I mean: disregarding IE, and developing for the future.

Okay I've been looking for some time now, but has anybody else noticed that IE8 recently returning true for if(window.addEventListener) but returns false if you try to set it!?! This has been causing all kinds of havoc in various libraries in my codebase (cry!) and I'm being forced to rewrite everything to handle the new even more broken "functionality"…