Multiple Submit Buttons in HTML

Quite a number of folks seem to mistakenly believe that a form
can have only one "submit button".
This document demonstrates that it is
possible to have several form submission "controls" on the same form
in HTML, and to detect which one was used in a server-side script,
without having to rely on any client-side scripting.
Browser coverage for multiple input type=submit is excellent,
in accordance with HTML specifications, which have been sufficiently
stable since HTML2.0/RFC1866.
(What is true is that a form can have only one action
URL, but that's a different issue, that we're not covering here.)

History: this page goes right back to HTML2.0/RFC1866, though it has
been updated from time to time since. My apologies for the somewhat
erratic notation used for HTML syntax,
which should eventually be unified using lower-case
lettering in <code> markup to make it compatible
with both HTML4 and XHTML.

In the HTML4 specification, the term form control is now used as the
generic term for input, button etc., and the present
web page has been updated to take account of that terminology.
People often refer to input type=submit as a "submit button",
but we do not want to confuse this with
input type=button, nor with the
button element, both of which are in HTML4
(although, as we'll see, the button element is
implemented too erratically to be of much practical use).

This discussion is interspersed with some "live" FORM controls,
so that you can try them out. When you use one of the various
submission controls, the page will be submitted to
a test script that does nothing more than displaying the
names and values that it found in the submission (decoded
from the encoded submission format, and presented in HTML).

Another two with a different name,
and, for variety, numerical values:

and

