[whatwg] [WF2] <select required>

[Tab Atkins Jr.]

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

> On Oct 23, 2008, at 12:19 PM, Tab Atkins Jr. wrote:
>
> Ultimately the display of the hint is, and should be, up to the UA, so that
> non-full-featured devices can display things in a maximally helpful way to
> the user.  Within the context of a standard browser on an ordinary computer,
> though, the correct display seems relatively clear.  When the select is
> collapsed, the hint should show until the user selects something.  After the
> user selects something, the hint will never again display in the collapsed
> state.  I'm not sure if it's necessary for the hint to display in the
> expanded state.  If it is, though, then it should always be the first item
> in the list, and it should be nonselectable, similar to how column groups
> display currently.
>
> My responses to the following questions (from Andy Lyttle, in case the
quoting throws anyone) should be considered only my own opinions.

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

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.

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

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.

This sound good?



> I realize these are display issues rather than semantic issues, but I think
> it's appropriate to discuss them.
>

Actually, I think they're very important issues that touch on more than just
display - this is fundamental usability here.  Thanks for bringing them up.

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