[whatwg] [WF2] <select required>

I just realized that there is existing support for using a first OPTION as a
non-selectable hint value. Instead of this:

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

One may set two attributes, @disabled and @selected, on the first OPTION:

<select>
>   <option disabled selected>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 behavior in browsers is that "Select one" is displayed as the value in
the drop-down, and in MSIE it's even grayed out. In Firefox and MSIE, since
the default selected option is disabled, it will not submit a value. In this
case, the option's @value makes no difference and can be an empty string or
any value at all. (Note that Firefox is a little buggy in that when clicking
on the select list, the shown selected option won't change but the value
submitted will change to the first non-disabled value.) Unfortunately,
Safari and Opera submit the disabled option, even though it cannot be
selected by hand. In IE and Firefox, once the one of the options is selected
by the user, they are unable to re-select the disabled option, as with
Safari and Opera.

Here's a demo:
http://weston.ruter.net/projects/test-cases/html-select-element/

I also include on that page a proposed "unselected" attribute for the SELECT
element. By default, a first option in a SELECT is selected; the only way to
select no OPTION is to set select.selectedIndex = -1. It would seem quite
useful if some non-scripting means of doing this; perhaps an "unselected"
boolean attribute would make sense. Unfortunately, WebKit still submits the
first OPTION as the value even if the selectedIndex == -1.

Regarding the original topic of this thread, the select at required attribute,
when select.selectedIndex == -1 (whether set programmatically or via some
"unselected" boolean attribute), a @required attribute absolutely makes
sense. It also absolutely makes sense with select at multiple.


On Fri, Oct 24, 2008 at 11:14 AM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:

>
>
> 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/b61b2282/attachment.htm>

Received on Friday, 24 October 2008 12:40:03 UTC