Choices in HTML forms

In HTML, there are several alternative methods for creating choices, which can be on/off, 1-of-many or many-of-many choices in forms. The methods, used inside a FORM element, include the SELECT element (containing OPTION elements and so-called radio buttons (INPUT TYPE="radio") and checkboxes (INPUT TYPE="checkbox"). Moreover, multiple submit buttons (INPUT TYPE="submit") can be used for the purpose. This document discusses the pros and cons of the alternatives in different situations. Although the document is not about the methodology of surveys, it describes how a careless use of HTML constructs can ruin a survey even if it is otherwise on a solid basis. This applies in particular to the problem of initial (default) selection, which can be solved by careful use of elements with the SELECTED or CHECKED attribute.

Content

1. Introduction: how to get bogus data without trying hard
2. Classes of choices
3. Various ways of creating choice menus
4. The inflexibility of SELECT, and the alternatives
5. Practical recommendations
6. The importance of sensible defaults
7. Forcing people to make a choice
8. Special case: dispensing with forms
9. Appendix: HTML specifications and default selections

Introduction: how to get bogus data without trying hard

Consider a very simple questionnaire which contains only yes/no questions, implemented using pairs of radio buttons, which is in itself a logical thing to do. But assume the code is essentially the following:

<STRONG>Question 1</STRONG>: Do you like apples?
<INPUT TYPE="radio" NAME="q1" VALUE="y">Yes
<INPUT TYPE="radio" NAME="q1" VALUE="n">No

which might look like the following on a screen:

In such a case, if the user does not answer a question at all, the results you get depend on the browser he is using to fill out the form.

It would be natural to assume that the data received indicates that the question was not answered, i.e. there is no q1 field in the data in this case. But in fact some HTML specifications recommend that browsers should behave as if the first choice had been selected. Actually most browsers do not behave that way; Lynx is an exception I've seen - there might be others. This way, you could get very positive results - which are positively incorrect. The person who answered your questionnaire might think he said "I don't know" or "I don't want to answer that question", but perhaps it was actually taken as "yes" (or whatever happened to be the textually first alternative).

On browsers which send no data in the case discussed here, it is the server side script that interprets the situation. And if it does not distinguish between lack of answer and a "no" answer the results would be fundamentally distorted. It is a feature of human behavior that we tend to avoid answering questions for various reasons, not just because we mean "no".

Even if the user's browser treats no selection the way that most browsers do, there is a problem if no neutral choice is available: if a user makes a selection, then decides to cancel that and leave the question unanswered, he can't do that - a radio button selection can be changed only by selecting another button in the same group. It is true that the entire form could be reset or reloaded, but it's a serious violation of good user interface design principles if the user has to clear everything just to cancel a single selection.

A classic design mistake on the Web is to have radio buttons that initially do not have a selection. Often, there is no way for the user to select a "nothing" option, once he or she has selected one of the choices. Always include an explicit radio button for the default choice and always include a selectable menu entry in pull-down menus for the default choice. Otherwise you do trap users.

Jakob Nielsen: Reset and Cancel Buttons

Moreover, a hurried user might mentally select the answer "Yes", then click on the radio button after it to express his opinion. Perhaps such errors are not frequent when there are just two choices, but in a row of choices, it might be rather easy to click on the wrong button if the association of buttons and texts is not indicated well. The association problem will be discussed later.

There is yet another reason for always including an initially selected alternetive: when tabbing is used to move inside a form, as many people prefer to do and many people need to do, then a group of radio buttons acts as a unit, on browsers such as Internet Explorer. More exactly, when you hit the tab key when in a field preceding a group of radio buttons, focus moves to the button that is currently checked. You can then toggle its setting by hitting the space bar, or move to other buttons in the group using arrow keys. (Technically, the group is defined as a set of radio buttons with the same name attribute.) But this functionality breaks if no button is checked: focus moves past the group, i.e. the buttons are not accessible at all via tabbing.

For dropdown lists, too, a preselected option should be provided, using the selected option, when the list is for selecting exactly one option. If you use a normal select element list with no option preselected, then it is undefined what happens if the form is submitted so that the user has made no selection from the list. Most browsers behave as if the first option had been selected, but this cannot be guaranteed, and it actually creates a serious problem if the first option is a real option: you cannot know whether you get that value because the user really selected it or whether it was sent because the user made no selection.

Classes of choices

The choices we discuss here mean that a user makes a selection from a well-defined finite (and usually small) set of alternatives. If this is not suitable, you need to use form elements which let the user input arbitrary text - arbitrary as far as HTML is concerned - using INPUT TYPE="text" or TEXTAREA elements. (In some cases, you might combine choices and free input; for example, you could have a set of alternatives, the last one being for "Other, please specify", with an attached free text input field.)

Note: If the choices are not essentially a simple list of alternatives, i.e. if you need to construct a hierarchic menu, see notes on simulating the OPTGROUP element.

For practical purposes, we can classify the kinds of choices we are discussing here as follows:

• A yes/no choice, or an on/off choice. This means selection between two alternatives.
• A 1-of-many choice. A selection from several alternatives so that you can choose one only, possibly with the option of not choosing anything.
• Many-of-many choice. Any number (0 to n) of choices out of n alternatives can be selected.

Various ways of creating choice menus

Let us consider a simple 1-of-many choice: we wish to ask the user select from a set of ice cream flavors. The following table shows four different ways to implement that in an HTML form.

Please feel free to try using the forms above if you are online. But note that the data is submitted to a very simple script which simply echoes back what it gets.

In the last method, using several submit buttons, BUTTON elements or INPUT TYPE="image" elements could be used as alternative. However, I think those methods would be inferior to using INPUT TYPE="submit" from the accessibility point of view. In any case, in this context they are just minor variations of a theme.

From a practical point of view, the basic characteristics of these methods are the following:

• The SELECT element is by default for 1-of-many choices, but by using the MULTIPLE attribute it can be made into a many-of-many menu. The author can also specify, using the SIZE attribute, his suggestion of how many alternatives are visible in the initial state. In a typical implementation, the default value for SIZE is 1 and for that value, the presentation is a compact "drop-down" menu, whereas for other values of SIZE, the presentation is a "scrollable list box". But the presentation of this element (and other form fields) may vary. As regards to a special case of using SELECT for a (1-of-many) choice between "navigational" alternatives, see the separate document Navigational pulldown menus in HTML.
• Radio buttons (INPUT TYPE=RADIO) are for 1-of-many choices. Radio buttons with the same name (as set by the NAME attribute) constitute a group. Only one of the buttons in a group can be selected: selecting a button clears out the previous selection. Note: The name used should be unique in the document, i.e. don't use it for another set of radion buttons in another form on the same page.
• A checkbox (INPUT TYPE="checkbox") is basically for a yes/no choice, the default being "no". Using a set of checkboxes with the same NAME attribute, one can effectively create a many-of-many menu.
• Using several submit buttons for creating a choice menu necessarily restricts it into a 1-of-many choice. The difference with the other methods, and the most common reason for using this method, is that a selection also causes immediate submission of the form data. (See also question Can I have two or more Submit buttons in the same form? in WDG Web Authoring FAQ.)

Note: Names of radio buttons and checkboxes are case-insensitive by the HTML 4 specification. However, several browsers get this wrong. Thus, it is best to avoid using names that differ in the case of letters only (e.g. name="foo" and name="Foo") and to write each name the same way in all occurrences.

As an alternative to including a choice menu at all, you can put a text input field into your form. A choice menu is a construct that makes the user select between predefined alternatives instead of typing his choice. Quite often text input is a better method even if you could easily specify a set of predefined alternatives. See the alertbox Drop-Down Menus: Use Sparingly by Jakob Nielsen.

Large menus, with dozens of alternatives, are rather problematic, no matter how you implement them. The problems are briefly mentioned on my page about country selection. For a large 1-out-of-many menu, the safest method is probably a select element with a size attribute larger than 1 (say size="4").

One of the drawbacks of the "button menu" approach is that if there are several submit buttons in a form, users might not be able to use an enter or return key in a text input field for form submission. This is browser dependent, but it is rather natural that some browsers do not accept enter or return as request for form submission in such cases, since the submission is not so well-defined semantically in such cases. As an example of this, take a look at the FOLDOC page. It contains a form with five different submit buttons and one text input field. On some browsers, filling just the text input field and pressing enter sends a search requests. On other browsers, doing so causes the original page reappear; this can be very confusing. (It would be a simple cure to make two distinct forms, so that the text input field and the search submit button belong to one form and the other submit buttons to another.)

The inflexibility of SELECT, and the alternatives

As mentioned above, the SELECT element is one of the ways of setting up a menu of choices, and it often has benefits over the alternatives. Especially when there is a large number of alternatives, SELECT is preferred by many authors; see notes on problems with large sets of radio buttons. But on the other hand, the use of SELECT implies serious restrictions.

Implications of using SELECT

In a SELECT element, the options must be written using plain text only, with no HTML markup (although entity references and numeric character references like &eacute; for é are allowed there). The reason is that syntactically a SELECT element may contain OPTION elements only, optionally grouped together using OPTGROUP, and in the content of OPTION, only plain text is valid.

This means, for example, that

• you cannot emphasize words using e.g. the EM element
• the options in a SELECT element cannot be put into different cells of table
• you cannot associate images with the options
• the methods for suggesting presentational properties like font face are rather limited.

Navigational SELECT?

If the limitations and problems of SELECT become serious, then the problems are often caused by the use of SELECT to create "navigational" menus, as explained in the document Navigational pulldown menus in HTML. In that case, the best approach is almost always to stop using a form at all and use a list of links instead.

Using radio buttons or checkboxes instead of SELECT

The restrictions listed above do not apply to radio buttons or checkboxes. The reason is that the basic method of setting up a menu using them is different. Instead of writing something like

<OPTION>apple

inside a SELECT element which has a NAME=fruit attribute you would, in the radio button approach, write

<INPUT TYPE="radio" NAME="fruit" VALUE="apple">apple

(typically followed by e.g. <BR> to cause a line break).

Note that you need to write a VALUE attribute, since there is no default for it in this case. But on the other hand, the text associated with the radio button is outside form fields, so you could use normal HTML markup there. You could even use an image, for example:

<INPUT TYPE="radio" NAME="fruit" VALUE="apple"><IMG
 ALT="apple" SRC="apple.gif">

Moreover, the construct consisting of the INPUT element and the associated text are "movable" in the sense that they could be put into cells of a table. There is no requirement that they appear inside a single container in the same sense as the options in a SELECT menu must be written inside a single SELECT element.

Making multiple selections easier

There is a special reason to avoid using SELECT when you wish to allow multiple selections, i.e. let the user pick up any number of alternatives presented. The reason is that the implementation of SELECT with the MULTIPLE attribute set is inconvenient in most browsers, and probably few users know how to actually select several alternatives especially if they want to select something else than a consecutive range. On a typical graphic browser (I tested this with IE 4, Netscape 4, and Opera 3.6 on WinNT), for SELECT MULTIPLE,

• normally clicking on one option turns it on and other options off
• when at least one option is on and one clicks on another keeping the SHIFT key pressed down, the a range of options gets turned on
• when one clicks on one option keeping the CTRL key pressed down, that option gets toggled (turned on if it was off, and turned off it is was on).

On the other hand, on Lynx for example a SELECT MULTIPLE is implemented as a fully visible list of options, with toggleable boxes for each option separately. This is basically similar to the implementation of a set of checkboxes on most browsers, so by using such a construct instead, you could make the user interface easier on most popular browsers too.

Example: "tabulated options"

Let us consider the following situation, which is probably rather typical: We wish to present some product information where each item consists of several sections of data. To take a simple example, that could mean product name (or code), product group characterization, and unit price - something that you would present as a table if it were to appear as such, not inside a form:

But how would you do the same, having the data aligned in columns in the visual presentation, when you put that data into a SELECT element in a form, to allow the user make an order for example? Basically, you cannot. Note that tab characters won't help - they are equivalent to spaces in HTML. If you tried to use tabs between the logical parts, you would just get something like

If it really appears as tabulated on your browser, it's exceptional browser behavior, and actually a bug!

What you could do to simulate tabbing is to use no-break spaces for padding, and to suggest (in HTML and in CSS) that the browser should use monospace font for OPTION elements. But that would mean something clumsy like

<style type="text/css">
select {font-family: Courier, monospace;}
</style>
 ...
<tt><select name="product" multiple size="3">
<option>XC232    Book     3.99
<option>DF345    CD-ROM  10.99
<option>WE320    CD       1.
99
</select></tt>

And although this produces "tabulated" look in most browsing situations, the appearance is not very nice due to the monospace font:

But there's a different approach. Since the SELECT element is so inflexible, let's use a set of radio buttons instead. (If we did not want to allow multiple selections, would would a set of checkboxes here.) This means that users will make the selections differently, typically by clicking on checkboxes, but as explained above, this probably makes things easier to them, and it lets you use tables for presenting something that is tabular material by its very nature. Example:

<table>
<tr><td><input type="checkbox" name="product" value="XC232">
 <th>XC232</th> <td>Book</td> <td align="right"><tt>3.99</tt></td></tr>
<tr><td><input type="checkbox" name="product" value="DF345">
 <th>DF345</th> <td>CD-ROM</td> <td align="right"><tt>10.99</tt></td></tr>
<tr><td><input type="checkbox" name="product" value="WE320">
 <th>WE320</th> <td>CD</td> <td align="right"><tt>1.99</tt></td></tr>
</table>

On you current browser, this looks like the following:

The markup is verbose, but not illogical. The appearance might not be quite what you prefer, but there are many ways to affect it, using various presentational attributes or style sheets or both. You'd probably want to use some simple utility (a short Perl script, for example) to generate (statically or dynamically) the markup. Note that this approach is more flexible functionally too: if you would like to modify the form so that the user can specify the number of items to be ordered, you could do that by replacing the checkboxes by text input areas (for typing in a number) or by select elements (for selecting 0,1,2,... up to some limit).

Simulating OPTGROUP

Using radio buttons instead of SELECT elements also allows us to present a hierarchic menu (or structured menu) in a sense. The HTML 4.0 specification defines the OPTGROUP element for constructing hierarchic menus, but this feature has not been universally implemented in browsers. And in any case, using radio buttons you can set up a hierarchic menu in a manner which works now and in the future. The following example corresponds to the latter OPTGROUP example presented in the HTML 4.0 specification (but so that one of the alternatives is prechecked):

<FORM action="..." method="post">
<P><INPUT TYPE="radio" NAME="ComOS" VALUE="unspecified" CHECKED
>Please select one of the alternatives below:
<TABLE BORDER="1">
<TR><TH ROWSPAN="3">PortMaster 3</TH>
<TD><INPUT TYPE="radio" NAME="ComOS" VALUE="pm3_3.7.1">3.7.1</TD></TR>
<TR><TD><INPUT TYPE="radio" NAME="ComOS" VALUE="pm3_3.7">3.7</TD></TR>
<TR><TD><INPUT TYPE="radio" NAME="ComOS" VALUE="pm3_3.5">3.5</TD></TR>
<TR><TH ROWSPAN="2">PortMaster 2</TH>
<TD><INPUT TYPE="radio" NAME="ComOS" VALUE="pm2_3.7">3.7</TD></TR>
<TR><TD> <INPUT TYPE="radio" NAME="ComOS" VALUE="pm2_3.5">3.5</TD></TR>
<TR><TH ROWSPAN="2">IRX</TH>
<TD><INPUT TYPE="radio" NAME="ComOS" VALUE="IRX_3.7R">3.7R</TD></TR>
<TR><TD><INPUT TYPE="radio" NAME="ComOS" VALUE="IRX_3.5R">3.5R</TD></TR>
</TABLE>
<P><input type="submit" value="Check">
</FORM>

This looks like the following on your current browser:

This was just an illustration; you might structurize such choices in many other ways too, e.g. using headings. But note that for a large menu (with lots of alternatives), practical problems may arise.

Practical recommendations

• For an optional selection, use a checkbox. This means a choice by the user to request for something, such as some optional equipment or feature when ordering something. In such cases, it is evident what the default is, and it is intuitively clear what the textboxes are for.
• For a very simple 1-of-many selection, you could use several submit buttons, unless you prefer either of the more normal methods described next. Simplicity usually means that the sole purpose of the form is to allow such a choice, without any other input from the user, except perhaps some optional input. If there isn't even any optional input and if the form submission method is GET, you could even dispense with forms (using just a normal link)!
• For a normal 1-of-many selection (apart from the two preceding cases), use either a SELECT element or a set of radio buttons. In both cases, make sure a well-defined default is initially selected, using the SELECTED attribute in the suitable OPTION element in the former case and the CHECKED attribute in the suitable INPUT element in the latter. Note that when using SELECT, the alternatives must be written as plain text without HTML markup; see section The inflexibility of SELECT, and the alternatives above.
• For many-of-many selection, use a set of checkboxes with the same NAME attribute. Normally you should not have any alternative initially selected, since it is intuitive to assume so, and people may not notice that the checkbox symbol (or equivalent) initially indicates a selected state. Using checkboxes for the purpose is much clearer than using a SELECT element with MULTIPLE attribute set, due to the way that element is typically implemented.

These recommendations are illustrated in the following table.

<INPUT TYPE="checkbox" NAME="milk" VALUE="yes">Milk requested

<INPUT TYPE="submit" NAME="bev" VALUE="Send tea!">
<INPUT TYPE="submit" NAME="bev" VALUE="Send coffee!"> 

<SELECT NAME="bev">
    <OPTION VALUE="no" SELECTED>No beverage
    <OPTION VALUE="tea">Tea
    <OPTION VALUE="cof">Coffee
    <OPTION VALUE="lem">Lemonade
</SELECT>

<INPUT TYPE="radio" NAME="bev" VALUE="no" CHECKED>No beverage<BR>
<INPUT TYPE="radio" NAME="bev" VALUE="tea">Tea<BR>
<INPUT TYPE="radio" NAME="bev" VALUE="cof">Coffee<BR>
<INPUT TYPE="radio" NAME="bev" VALUE="lem">Lemonade<BR>

Please specify ingredients:

<INPUT TYPE="checkbox" NAME="sal" VALUE="tom">tomatoes<BR>
<INPUT TYPE="checkbox" NAME="sal" VALUE="cuc">cucumber<BR>
<INPUT TYPE="checkbox" NAME="sal" VALUE="oli">olives<BR>
<INPUT TYPE="checkbox" NAME="sal" VALUE="oni">onion<BR>
<INPUT TYPE="checkbox" NAME="sal" VALUE="fet">feta<BR>

When you use checkboxes or radio buttons, make sure the association between a box or a button and the description of the choice is clear. Let us return the simple example in the introduction, now improved so that it has a neutral choice too (and selected by default):

This would be better if presented so that each choice occupies a separate line:

If you think this would occupy too much space, remember that HTML forms will normally be filled on screen, not on paper. But if you really want to save space, you might consider using a simple table:

You might also consider using the FIELDSET element.

The importance of sensible defaults

The introduction showed what may happen if the author does not bother considering what happens when a user does not answer a question at all.

In particular, a yes/no question should normally have a third alternative and it should be the default. (Some exceptions were discussed in the recommendations above.) Depending on the question, the third alternative might be "don't know", "don't care", "don't want to answer", "not applicable", or something like that. Such method, in addition to respecting people's right to refrain from answering a particular yes/no question, makes it technically possible to distinguish the lack of any answer from accepting "yes" or "no" (whichever you have set as default).

Similarly, in other 1-of-many situations as well, you should provide a neutral alternative as the default. Depending on the situation, you might actually provide several neutral answers, distinguishing for example "don't want to answer" from "don't know".

If the alternatives constitute an ordered set, say a scale from 1 to 5, it is normal to use an odd number of alternatives and let the middle one be the neutral and default choice. The problem with this, in terms of survey methodology, is that that it strengthens the tendency of answering too neutrally. People tend to select middle values in a scale even when they seriously try to tell their opinion. If the middle value is also the default, taken when the user doesn't really make a choice, you lose valuable information. Thus, it might be wise to have a default labeled e.g. "no answer" as logically distinct from the entire scale, placed either before or after the real alternatives. This allows you to have an even number of real alternatives, which you might wish to consider as one way of pushing people into making a decision of what they really prefer.

Technically, a default (initial) value for a form field can be specified as follows:

• for a SELECT element, by including a SELECTED attribute into the OPTION element corresponding to the the alternative to be initially selected
• for a set of radio buttons, by including a CHECKED attribute into the INPUT TYPE="RADIO" element corresponding to the the alternative to be initially selected
• for a checkbox, by including a CHECKED attribute into the INPUT TYPE="CHECKBOX" element if that checkbox is to be initially selected and by omitting the attribute if it is not
• for a single-line text input box (INPUT TYPE=TEXT), by including a VALUE attribute for it
• for a multi-line text input box (TEXTAREA), by writing the default value as the content of the element (i.e. between its start and end tags).

Forcing people to make a choice

One of the reasons for using choices instead of text input fields is to restrict people's choices to a finite set of alternatives. For example, if you ask a person to specify a country, you'd prefer getting unique, easily tractable answers instead of all possible and impossible spellings that people might use. Thus, using a menu of choices instead of a text input field is in a sense a way to "force" answers to be in a limited set of possibilities. Note that you still can't be absolutely sure, since a user might, for some reason, create a copy of your form and modify it; thus, for robust processing of data, the processing script should anyway check that a selection is valid.

But in addition to this, authors often wish to force users to answer, to make a real choice. For example, an author might provide a default choice as a dummy choice only, as something that the user must change.

The simple answer is that the only reliable way of checking such things is to do the checks in the server side script. Using the methods described here, you would provide a dummy default choice, then check in the server side script that the value submitted is different from the dummy default. More positively and more robustly, the script should check that the value is one of the allowed choices. Normally the script would send back an error message and the form (with supplied values as defaults) so that the user can fix and re-submit the form.

Note that any client-side checking (using e.g. JavaScript) would at most be an extra comfort to some users: they would get an error message more smoothly. But it is debatable whether double checking pays off. First, by writing the client-side checking you might tempt yourself into relying on it, omitting the server-side checking that really matters. Second, writing and maintaining two pieces of code for (partly) the same thing involves extra effort, and there's always the risk of logical mismatch between them. Third, if you give adequate and well-written filling instructions (about required choices, for example), as you should anyway, a user who fails to comply with them really deserves some mild punishment (a few seconds' delay)!

