A custom image for a reset button?
(and other notes on reset buttons)

Just as HTML authors often like to replace a submit button by an image in a form, they may ask how to do the same to a reset button, or at least make the button somehow visually different from the default. This is a more complicated question, but there are stylesheet and JavaScript techniques by which it can be done in rather many cases, even in a safe manner which "degrades gracefully" to a normal reset button when the conditions are not met. This document discusses, in addition to those techniques, the question whether and when this is a useful thing to do, as well as the necessity and placement of a reset button. The conclusions recommend making the reset button the first field in a form and using style sheet in a simple way to suggest modified visual appearance without trying to use a custom image; a relatively complex method could be used which often causes such an image to be used, without sacrificing basic functionality when that does not happen.

The normal reset button

A normal reset button is the representation of an input type="image" element. Activating the button, usually by clicking, causes the form elements to be set to their initial (default) values, ignoring all user input.

This is a demo form, with just a text input field. You should be able to type into the text field and to clear your input using the reset button.

However, as Alan Flavell has noted in his SELECT tag issues, the reset is in some cases on some browsers too effective, applying to explicit initial settings in HTML markup! A form reset is not expected to set form fields to null values but to their initial values as set up in HTML markup. Although browsers sometimes violate this, they generally do it right. Thus, for example, using the reset button for the sample form above you reset the text input field to "Default string", not empty. It would be possible to create JavaScript-based buttons which behave differently, but we won't discuss that here. (You could use the technique illustrated in the JavaScript FAQ entry How can I write my own reset function to reset form fields to their default values?, modifying it so that sets the values to desired values. Remember to ensure that a nonfunctional button does not appear when JavaScript is disabled; cf. to section Using JavaScript more safely below.)

Is a reset button needed at all?

The Web would be a happier place if virtually all Reset buttons were removed. This button almost never helps users, but often hurts them.
Jakob Nielsen: Reset and Cancel Buttons

Quite often authors routinely include a reset button alongside with a submit button:

Enter query:

Perhaps this is caused by the mistaken assumption that a reset button is an obligatory part of a form. More probably, authors just include it because they are used to seeing a reset button in forms on other people's pages, and seldom think why they should do that. I have criticized this as follows:

It is customary to include a reset button after the submit button, but this means that if a user accidentally clicks on the wrong button, all information entered by him using the form is lost. So perhaps you should put the reset button somewhere else (if you include it at all). For a typical form, a reset button is rarely useful, since it is unlikely that the user wishes to clear all fields. However, a reset button might be useful if the form has e.g. prefilled text fields; see the fourth example in the description of the FORM element.

Learning HTML 3.2 by Examples, description of the input type="reset" element

Especially for large forms, containing perhaps dozens of fields, or a multi-line text input field into which the user has typed a long story, it is really harmful to accidentally hit the reset button.

On Internet Explorer, starting from version 5, the presence of a reset button in a form has a strange side effect on the use of the ESC key key. On IE, hitting ESC in a text input field resets that field to its initial value (or, maybe depending on browser version, to the the value it had when it was last focused on). But when the form contains a reset field, IE resets the entire form when ESC is hit in any text input field! If you wish to provide a reset button and avoid that unpleasant effect, then you might consider using the JavaScript technique discussed below, instead of an HTML reset button. As an alternative, you might include a piece of JavaScript that circumvents the problem - though naturally only when JavaScript is enabled. At the simplest, you could include
onreset="return confirm('Really reset all form fields?')">
into the form tag. This would cause the confirmation request even when the reset button is clicked on, but this might actually be a good idea.

On IE 6, hitting ESC twice in succession clears the form even if there is no reset button. This suggests that it might be a good idea to include an onreset attribute like the above into each nontrivial form.

In fact, even the "local" effect of clearing current input field on IE can be a real nuisance, especially if it is a textarea and the user has typed a lot, then accidentally hits the ESC key. The following method of preventing ESC functionality on IE 5 seems to work (when JavaScript is enabled) and should hardly cause any harm on other browsers: Use

