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.

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.

Here's some variations, for you to try on the browsers that
you use, and some comments on their usage.
Try submitting it before you've made any selections, and see what
happens. Then try making some selections and submitting again.
You might also want to play with the Reset button and find out
whether your browser really re-instates the initial state
of the form when you press it: you might need to re-load a fresh
copy of the form if you want to re-confirm the results of
submitting a form in its initial state.
I urge you to view the source of this document
to understand better what you are seeing here.

Above all, don't assume that what happens with one browser is
going to be the same with all other browsers.
Design defensively.

Examples when no option is explicitly
SELECTED

Test 1
, Test 2
, and Test 3

Variations with an option (dummy or not) initially
SELECTED

Test 4
, test 5
, test 6
, test 7

Variations on the MULTIPLE attribute

These are not reviewed in the browser results table,
but were added later for you to try out.
8 and 9 have the size explicitly specified and equal to
the number in the list: for a scrollable list you'd of course
specify a size greater than 1 but smaller than the number in
the list; 10 specifies size=1, and 11
does not specify the size.
Test10 comes out rather silly on the "big two" browsers,
I wouldn't recommend to copy that idea.

Test 8
, Test 9
10
, 11

Interaction of value, label and
element content

The following submit-button will submit all of the
above tests.

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!!!

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.