views:

139

answers:

2

Is there any reason to use one of the following more than the others:

<input type="button" value="b1" onclick="manageClick(this)" />
<input type="button" value="b2" onclick="manageClick(this);" />
<input type="button" value="b2" onclick="manageClick(this);return false;" />
<input type="button" value="b3" onclick="return manageClick(this);" />
<input type="button" value="b4" onclick="javascript:return manageClick(this);" />

And please do not spend your valuable time to tell me to use jQuery or attachEvent/addEventListener. It's not really the objective of my question.

+3  A: 
<input type="button" value="b3" onclick="return manageClick(this);" />

edit Return is preferable in cases where you wish to control element behaviour, such as for <a> and <input type="submit">, so assuming this is the case, above is your answer, if not just omit the return and just go with onclick="manageClick(this);".

Also, have a look at http://crisp.tweakblogs.net/blog/313/the-useless-javascript-pseudo-protocol.html regarding the use of javascript:. ^_^

kb
+7  A: 

There's no difference at all between the first two, in this specific situation the semicolon is optional.

The third one will prevent any default action from occurring, which the first two won't.

The fourth will prevent the default action or not depending on the return value of manageClick.

The fifth one is incorrect.

(And wherever suitable, use attachEvent/addEventListener -- ducks and runs)

T.J. Crowder
so javascript:manageClick() is the correct way to write it? i thought javascript: was deprecated, and only used in non-event attributes. (edited comment)
kb
+1. but i'd change to "whenever *suitable*, use `attachEvent`/`addEventListener`", and i'd ask myself if it ever is.
David Hedlund
@kb: No, I said "javascript:manageClick" was the *incorrect* way to write it.
T.J. Crowder
@David: Agreed; changed. :-) And yes, it's almost always suitable. You want designers designing your pages, and software engineers hooking things up.
T.J. Crowder
@T.J. Crowder: well yes, but an inline `onclick` attribute will be registered the moment the control is available, which could be some considerable time before DOMReady, which is usually when events are hooked up programmatically (and creating a script block in the middle of the page, immediately after each control, containing a hookup only to that one control, is poor design and poor performance). you may want the event to be registered immediately, in which case you'd have to take this into consideration. if you really don't care about that, then i'll agree it should be done [continued]
David Hedlund
programmatically, but in those cases, i'd advocate the use of a library for this, over `attachEvent`, which will take care of all the browser issues, and has functions for unbinding sorted out already (although I'll grant that `jQuery.bind`, for instance, is just `attachEvent` by proxy)
David Hedlund
@David: Completely agree about using a library to iron out differences and issues around attaching/removing handlers. We'll have to agree to disagree about when and where to attach handlers.
T.J. Crowder
@all, thanks for the debate. As stated above, I use a JS templating engine, and found very useful and fast to do it the old inline way. As my JS to generate this is outside the HTML, it is enough unobtrusive for me. In my opinion, it's even easier to maintain, as you know what's happening just by looking at the generated code. But as I said it was not the point here ;)
Mic
@Mic: Glad this helped!
T.J. Crowder