[whatwg] [WF2] <select required>

On Fri, Oct 24, 2008 at 11:57 AM, Andy Lyttle <whatwg at phroggy.com> wrote:

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


Well, remember what the fallback <option> is for.  It's *only* meant to
indicate that the <select> has *not* been selected yet.  If "None of the
Above" or whatever is a valid choice, then it is ipso facto *not* a fallback
option.  It may be the default option, but that's no different than a
country selector setting United States as the default.  This doesn't clash
with my proposal at all, as it doesn't run afoul of the "first child of the
<select> with whitespace for content" rule.  The "none of the above" option
can be first, last, or anything in between.

You can even specify both a fallback and a "none of the above" option with
the same value if you so chose, though how that would be different from just
setting the "none of the above" option as @selected, I don't know.

So, frex, this code would be perfectly fine, and would display the same in
both legacy and hypothetical conforming UAs:
<select>
  <option value="">None of these</option>
  <option value="love it">Love It</option>
  <option value="hate it">Hate It</option>
</select>
Because there's no @hint attribute, both legacy and conformant UAs would
show the "None of these" option by default, and submit its value (the empty
string) if the user doesn't actively select anything.

If you provide a @hint attribute, the *only* change will be that conformant
UAs will display the hint in the collapsed <select> until the user actively
selects something.  Both legacy and conformant UAs will submit the empty
string as the value of the control if the user doesn't actively select
anything, because that is the value of the first <option>.  The defining
point of this piece of code is that "None of these" is an acceptable default
option to the author.  (Note that the author should probably give the first
option @selected, but that would prevent the hint from displaying; there are
some tradeoffs here.  Without the @selected it works the same, though.)

On the other hand, this markup works differently:
<select hint="Select one">
  <option value="[[invalid]]"></option>
  <option value="">None of these</option>
  <option value="love it">Love It</option>
  <option value="hate it">Hate It</option>
</select>
In a conformant UA, the <select> will initially display "Select one" while
it is collapsed.  When it is expanded, the first (blank) option will *not*
display.  If the user attempts to submit the form without actively selecting
a value, the UA will prevent it and inform them that they must select a
value in the control.

In a legacy UA, on the other hand, the <select> will initially display empty
when collapsed, and will have a blank line as the first option when
expanded.  If the user submits the form without actively selecting a value,
the server will receive the value "[[invalid]]", which lets the author know
that the user didn't actively select an option (or chose to select the blank
<option>, which is just as invalid), and that the user should be returned to
the form with an error message.

And, of course, contrast that with this markup, which is how you would do
this currently:
<select>
  <option value="[[invalid]]">Select one</option>
  <option value="">None of these</option>
  <option value="love it">Love It</option>
  <option value="hate it">Hate It</option>
</select>
The UA will display "Select one" initially in the <select>, and will send
"[[invalid]]" if the user doesn't select anything.  The difference is that
there's no way for a UA to detect that the form shouldn't be submitted with
the first <option> selected, and so any client-side validation has to be
done explicitly with scripting.

Reserving value="" to indicate which option is the "blank" one would solve
> this problem (while presenting more). :-)
>

Yeah, I don't think there's any need to go this far.  The existing hinting
practices allow us to formulate more exacting requirements for recognizing a
non-option, which avoids us having to deprecate large swaths of behavior.

~TJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081024/ceca6c68/attachment.htm>

Received on Friday, 24 October 2008 11:14:32 UTC