Later on, browsers begin to support these attributes even in other tags like <div>, and pretty much anything else.

However, as web standards develop over the years and people’s coding practices for the web begin to standardize, it is generally considered bad practice to use them. There are many reasons for this, among others:

1. You cannot attach more than 1 action this way. If you want to do a lot of things in one event, you will need to put a lot of code either in this attribute, or in the function being called from this attribute; and these may very well be unrelated actions. This makes your code less organized and harder to develop.
2. No good separation of presentation (HTML) from functionality (JavaScript). Everything is mixed together. This makes collaboration development efforts difficult; and makes the code hard for you to manage even if you were the sole developer.

Fortunately, we have an alternative solution. They are Event Listeners.

Event Listeners basics

Event listeners are initiated strictly in JavaScript code, not within any HTML tags.

For the remaining of this article, I will assume the use of the Prototype.js framework. I’m aware that there are advanced developers who dislike this library, but it is used fairly commonly (either completely, or their own in-house modified version) among a lot of startups and web apps, so hopefully it’s not unreasonable to depend on it.

With that in mind (with the inclusion of Prototype.js), you can initiate an event listener like this. Assuming you defined a function for handling the “click” event on a div block with an id “main_div”:

var handlerFunction = function(event) {
alert('Hello world!');
};

var my_box = document.getElementById('main_div');
Event.observe(my_box, 'click', handlerFunction);

The main idea is very simple. It is simply this: instead of using onclick (or on-* of any event) in any HTML tags, you have Event.observe in your JavaScript code instead. This way, you can add as many different functions as you like to any elements. They can even come from different .js files. (for more details on how to use Event.observe, see the Prototype.js documentation.)

To see what kind of events are available to you other than “click”, see the DOM Events W3C spec. What you will often be using are in section 1.6.2, mouse events.

Page loading, and Initialization routine

If you understand what the above code means, you can also logically deduce that, your event handler does not start being observed until the point this JavaScript runs. And whether you want it or not, when the Event.observe line executes, it will start.

The implication here is that, it is entirely possible that your HTML document is not ready to handle this. This is because JavaScript runs linearly as your HTML file is being loaded and parsed.

More often than not, your JavaScript resides in the beginning of your file. (It is recommended for web developers to keep their JavaScript at the top) That means you don’t even have any objects on your HTML page yet! Your Event.observe line is sure to fail, because the object by the id “main_div” does not exist yet.

So should you put your JavaScript at the end of your page instead? Of course not! What you want is a way to run all your Event.observe lines after your page is fully loaded.

Event.observe(window, 'load', function() {
Event.observe(my_box, 'click', handlerFunction);
// ... any other event listeners go here
});

Once you have this in your JavaScript, all your event listeners will only initiate after your page is completely loaded. The way this works is simple. The “window” element means the entire browser window. The ‘load’ event for this element means that this handler function will execute when the page is done loading. So the effect is that all your interactive elements on your page will start being interactive when the page is fully loaded.

DOMContentLoaded

But there is still a problem! The key word in the last paragraph was “fully loaded”. What this means is, your interactive elements only work after your entire page is ready. Unfortunately, this means after all images and other binary data have finished loading. When your web page is heavy with data, this might be a long time. If you use event listeners for your navigation dropdown menus, for example, that means they are not going to work until all your images are done loading. It would be very annoying if a user cannot use your navigation menu before the page finishes loading.

*This is why I wrote this article!* The key point is here.

Fortunately, thanks to many wise web developers on the internet, we now have a solution. This solution lets you initialize your event listeners as soon as your HTML finishes loading, and without having to wait for images and all other data on your page.

The solution: DOMContentLoaded.

In simple words, this events.js library will let you do this:

addEvent(window, "DOMContentLoaded", function() {
Event.observe(...);
// ...
});

What will happen now is that, all your event listeners will initiate as soon as the HTML of your page is loaded, without having to wait for anything else. I am not going to go through the details of how and why here (I try to make my blog as close to practical usage lessons as possible without being too academic). If you are interested, the link I gave you above should give you every detail you want.

Conclusion

With all of the above knowledge, there is absolutely no reason one should be using the old ways of “onclick”, “onmouseover”, etc. anymore. Many people attempt to use event listeners, but oftentimes they encounter the problem I stated above of elements having to wait for the page to be fully loaded to become interactive. This has turned many people back to using the old-school methods, which is unhealthy. After having introduced you to DOMContentLoaded, it should solve all concerns you have with using event listeners.