This text was originally written as a response to a news article
where the questioner assumably was using an element in a
which is displayed in a button-like manner and which causes submission
of the form
and wishes to have
multi-line text within that button.
Often a "graphic submit button"
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".
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?
Consistency in widget appearance is essential in usability, and on the WWW, that means compliance with what each user is accustomed to, i.e. browser defaults (whatever they are in each browser). Jakob Nielsen writes in his alertbox The Top Ten New Mistakes of Web Design:
Consistency is one of the most powerful usability principles: when things always behave the same, users don't have to worry about what will happen. Instead, they know what will happen based on earlier experience. Every time you release an apple over Sir Isaac Newton, it will drop on his head. That's good.
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.
Just as an example, the user can write a simple user's
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.
The text for a normal submit button, i.e. the value of the
INPUT TYPE="SUBMIT" element, should be relatively
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.
is in principle no way to include a line break into
since in attribute values, no markup (like
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
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
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">
A previous version of this document suggested the following:
<INPUT TYPE="submit" VALUE="Submit"> the document for validation to the <A HREF="http://validator.w3.org">W3C validator</A>.
Can you guess why I changed my mind? Consider what happens on a speech-based browser: the browser tells the user that there is a submit button, and after that the user hears what it is for. It is clearly better to put any explanations related to a button, or any form field, before it.
buttonelement is not a good solution
In theory, you could use the
as defined since HTML 4.0,
but in practice it is far from universally supported.
Worse, it does not "degrade well".
<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.
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,
containing the text you like.
You could then use,
instead of a normal submit button,
<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
as one of the
HTML 4.0 doctypes,
ALT attribute for
INPUT is not valid in HTML 3.2.
You might additionally include a
TITLE attribute (see notes on "tooltips"
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
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
According to the HTML 4 specification, you
can use the
for most elements (including
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
IE uses the
ALT attribute for that purpose.
It's still a good idea to specify both, even if they have the same value.
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
ALTattribute specifies the alternative text to be used instead of the image
NAMEattribute 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"
VALUEattribute, 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
TITLEattribute specifies an advisory title, and is optional; note that while
VALUEattribute values should typically be short (one word, normally) due to their varying uses,
TITLEcan be significantly longer, though there are some practical considerations similar to those for the length of
ALTattributes for normal images.
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
Text-only browsers have traditionally sent
.x=0 and name
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
.y are not included at all)
or the value 5 for both
Scott Brady has reported that
.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!
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
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)
input element cannot have
height attribute, according
to HTML specifications. This is odd, since such attributes are
img elements. In fact, several browsers allow
them for image submit buttons too, with the intuitively obvious
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.
Netscape browsers draw (blue) borders around image buttons.
If you wish to prevent that, you can include the
border="0" into the
input type="image" tag.
But this might remove a vital clue about the image being something
Netscape 4 does not seem to support
event attributes for image submit buttons.
For example, if you try to pre-check form data
onclick event handler, it will not be
handled by Netscape. There are various ways to deal with that:
onsubmitattribute in the
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
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"
then the form data set contains the fields
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
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.
one can create an imitation of an image submit button:
an image which is inside an
A HREF element
(or by using a
HREF attribute value). Example:
<a href="fail.html" onclick="document.myform.submit();return false;" ><img alt="Submit" src="submit.gif"></a>
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
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
imposed by using client-side scripting, these techniques
have some specific problems.
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
attribute value before calling
questions related to these issues.
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
the event attributes don't work,
i.e. the browser just uses the initial image.
You might consider using the above-mentioned
on Netscape too; the point is that Netscape supports those attributes
for something that's syntactically a link.
has a page
Rollover Submit Image which
an example of using it. The example adequately uses
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).