Multiple Submit Buttons in HTML

Two INPUT TYPE=SUBMIT controls with name=foo, different values:

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

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"

This is complicated enough to get a separate page for its discussion, Form submission and the ENTER key?.

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.

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:

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:

Here's some text
for
the button element.

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.