addEventListener in IE failes

[jonaveen]

I'm trying to add a clickevent to an anchor that I created trough DOM.
This his how the code looks:

var oSubLink = document.createElement("A");
oSubLink.appendChild(document.createTextNode("+"));
oCel.appendChild(oSubLink);
oSubLink.addEventListener("click", klapUit(oTabel.id, eigenschappen[2]), false);

It failes at the addEventListener call, saying "No such interface supported" (appears to be one of the two default error messages IE gives when it can't handle your JS :mad: ).

How can I fix this? The solution should work in IE6, FF, Opera, Mozilla and Safari.

[Kor]

try the DOM 0 simple, trusty and crossbrowser method to attach events:

oSubLink.onclick=function(){klapUit(oTabel.id, eigenschappen[2])};

[Bill Posters]

try the DOM 0 simple, trusty and crossbrowser method to attach events:

oSubLink.onclick=function(){klapUit(oTabel.id, eigenschappen[2])};


Nah. DOM 0 overwrites any pre-existing events on the targeted object.

We should at least try to use the less destructive methods first and fall back to DOM 0 only when neither addEventListener or attachEvent are supported (possibly not even then, some would argue).

- - -

jonaveen, …

IE6 doesn't support the W3C addEventListener method. (Not sure about IE7.)
IE6 uses a proprietary attachEvent method, which means we're still stuck in the good, old days of using browser-specific coding for some tasks.

To alleviate this, some developers have started working with their own, custom 'addEvent' methods which build in the appropriate methods in order for them to work x-browser.

I personally use a method based on the PPK "contest winner" approach touted in this article…
ParticleTree: Catching Up with addEvent (PDF, 270KB) (http://particletree.com/files/designersguide/AddEventHistory.pdf)

// The method I use

function addEvent(obj,type,fn) {

if (obj.addEventListener) {
obj.addEventListener(type,fn,false);
return true;
} else if (obj.attachEvent) {
obj['e'+type+fn] = fn;
obj[type+fn] = function() { obj['e'+type+fn]( window.event );}
var r = obj.attachEvent('on'+type, obj[type+fn]);
return r;
} else {
obj['on'+type] = fn;
return true;
}

}

e.g. …
addEvent(window,'load',doSomething)

[jonaveen]

Thanks, guys.

Bill, I completely see your point, but... (could have expected that :) ).
... because I create the node and attach the event in the same method, I can and will asume that there isn't any other event attached already.
For ease of use, better readable code and maybe even better performance I will go with Kor's approach.

[Kor]

Nah. DOM 0 overwrites any pre-existing events on the targeted object.

Sure. But in the case of a new created element, there is no previous same event already attached, so that there is nothing to be overwritten...:)

[Bill Posters]

I was speaking generally.
That said, I'd still personally regard it as preferable to go with an addEvent approach, but I guess that's down to preferences in this instance, so long as the intentions for the object(s) don't change from their current uses.

I've made addEvent part of my workflow/library, so it's my first instinct nowadays, hence the perhaps evangelic approach. ;)
I feel that it's better to learn and adopt (and teach) a single, reliable approach rather than chop and change depending on circumstances, particularly when introducing new techniques to those relatively new to the task.

But, like I say, it was general advice. :)

[Kor]

Almost always there is no need to add a function to an event, but to create an new event or the change it entirely. So that almost always there is no need to use an intricate code of about 12 lines instead of one of a simple 1 line.

I know, we all know, the IE/Moz different codes to attach events, but we are to use them only when it is really needed, that means always never.

[Bill Posters]

There are a good number of respectable developers who presumably disagree and consider there to be a need for an addEvent method.

I've certainly encountered situations where it's desirable to add a further event to an object which may or may not already have an instance of that event. This sort of situation is potentially even more likely when code development is the accumulation of input from more than one person or possibly even more than one company.
Add to that the fact that DOM 0 method may not enjoy the level of support under application/xhtml+xml (or similar) as they currently enjoy under text/html.

For me, it's about flexibility.

You're free to use whichever approach feels most appropriate to you.
I'll do likewise by taking a 'just in case' approach, particularly when doing so means only an extra 10 or so lines of code (c.350 bytes), all of which will be cached on the first pass.

Each to their own. ;)

The intricacy is largely academic. I myself don't completely understand how the addEvent function that I'm using works. Tbh, I've never taken the time to look at it properly. It's a frankenscript put together from bits of other addEvent methods that I've seen.
Still, I do know that it does work and that's really all that matters.

You don't need to know how it works, you just need to know that it does - and how to use it. :)
That's why 3rd party libraries are becoming ever more popular.

(…though, I personally prefer to stay within intellectual arm's length of the code that I use, so tend to work with a smaller, more focussed library of my own compiling, rather than going for something like Prototype or YUI, both of which are far more convoluted than I like things to be.)

Anyhoo. … :)

[Kor]

I said nothing wrong about other variants/methods. You started and said DOM 0 is not good. I said is good, according to the needs. If other needs, other variants/methods are to be used as well.

[Bill Posters]

I said nothing wrong about other variants/methods. You started and said DOM 0 is not good. I said is good, according to the needs. If other needs, other variants/methods are to be used as well.

Maybe I'm just having a little trouble understanding what you're saying.

This sounded pretty resoundingly against non DOM 0 approaches:
I know, we all know, the IE/Moz different codes to attach events, but we are to use them only when it is really needed, that means always never.
"…always never" sounds pretty much against other variants/method.

I said is good, according to the needs.

I prefer to use (and recommend) a single, reliable, progressive approach rather than using (and recommending) DOM 0 first and foremost.
I don't tend to favour the 'only use modern standards when absolutely needed' approach.
Modern, standards-based approaches are my first attempt, building in progressive fall-backs for backwards support.

It's a habit which I feel is more straight-forward (v-a-v 'learn once, use many') and more likely to demonstrate the flexibility and shelf-life that I desire in my output.

I prefer to use - and pass on - techniques which come with as few caveats and conditions as possible.