Internet Explorer 8 - Fix Event Handling, Or Don’t Release It
Join the DZone community and get the full member experience.
Join For FreeSomething 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 keywordthis
in the event handling function refers to thewindow
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.
Published at DZone with permission of Robert Nyman, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Trending
-
Unlocking the Power of AIOps: Enhancing DevOps With Intelligent Automation for Optimized IT Operations
-
Mastering Time Series Analysis: Techniques, Models, and Strategies
-
Exploratory Testing Tutorial: A Comprehensive Guide With Examples and Best Practices
-
Microservices With Apache Camel and Quarkus
Comments