On Fri, Oct 24, 2008 at 12:37 AM, Andy Lyttle <span dir="ltr"><<a href="mailto:whatwg@phroggy.com">whatwg@phroggy.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=""><div class="Ih2E3d">
<div>On Oct 23, 2008, at 12:19 PM, Tab Atkins Jr. wrote:</div><blockquote type="cite"><div class="gmail_quote"><div>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.</div>
</div></blockquote></div></div></blockquote><div>My responses to the following questions (from Andy Lyttle, in case the quoting throws anyone) should be considered only my own opinions. <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=""><div>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?</div></div></blockquote>
<div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style=""><div></div><div>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.</div>
<div><br></div><div><div>* 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.</div>
<div><br></div></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>How should the placeholder behave in each of these cases?</div>
</div></blockquote><div><br>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.<br>
<br>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>).<br>
<br>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.<br><br>(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.<br>
<br>(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.<br><br>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.<br>
<br>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.<br>
<br>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>.<br>
<br>So, pulling it all together, my proposal for a hinting ability on <select> is thus:<br><br><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).<br>
<br>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.<br>
<br>This sound good?<br><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style=""><div></div><div><br></div><div>I realize these are display issues rather than semantic issues, but I think it's appropriate to discuss them.</div>
</div></blockquote><div><br>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. </div><br>~TJ</div>