<script type="text/javascript"><!--
function noesc() {
  return !(window.event && window.event.keyCode == 27); }
//--></script>
and include onkeydown="return noesc()" into each text input element. This means checking whether the ESC key - Ascii code 27 - was what was pressed down, and effectively cancels the effect of pressing it down, so it won't have its "normal" (to IE) meaning, so even the current field does not get cleared.)

This approach is debatable, though, since it prevents IE from working in its usual way, clearing fields or even the entire form. Some users might be aware of and accustomed to such functionality.

Thus, it might be harmful to remove this functionality for your pages. In principle, it is more natural to have resetting as a browser function, rather than a control created by markup. In that sense, the IE feature is understandable, though unfortunately it is poorly documented and does require confirmation from the user.

Alan Flavell remarks in his Multiple Submit Buttons in HTML that some people "consider that it's handy to be able to get a nice fresh form without having to reload it from the server". In fact, just hitting the normal reload (refresh) button of a browser's basic user interface doesn't always get a fresh copy of the form. The user might find it faster to delete his previous input manually than to find a way to force the browser re-initialize the form. This would get rather awkward if the user is e.g. entering several sets of data - say, typing in data from forms on paper.

This is actually a somewhat nasty situation. For a small form, containing perhaps just a text input field for a query string, a reset button isn't particularly useful, since the user can usually conveniently erase the input using other tools. For large forms, manual erasing is awkward - but for large forms, the damage caused by accidentally resetting everything is rather bad, too.

Ideally, Web browsers would provide some convenient method to reset any form, without requiring any specific HTML markup. This could take place e.g. so that when the user clicks somewhere on the form area, the menu which pops up would contain an entry "Reset this form". I haven't seen any browser with such a feature. Several browsers have "Refresh" or "Reload" in such a menu, but it's just a duplication of the above-mentioned function for reloading the entire page from a server, and it often doesn't even reset the form! Thus, in practice, for the time being authors might need to consider these issues.

If you expect that a user will typically submit several sets of data, you might consider an alternative approach. Make the form handler send back a response page that contains feedback about the submission (at least telling it was OK) and a fresh form for a new submission. The default values of fields in the fresh form might remain the same as originally, or they might depend on previous submissions (e.g., carry a counter to help the user keep track of his submissions). However, this approach might not feasible in some situations.

So there might be cases where it would be convenient to clear a form using a reset button, typically after making one form submission and having used the Back button to get back to the page containing the form. Depending on whether he wants to start from a "clean desk" or by editing his previous data, he may or may not wish to clear the form. This gives us a hint to the answer to the next question:

Where should we put the reset button?

The reset button is most useful in a situation where the form contains data that was previously submitted and the user wants to start afresh. Thus, the logical position of a reset button is at the beginning of the form. This typically maximizes its distance from the submit button.

This way, the user, in the situation discussed here, will first make the natural thing: select whether to clear the entire form or to reuse the data which was previously submitted. Note that when using keyboard-only (no mouse) input, this order is much more convenient than having to tab through the entire form to the reset button, then tab through the entire page to get back to the first input field!

A potential problem arises if there is prefilled text in the form. The user may intuitively think that a reset button will wipe out that too. Moreover, a person who is just starting to fill out the form may wonder what to do with the reset button when it appears in a "nonstandard" place. Well, perhaps we can just state that users need to learn their browsers and this isn't a particularly difficult thing to learn; the first few experiences will hopefully make things clear. We might help some users by including a title attribute for the reset button, saying in a few words what the button means.

This is a simple demo form. If you submit it, your input will be simply echoed back to you.


Why make it an image?

Authors who wish to replace a normal input button by an image seem to have mainly esthetic reasons; they use phrases like "ugly grey buttons". I have discussed this issue in my document About image buttons in HTML forms.

But for reset buttons, an image could be desirable for quite different reasons. The problem is not that the button is grey and has the text in a boring font. The problem is that the reset button is, at least on most browsers, by default quite similar in appearance to a submit button. Naturally we need to use different texts in them, but they still look too similar, since they have quite different meanings.

