SELECT tag issues

There's an area of confusion regarding the SELECTED attribute of the OPTIONs in a SELECT group. RFC1866 said that in the absence of an explicit SELECTED attribute, the initial state of the form is to have the first option selected. You may or may not agree that this was a good idea, but this is what the HTML2.0 specification said. Although some browser developers implemented the specification, others did their own thing. Authors who assume that what their favourite browser does is also universal for other browsers, may in fact publish a form that is unusable by some proportion of their readers: this can be avoided by following the advice given in the HTML4.01 specification and demonstrated below.

(Started around Sept 1996: incompletely updated since, apologies for any rough edges. Some browser versions could now be considered obsolete but have been left in for information anyway. Last substantive update Nov 2001.)

This page is a tutorial on a particular aspect of browser behaviour and an authoring workaround, and makes no attempt to be a tutorial on forms authoring in general.

This issue goes back to the HTML2.0 spec, RFC1866, specifically section 8.1.3. Note that HTML3.2 does not explicitly address this issue: it makes it clear that in a non-multiple SELECT it is an error to make more than one OPTION "SELECTED" (as if this wasn't obvious), but fails to make the rest clear one way or the other.

When HTML4.0 was first published, it completely negated the RFC1866 specification on this issue: you might still find the archived original which says:

If no OPTION element has the selected attribute set, no options should be pre-selected.

However, in the revisions that went into HTML4.01, the specification was substantively changed, and now declares the issue to be undefined and browser-dependent:

If no OPTION element has the selected attribute set, user agent behavior for choosing which option is initially selected is undefined. Note. Since existing implementations handle this case differently, the current specification differs from RFC 1866

In RFC1866 where it discussed preselection of an OPTION, it didn't draw any distinction on whether MULTIPLE was used. Again, I'm not discussing whether this was the right choice, or might even have been a mistake in drafting: I'm just pointing out what RFC1866 actually says.

These tests don't normally use the VALUE attribute on the OPTION tag, as it isn't relevant to the issue.

The tests use FORM METHOD=GET; most of the tested browsers also support method POST of course.

As you (one hopes!) can see. In Test4, the user sees the invitation to choose; they are meant to click the button and choose one of the options that appear. In Test5, on browsers that honour the SIZE>1 specification, they see all of the options, including the dummy (which is blank). Test 6 is similar to test 5, except it attempts to hide the dummy selection by making the SIZE smaller: this works OK on some browsers (e.g NS Nav 3.0), but a couple of the tested browsers scroll down to the dummy selection, thereby scrolling one of the genuine options out of view, unfortunately.

In the situation where there were many more options to choose from, you would have to keep the SIZE to a reasonable value; but you could still add a dummy entry to the end of the options list, and arrange to send back either no value, or a dummy one. Sure, there's nothing to prevent some joker from choosing this value, but in your form evaluator you could reject this value and call for the user to try again, if that's the appropriate thing to do.

I've avoided unnecessary decorative markup in this document: this page only gives you some technical information to help you with the specific aspect of forms design that it describes. When you actually make your forms you are, of course, free to decorate them in any way you wish.

Browser results

Explanation of the table:

[omitted]

This name=value pair was omitted from the submission

[blank]

This name=value pair was included in the submission; the value was null.

Test6

The submission results from test 6 were the same as test 5, so they are not tabulated.

Test7

The submission results from test 7 were all successful (they sent the expected "US $ Check"), so they aren't tabulated.

Reset

Shows whether using the Reset button successfully re-instated the form to its initial state. On some browsers the re-instatement was ineffective (some of the selections remained selected) while on at least one, the Reset button was too effective, it even unset the explicit selections coded in the HTML!!!

Notes.

• 1. In test 6, this browser positioned the SELECTED, dummy, option in the viewable window, with the result that one of the "real" options was out of view. So that defeated the purpose of this variation.
• 2. Opera 2.08 and UdiWWW only used a size=1 widget, ignoring the suggested size.
• 3. NCSA Win Mosaic 2.1 screwed up the display of the explicitly-sized widgets.
• 4. WinWeb (this version, anyway) is obsolete, but it was thought to be HTML2.0 compliant in most respects. (By the way, it does not support POST, only GET).
• 5. Lynx's initial display, not unreasonably, shows only one option from each widget. However, the SIZE parameter affects the way in which the selections are displayed when a selection widget is activated.
• 6. iCAB apparently implements all non-MULTI selects as pop-outs, and all MULTI selects as scrolling lists, irrespective of the SIZE attribute specified. Also, the "reset" and "submit" buttons were unlabelled by default.

Observations

Curiously, whereas all of the tested browsers seemed to follow the requirement of RFC1866 when size=1, most of the popular browsers followed the original HTML4.0 recommendation when size>1. Nevertheless, there were browsers (including iCAB and w3m, as well as then-recent versions of Lynx that were included in the tests) which still followed RFC1866 in both cases. The only difference in the HTML is whether the size attribute is 1 or greater: the HTML specifications don't say anything about the implied option selection being dependent on that!

So, starting from an unsatisfactory situation where browsers only partially conformed to RFC1866, we have now added a crop of browsers to the mix that only partially conform to the original HTML4.0 recommendation; and HTML4.01 has abandoned any hope of codifying the behaviour. I think the advice to authors is much the same as it was before: design defensively.

The earlier problems with the Reset function seem to have been solved in current browser offerings.

Conclusions and recommendations

It isn't possible with the methods of tests 1 and 2 to determine reliably whether the user made an actual choice or not; therefore, it's probably best avoided unless the default choice is acceptable, in which case test 7 shows the user more clearly what is the default.

Test 6 was neat on some browsers, but worse than test 5 on others. I can't recommend it in general.

Test 2 is poor both from the point of view of the author (when the user fails to make a choice, browsers differ as to whether they report North as having been selected or not) and from the point of view of the user (the user gets no idea what will happen if they don't make a choice): if a default choice is acceptable, then test 7 is better. If a default choice is not acceptable, i.e the script should detect that the user has failed to make an explicit choice, then any of 3, 4 or 5 produce acceptable results: as test 5 is not particularly attractive visually, I think that for a SIZE attribute greater than 1, I would follow the pattern of Test 3, leaving it to the evaluation script to resolve the differences between browsers that submit a blank value, and those that omit the item from the submission.

Test1 could potentially behave like Test2, if there seemed any risk of browser implementers actually complying with the original HTML4.0 recommendation. If you want to have an option preselected, you can preselect it explicitly - that then conforms to both RFC1866 and HTML4.0, as well as to what browsers actually do. In any case, your evaluation script needs to be able to deal with literally any submission, whether a browser could have created it or not: a popular pastime among some hackers is creating fraudulent form submissions in the hope of causing your server scripts to crap out. Again: "design defensively".

Some browsers send a null value by sending a name=value pair with the value being null, which is what the specs seem to call for, while others (mostly older versions) omit the complete name=value pair from the response: forms evaluators should be coded to deal with this. Well, I expressed that badly: you shouldn't really be coding a form evaluator yourself at all, but making use of some well-designed CGI library that has already been debugged. But no library can achieve for you something that your FORM is incapable of supporting, so you still need to know how to make a workable FORM in the first place. And this note is intended to help on that specific point.

  

Original materials © Copyright 1994 - 2006 by A.J.Flavell