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

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.

Posted in Developing,JavaScript,Technology,Web browsers |

44 Comments

  • Daniel says:

    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 says:

    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. :(

  • 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 says:

    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 says:

    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?

    <code>Element.prototype.addEventListener = function(action, fn, phase) {

    var self = this;

    return this.attachEvent('on' + action, function() {

    return fn.apply(self, [window.event]);

    });

    }</code>

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

  • 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 says:

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

  • Aldrik says:

    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 says:

    Aldrik,

    Thanks about the typo!

    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.

  • JMG says:

    > 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 says:

    JMG,

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

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

  • 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 says:

    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 says:

    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 says:

    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 says:

    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 says:

    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 says:

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

  • Richard Fink says:

    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 says:

    Richard,

    First, it's <code>addEventListener</code> 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 says:

    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 says:

    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 says:

    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 says:

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

  • [...] 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 says:

    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 says:

    Stef,

    Glad that you agree!

  • JMG says:

    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.

  • Robert Nyman says:

    JMG,

    Interesting. Well, that’s useful for extending it, but the core functionality is still very missing.

  • Yaroukh says:

    C'mon, just ignore MSIE8 on your non-commercial websites.

    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.

  • Robert Nyman says:

    Yaroukh,

    Ignoring it is not an option. And yeah, no idea about the name.

  • [...] most userscripts are written with standards-compliant web browsers in mind, meaning that due to improper event handling and such in IE, a lot of userscripts won’t work in [...]

  • convert says:

    Thanks for the code, glad to see it's allowed this way or at least that we know about it. And yes as per your current article I too stopped developing for the old Internet Explorer 6.

  • Robert Nyman says:

    convert,

    Glad you agree!

  • nietzsche says:

    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!

    reference: http://www.w3schools.com/browsers/browsers_stats….

    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.

  • [...] est pitoyable. C’est exact, et je m’en pleins quotidiennement quand je code un site. Mais au lieu de voir le verre à moitié vide, voyons le verre à moitié plein. la IETeam n’a pas modifié le comportement de son [...]

  • [...] d’implémentation de la gestion des événements entre les navigateurs (et croyez-moi il y en a quelques-une), je recommande l’utilisation d’une bibliothèque Javascript comme DOMAssistant ou [...]

  • Mitch says:

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

  • Robert Nyman says:

    Mitch,

    Hmm… Never seen that behavior, but I can understand the problems it might be causing you. What about document.addEventListener?

  • Mike says:

    The mouse events crawl on a busy page. So you cannot drag items i.e. custom scrollbars and moveable divs and such. NOT A PROBLEM in Firefox.

    I think microsoft hired to many developers from india, the same programmers that program navigation systems in your car – CRAP!

  • [...] Internet Explorer 8 – fix event handling, or don’t release it [...]

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>