It would be preferable if a reset button could be visually distinguishable from a submit button by its general appearance. (I have often mistakenly clicked on the reset button when filling out a form I've created myself, despite having put the reset button at the start!)

So what might be preferable is something like the following (the image used is a bit exaggerated on purpose):

[An image containing the word "Clear"]

A good browser would display normal reset buttons in a style different from submit buttons (say, using different colors), but at present browsers don't do that. This is why we consider what an author might do to help users in distinguishing reset buttons from submit buttons (and other ingredients of a page).

For these purposes of clarity, an image submit button is actually inferior to a "styled" button, i.e. a normal submit button containing text displayed in a distinctive font or color.

One reason to that is the adaptability of (well-designed and well-implemented) "styled" buttons to various browsing situations. In particular, text size inside them would adjust to the browser's font size settings, whereas an image is of fixed size in pixels.

But since not all browsers support "styled" buttons, we shall first consider whether images could be used for reset buttons.

Techniques for customized reset buttons

In the following, we assume that we have an image, say with name clear.gif, which we wish to use as a "custom reset button". (The image used in the examples is from the free graphic collection http://www.free-graphics.com/buttonstext2.htm.)

Theory: using button type="reset"

In principle, one could use a button element to specify a reset button so that its visible content is not just plain text. In particular, the content might be an image:

<button type="reset"><img src="clear.gif" alt="Clear"></button>

This, however, currently has limited browser support. What's worse, on non-supporting browsers, the effect is seriously misleading: They ignore the start and end tags of the button element, rendering its content. So if the image the user sees something that looks like a submit button, but clicking on it has no effect.

This means that if you use button type="reset", you would have to use some "browser sniffing" so that non-supporting browsers get a page with a normal reset button or some other solution discussed here. And since such sniffing is typically done with JavaScript, it would actually be easier to use the solutions discussed below.

Moreover, Interner Explorer does not use the image as such as the button. Instead, it puts the image into a button (with grey background by default). This can be affected using a style sheet which suggests dimensions for the button. However the dimensions shouldn't be exactly those of the image (but about 4 pixels larger), since IE does not let you entirely remove the background. Suggesting a background color close to that of the basic color of the image would reduce the effect to barely noticeable.

Using JavaScript

Using just JavaScript reset()

In JavaScript, one could use the reset() function to set a form to its initial state. (We'll discuss later the problem that older JavaScript versions do not support that function.) An event attribute can be used in HTML to associate JavaScript code with the clicking of an image. Since event attributes are supported differently in different contexts by different JavaScript-supporting browsers, it is perhaps best to associate the code with a link. In our case, we would make the image a link as follows:

<a onclick="document.theform.reset();return false;"
href="#"><img alt="Clear" src="clear.gif" border="0"></a>

Here theform is the name of the form as set in a name attribute in the form tag. The JavaScript statement return false; means that the normal processing of a link is suppressed, i.e. the href value is not used. To make this doubly sure, that value is set to "#" which is generally recognized by JavaScript-supporting browsers as having the same meaning.

Note that thanks to the use of a meaningful alt attribute, the code above works when images are disabled, too. Also note that using just text (no img element) might be suitable, too, especially if stylesheets are used to affect the appearance of the text.

The problem is that on browsers which do not support JavaScript or have JavaScript disabled the code won't work at all. And there are many reasons why this is a serious problem. Just as in the previous technique, the user would see something that looks like a reset button but isn't. But in this case the effect is unpredictable, since "#" is an incorrect URL reference.

We could improve the situation by using a href value which refers to some real document or location. It could be a document explaining the situation, but that would be very clumsy; the user would need to get back to the page containing the form and manually clear the forms. One idea would be to make it a document which is a copy of the one containing the form but with a normal reset button instead of the construct discussed here. However the user might be puzzled when seeing the reset image change to a reset button. The next technique avoids this.

Using JavaScript more safely

When we have something that is based on JavaScript and the same basic functionality can be achieved in plain HTML (though perhaps not so nicely), we can make the page more robust as follows:

Netscape 2 supports JavaScript but still renders all noscript content. This usually isn't a significant problem since Netscape 2 is not widely used anymore. And in our case, the problem just means that the user sees both a normal reset button and an image acting as reset button, which isn't that fatal.

In our case, this could mean the following:

<noscript>
<p><input type="reset" value="Clear"></p>
</noscript>

<script type="text/javascript"><!--
document.write('<p><a onclick="document.theform.reset();return false;"',
'href="#"><img alt="Clear" src="clear.gif" border="0"><\/a><\/p>');
//--></script>

The solidus (slash) character / needs to be "escaped" here, by preceding it with the reverse solidus (backslash) character \. Otherwise e.g. </a> would be an end tag, which is not allowed within the script element.

Handling JavaScript versions

There is one more robustness issue. Older JavaScript implementations do not support the reset() function (and would have some problems with other constructs we're using, too). In browsing situations where JavaScript is enabled but only JavaScript 1.0 is supported, we'd wish to have the same fallback as when JavaScript is disabled.

Using a technique presented in the JavaScript General FAQ, we include the following (most logically, into the head part of an HTML document):

<script type="text/javascript" language="JavaScript"><!--
var js_version = 1;
//--></script>
<script type="text/javascript" language="JavaScript1.1"><!--
var js_version = 1.1;
//--></script>

Then, in the script element which generates the HTML markup for a reset button, we just write conditional code which generates a normal reset button when js_version equals 1, otherwise the version using an image and a scripted event.

Using stylesheets

The basic reason for making a reset button an image as discussed above is to make reset buttons visually different from submit buttons. Thus, just using a normal reset button as far as HTML is considered could be quite sufficient if we can manage to make it look different by using stylesheets. However, let us first discuss whether we could turn a reset button into a custom button using stylesheets.

A naïve attempt

One might try to following trick: Using stylesheets, specify a background image for a reset button, and make the text in the button empty. Example (using a style sheet embedded into an HTML attribute):

<input type="reset" value="" style=
 "background : url(clear.gif); width:95px; height:35px;">

On your current browser, it looks like the following when placed between a text input field and a submit button:



The trick above is dangerous, because whenever the style sheet is not applied, for some reason or another, the reset button will appear as looking like a normal submit or reset button with no text inside it. So the user is probably very confused. Besides, Netscape 6 shows both the background and the text "Reset" (apparently ignoring the value attribute).

The essential thing to remember is that style sheets are not for control but for suggestions. With this in mind, we'll consider turning the trick into a robust method.

Using style sheets to suggest a background image robustly

We could use a normal, reasonable value attribute (say value="Clear") in an input type="reset" element, and suggest, in a stylesheet, an image which is really suitable for use as a background image. This is robust: the text in the value attribute will appear in the button, either using the browser's default presentation for reset buttons or against the background image, in a text style we would suggest in the style sheet. (It would be necessary to suggest the text color at least, since otherwise the text might get presented - due to browser defaults or to a user style sheet - in a color which is not legible against our background image.)

This approach is quite reasonable, but it's actually just a variant of the method to be described next, with the additional suggestion of a background image.

The simple way of using style sheets

The simple way of using stylesheets to suggest that reset buttons be presented visually differently from submit buttons is to suggest one or more of the following presentational features for reset buttons:

It is not fatal if we suggest, say, a particular font face and it happens to be what browsers normally use for submit end reset buttons. We are in a position no worse than without stylesheets. And if we suggest several of the above features, there is a rather good chance of looking different in one way or another, if the style is applied by a browser. Naturally, the presentational properties mentioned above are not the only ones we could suggest, but they are probably the most important to consider.

Technically, we could include the attribute class="reset" into each input type="reset" element, and specify, in a style sheet, a rule using the selector input.reset. The class name is just an assigned name, so it could be anything you like, but reset looks rather natural. (In CSS2, one could use a selector which refers to those input elements which have the attribute type="reset", but this isn't supported by browsers yet, so we need to include a class attribute or otherwise specify which input element(s) our rule is to be applied to.)

As an example, we could include the following into the head part of a document:

<style type="text/css"><!--
input.reset { color: #c09; font-size: 110%; font-weight: bold;
  font-family : Arial, Helvetica, sans-serif;
  background : #ccf none;}
--></style>

See the nice reference CSS Properties by WDG for an explanation of the properties and values used above, in order to know how to modify the style sheet for your needs and taste.

And then we could write the reset button(s) as follows:

<div><input type="reset" class="reset" value="Clear"></div>

This gives the following appearance on your current browser:

This would be an ideal way of making reset buttons visually distinctive if it worked widely. But among the browser I tested, only IE 4 and newer support the "styling" of buttons that way. We can however expect browser coverage to become more widespread. The method itself is robust in the sense that browsers which lack sufficient style sheet support (or have the support turned off) will just display a normal reset button.

Giving a hint using the title attribute

Independently of the method used to affect the presentation of a reset button, one could include a title attribute. to give a "tooltip" about the effect of the button. This might be useful especially if the presentation might be different from the way reset buttons are normally displayed.

The title attribute can be specified for most elements, including input, img, and a. It is currently supported by IE 4 and newer only, except that Opera supports it for links (a element with href attribute).

The next section will illustrate the use of the title attribute. It is important that an author regards it as advisory only. You should make any reasonable effort to make sure the meanings of form fields, including reset buttons, is obvious to the user even without the "tooltips" which might be available to some users.

A combined method (JavaScript and stylesheets)

This combined method consists of the "safe" method of using JavaScript, with extra code for handling older JavaScript implementations, to create an image which acts as a reset button, but with stylesheets used for the "fallback" content in the noscript element. Since this is just a combination of the three techniques, we only present an example:

<form action="http://www.cs.tut.fi/cgi-bin/run/~jkorpela/echo.cgi"
name="theform" method="post">
<noscript>
<p><input type="reset" value="Clear" class="reset" title=
"Clear all form fields (all of your input)"></p>
</noscript>

<script type="text/javascript"><!--
if(js_version == 1){
 document.write('<p><input type="reset" value="Clear" class="reset"',
 'title="Clear all form fields (all of your input)"><\/p>');}
else {
 document.write('<p><a onclick="document.theform.reset();return false;"',
 'title="Clear all form fields (all of your input)"',
 'href="#"><img alt="Clear" src="clear.gif"border="0"><\/a><\/p>');}
//--></script>
<p>
Type something: <input name="anytext">
</p>
<p>
<input type="submit" value="Send">
</p>
</form>

When used in a document which contains (or refers to) the JavaScript code for version detection and the style sheet presented above (which style sheet may or may not effect the presentation you see), this is how it looks like on your current browser:

Type something:

It would also be possible to give preference to a "styled" reset button over an image acting as such a button. I'd actually recommend that, for reasons explained above. This is currently relevant for IE 4+, and can be achieved by replacing the line

if(js_version == 1){
by the line
if(js_version == 1 || document.styleSheets){
(See Michael Bednarek's Dynamic StyleSheet, section Constructing the Page.)

Our example modified that way is rendered as follows on IE 4, when no other style sheet is in effect (irrespectively of whether JavaScript is enabled or not):

A relatively large light blue box with the word "Clear"
in it, in large red sans-serif font; followed by other form ingredients

Conclusions

The simple stylesheet method of suggesting font properties, together with background suggestions compatible with them, for reset buttons is probably the most recommendable in normal authoring. It is simple and robust, and increased browser support is to be expected. But if you wish to increase the odds of making reset buttons look different on current browsers, consider using the more complex method which combines stylesheets and JavaScript.

The complex, combined method gives us a reset button (or equivalent) as follows:

For reasons explained above, a reset button should normally appear as the first element in a form. For small forms, e.g. simple query forms with a single-line input field only, a reset button is usually not needed at all.