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

By: Testing the Internet Explorer Platform Preview (IE9) – reviewing the good, the bad and the main letdown - Robert's talk

Wed, 17 Mar 2010 14:01:05 +0000

[...] This is something I thought IE8 should not have been released without. [...]

By: Le code CSS et Javascript inline saimal -- css 4 design

Le code CSS et Javascript inline saimal -- css 4 design — Sat, 05 Dec 2009 07:02:12 +0000

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

By: 5 mauvaises raisons pour ne pas installer IE8 | nyamsprod's web labs

5 mauvaises raisons pour ne pas installer IE8 | nyamsprod's web labs — Tue, 24 Mar 2009 10:51:02 +0000

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

By: nietzsche

nietzsche — Thu, 12 Feb 2009 01:10:30 +0000

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

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.

By: Robert Nyman

Robert Nyman — Tue, 10 Feb 2009 08:08:33 +0000

convert,

Glad you agree!

By: convert

convert — Tue, 10 Feb 2009 02:56:45 +0000

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.

By: Extending web browser functionality - Greasemonkey for all web browsers - Robert’s talk - Web development and Internet trends

Mon, 19 Jan 2009 12:35:55 +0000

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

By: Robert Nyman

Robert Nyman — Sat, 17 Jan 2009 12:57:04 +0000

Yaroukh,

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

By: Yaroukh

Yaroukh — Fri, 16 Jan 2009 18:49:39 +0000

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.

By: Robert Nyman

Robert Nyman — Fri, 16 Jan 2009 10:22:43 +0000

JMG,

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

By: JMG

JMG — Fri, 16 Jan 2009 00:14:52 +0000

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.

By: Robert Nyman

Robert Nyman — Sun, 28 Dec 2008 22:06:26 +0000

Stef,

Glad that you agree!

By: Stef

Stef — Sat, 27 Dec 2008 23:37:40 +0000

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.

By: Why inline CSS and JavaScript code is such a bad thing - Robert’s talk - Web development and Internet trends

Thu, 20 Nov 2008 21:24:13 +0000

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

By: Robert Nyman

Robert Nyman — Mon, 17 Nov 2008 18:42:25 +0000

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.

By: Richard Fink

Richard Fink — Mon, 17 Nov 2008 03:49:11 +0000

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

By: Robert Nyman

Robert Nyman — Fri, 14 Nov 2008 08:50:50 +0000

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.

By: Richard Fink

Richard Fink — Thu, 13 Nov 2008 17:26:18 +0000

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.

By: Robert Nyman

Robert Nyman — Thu, 13 Nov 2008 09:13:10 +0000

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.

By: Richard Fink

Richard Fink — Thu, 13 Nov 2008 01:01:08 +0000

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?