Oh, you need a "name", not
only a "value". Here's one to try
(when I use this one, the value shazam is missing
from the server report, OK?:

Well, for completeness let's have a name without a
value:

It looks as if some browsers supply a default value of their
own, "Submit" or "Submit Query" seem to be popular.
At least one version of
Mozilla submitted an empty value, but other versions
reverted to supplying "Submit Query" instead: Bug 330469 seems to relate to this behaviour.
Possibly there will be differences depending on whether the
value attribute has been omitted, or explicitly set to the
empty string, as value="".

Form submission by using "Enter"

The particular issue as it affects us here is that if the
form is submitted by means of ENTER, then, depending on browser/version
and on the location of the "focus", and on some other things,
the script may or may not receive the expected name=value
pair corresponding to (one of the) Submit buttons.
MSIE, in particular, makes up its own rules, see the "Remarks" section
at the end of MSDN workshop page on type=submit.

input type=image

An input type=image has a rather similar effect
to an input type=submit.
In the HTML/2.0 specification, it was shown as not using the
value attribute.
The formal DTD neither mandates the name attribute,
nor prohibits the value attribute,
but we can't draw any particular conclusions from that, because
the DTD rules are formulated to be applicable to all types of
input element, they don't apply different rules to
e.g input type=submit than to
input type=image.

The response required from a graphical browser was to encode the x and y
co-ordinates of the click together with the "name" attribute,
which in this example is "foot", sending them as foot.x and foot.y as you
should be able to demonstrate.
Text-mode accessibility depends on whether you have planned to use
the x and y values (thus using TYPE=IMAGE as a form of server-side
imagemap), or not (thus using TYPE=IMAGE as nothing more than a
decorative variant of TYPE=SUBMIT).
In the first instance, there is no inherent text-mode
accessibility, so there should, as a rule, be some alternative
access to the material for text-mode readers.

type=image in various browser situations

HTML specs do not say what is supposed to happen
when images are not being displayed for various reasons:
e.g image server inaccessible; graphical browser with image loading
turned off; text-mode (character-mode) browser.

In some respects, input type=image
behaves like an img, having a src=
attribute just like it. Prior to the HTML4.0 spec, this construct
did not officially have an alt attribute, although there
were a couple of browsers that could use alt
if you provided one: the HTML4.0 spec introduces
an ALT attribute, and contains some
cautionary advice to HTML authors about accessibility for
text-mode browsers.

Some historical detail about behaviour of text browsers can be found in
"INPUT
TYPE=IMAGE for text users".
The conclusion was that best results for all kinds of text
readers can be achieved by choosing a suitable text string and
using it in NAME, VALUE and ALT attributes, although for
recent browser versions, the ALT attribute should suffice for
getting the text-mode fallback behaviour (you'll probably want
to have the NAME attribute for other reasons, anyway).

At least one graphical browser (Mozilla) has been observed to
respond to the presence of a value attribute by
submitting a name=value pair in addition to the
name.x and name.y co-ordinates.

Although the issue does not seem to have been discussed with any
kind of high profile, some recent (early 2004) discussions have
shown that the HTML/4.01 specification can indeed
be interpreted in this way. According to Control
types created with INPUT:

When a pointing device is used to click on the image [...]
the submitted data includes name.x=x-value
and name.y=y-value

So far, so good. But in the terms of section 17.13.2, the input type=image can also
be rated as a "successful control", meaning that its
name=value pair should also be
included amongst the submitted data.
Furthermore, it would seem that in any situation where the submission
is actioned without the use of a pointing device,
the co-ordinate pairs ought to be omitted.

Interestingly, that would be just the behaviour which the Lynx
developers had been promoting so many years ago, and finally
abandoned due to lack of support from the community.
But it seems Mozilla doesn't go along with the latter part of the
plan: if I position the "focus" on the footprints by using
the Tab key, and hit Enter,
then I surely have not "clicked with a pointing device", but
Mozilla (1.6) nevertheless submits foot.x and foot.y (both = 0).

Closer inspection of Mozilla's behaviour (I looked at version 1.6)
produces some results which seemed strange to me, though I presume
the developers had some good reasons for doing what they did.
However, the actual behaviour doesn't seem to me to
exactly reflect the discussion on the related bugzilla
item 110595.

Mozilla (Win 1.6) -
Situation:

Display:

name.x and name.y values submitted:

name=value submitted, if present:

Images loaded

Image displayed

Yes

Yes

Images enabled but could not be displayed (inaccessible etc.)

alt text, if available; else value text

No

Yes

Image loading disabled

Nothing at all

n/a

n/a

The most important thing to note seems to be that if the browser
user has deliberately disabled image loading (Preferences> Privacy>
Images...), then they see nothing, not even an
alternative text.
This could produce a situation where the form was otherwise
usable, but could not be submitted due to the absence of any
viable "submit control".

The other point that seems to call for comment is that if image loading
has failed (server inaccessible etc.) then they see the alternative
texts, but there is nothing by default to indicate to them that those texts
are form submission "controls".
Only if the text carries a clear enough message and they decide, despite
the unpromising appearance, to "click on" the text, or to navigate to it
with their Tab key etc., does it become clear that the text is somehow
special.

Evidently, not all browser implementers have interpreted
the HTML4 specification in the same way.
So authors will need care and resourcefulness to achieve usable
results across a full range of browser and browsing situation.

Summing up

Using input type=image in the originally-intended
way, as an imagemap-like facility, with images enabled and users
selecting specific points on the map, rates to work well,
in those browsers/situations where its use is applicable.
But it will be essential to provide some alternative method of access
to those who are in a different (text-mode or nonvisual) situation.

Using it merely as a decorative "submit button", on the other hand,
has a number of pitfalls if it's to work across a wide range of
browsers and browsing situations.

Note that when stylesheets are better-supported (support for
styling of form controls has been particularly weak), quite a range
of decorative "submit controls" could be produced by applying stylesheets
to ordinary INPUT TYPE=SUBMIT controls, and will be
automatically compatible with older browsers without needing any
kind of extra effort on your part.
However, I think it's important to repeat a well established
principle of user interface design, which is also stressed on J.Korpela's
pages: consistency -
users know what a submit button looks like and what it does; it
is bad manners to try to fool them by making it look different,
or even to make it look like something else.
An author who plays such tricks on them is liable to lose their
trust.

Fixing the size of form controls?

Here's another frequently asked question: people want to have
several submission controls showing text strings of different
lengths, but they want them lined up all the same width.
You can try packing out the strings with extra spaces, but
it won't work reliably, I assure you that I've tried it (you
stand a rather better chance if you use no-break spaces, of course).
By default the browser may be using a proportional font here, so
another suggestion was to enclose them in TT or other
monospaced markup - sorry, that helps on some browser/versions
too, but doesn't seem to work reliably across all
browsers and versions, either.
Here's a sample, anyhow (don't forget to make allowances in your
script for the actual value that's going to get submitted, complete
with the extra spaces!).