Special case: dispensing with forms

In a rather special, but common, case you can dispense with using forms and use just a link or a set of links instead. The conditions for this are as follows:

• The form would use the GET method of submission, i.e. METHOD="GET" as opposite to METHOD="POST". Note that GET is the default and that it means that the browser encodes the form data into the URL and processes the result as if it were a link anchor.
• The fields in the form would consist of a submit field and hidden fields only

Under these circumstances, you could replace the form by a link (or several links, corresponding to different submit buttons). Alan Flavell has written an illustrative document about this, FORM Submission (GET) by URL. The following is just a compact technical description.

Basically, you'd use a link with HREF value of the form
http://foo.bar.zap/script?name1=value1&name2=value2&...&nameN=valueN
but there are several complications; for instance, you must "escape" the & character when writing a URL into an HTML element. The detailed instructions are:

• For each submit button that would be included into the form, write a link.
• As the link destination (the HREF attribute), use the URL that would appear as the value of the ACTION attribute of the form.
• However, if the form would contain hidden fields, append a question mark (?) and data corresponding to the hidden fields to the link target URL according to the following rules:
  • Present the data in the form name=value where name and value are what you would have as values of the NAME and VALUE attributes of an INPUT TYPE="hidden" element.
  • However, encode "unsafe" characters appearing within the name or the value. In this context, all characters except the following are "unsafe": alphanumeric characters and the characters $-_.+!*'(),
  • If there would be several hidden fields, separate the data corresponding to them by the notation & (which is the HTML "escape" notation for the ampersand character & as a data character).

