Internet Explorer 8 - fix event handling, or don’t release it

Published on Tuesday, November 4th, 2008

Something which have troubled web developers for a long long time is the proprietary event handling implementation in Internet Explorer. In IE 8, this really has to go.

Event handling background

The basic problem is that, as in many other cases, there’s one standardized way of handling events and then there’s a specific one implemented by Microsoft in Internet Explorer.

DOM Level 2 Events Specification

November 13th, November 2000, the Document Object Model (DOM) Level 2 Events Specification was issued. Basically, you use a method called addEventListener to add an event to an element, like this:

document.addEventListener("mousemove", trackMouse, false);
function trackMouse (evt) {
    // The evt parameter is a local event object
}
document.addEventListener("mousemove", function (evt) {
    // Track mouse movement
}, false);

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:

document.attachEvent("onmousemove", trackMouse);
function trackMouse (evt) {
    // The evt parameter isn't available here, just the
    // one global event object in Internet Explorer
}
document.attachEvent("onmousemove", function (evt) {
    // Track mouse movement
});

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!

Microsoft’s take

What’s very interesting, and at the same time scary, is that if you dig a little, there was a bug report for lack of support for addEventListener in Internet Explorer 8, but it was closed with the wonderful motivation “by design”.

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.

Fix event handling in Internet Explorer 8, or don’t release it.

28 comments

  • Daniel
    November 4th, 2008 at 19:07

    I couldn’t agree more. Altough alot of things have gotten better since IE6 I still feel there are a lot of bad decisions lately coming from the IE developers team.

  • Steven Clark
    November 5th, 2008 at 0:12

    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.

    It’s kind of maddening (disappointing), for sure. :(

  • Ross Bruniges
    November 5th, 2008 at 0:20

    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……

  • Lillan
    November 5th, 2008 at 5:10

    Hey - isn’t this MS and IE in a nut shell? Why bother? In time I’m pretty sure they’ll discover the consequences of their lack of responses.

  • JMG
    November 5th, 2008 at 11:21

    I just can’t believe it. JS hacks and libraries still have a long to go, I guess.

    BTW, I’m sure they didn’t, but did they implemented the Element object? I mean can we do something like the following, or do we still have to extend objects manually?

    Element.prototype.addEventListener = function(action, fn, phase) {
    var self = this;
    return this.attachEvent('on' + action, function() {
    return fn.apply(self, [window.event]);
    });
    }

    I thought IE8 was to fix Javascript. We’ve been wrong I guess. They just added some high-end features to fool us.

  • Anders Ytterström
    November 5th, 2008 at 18:35

    Sad to hear about this. But there is still time.

    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.

  • Robert Nyman - author
    November 5th, 2008 at 20:22

    Thanks guys.

    Ross,

    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 attachEvent for backwards compatibility (for code that doesn’t use proper object detection), while at the same time implement addEventListener 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.

  • Aldrik
    November 6th, 2008 at 2:52

    Ross,
    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.

    PS. There’s a typo in your post, s/”by know”/”by now”/

  • Robert Nyman - author
    November 6th, 2008 at 3:24

    Aldrik,

    Thanks about the typo!

    Well, W3C could have used it, although it was broken in implementation (with the this 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 attachEvent example, I meant that no actual local event object was available, but the global is.

  • JMG
    November 6th, 2008 at 16:18

    > Sad to hear about this. But there is still time.

    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.

  • Robert Nyman - author
    November 6th, 2008 at 16:50

    JMG,

    The problem is, though, that it will have to be fixed, sooner or later. When will it be addressed? 2010? 2015?

  • Morgan Roderick
    November 6th, 2008 at 22:14

    JMG: delaying IE8 is not acceptable to whom?

    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.

  • Anders Ytterström
    November 6th, 2008 at 22:16

    JMG,

    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.

  • mdmadph
    November 7th, 2008 at 18:09

    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.”

  • Robert Nyman - author
    November 7th, 2008 at 23:39

    mdmadph,

    Given Firefox continuous marketing gain, together with Safari, Chrome and the WebKit rendering engine’s increasing share in general, I think that, sooner or later, Microsoft will have to fix it.

    Only the future can tell, though!

  • Andrew Noyes
    November 10th, 2008 at 4:11

    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.

  • Stefan Van Reeth
    November 10th, 2008 at 9:40

    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 ;)

  • Robert Nyman - author
    November 10th, 2008 at 20:28

    Andrew Noyes,

    Absolutely, they really need to ix things as soon as possible before they’re overun by their competitors.

    Stefan,

    Well, that’s one way of seeing it… :-)
    But just imagine of all that hard work and creativity had been put into something new and better instead of fixing bugs?

  • Stefan Van Reeth
    November 11th, 2008 at 0:47

    That’s quite a painfull thought. Let’s just ignore it :D

  • Richard Fink
    November 13th, 2008 at 2:01

    Robert,

    This question might sound very simplistic but I’m quite sincere.
    What exactly is it that could be done on the client side that would be of great benefit for users that cannot be done now with the workarounds for the IE event model that already exist?
    In other words, what doors open up if IE were to adopt attachEvent?

  • Robert Nyman - author
    November 13th, 2008 at 10:13

    Richard,

    First, it’s addEventListener Microsoft should adopt.

    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.

  • Richard Fink
    November 13th, 2008 at 18:26

    Sorry about the goof. Late night post. addEventListener, of course.

    Anyway, thanks. By not really answering the substance of the question, you answered the question.
    Your answer seems to be “nothin’ particularly important that can’t be done with the workarounds.”
    And that’s what I thought.

    And that helps explain to me - since I think you’re a more sophisticated scripter than I am - why MS didn’t give adding it a high priority in this release.

  • Robert Nyman - author
    November 14th, 2008 at 9:50

    Richard,

    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.

  • Richard Fink
    November 17th, 2008 at 4:49

    Now we’re getting somewhere.
    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?
    That’s all I’m saying. Color me cranky.

    ciao

  • Robert Nyman - author
    November 17th, 2008 at 19:42

    Richard,

    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 XMLHttpRequest, 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.

  • Why inline CSS and JavaScript code is such a bad thing - Robert’s talk - Web development and Internet trends
    November 20th, 2008 at 22:24

    [...] having to bother about event handling quirks between web browser implementations (and believe me, there are some), I recommend using a JavaScript library like DOMAssistant or jQuery [...]

  • Stef
    December 28th, 2008 at 0:37

    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.

  • Robert Nyman - author
    December 28th, 2008 at 23:06

    Stef,

    Glad that you agree!

Share your thoughts:

HTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> . If you want to display code examples, please remember to write &lt; for < and &gt; for >.

Comment preview

Top results