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, 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.
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.
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 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.
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.
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:
<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 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".
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.
Original materials © Copyright 1994 - 2006 by A.J.Flavell