Form onsubmit versus submit button onclick

Question

UPDATE From @BrendanEich ‏

@mplungjan onclick of submit just falls out of that being a button; form onsubmit is clearly better.

---

Which would be the reasons to ever use the onclick of a submit button to determine whether or not the form should be submitted?

I believe strongly that

1. to execute something before submit and cancel the submit in case of error, the form's onsubmit event is the obvious place to put it
2. If you use the onclick of a submit button and later decide to use type="image" the event handler will fail in many browsers
3. if you change the submit to a button, you will have to add a submit to the onclick event handler too.

I am looking for strong reasons to prefer using a submit button's onclick event over the form's onsubmit.

UPDATE: Please note that I am personally well aware of many of the issues around form submission and validation.

For example that submitting by javascript will not trigger the onsubmit http://jsfiddle.net/mplungjan/3A4Ha/

<form onsubmit="alert('onSubmit called')">
    <input type="text" value="This will submit on enter but in IE the onclick is not triggered" style="width:100%"/><br/>
    <input type="submit" onclick="alert('Clicked')" />
</form><br />
<a href="#" onclick="alert('Submitting by script'); return false">Submit by script will not trigger onsubmit</a>

Also that IE will not trigger the onclick if you hit enter in the form in my fiddle

---

History:

Got into a discussion here

html button not clickable without being disabled

I have an intense dislike of using the onclick of a submit button for ANYTHING due to many¹ years of seeing this not work in a number of browsers, mostly older version of IE. I have listed a few of the obvious reasons, but I am sure they will not convince the hardened user.

Can SO's community help me nail this one to the wall, like they nailed w3schools? Also feel free to give comments as to how I can phrase this question in an acceptable manner.

---

^{1: since the days of NS2.x and IE3.02}

Ruthenium

Looks more like a discussion than a question... look out!! Oh, I agree with using submit event. :-) – Thagard

I agree with using onsubmit of the form - this also covers you for submit via the enter key rather than the submit button. – Enmity

Possible duplicate: #4529512 – Saltation

No Paul it is NOT a duplicate. I know the difference. I am looking for good arguments on not to use the onclick at all. – Ruthenium

A downvote without a comment is the most useless action at SO. – Ruthenium

Answer 1

Form onsubmit is a more correct approach, for the simple reason that a form can also be submitted with the <ENTER> key, and not just by clicking the submit button.

Railey

That too :) But I tend to give a more practical example. Good call though. – Concomitant

Just for the sake of completeness, for future visitors. :) But yes, you covered 99% of the use case, which is why I just commented on your answer instead of adding my own. – Davisson

@Paddy: submitting using script is a special case since it bypasses the onsubmit handler - see update – Ruthenium

@Rikudo - not a reason. If there IS a submit button, it will be clicked when you press enter in a text field - see the fiddle in my update – Ruthenium

@Ruthenium Go figure. Learned something new today. :) – Davisson

True, but there aren't always submit buttons. – Concomitant

Actually IE will not click the button so you are partially correct. In this question assume there IS a button – Ruthenium

There's nothing to assume here. onsubmit is a more general solution the onclick, period. – Concomitant

I agree - but need some kind of authority. – Ruthenium

Also, when you use onsubmit, the value of the button is submitted, allowing you to have more than one submit button with slightly different behaviour – Strap

Answer 2

There are no direct reasons to use a from’s onsubmit handler over a button’s onclick handler. One should use named events according to their intent.

You may consider a scenario with two actions – a “send” action (as in “to send an e-mail”) and a “save” (as in “draft”). The former action assumes the form filled in a coherent manner, while the latter action should allow the user to persist whatever state the user likes. That makes the click handlers ideal places to decide on validation and cancellation. The relevance of the submit event in this case is undetermined.

To make the matter even more complicated you may add auto-save and optimistic concurrency to the scenario.

IMHO The years of tries and errors in the matter resulted in the HTML5 standard to have ruled the question in favor of the button element. See button’s [form*] attributes that allow to change the form action, method by each button individually.

Mt

The form attribute is the ONLY reason it makes sense to me. I would never use a submit button's click event to submit the form. If I needed to have more than one button, I had type="button" - now I could consider the form="" but likely would not – Ruthenium

I agree with type-button alternative, yet it does not make the end-user experience different. It just illuminates that the form/controls model is incomplete in some sense. Different user input (mouse, keyboard) may lead to the same action while there may be a few different actions subordinate to the form. In fact, the “submit” and “reset” are categories from another dimension with respect to “click” and “validate”. – Mt