- From: Ian Hickson <ian@hixie.ch>
- Date: Sat, 29 Nov 2008 21:18:21 +0000 (UTC)
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. `._.-(,_..'--(,_..'`-.;.'
Received on Saturday, 29 November 2008 13:18:21 UTC