You could (I'm not saying that you should)
make them up as equal sized images and use
INPUT TYPE=IMAGE instead - they still won't line up
for users who have image loading off, or from text mode browsers.

The "HTML4 way" for suggesting this is to use
stylesheet attributes on the INPUT control.
Since the contents of the control are going to be text,
and you won't know what size that's going to be in pixels, the
appropriate size units to use are text-sized units, for example
em units.
When this works, it works very well indeed, of course; but there's
even less certainty of your CSS suggestion being honoured than there
was with the various HTML kludges mentioned above.
So it would be advisable to verify
that the form is still usable even when the style
suggestion isn't followed. Anyhow, here's an example.

By the way, that actually works on Win MSIE5.0 and 5.5,
as well as on Mozilla (version 1.3.1 was tried).
It doesn't work at all on Netscape 4.* or many other browser/versions,
though it's not actually harmful on most of them, and there are
recognised techniques for hiding challenging CSS constructs from older browsers.

An email correspondent, commenting on the foregoing advice, reports
that she had good results by padding the texts out with spaces
(which works on Netscape 4.*) plus using a CSS width property
in em units (which works for Win MSIE5, and presumably other CSS-aware
browsers). She comments that Netscape produced some "very odd"
line spacing, which she adjusted with the CSS line-height property.

So, if we can't
be sure of making them the same length on a good range of
browsers and settings, you might want some other approach?
Well, here's one simple but effective method:

Please order your favourite drink:

Aquavit

Beer

Champagne

Dihydrogen monoxide

etc.

Your form script then has to make its selection on the basis
of the "name" returned, not on the "value", since the
values are all the same.
This approach impairs accessibility, but Sascha Claus
(private mail) points out the use of the <LABEL>
construction, which I have now added in accordance with WAI guidelines.

To summarise: there are various techniques that could give you a
better chance of achieving similarly-sized buttons, but in the final
analysis it's best to design flexibly, so that, if/when your techniques
aren't successful, you've still got a usable form, even if its
visual appearance doesn't meet your ideal.

Special meanings for "Submit", "Clear", etc. ?

There is no special meaning given by HTML
to the "names" (or "values")
"Submit", "Clear", etc. on an INPUT TYPE=SUBMIT.
They are just normal names (or values) that are sent to the
server in the normal way, and the server will process them
just as it processes any other kind of
INPUT TYPE=SUBMIT -
or, indeed, any other name=value pair
resulting from a "successful form control"
that is included in the submission.
INPUT TYPE=RESET, on the other hand,
is a control having a purely local
effect, and not sending anything to the server.

The modern way of getting your reset control, like other
form controls, to be
styled/decorated would be a stylesheet: but fuller discussion of that
issue goes beyond the scope of this note.
There is no way to replicate the effect of
TYPE=RESET with an image (at least, there wasn't
prior to HTML4.0; it's your choice if you want to risk using
the BUTTON control, that would not be supported in older
browser/versions).
Sure, you can mimic the effect of a RESET by having the
server respond to a specific TYPE=IMAGE submission by sending
a fresh copy of the form, but that's not
the same thing, quite apart from the unnecessary network
and server overhead, and delay.

What's the use of a RESET control anyway?

That's a very good question, on which opinions differ strongly.
Some consider that it's handy to be able to get a nice fresh
form without having to reload it from the server; others think
it's a damned nuisance to have a button - as often as not
placed very close to the Submit button - which, if clicked
by accident, will throw away all the input which one had carefully
prepared and was intending to submit!
Perhaps the safest thing I can recommend is, that if you decide
to provide a RESET control at all, you better make it very clear
what it is, and place it well away from any other controls so
as to avoid accidents. Putting it at the top of the form might
be helpful: putting it at the end, adjacent to the Submit
button (which seems to have become a common convention) may
be the worst possible choice. I apologise for doing this myself
before the logic of it was pointed out to me.

OK, let's have some variations on the RESET control by giving it
a NAME and/or a VALUE. Then perhaps we'll have the full set!

Of course the Name's rather pointless, as this button isn't supposed
to send anything to the server. The Value, however, as you see,
is available to be displayed by the browser.

The HTML4 BUTTON element

HTML4 introduced the BUTTON element, to give more
flexible options for designing a "control": unfortunately, this
isn't going to do anything useful on a browser that doesn't implement
it; see also the notes below about its mis-implementation in MSIE;
so it would be wise not to make a form completely dependent on it.
(Don't confuse this with the INPUT TYPE=BUTTON element:
that is for use with client-side scripting, which I'm
not covering here.)

The point of the BUTTON element is that its contents allow
almost all of the %flow content model, thus offering
a great deal of freedom in designing a "control".
OK, let's try one:

When I tried this in Aug.1998, the only one of the
browsers that I tried, apart from Lynx, that honoured
it as a Submit button was MSIE4, and that failed to send the
name=value pair that the spec calls for.
NS4.5b1, Opera 3.50 beta, Amaya, were unimpressed,
as was my (admittedly old) version of emacs-w3.
The only browser that submitted the button correctly was Lynx,
although, obviously, its rendering of the "button" (which used
the value attribute) in Lynx's
character mode environment was no better than a normal
Submit button would be, and the material that was inside the
BUTTON element was simply displayed as normal
text, which was a little confusing.

In July 1999 I finally saw a development version of Mozilla
behaving correctly in response to this test.
Win MSIE5, on the other hand, submitted the button's HTML markup,
instead of the specified value attribute!
In March 2001 I saw it working in Amaya 4.3.2 and in
a release candidate of Opera 5.10
(it may well have been working in these browsers
at an earlier stage, I don't
get time to do regular and comprehensive testing).

In 2003 it was pointed out to me that Microsoft,
while referring to the button element as
"defined in HTML4.0", nevertheless have the affrontery to describe
a completely different behaviour by their browser, without
any warning about the discrepancy (refer to the "Remarks" and to the
"Standards Information" at the foot of the cited page).
So it appears that the broken behavour observed
and described above for MSIE5 is quite deliberately wrong
("it's not a bug, it's a feature").
Per Jessen (Zurich) emailed to say that additionally:

For MSIE, I would add that forms containing multiple "submit"
buttons using the button element, are submitted
with all buttons being successful events -
as far as I can see, there is no way of telling
which button was pushed.
This seems to be the behaviour with MSIE5.5SP2 and MSIE6.0SP1.

and indeed both anomalies can be demonstrated when this page is
used on MSIE (I was using IE6.0SP1 for my most recent test):
when one of the submit controls is used, the report shows that
MSIE wrongly added the wrong data from the button
control to the submission, even though the button had not been
used to submit the form.

Conclusion: due to these anomalous
behaviours, I'd have to conclude that, except perhaps in a few
special cases, the BUTTON element is unusable in
a practical WWW forms submission situation, unfortunately.

Final remarks

Please feel free to examine the HTML source of this document:
anything that isn't obvious from the source, I've tried to explain
in the text.

A frequently asked question is the one already noted above,
How can I submit a form by just hitting
ENTER?.
This includes some issues that are relevant to the use of
multiple submit "controls", so I'd urge you to take a look at it
before finalising your design.