A couple reasons. It's essentially an alias to the DOM Level 1 interface of element.onclick
, which only allows for one event listener.
Another reason is that it's simply philosophically wrong. It leads to poorly organized code: You're mixing a declarative language with a functional language which incorporates massive amounts of logic in its execution.
The proper way would be:
element.addEventListener('click', function() {
console.log('hello world');
}, false); // required for old gecko
Or in IE:
element.attachEvent('onclick', function() {
console.log('hello world');
});
or at the very least, use the DOM level 1 model:
element.onclick = function() {
console.log('hello world');
};
(Also note, alert
is bad practice, it will block execution of the entire page.)
Another reason would be, you don't get access to any kind of event object you would normally get as the first argument of the listener's callback. (You're essentially inside a callback when setting on[event] attributes, so I'm not sure if you can do arguments[0] or how different rendering engines implement it. It's very awkward, which is why it's best to bind events in JS-land.)
The final reason I can think of would be cross browser compatibility. You can't ever normalize an event interface for yourself if you're binding events in HTML.