No problem.

Sorry for the mix up.

Yes, it’s mentioned in the post. The problem lies with IE and its own event handling, and how to get around that.

type: The Event type, without the “on”. Example: ‘click’
listener: The function that will handle the event.
useCapture: I’m not sure what this is, but according to w3 is states that if the user wishes to initiate capture.

Example:

<input type="button" id="btnTest" value="Click Me" />
<script type="text/javascript">
document.getElementById('btnTest').addEventListener('click', btnTest_Clicked, false);
document.getElementById('btnTest').attachEvent('onclick', btnTest_Clicked);
addEvent(document.getElementById('btnTest'), 'click', btnTest_Clicked);

function btnTest_Clicked(evt)
{
evt.target.value = 'You Have Clicked ME!!';
}
</script>


To my knowledge, when the onunload event occurs, it’s not possible to tell if the window has actually been closed or just reloaded.

Interesting. You’re absolutley right. I never work in environments with frames so it didn’t occurr to me.

event = event | window.event;

this assumes you only have one window and will only work if one attaches events to the same window containing the script. If one needs to attach events to other dynamically created windows or iframes that will not work.

I believe that something like this will work in Aaron Moore code:

event = event || (((this.ownerDocument || this.document || this).parentWindow || window).event);

Also, see the latest Dean Edwards addEvent() source to see how this line has been modified to fit his code.

Diego

I’ve seen it, and to be honest I haven’t read all of the code for it. However, I don’t want to be dependable on Yahoo’s JavaScript libraries, I’m just looking for the most light-weight and easiest addEvent.

See Dustin Diaz’s Review

As far as I know, Gecko-based web browsers have supported capturing for a long time too.

But I agree with you. If you want to handle events consistently across web browsers, playing around with capturing isn’t that interesting.

Aaron,

Good luck!

Essentially, what I want boils down to 3 things: your opinion of the design itself, testing of browsers I can’t test, and testing of performance.

1) Opinions

I haven’t managed to get a single javascript developer to read through the code and give me an opinion of the design. Is this method as wonderful as I think it is? The quick explanation should be enough to make the code accessible. It is documented. The long explanation is comprehensive. Reading it should leave you with no questions.

2) Browsers

I don’t have easy access to a Mac. I believe that my functions will work on IE 5.5 on Mac, but I haven’t been able to test it yet. Any old browsers, or rare browsers which support javascript would be appreciated. If the table on the testing page does not already have an entry for a browser you have, I probably can’t test it. This is important to me because I want them to support all browsers that a person might want to do DHTML programming in.

3) Performance

After the addEvent contest on Quirksmode, some performance issues, such as ‘memory leaks,’ were brought up. I don’t have experience testing performance in javascript, but since I mean these functions to be as good as possible, I want them to be efficient in time and memory. If you have experience doing this kind of testing, I would love to hear from you.

Please, email me (two.a.ron [at] gmail [dot] com), or post comments on the explanation page.

Thanks again,

–Aaron

While I understand your position, what you’re missing out on by using inline event handlers is, most likely, accessibility (it depends on what element you’re applying the event to) and also that the user will have to load a lot of extra kilobytes for all those extra event handlers, as opposed to having all the events in a JavaScript file that will be cached by the web browser after the first visit to your page; i.e. unnecessary extra bandwidth usage.

Something that might address your concerns and apply JavaScript events as soon as possible to a web page is by not using the window.onload event, but instead by using the approach suggested by Dean Edwards: The window.onload Problem – Solved! and window.onload (again).