There are several FAQs based on issues of using the ENTER key in a text field for submitting a form. Some folks want to make it possible, in order to simplify the submission of an otherwise straightforward form; while others want to prevent it, in order to avoid inadvertent submission of a partially-completed form.
For widest browser support,
form should have just one
The form may of course have other form elements (checkboxes,
There's a clue in the HTML 2.0 specification, in the section entitled Form Submission, logically enough:
When there is only one single-line text input field in a form, the user agent should accept Enter in that field as a request to submit the form.
This was evidently meant as a convenient way to submit simple
queries, but reducing the risk, on a complex form, of prematurely
submitting it while trying to fill it in.
Numerous browser implementers (e.g Netscape, Opera,
various versions of Lynx,...)
followed this advice, though it seems with slightly different
If you use only one "single-line text input field" (i.e
input type="text"), along with other kinds of form
widget such as buttons, selections etc., then these browsers will
submit the form.
Some (e.g Netscape) did this even if the form also contained
multi-line input field(s) i.e
textarea element(s), but
some others will not.
Therefore, for widest accessibility of Enter=>Submit, you would
want to use no
textarea elements in the same
There's nothing more that the author needs to do in order to
make this possible, and nothing that the author can do,
within the context of HTML itself,
to help a browser that doesn't make this possible: the HTML4
specification makes no particular ruling about what Return or Enter
should do (and it looks as if recent versions of Lynx have
a different behaviour in this respect).
So, you really have to include a Submit function
(preferably a straightforward
to be sure that all bases are covered.
Note that a page can contain several forms: almost all of the browsers tried were applying the rule to each form separately.
You can't completely prevent a browser from submitting a form, at least not in all circumstances: to do the job properly (no matter what you might do additionally with client-side scripting to reduce its likelihood), one needs some reliable means of detecting at the server that the submission is somehow irregular or incomplete.
With earlier browsers, if you had at
input type="text" elements in a form,
most browsers were discouraged from submitting the form via Enter.
However, this was never entirely reliable, and it's much less so
nowadays as we will see.
With MSIE4 and later, there are more situations
where hitting Enter will submit the
form. This was even claimed to be a usability enhancement.
There seems to be some confusion/disagreement among browser developers as to whether a Submit control is a "successful control" (in the terms of e.g the HTML4 specification) when a form is submitted by means of Enter.
If the "focus" is on the submit button (e.g moved there with TAB) at the time that Enter is pressed, then the submit button's name/value pair gets sent, and this seems entirely reasonable. What's in question is what ought to happen when Enter is pressed while the focus is somewhere else.
MSIE4's behaviour seemed odd.
If there was only a single text-input field, then hitting
Enter with the focus on the text-input field would
submit the form without sending the name/value
pair associated with a submit control.
Surprisingly, however, if there were two text-input fields,
then hitting Enter when the focus was on either of those
fields would result in the form being submitted together
with the name/value pair of the submit control (or
of the first submit control if there were more
This seemed illogical and inconsistent.
onclick action on the submit button
would be triggered, whereas the single text field case would not;
or to say the same thing in different words, the browser behaviour
in the multiple text fields case was just as if the Submit button
had been pressed, but the behaviour in the single text field case
And some of this behaviour was inherited by later MSIE versions, although there seem to be differences of detail.
MS's presentation of the
type=submit control can be
found in the "Remarks" at the foot of the MSDN workshop page on
It seems (or do you read this differently?) that if the first
type=submit has a
name attribute, then
it is treated as a "successful control" in the meaning of the HTML4
specification, even if the form was submitted by means of ENTER,
without making any use of the submit control
If you want to make some effort to detect accidental form submissions via Enter, then you can evidently have your form evaluation script verify that the name/value pair associated with the submit button is actually present, and give the user a second chance if it isn't. However, as we see, this won't always work reliably.
And in a separate discussion on accessibility issues, a commentator
was complaining about a form which used
type="image"...> where the server was evidently looking
for the specific name=value pattern returned by that control, and was
complaining that if he put the focus on the image and used Enter to
submit the form, the server rejected the submission.
This he rightly criticised as an accessibility fault.
Jukka K. had an interesting idea here: you could put two submit buttons, the first one marked "Preview" and the second marked "Submit". Then, if you either don't get a submit-button's name=value pair, or you get the one belonging to the Preview button, then you simply redisplay the filled-in form. That looks a neat solution, as long as the consequences of an error are not too drastic: if they are, then see further discussion later in this page.
John Sutton of SCL contributed the following interesting variation, which of course goes in place of Jukka's "Preview" button:
<input type="image" border="0" name="refresh" src="transparent-1x1.gif">
Server side you just need to look for submissions of refresh.x or refresh.y and act appropriately.
This avoids having to mess up your beautifully crafted piece of screen design just to cope with another stupidity from the Evil Empire ;-)
Well, that's true, but it needs some care and attention to make sure that users of text-mode browsers, screen-readers etc. are not confused by the presence of this item in the form.
It's certainly possible to have the
onsubmit intrinsic event for the
validation and either allows the submission to proceed or
stops it with an appropriate warning to the user; and such
a script could be a useful optional extra. However, it should
again be stressed that in a WWW context you cannot absolutely
assure that your users will execute these scripts, and so the
server must still be programmed to handle anything which the
client might throw at it.
In 2001 it was noticed that Mozilla 0.9.5 had started behaving rather like MSIE: there's a bug report, 104211. It says that the change was made in order to align with MSIE's behaviour, which apparently some server-script authors were relying on; and a lively argument developed.
I can't see any justification based on the HTML4 specification for considering a submit control that has not been used, to be a "successful control" in the terms of this specification. However, the spec does not seem to clearly rule it out: the relevant section says no more than:
- If a form contains more than one submit button, only the activated submit button is successful.
It says nothing directly about what happens when no submit button is used!
However, the basis of the argument being used by the proponents of this new Mozilla behaviour seems to be not so much conformance to specification, but a principle of least astonishment to server script authors. Given that these authors already should have been dealing with the behaviour of non-MS browsers, I don't see what's the big deal. If those authors are writing broken scripts, then they better fix them, rather than expecting Mozilla to sort them out by imitating illogical behaviour found in some other browser-like object, no matter how popular it might be. There also seemed to be some kind of belief that a submit control which had not in fact been used to submit the form, could be treated differently depending on whether it had an explicit name: I personally don't see the difference - if the submit control was not used for performing the submission, then in my view it is not a "successful control", irrespective of whether the HTML gives it an explicit name.
An email correspondent writes (March 2004, Firefox 0.8) to say that submit-on-enter appears to be including the first "submit" control with the submission if the focus was on a text input, but omits it if the focus was on a radio button or checkbox. It's assumed that this applies also to other Mozilla-based browsers.
Anyhow, if you're in this situation and you decide to use a solution based on one or other of the workarounds shown above, you should be set for either kind of browser behaviour. There's nothing to beat designing your server-side scripts defensively, rather than just making them work in the specific situations you tested and - leaving the rest to chance.
There's a type of spammers who have bots hunting the web, looking for forms to submit, and trying to submit a copy of their spam to them. I'm told that having a first submit "control" which only previews the changes, and a second submit "control" which performs the actual posting, has been found to be quite an efficacious defence against such robots, which aren't yet clever enough to recognise the difference, and will use the first submit "control" which they get to. Until they catch up with our defences, then, this looks like a useful move.
If you have several "submit controls", and one of them performs an operation which is sufficiently drastic, then I would recommend that you consider some alternative way of protecting against accidental invocation of this operation. In view of the uncertainties described in this page, it seems advisable to avoid relying on multiple submit controls in such critical cases: instead, you could use some kind of checkbox or select control to indicate the desired function, with the defaults set for a harmless preview of the requested operation, and the critical operation(s) requiring some positive action by the user before submission: the actual form submission being done with a single Submit control. Examples that have been seen in practice are e.g an ordering form with a final checkbox "I have read and agree to the terms of ordering from this site", and without which the actual order will not be accepted; another example was a collaborative editing site with a select pulldown "Preview changes so far" (default) and "Submit revised document".
Well, in any case it's good practice (I'd go so far as saying it's indispensible) to field your form with a server-side script that evaluates its contents and rejects it politely if it seems to be incomplete or defective, offering the user an opportunity to try again. The nicest way to do this is to use (something like) CGI.pm, and have it write the original form: if the submitted form is incomplete or defective, then have the script rewrite the form, with their previous acceptable input pre-entered as the default, so that they can continue where they left off. The alternative, displaying a simple error page and expecting the user to go "Back" to the page with their original form on it, exhibits various different browser behaviours, and so is best avoided.
By the way: I think it should be said quite strongly that
trying to launch forms submissions off directly
as email with a
action simply isn't good enough, no matter how convenient it
might at first seem.
Last changed Saturday, 15-Apr-2006 17:27:19 BST
Original materials © Copyright 1994 - 2006 by A.J.Flavell & Glasgow University