I just realized that there is existing support for using a first OPTION as a non-selectable hint value. Instead of this:<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
<select><br>
<option value="[[invalid]]">Select one</option><br>
<option value="">None of these</option><br>
<option value="love it">Love It</option><br>
<option value="hate it">Hate It</option><br>
</select><br></blockquote><br>One may set two attributes, @disabled and @selected, on the first OPTION:<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
<select><br> <option disabled selected>Select one</option><br> <option value="">None of these</option><br>
<option value="love it">Love It</option><br>
<option value="hate it">Hate It</option><br></select><br></blockquote><br>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. <br><br>Here's a demo: <a href="http://weston.ruter.net/projects/test-cases/html-select-element/">http://weston.ruter.net/projects/test-cases/html-select-element/</a><br>
<br>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. <br>
<br>Regarding the original topic of this thread, the select@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@multiple.<br>
<br><br><div class="gmail_quote">On Fri, Oct 24, 2008 at 11:14 AM, Tab Atkins Jr. <span dir="ltr"><<a href="mailto:jackalmage@gmail.com">jackalmage@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><br><div class="gmail_quote"><div><div></div><div class="Wj3C7c">On Fri, Oct 24, 2008 at 11:57 AM, Andy Lyttle <span dir="ltr"><<a href="mailto:whatwg@phroggy.com" target="_blank">whatwg@phroggy.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>On Oct 24, 2008, at 8:23 AM, Tab Atkins Jr. wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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>
</blockquote>
<br></div>
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.</blockquote>
</div></div><div><br>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.<br>
<br>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.<br>
<br>So, frex, this code would be perfectly fine, and would display the same in both legacy and hypothetical conforming UAs:<br><select><br> <option value="">None of these</option><br> <option value="love it">Love It</option><br>
<option value="hate it">Hate It</option><br></select><br>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.<br>
<br>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.)<br>
<br>On the other hand, this markup works differently:<br><select hint="Select one"><br>
<option value="[[invalid]]"></option><br> <option value="">None of these</option><br>
<option value="love it">Love It</option><br>
<option value="hate it">Hate It</option><br>
</select><br>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.<br>
<br>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.<br>
<br>And, of course, contrast that with this markup, which is how you would do this currently:<br><select><br>
<option value="[[invalid]]">Select one</option><br>
<option value="">None of these</option><br>
<option value="love it">Love It</option><br>
<option value="hate it">Hate It</option><br>
</select><br>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.<br>
<br></div><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Reserving value="" to indicate which option is the "blank" one would solve this problem (while presenting more). :-)<font color="#888888"><br>
</font></blockquote></div></div><br>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.<br>
<font color="#888888">
<br>~TJ<br>
</font></blockquote></div><br>