Unobtrusive Javascript

http://onlinetools.org/articles/unobtrusivejavascript/chapter1.html
Keep Javascript separate
The first rule of the unobtrusive Javascript club is don't talk about the unobtrusive Javascript club. No, hang on, it is...

1. Never, under any circumstances add Javascript directly to the document.
One of the big powers of Javascript is that it comes in a separate file. Much like CSS, this means you can apply one collection of functions to every page of the site, and if you need to change its functionality, you can do that in one document rather than going through each page.

This means - unless there are special circumstances - all we ever need to see in an HTML document is:

This is all we ever need, no more inline Javascript. Rinse and repeat.

2. Javascript is an enhancement, not a secure functionality
We only use Javascript to enhance a functionality that is already given, we don't rely on it. Javascript can be turned off or filtered out by proxies or firewalls of security aware companies. We can never take it for granted.

This does not mean we cannot use Javascript, it only means we add it as an option rather than a requirement.

3. Check the availability of an object before accessing it
A lot of Javascript errors are occuring simply because the scripter was too lazy to check if a method or an object is available or not.

Javascript:
function color(o,col)
{
o.style.background=col;
}

could result in a Javascript error, when the object o is not available.

Javascript:
function color(o,col)
{
if(o)
{
o.style.background=col;
}
}

works all the time.

4. Keep effects mouse independent
Just making sure that things only work when Javascript is enabled is not enough. We also have to be aware of users who cannot use a mouse at all or only badly. Therefore we must ensure that all effects are triggered by mouse and by keyboard access.

The biggest problem with mouse independence are form elements that get validated or trigger an effect onchange or onblur. Don't use them, it is as simple as that.

Seemingly the main problem is that when you use a keyboard to tab to the element and hit arrow down to select something you can never get past the first option, as send() gets triggered when you go from the first to the second option.

Experienced keyboard users will know though that you have to hit alt+arrow down first to expand the whole drop-down before choosing.

However, this is not known to all users. Furthermore, the example does nothing when Javascript is not available.

What about the onkeypress?

When we read through the Web Content Accessibility Guidelines, we are asked to use device independent event handlers for our scripts:

Otherwise, if you must use device-dependent attributes, provide redundant input mechanisms (i.e., specify two handlers for the same element):
- Use "onmousedown" with "onkeydown".
- Use "onmouseup" with "onkeyup"
- Use "onclick" with "onkeypress"

This sounds perfect in theory, but in real life situations, the onkeypress handler is badly supported in different browsers. Users that are dependent on keyboard browsing do normally have a key set up to simulate clicking, either the enter key or space bar, and both of these do fire the onclick event. By using onkeypress we might hijack other keyboard functionality the user wants. Examples are the type ahead functionality of Mozilla, Opera's extensive keyboard shortcuts (like 'A' for next link) or JAWS' keyboard controls.

So by doing the right thing according to the accessibility guidelines, we might make our script even less accessible.