If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Enjoy an ad free experience by logging in. Not a member yet? Register.

Forgive my conciseness, but in Win/IE, if you attach a function to an event via attachEvent(), window.event is passed in as an argument to it. MSDN does not document this behavior, but it is incredibly useful:

attachEvent is similar to addEventListener in that it allows you to add more than one listener for the same event to the same element object. However, attachEvent has a major drawback - in your listener 'this' will not reference the correct instance, in fact it will point to window or document.

So my advice is...

Always use the DOM0 Events interface unless you specifically need to add more than one listener for the same event to the same element.

Essentially, you shouldn't rely on "this" as a self-reference in addEventListener either, so for all encapsulated event handling, references should be obtained by upwards iteration from target|srcElement.

btw jkd - why do you pass the useCapture argument through, when attachEvent can't use it? Wouldn't it be marginally more efficient to lose that argument, or did you foresee a future extension for it?

Last edited by brothercake; 05-23-2005 at 04:07 PM.

"Why bother with accessibility? ... Because deep down you know that the web is attractive to people who aren't exactly like you." - Joe Clark

Ah, thanks for pointing that out. These issues are why I advise to only use the DOM0 event interface - except in a few cases.

brothercake, in the thread you linked to I notice liorean said this:

Originally Posted by liorean

For W3C DOM events, the Event.prototype.target property should contain a reference to the element which originally dispatched the event, which means that it should be the same as this for a DOM0 event.

Perhaps I'm misunderstanding something by his reference to Event.prototype. I thought event.currentTarget was equivalent to this. There are situations where event.target is not equivalent to this for example during the BUBBLING_PHASE. My understanding was that event.target is only equivalent to this during the AT_TARGET phase. Perhaps I am misunderstanding liorean's statement?

As you know, writing libraries is a whole different discipline from writing scripts for yourself, and for such scripting I generally go by the opposite principle - never use the DOM 0 event interface for event handling on pre-existing HTML elements - only ever use it on elements you created yourself in the script - or you risk conflict with other scripting.

But this is a real problem - target may not be the target you want, depending on the event phase. Now I think about it, this exact problem has bugged me twice before, and I found two different solutions:

- I maintained a manual "bubble flag" so that I could track the flow of events cross-browser

- I just prevented event bubbling on all instances, so the issue never came up

But both of those are solutions of convenience - the first is an ugly hack, the second is not necessarily appropriate. What we really need is an IE-equivalent of currentTarget .... but of course we don't have that.

However IE does support the eventPhase property .. so that's probably the way in - using eventPhase discrimination at the point where the reference to "this" is derived ..

hmm ... need to think about this one

Last edited by brothercake; 05-23-2005 at 05:20 PM.

"Why bother with accessibility? ... Because deep down you know that the web is attractive to people who aren't exactly like you." - Joe Clark

As you know, writing libraries is a whole different discipline from writing scripts for yourself, and for such scripting I generally go by the opposite principle - never use the DOM 0 event interface for event handling on pre-existing HTML elements - only ever use it on elements you created yourself in the script - or you risk conflict with other scripting.

Very good point - but that opens up another big can of worms similar to the one opened by the window.onload event, eh?

Originally Posted by brothercake

However IE does support the eventPhase property ..

?!? are you sure?

Originally Posted by brothercake

hmm ... need to think about this one

Me too - this is a big can - it will take me a while to digest all the worms

attachEvent is similar to addEventListener in that it allows you to add more than one listener for the same event to the same element object. However, attachEvent has a major drawback - in your listener 'this' will not reference the correct instance, in fact it will point to window or document.

So my advice is...

Always use the DOM0 Events interface unless you specifically need to add more than one listener for the same event to the same element.

I played around with similar ideas several years ago - implemented DOM2 Events interface in Javascript for IE4+ as well as NN4 , but I had my fun with those toys and now I don't play with them any more

I played around with similar ideas several years ago - implemented DOM2 Events interface in Javascript for IE4+ as well as NN4 , but I had my fun with those toys and now I don't play with them any more

Well, everybody and their grandma had their fun with this stuff during IE4/NS4 days. But the difference between now and then is that this is using native methods, providing an incredibly light-weight and next to zero-cost implementation (and certainly more of a bug-free experience), as opposed to reimplementing everything from scratch.

Or at least, that's how I justify the bit of time I spent writing this.

Ah, thanks for pointing that out. These issues are why I advise to only use the DOM0 event interface - except in a few cases.

brothercake, in the thread you linked to I notice liorean said this:

Perhaps I'm misunderstanding something by his reference to Event.prototype. I thought event.currentTarget was equivalent to this. There are situations where event.target is not equivalent to this for example during the BUBBLING_PHASE. My understanding was that event.target is only equivalent to this during the AT_TARGET phase. Perhaps I am misunderstanding liorean's statement?

By using Event.prototype I mean that all instances of the Event object have it, but not the Event object itself. This instance would be the first argument to the event listener.

In a correct implementation, Event.prototype.target is always the element the innermost listener is attached to in all phases, but Event.prototype.currentTarget is the element the current listener is attached to in bubble and capture phases. And the this keyword always points to the element the current listener is attached to, not the element the innermost listener is attached to. So yes, you're right about capturing and bubbling phases, and that Event.prototype.currentTarget points to the same as this in those cases.

But then of course, we have two problems I can see: Incorrect implementations (Safari 1.2, maybe later ones too) and implementations where Event.prototype.currentTarget is not present or plainly wrong (Different Opera versions exhibit both these properties. Haven't tested recent builds.) I also recall problems in some other mac browser but can't remember which. OW5 or MSN/OSX maybe?

Of course, the real problem is that using Element.prototype.attachEvent there is no way to get a reference to the element that Event.prototype.currentTarget or this would point to except through encapsulating that in the event registration function. And doing that you've suddenly opened that whole can of worms with iew leaking memory because elements contain references to functions that contain references to elements that... well you know.