FORM submission and the ENTER key?

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.

ENTER to act as Submit: the short answer

For widest browser support,
the form should have just one input type="text",
and no textarea.
The form may of course have other form elements (checkboxes,
select etc.)
present.

Long answer

N.B. this FAQ is primarily about HTML FORMs.
If you are doing client-side
scripting (Javascript, etc.) with your FORMs,
there will be extra complications, which this FAQ only touches upon.
Keep in mind however that you cannot
force your users to execute Javascript: a malicious user could even
take your source code and modify it before using it to submit
something to your server, so your server needs to be
able to cope with anything that a client could throw at it.

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
interpretations.
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
form.

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 input type="submit")
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.

Preventing Enter from submitting?

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
least two 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.

"Successful controls" on Enter?

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
than one).
This seemed illogical and inconsistent.
And, any 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
was not.

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 input type=submit.
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
in question!

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 <input
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:

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
form calling up a Javascript routine which performs some
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.

A reader has suggested that I include an actual Javascript recipe for
suppressing the use of Enter as a submit function.
This reader cited a recipe which is included in a Javascript FAQ at
www.irt.org, but when I passed the recipe by Jim Ley
(curator of the respected comp.lang.javascript FAQ),
it got the thumbs-down, with the words
"please take all references to that useless script away".
Although this page is not the place for a Javascript tutorial,
I would mention that J.Korpela
discusses the issue and provides an IE-oriented solution;
Jim had a mind to draft a more portable version of the script but was
understandably reluctant to offer untested code for me to quote.
Meantime he wasn't too disturbed by one of the other recipes at IRT,
Q1693, which
does a slightly different job - but the adaptation to do the
present job seems obvious.
Whatever coding you decide to use,
take care when using this kind of technique to make sure the form
is still usable when Javascript is disabled.
And never make the mistake of leaving out a server-side solution to
deal with accidental or deliberate submission of defective data.

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".

Closing thoughts

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 mailto:
action simply isn't good enough, no matter how convenient it
might at first seem.