Thus, it's rather complicated. Perhaps a simple example shows it's not that complicated, though. In the following table, there is a simple form for submitting a Web page (this page, by the way) to Babelfish for automatic translation, and a simple link for the same purpose:

<FORM action="http://babelfish.altavista.digital.com/cgi-bin/translate">
<P>
<INPUT type="hidden" name="doit" value="done">
<INPUT type="hidden" name="urltext"
value="../forms/choices.html">
<input type="hidden" name="languagepair" value="en_fr">
<INPUT type="Submit" value="en fran&ccedil;ais">
</FORM>

<A HREF=
"http://babelfish.altavista.digital.com/cgi-bin/translate?doit=done&amp;
languagepair=en_fr&amp;urltext=http%3A%2F%2Fwww.hut.fi%2Fu%2Fjkorpela%2F
forms%2Fchoices.html">
Translate into French</A>

In the HTML code for the link, the notations %3A and %2F are encodings of the "unsafe" characters colon (:) and slash (/).

Although the example shows only one submit button or an equivalent link, the method can be extended into a 1-of-many choice. At the bottom of my home page you can see a set of buttons which effectively lets the user get a translation in one of the languages available. My reason for using submit buttons instead of links is that in such a case a submit button conveys the message that it really submits some data to a service, instead of being just a normal link.

