On Oct 24, 2008, at 8:23 AM, Tab Atkins Jr. wrote:
So, pulling it all together, my proposal for a hinting ability on
<select> is thus:
<select> can have a @hint attribute, which takes a text value. If
there is no <option @selected>, then this hint is initially
displayed in the <select>'s collapsed state. As soon as an option
is selected, though (or if an <option> had @selected initially),
the hint disappears and the selected <option>'s text is instead
displayed in the <select>'s collapsed state. When @hint is
supplied, a conforming UA will not allow the form to be submitted
until an option is selected (again, an <option> with @selected
specified counts here), indicating in some way that a value in the
<select> must be chosen (the exact method UAs use to indicate this
to users is left undefined, but should be similar to how the UA
alerts a user that an <input> with @required is empty and must be
filled).
For fallback, authors should provide an empty <option> (or one
containing only whitespace) with an appropriate default @value as
the <select>'s first child. If <optgroup>s are used, this <option>
should come before them. Conforming UAs will not display this
<option>. In legacy UAs, this will cause the <select> to initially
display as blank in the collapsed state, and will submit the author-
supplied default value as the value of the control if the user does
not make a proper selection.
This sound good?
Almost! The only problem is, I might want the text of my "blank"
option to be something other than whitespace, for example "(none)",
"None of the above" (it could be the last option instead of the
first), etc. Remember that in a case where the initial state is some
other <option> selected, we want the user to be able to choose the
"blank" option, and "(none)" is much clearer in the expanded menu
than whitespace, which may not be recognized as being a selectable
choice.
Reserving value="" to indicate which option is the "blank" one would
solve this problem (while presenting more). :-)
--
Andy Lyttle
[EMAIL PROTECTED]