Writing unobtrusive JavaScript with MooTools

Unobtrusive JavaScript is a set of techniques and principles for writing code that's separated from your web page's structure.

It's best to learn about unobtrusive JavaScript by way of example.

An "obtrusive" JavaScript example

In this example, you'll see JavaScript code that works perfectly fine but doesn't adhere to unobtrusive JavaScript principles. The script contains a function called mouseClick() that, when triggered, opens up an alert dialog box with the message, You clicked me!.

The HTML markup is a simple unordered list of links. The hyperlinks<a> are assigned an onclick attribute which triggers the mouseClick() function when you click on them.

<html>
<head>
<script type="text/javascript">
// A simple function that opens an alert dialog box with a message
function mouseClick()
{
alert( 'You clicked me!' );
}
</script>
</head>
<body>
<ul id="nav">
<li><a onclick="javascript:mouseClick();" href="#">Home</a></li>
<li><a onclick="javascript:mouseClick();" href="#">About</a></li>
<li><a onclick="javascript:mouseClick();" href="#">Contact</a></li>
</ul>
</body>
</html>
An "obtrusive" JavaScript example

What's so bad about it?

If the script works as intended, then what's the big deal?

Imagine this scenario: you have a 30 page website and each web page has to have that list of links; if you noticed, the unordered list (<ul>) tag has an id attribute of nav, so let's pretend that this is your site's primary navigation. You would have to go through all 30 pages to add mouseClick() to the list of links found on each page. This would be very time consuming.

Don't repeat it if you don't have to

That's a lot of repetition, and you'll be breaking a lot of MooTools' core developers' hearts because they designed the framework with the Don't Repeat Yourself (DRY) principle.

If you have to manually implement that block of code, there's a big chance that you'll commit an error that can result in your web pages rendering incorrectly or behaving unexpectedly.

It'll be hard to maintain

Say that for some reason, you want to add something else to the onclick attributes of the links (like calling another function) or remove it entirely. Whenever there's a change to the onclick attribute, you'll have to go through each page and change them. That's not an ideal situation, especially because by writing unobtrusively, you can sidestep this issue and write a more maintainable code base.

It's a bad practice to have functionality in your content structure

Modern web development best practices encourage separating your web page's content/structure (HTML) from its presentation (CSS) and behavior/functionality (client-side/server-side scripts). By relying on the onclick attribute, we're intermixing our web page's structure with its behavior (opening a dialog box when the link is clicked).

Separating structure, style, and functionality goes back to maintainability; it allows us to keep things separate so that we can work with each component individually without affecting the other components. This involves taking out all inline event handlers (namely, the onclick attribute on our<a> tags).

Adding on event handlers directly into the HTML could also cause memory leaks in Internet Explorer and make adding multiple events of the same type impossible.