views:

55

answers:

4

Using the "Good Parts" defaults on JSLint, the use of HTML event handlers (such as onclick) is not allowed.

What is the logic behind this? What is bad about them that should be avoided?

+1  A: 

I think the reason is this:

When you use a default event handler, there can only be one registered function.

There might be one defined already (via the onclick attribute), and when you re-define it in JS code, the original handler gets lost, possibly breaking functionality. This cannot happen if you take the "add event handler" route (for example via jQuery's bind()).

For a small web app that you control completely, this might be okay. If the JS code you are writing is a plugin/library of some sort, this behavior becomes unacceptable.

Tomalak
`frozenPole.onlick = alert('I thzink I'm thduck...!');` Or in other words, you have an amusing typo.
Andrzej Doyle
@Andrzej Doyle: Thanks. :)
Tomalak
+2  A: 

The logic is best summed up by the phrase "separation of concerns", which is a common tenet of software engineering. In this case, having an inline event handler in the HTML is bringing a behavioral concern (event handler) into your presentation concern (HTML). For some ancient advice, see Unobtrusive DHTML, and the power of unordered lists. Other good sources are A List Apart and of course Wikipedia.

Mike McCaughan
+1  A: 

Nothing's wrong with them. However, you can only attach one listener via that method (as opposed to using addEventListener / attachEvent, which allow multiple listeners). This may not be a problem for a simple application, however.

The other issue is that if you're using event handler attributes in your HTML, you are mixing content with behaviour. This is not ideal and the unobtrusive JavaScript crowd will tut at you for doing it, but again, achieving this separation is not the only consideration and for a very simple application I'd favour this method for its simplicity. There is also a feature of event handler attributes that no other mechanism has, which is that the JavaScript behaviour is available immediately after the element is rendered rather than once the document has loaded (the typical time you would otherwise assign an event handler).

Tim Down
+2  A: 

Using the "Good Parts" defaults on JSLint, the use of HTML event handlers (such as onclick) is not allowed.

The use of event handlers in the actual markup is flagged, yes:

<div onclick="...">

This is generally considered bad practice. Mixing scripting behaviour into markup is hard to read and manage; easier to keep all your scripting together, in an actual script, so you don't have to delve into your markup to find what scripting hooks are being called.

Also, by putting your script code in a context where it needs HTML-encoding, you are adding an extra layer of escaping confusion. You end up saying nasty stuff like:

<div onclick="if (a&lt;b) this.innerHTML= &quot;I said \&quot;Hello &amp;amp; welcome!\&quot;&quot;">

naturally it's difficult to get this encoding right, and if you're dealing with dynamic values an incorrect combination of encodings leaves you with a script-injection (XSS) problem.

The same in a standalone script:

somediv.onclick= function() {
    if (a<b)
        this.innerHTML= "I said \"Hello &amp; welcome!\"";
};

is one escaping level clearer.

JSLint does not complain about this usage. Whilst some would argue that using listeners is better as you can add multiple listeners to an event, that's more of a heavyweight solution, as you have to work around IE<9's attachEvent instead of addEventListener, and perhaps provide something for older browsers that support neither.

bobince
The escaping/xss issue is a good point
Nathan Voxland
I agree the escaping point is a good one, but can be mitigated somewhat by calling a function defined elsewhere within the attribute. One other point is that there's no browser worth worrying about that doesn't support one of `addEventListener` and `attachEvent`. Even IE 5 has `attachEvent`.
Tim Down
@Tim: Depends. Today's mainstream desktop browsers all support one or the other (or both!), but once you start looking at mobile and other niches like old-school nettops, things get creakier. If you're unlucky enough to be developing for IEMobile<8 the event-handling possibilities are very limited.
bobince
@bobince: Fair enough. I know next to nothing about IE Mobile, or most non-WebKit mobile browsers, having not had the misfortune of having to work with them.
Tim Down
Yeah, probably best kept that way really. IEMobile before version 8 (also known as IE 6 Mobile, because Windows Mobile version numbering has always been deliberately, confusingly obtuse) is a special horror that recalls the nightmare Netscape 4.
bobince