Appendix: HTML specifications and default selections

This appendix quotes HTML specifications as regards to setting a default in the use of a set of radio buttons (with the same NAME attribute) and the SELECT element.

Radio buttons

• HTML 2.0 specification (a.k.a. RFC 1866) says:

  At all times, exactly one of the radio buttons in a set is checked. If none of the INPUT elements of a set of radio buttons specifies CHECKED, then the user agent must check the first radio button of the set initially.

• HTML 3.2 specification says:

  Only the checked radio button in the group generates a name/value pair in the submitted data. One radio button in each group should be initially checked using the checked attribute.

• HTML 4.0 specification says:

  Checkboxes (and radio buttons) are on/off switches that may be toggled by the user. A switch is "on" when the control element's checked attribute is set. When a form is submitted, only "on" checkbox controls can become successful. - -

  Radio buttons are like checkboxes except that when several share the same control name, they are mutually exclusive: when one is switched "on", all others with the same name are switched "off".

  Note: The text of the specification says selected instead of checked, but this error is mentioned in the errata.

Thus, the HTML 2.0 specification requires that the user agent provides a default (of the first item) when no author-specified default exists. The HTML 3.2 specification makes the additional requirement on authors (and documents) that a form must provide a default. These requirements are not mutually exclusive of course; when combined, they say that an author must provide a default but if the fails to do so, the browser must make the first item the default. (Notice that in many areas the HTML 3.2 specification must be read assuming the HTML 2.0 specification as background, so that anything in HTML 2.0 spec which is not explicitly changed in HTML 3.2 still holds in HTML 3.2.)

