9

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.

Improve this question
6
  • i could not understand objective your question :( Commented Feb 3, 2010 at 9:40
  • Can I tell you to use input.onclick= manageClick; and have manageClick look at this? It's the simpler form of attachEvent/addEventListener for when you don't need multiple listeners. Commented Feb 3, 2010 at 10:25
  • @bobince. Sure you can ;) But as you know I'm on the templating side, and was just questionning if those "returns", ";", etc... are useful or not. Commented Feb 3, 2010 at 11:41
  • Aha. For a type="button" the return true/false isn't useful as there's no default action to allow/cancel anyway. For a link or submit it can be. But yeah, inline event handlers are generally to be avoided (in every case except one where occasionally you might need it: img onload on static images), and javascript: is very much wrong, a sign the author doesn't know what they're doing. Commented Feb 3, 2010 at 12:12
  • @bobince Avoiding inline events is a kind of religion, a mess aversion or is it something else? Commented Feb 3, 2010 at 21:39

2 Answers 2

Reset to default
8

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)

Improve this answer
Sign up to request clarification or add additional context in comments.

8 Comments

so javascript:manageClick() is the correct way to write it? i thought javascript: was deprecated, and only used in non-event attributes. (edited comment)
+1. but i'd change to "whenever suitable, use attachEvent/addEventListener", and i'd ask myself if it ever is.
@kb: No, I said "javascript:manageClick" was the incorrect way to write it.
@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: 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]
|
4 
<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:. ^_^

Improve this answer

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.