About image buttons in HTML forms
and multi-line texts in normal submit buttons

Content: Why? | Why not? | Styles | Line break in normal submit button text? | How? | What about "tooltips"? | Technical problems and notes | Side effect: what really gets submitted | Notes on the JavaScript surrogate | Rollover effects

Why?

This text was originally written as a response to a news article where the questioner assumably was using an element in a form which is displayed in a button-like manner and which causes submission of the form (that's INPUT TYPE="SUBMIT") and wishes to have multi-line text within that button. Often a "graphic submit button" (INPUT TYPE="IMAGE") is suggested as a solution. This document explains, among other things, why that would create problems instead of solving them. The same applies to the more common desire which makes authors use image buttons, namely the desire to make buttons "look better" instead of the "ugly grey button".

Why not?

First we should understand the inherent limitations caused by the flexibility of the medium we use. Forms can be filled and submitted on the Web in many environments where "button" as a visual concept makes no sense, although the logical concept of form submission is present. Moreover, there are user interfaces where the "line" concept is vague at least; what does a line break mean in speech synthesis?

The desire to present buttons in some particular way in graphic contexts is itself understandable. Whether it is an HTML issue is debatable. The crucial thing in the useability of forms in visual user agents is that users recognize submit buttons as submit buttons. For this purpose, it is best to let a user agent present those buttons in its way, which is what its users are accustomed to; if they don't like them esthetically, they need to consider whether the dislike is strong enough to make them change the browser (or perhaps its settings, if the appearance of buttons is configurable).

The use of images for submit buttons causes some additional technical problems, to be discussed later.

Styles

Just as an example, the user can write a simple user's style sheet to affect the appearance of normal submit buttons, i.e. those which you code as INPUT TYPE="SUBMIT" as an author. The following simple screenshot illustrates this; the first button is a submit button as rendered by default by IE 4 while the second one is affected by a simple style sheet.

The code used for the latter was:

<INPUT TYPE="SUBMIT" VALUE="Demonstration only"
STYLE="font-family:sans-serif; font-size:large;
font-style:italic; background:#ff0 none; color:#000; width:10em"> 

Naturally, you may prefer some quite different style. You can then configure things differently--for your viewing. The point is that you, as a user, can easily recognize submit buttons when a uniform style is used for all submit buttons. There can be great variation between users (and browsers); but adding variation between Web pages to that will cause confusion.

You could include an author style sheet which suggests presentational details with respect to submit buttons, too. Notice, however, that even browsers which otherwise support style sheets often ignore them for submit buttons (and other form fields), since they use more or less fixed routines for displaying them.

Line break in normal submit button text?

The text for a normal submit button, i.e. the value of the VALUE attribute in an INPUT TYPE="SUBMIT" element, should be relatively short. Otherwise one takes an unnecessary risk of browsers presenting it badly. As an illustration, the screen shot on the right shows submit buttons with texts of varying length on IE 6 on Windows XP. When the text is short, you get the nicely rounded and shaded 3D button from the standard XP widgets. But beyond some length, you get a crude button, with oddly distorted border. Moreover, there is disproportionately large white space on the left and right of the text.

There is in principle no way to include a line break into the VALUE attribute, since in attribute values, no markup (like <BR> for line break) is allowed and a newline is equivalent to a blank. In practice, some browsers seem to treat a newline within such a value so that the presentation contains a line break at that point. I don't recommend relying on this incorrect behavior, though, especially since other popular browsers have other incorrect behavior (Netscape 4.0 seems to ignore a newline within an attribute value).

"Incorrect behavior" refers to processing newline as different from space. A browser may of course present text in a submit button the way it likes, perhaps in two or more lines. But it must not present it differently depending on whether the source code contains a linebreak or a space. This was clearly stated as early as in the HTML 2.0 specification where requirements on a conforming browser or other user agent include the following: "It behaves identifically for documents whose parsed token sequences are identical". This is even illustrated with the following example: "comments and the whitespace in tags disappear during tokenization, and hence they do not influence the behavior of conforming user agents".

Any long explanations related to submit buttons should be given outside them (where you can use <BR> and other text level markup). For example, instead of

 <INPUT TYPE="submit" VALUE="Submit the document for validation
to  the W3C validator">

one should use e.g.

<LABEL FOR="subm">Submitting the document for validation
to  the <A HREF="http://validator.w3.org">W3C validator</A>:</LABEL>
<INPUT TYPE="submit" VALUE="Submit" id="subm">

<INPUT TYPE="submit" VALUE="Submit"> the document for validation to
 the <A HREF="http://validator.w3.org">W3C validator</A>.

Why the button element is not a good solution

In theory, you could use the BUTTON element as defined since HTML 4.0, but in practice it is far from universally supported. Worse, it does not "degrade well".

Consider
<button type="submit">very long text<br>in submit button</button>
This works on some browsers, like IE 4 and newer, but on browsers that do not support the button element, its content is presented instead. This means that the user sees just the text; there is no button, and no way to submit the form.

How?

Assuming the good advice above is not taken, some technical advice for doing the wrong thing right follows.

Let's suppose you want a submit button containing the word "Submit" and below it the word "now". You could create, using your favorite graphics program, a GIF image, say button.gif, containing the text you like. You could then use, instead of a normal submit button, the following:

<INPUT TYPE="image" SRC="button.gif" VALUE="Submit now"
ALT="Submit now" NAME="Submit now">  

That is, you would specify the same textual replacement in three ways. See Alan Flavell's INPUT TYPE=IMAGE for text users? for an explanation.

You would need to specify a DOCTYPE as one of the HTML 4.0 doctypes, since the ALT attribute for INPUT is not valid in HTML 3.2.

You might additionally include a TITLE attribute (see notes on "tooltips" below).

The following artifical example illustrates the use of the different attributes:

<form action=
"http://www.htmlhelp.com/reference/html40/forms/input.html#submit"
><div><input type="image" src="submit.gif"
 value="About submit buttons"
 alt="[Submit]"
 name="submit"
 title=
"Description of INPUT TYPE=SUBMIT in WDG's HTML 4.0 reference"
></div>
</form>

And notice that in some browsing situations, none of the attributes actually works, so the user has to guess that it's actually a graphic submit button and not just an image. In particular, several versions of Opera in "no images" mode display an image submit button simply as the fixed text IMAGE (in a box), no matter what attributes you use. (In version 6 of Opera, this has been fixed.) Since it's easy to turn on automatic image loading or to load individual images on Opera, this might look like an insignificant problem. But it's still a problem; for example, it's foolish that I can't see the meaning of a button if the connection to a host (where the image file is) is temporarily broken. Cf. to reasons for using ALT texts for IMG elements.

What about "tooltips"?

According to the HTML 4 specification, you can use the TITLE attribute for most elements (including input elements) to suggest an "advisory title", i.e. additional information which might be optionally presented to the user, e.g. as a "tooltip" popup. Supported to the TITLE attribute was introduced in IE 4, and later some support has been added to other browsers too.

In the absence of a TITLE attribute, IE uses the ALT attribute for that purpose. It's still a good idea to specify both, even if they have the same value.

Netscape 4 uses the NAME attribute as a "tooltip". This is in principle just as odd as using the ALT attribute for such a purpose. Cf. to the strange use of the ALT attribute as tooltip for a normal image. But you might just as well take this behavior into account and select the NAME attribute so that it works even as a tooltip.

To summarize, for INPUT TYPE="IMAGE",

• ALT attribute specifies the alternative text to be used instead of the image
• NAME attribute gives a name to the field, to be used in the form data set when submitted; but try to select it so that it works even when used as an alternative text or when used as a "tooltip"
• VALUE attribute, despite being syntactically valid, has no logical meaning in this context - note that it does not get transmitted in the form data set; but since some browsers use it, instead of ALT, for the alternative text, it is a good idea to include it too (with the same value as ALT)
• TITLE attribute specifies an advisory title, and is optional; note that while ALT, NAME, and VALUE attribute values should typically be short (one word, normally) due to their varying uses, TITLE can be significantly longer, though there are some practical considerations similar to those for the length of ALT attributes for normal images.

Technical problems and notes

Additional accessibility problems: no keyboard-only access

In addition to the problems related to the use of images, there is another accessibility problem: on Netscape, image submit buttons do not participate in the tabbing order. Thus, it cannot be focused on, and on Netscape, an image submit button cannot be used at all without a pointing device (such as a mouse). Guideline 9 in Web Content Accessibility Guidelines 1.0 explains:

If, for example, a form control can only be activated with a mouse or other pointing device, someone who is using the page without sight, with voice input, or with a keyboard or who is using some other non-pointing input device will not be able to use the form.

On IE, it is possible to use tabbing to focus on an image submit button and then hit Enter to submit the form. The HTML specification doesn't actually say what should happen in such a case; the description of image submit buttons just says what happens "when a pointing device is used to click on the image", then adds a note "If the server takes different actions depending on the location clicked, users of non-graphical browsers will be disadvantaged." Text-only browsers have traditionally sent name.x=0 and name.y=0, and IE does the same when Enter is used. This is actually not very nice, since it is then impossible to distinguish, in the form handler, whether a form was submitted that way or by clicking on the very upper left corner, with coordinates (0,0). (Returning negative values would be suitable.) Opera 5.0 behaves very oddly - when Enter is used to submit a form via an image submit button, it seems to send either nothing (i.e. name.x and name.y are not included at all) or the value 5 for both name.x and name.y. Scott Brady has reported that name.x and name.y are not included when Enter is used on IE 5.5 and Mozilla 0.7. In the most common use for image submit buttons, to replace the "ugly grey button", this problem does not matter, if there is only one such button. But if there are several of them, there is no reliable way of determining which one was used!

Fixed size is a problem to visually impaired

Any image you put on your Web page has a fixed size in pixels, and you cannot control the pixel size on users' screens. Thus, if the text in an image looks like normal text on a low-resolution screen, it will look tiny, perhaps illegibly tiny, on high-resolution screen. This lack of adaptability is a price you pay every time you use images to present text in HTML.

Thus, even if you use the INPUT TYPE="IMAGE" in the technically best way, you will cause problems to users, especially Netscape and IE users (unless they happen to have image autoload on and a resolution which makes the text in the image legible)

The width and height attributes

An input element cannot have a width or height attribute, according to HTML specifications. This is odd, since such attributes are allowed for img elements. In fact, several browsers allow them for image submit buttons too, with the intuitively obvious ïnterpretation.

You can use style sheets to specify (or, actually, suggest) the dimensions of an image button. Example: instead of
<input type="image" width="42" height="42" ...>
which is syntactically invalid HTML, you could use
<input type="image" style="width:42px; height:42px" ...>

If those dimensions deviate from the inherent dimensions of the image, the result is usually awful. If they coincide with them, the browser would be able to allocate space for the button before getting the actual image, and this would be the normal reason for specifying the dimensions.

The border (on Netscape)

Netscape browsers draw (blue) borders around image buttons. If you wish to prevent that, you can include the (nonstandard) attribute border="0" into the input type="image" tag. But this might remove a vital clue about the image being something "clickable"!

Problems with event attributes

Netscape 4 does not seem to support event attributes for image submit buttons. For example, if you try to pre-check form data using an onclick event handler, it will not be handled by Netscape. There are various ways to deal with that:

• Just make sure that you have server-side checks, as you should anyway.
• Use an onsubmit attribute in the form tag instead.
• Use a normal submit button.
• Use some (relatively complicated) combined approach where you have a JavaScript surrogate for an image submit button, preferably dynamically generated and with an image submit button in a noscript element.

Side effect: what really gets submitted

There is a technicality related to form submission if you use an image submit button. It is usually relevant only if you have several such buttons in one form. That's perfectly valid per se, but the usual instructions for including several submit buttons do not apply as such. When using image submit buttons, you need to use specifically different NAME attributes in order to be able to recognize in the form handler which button was clicked on.

The reason to this is the way in which image submit buttons contribute to form data set: the value of the VALUE attribute is ignored, and the coordinates of the clicked location are passed instead. For example, if you have <input type="image" src="submit.gif" name="foo" value="bar">, then the form data set contains the fields foo.x and foo.y, with numeric values that indicate the x and y coordinates of the clicked location.

It has been remarked that according to the HTML specification, the form data set should additionally contain the field foo with the value bar, according to general principles of including all "successful controls". This is somewhat debatable and depends on the interpretation of wordings in the specification. Anyway, IE 6, for one, does not work by this interpretation. For more information, check the Usenet thread <input type='image'> ... IE fails to pass value while Mozilla and Netsacpe works .

This implies, on the other hand, that one could use an image submit button in a manner comparable to (server-side) image maps. In fact, image submit buttons would give more flexibility, since they can be used within a form so that the user first provides some information via other form fields (text input, radio buttons, etc) and then clicks on the image, thereby giving still more data to be processed by the server-side script.

See also: Multiple Submit Buttons in HTML (and related issues) by Alan Flavell.

If you use PHP for form processing, note that PHP automatically replaces the periods in names by underscores.

Notes on the JavaScript surrogate

Using client-side scripting, one can create an imitation of an image submit button: an image which is inside an A HREF element with an ONCLICK attribute (or by using a javascript: pseudo-URL as the HREF attribute value). Example:

<a href="fail.html" onclick="document.myform.submit();return false;"
><img alt="Submit" src="submit.gif"></a>

Here fail.html might contain some instructions for situations where JavaScript is not enabled. This precaution would be unnecessary (and you could use the dummy href="#" instead), if you generate the construct dynamically (via document.write), so that it never appears when JavaScript is disabled. In such a case you could use a noscript element to specify an alternative, such as a normal submit button or an image submit button.

Similar technique could be used to make some text imitate a submit button, perhaps using text-level markup or stylesheets to affect the visual presentation (font, color, etc.)

In addition to the usual limitations imposed by using client-side scripting, these techniques have some specific problems. In particular, the ONSUBMIT event handler for the form is not invoked; this however is not very serious, since you can put the code (e.g. for form data checking) into the ONSUBMIT attribute value before calling submit(). The JavaScript Form FAQ contains answers to questions related to these issues.

Rollover effects

You might wish to create a "rollover effect" for an image submit button so that the image is replaced by another image (of the same size) on mouseover and turns back to the original when the mouse moves out. I don't think that's a good idea - such behavior is not normal for submit buttons, so you are deviating more and more from the user interface that users are familiar with - but it can be done by including attributes like the following into the INPUT tag:
onmouseover="this.src='go.gif'" onmouseout="this.src='send.gif'"

Demo:

This is supported by Internet Explorer 4+ when JavaScript is enabled. On Netscape 4.x, even with JavaScript enabled, the event attributes don't work, i.e. the browser just uses the initial image. You might consider using the above-mentioned JavaScript surrogate to make the attributes work on Netscape too; the point is that Netscape supports those attributes for something that's syntactically a link. Mikodocs has a page Rollover Submit Image which contains an a general JavaScript function for this and an example of using it. The example adequately uses a noscript element to specify a non-JavaScript fallback; in that example the fallback is a normal submit button, but it could be an image submit button, too, of course.

This document is part of my material on HTML forms. Notice in particular that there is a related document about reset buttons: A custom image for a reset button? (and other notes on reset buttons).