[whatwg] [WF2] <select required>

[Ian Hickson]

Quoted below is some feedback basically asking for a way to:

 a) make <select> not have a default value
 b) show a placeholder when there's no default value
 c) make picking a selection required for submission

Something like:

  <label>
   Country:
   <select placeholder="Select a country" required="" value="" name="c">
    <option>Ukraine
    <option>Norway
   </select>
  </label>

Requests b) and c) are easy; we can just port placeholder="" and 
required=""; request a) is a little harder because we have to have a way 
to indicate that no <option> should be selected, but using value="" seems 
reasonable if we've added value="" as part of another request.

However, I am loath to do this right now, because, as noted earlier, we 
already have a lot of new features in the forms section and these are not 
really all that critical in comparison to some of the other features.

So, I have noted them as "v2" feature requests in the markup in a comment 
in the <select> section, but I haven't yet added them. If and when 
implementations reach a state where implementations could benefit from 
more features to implement, then we can look at adding these.


On Thu, 23 Oct 2008, Weston Ruter wrote:
>
> Many times I've set SELECT.selectedIndex to -1 to have the effect of an 
> invalid starter value; I think this is a case where the REQUIRED 
> attribute would make sense. If a SELECT has a REQUIRED attribute, and 
> SELECT.selectedIndex == -1, then the control would be considered 
> invalid. It would also seem to be beneficial to have some non-scripting 
> means of setting SELECT.selectedIndex to -1. Perhaps an "UNSELECTED" 
> boolean attribute, as in <select unselected>

On Fri, 24 Oct 2008, Weston Ruter wrote:
>
> 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 Thu, 23 Oct 2008, Andy Lyttle wrote:
> 
> 1) If the user clicks to open the menu, then clicks away or presses Esc 
> without making a selection, does that count as a selection for purposes 
> of making the placeholder not appear again?

On Fri, 24 Oct 2008, Tab Atkins Jr. wrote:
> 
> No.  They have not yet selected anything.  The situation is similar to 
> the preferred display of the hint in a text input - if the user focusses 
> the field (making the hint disappear) then changes the focus without 
> ever entering anything, the hint should display again.

On Thu, 23 Oct 2008, Andy Lyttle wrote:
>
> 2) If the user never selects something, they'll never see anything but 
> the placeholder.  That means they won't see the text associated with 
> whatever option is selected by default.  In many cases, the default 
> option will be some sort of blank* value to indicate that the user has 
> not made a selection; the current practice serves both purposes at the 
> same time (having a blank value to indicate no selection, and setting 
> the text of that option to a placeholder/hint).  A placeholder option 
> would replace one of these purposes, but not both; authors would still 
> need to have a default option that indicates non-selection.
> 
> * By blank, I mean something unique that the script that will process 
> the form knows means a non-selection.  I normally use <option value=""> 
> for this purpose, but it could be any value the author devises.
> 
> In other cases, there must always be something selected; a non-selection 
> shouldn't be possible.  An example might be the "country" field on an 
> address form, which defaults to the most likely choice (e.g. United 
> States for sites that expect most of their audience to be American).  
> The user shouldn't be permitted to select a non-value.  How should the 
> placeholder text be displayed?  It seems clear to me that it should NOT 
> appear on the collapsed menu at all, but should appear at the top of the 
> expanded menu.
> 
> There are other cases where having a blank option is appropriate, but 
> the default may be something else.  The user can explicitly change the 
> selection to a blank option.
> 
> How should the placeholder behave in each of these cases?
> 
> I realize these are display issues rather than semantic issues, but I 
> think it's appropriate to discuss them.

On Fri, 24 Oct 2008, Tab Atkins Jr. wrote:
> 
> Very, very good questions.  Okay, so let's go back to the beginning. 
> <select> already has a widely-used hinting method.  If there is an 
> appropriate default <option>, then an author puts @selected on it, and 
> everything's golden.  If not, the author makes the very first <option> 
> have an appropriately hint-y text, and an appropriate default value, so 
> that they can distinguish on the server side that the <select> wasn't 
> successfully submitted.  These two methods are already widely used, so 
> is there actually a problem needing to be solved here?  Both methods 
> will also need to be supported into the future as fallback material.
> 
> I think yes.  If there is an appropriate default value, we don't need a 
> hint.  This is similar to a text input with @value - a good value is 
> already provided, and the <label> and context provides the rest of what 
> you need. However, if there is *not* an appropriate default value, the 
> current practice makes this known *only* to the server-side script.  
> The UA has no way of knowing that the <select> is officially in an 
> invalid position at the moment, and so can't provide automatic 
> validation help (like it can with <input @pattern>).
> 
> So that's the only problem we really have to solve - how to tell the UA 
> that the first <option> in the <select> is invalid.  We Two things 
> present themselves to me.
> 
> (1) Allow @hint as a boolean attribute on the first <option>.  This is 
> nothing more than what I said above - a hint to the UA that the first 
> <option> in the list isn't a valid choice, so it should display as 
> normal but not be submittable with this value.
> 
> (2) Put @hint as a text attribute on <select>.  This would then display 
> initially on the collapsed <select>.  Upon selecting a value, the hint 
> disappears and <select> acts like normal.
> 
> Option (1) is easy.  However, it breaks symmetry with the proposed 
> <input>/<textarea> @hint attribute.  As well, it still provides an 
> officially selectable attribute, even if the UA prevents the form from 
> actually being submitted with it.  The best user experience would be if 
> the user simply couldn't select this.
> 
> Option (2) has some possibilities when we consider the fallback issue.  
> For legacy UAs we must allow a 'default' value that the server can 
> detect, and this should be expressed as the first <option> to match 
> current strategies, so that it will be automatically submitted if the 
> user makes no choice.  We can exploit this.  I think it's reasonable to 
> say that if @hint is specified on the <select>, and the first <option> 
> has no text within it, the UA can choose to *not display* that first 
> <option>.  This produces exactly what we want - an initially displayed 
> hint that disappears as soon as the user actually interacts with the 
> control, just like @hint works on a text input. In legacy UAs that don't 
> understand @hint, they'll simply display a blank <option> initially, 
> which will be submitted with the author-supplied default value (so "" 
> isn't reserved as the default and unusable as an actual value).  This is 
> a reasonable fallback method, and is used today in many cases.
> 
> To jump to another issue, I do *not* believe the hint should be 
> displayed when the <select> is expanded.  That's similar to displaying 
> the hint when the user has focused a text input.  If you need any help 
> inside of a <select>, you have <optgroup>, which is more flexible.  You 
> can wrap all the <option>s in an <optgroup> if you really need text in 
> the expanded <select>.
> 
> 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.

On Fri, 24 Oct 2008, Andy Lyttle wrote:
> 
> 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). :-)

On Fri, 24 Oct 2008, Tab Atkins Jr. wrote:
> 
> 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.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'