Unfortunately the HTML 4.0 specification here messes things up instead of clearing them up. The formulation is vague and does not even address the important question about the default! It even contains an example with a set of two radio buttons without a default.

See also Alan Flavell's document RADIO button issues.

SELECT element

For the SELECT element, HTML 2.0 specifies:

The initial state has the first option selected, unless a SELECTED attribute is present on any of the OPTION elements.

The HTML 3.2 specification does not mention this issue at all.

The HTML 4.0 specification contains a rather complicated set of rules:

Zero or more choices may be pre-selected for the user. User agents should determine which choices are pre-selected as follows:

• If no OPTION element has the selected attribute set, no options should be pre-selected.
• If one OPTION element has the selected attribute set, it should be pre-selected.
• If the SELECT element has the multiple attribute set and more than one OPTION element has the selected attribute set, they should all be pre-selected.
• It is considered an error if more than one OPTION element has the selected attribute set and the SELECT element does not have the multiple attribute set. User agents may vary in how they handle this error, but should not pre-select more than one choice.

Thus, there is definite contradiction between the HTML 2.0 and the HTML 4.0 specifications in the situation where no default is set in the document: HTML 2.0 says that the first option shall be initially selected, while HTML 4.0 says no option shall be initially selected.

Later, HTML 4.01 changed things again: in the first case, the browser behavior is undefined. The simple conclusion to be drawn from this is: don't let that situation arise. My advice of always including a "dummy" preselected option takes care of this.

For more information, see Alan Flavell's document SELECT tag issues, which discusses both the specifications and observed browser behavior.

Conclusion

Browser-independent behavior in this area can be guaranteed by always providing an author-specified default. This holds both in practice and according to the specifications, and it also avoids a situation where the specifications contradict each other. Thus:

An HTML author should always provide an explicit default for a set of radio buttons and for a SELECT element.