Lee <RE**************@cox.net> wrote:
Ed Jay said:
Lee <RE**************@cox.net> wrote:
Ed Jay said:
Thanks, Lee. I'm using onSubmit to call a preliminary validation script
and then submit() to actually submit the form.
Don't do that.
If you want to actually submit the form, have the onsubmit handler
return true. If you don't want it to submit, return false.
<form action="whatever" onsubmit="return myValidation(this)">
I respect your advice, but please 'splain me why it's a bad idea to use
submit().
The simple answer is that it's simpler. The browser is already in
the process of submitting the form. It's just waiting for the onSubmit
handler to give it permission to proceed by returning anything except
false. Why go to the extra step of invoking the submit() method?
Understood. Of course, one could argue that as you're already in a js
routine validating or whatever, it's just as simple to finish in the js.
:-)
A more complete answer includes considerations of users who don't
have Javascript enabled, the chance that some browsers will be
confused by having submit() invoked while they're already in the
process of submitting the form, and the fact that the submit()
method is frequently accidentally clobbered by adding a form
element named "submit".
Yes, you're both 100% correct in this regard. That said, my visitors are
clients using the application as a paid-for service. I require that js be
enabled to take advantage of the service. If they don't want to do that
because they think it makes their system more secure or it blocks popups,
or whatever, we'll be supplying them with dedicated Opera or Firefox with
custom ini files in which js will be enabled.
Certainly, though, for generic web-based application, I agree...use js
sparingly.
Thanks much for the comments and explanation.
--
Ed Jay (remove M to respond by email)
