I'm hopping that around the community of js developers we can have a consensus around this:
Should we declare or onclick, onkeyup... etc... events inside or outside our HTML document?
1) I do prefer to have them separate. True. 2) I'm also aware that HTML5 adds some new interactive elements on the game...
Regards, MEM
Consider reading about Unobtrusive JavaScript and jQuery.
The current popular opinion is that everything must be unobtrusive, which means that event handler properties such as
someElement.onclick = function(e) { ... };
are widely frowned upon and event handler attributes such as<input type="button" onclick="doSomething()">
are outright dismissed. In fact, there are valid uses for both.The desire to separate behaviour (such as scripted event handlers) from content is a natural one and is a major consideration, but should not be the only consideration. As shown in the summary below, the three methods of creating event handlers have their own advantages and disadvantages, and in a particular situation, separation of behaviour and content may not be the overriding concern.
In conclusion, for a given task, use the simplest method that fits your needs.
Event handler properties
Example
These are particularly useful for assigning an event handler to an element that you create in script and are certain will only ever require one listener.
Advantages
window.event
in IE, function parameter in other browsers)return false
Disadvantages
Event handler attributes
Example
This is the only approach that works when it matters that an element responds to an event before the document has finished loading (see http://peter.michaux.ca/articles/the-window-onload-problem-still for a longer discussion of this). Also, it's the easiest way to add event handlers.
Advantages
return false
Disadvantages
addEventListener/attachEvent
Example (attachEvent equivalent not shown)
This is the only method that allows you to attach multiple listeners to a particular event on a particular object.
addEventListener
is standardized in the DOM Level 2 Events specification.Advantages
addEventListener
is a modern standard, with support in IE 9 meaning that all current major browsers will support on release of IE 9Disadvantages
attachEvent
is not exactly equivalent toaddEventListener
Ideally if you can define your event code and attach those events to matching elements in separate JS files. Separate JS and HTML where ever possible.
Writing event handlers inline has been a solidly bad idea for at least a decade.
Even accessing properties like 'element.onkeyup' is a pretty bad idea.
Use listeners. Better yet a framework.
EDIT: And here's why Tim Down's comment is ridiculous:
If the rationale for ANY programming decision starts with "if you know you're only ever going to need..." then don't do it. Seriously.
"All scriptable browsers" actually means IE5.5+ FF2+ Safari 3+ Opera 9+. That covers 99%+ of web users, and all those browsers support event listeners. Event listeners have major advantages over accessing event handler properties - the big one is that there can be more than one listener for any event. In modern Javascript programming this happens all the time. Special-casing your code to use an antiquated event handling system just because you can is an awful idea, hostile to really good ideas like using libraries and writing unobtrusive, consistent code.
return false;
is a solidly counterintuitive and anti-semantic way to mean "stop bubbling/propagating this event up/down the DOM tree." You know what is intuitive? Common expressions in library code likeevent.stop()
.