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
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".
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
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.
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">
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.
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.
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.
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.
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!
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)
width
and height
attributesAn 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.
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"!
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:
onsubmit
attribute in the form
tag instead.
noscript
element.
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.
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.
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).