Re: [whatwg] [WF2] select required
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 optionUkraine optionNorway /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 itLove It/option option value=hate itHate It/option /select One may set two attributes, @disabled and @selected, on the first OPTION: select option disabled selectedSelect one/option option value=None of these/option option value=love itLove It/option option value=hate itHate 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: [whatwg] [WF2] select required
On Fri, Oct 24, 2008 at 12:37 AM, Andy Lyttle [EMAIL PROTECTED] 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.
Re: [whatwg] [WF2] select required
On Fri, Oct 24, 2008 at 11:57 AM, Andy Lyttle [EMAIL PROTECTED] wrote: On Oct 24, 2008, at 8:23 AM, Tab Atkins Jr. wrote: 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 optgroups 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? 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. 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 itLove It/option option value=hate itHate 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 itLove It/option option value=hate itHate 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
Re: [whatwg] [WF2] select required
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 itLove It/option option value=hate itHate It/option /select One may set two attributes, @disabled and @selected, on the first OPTION: select option disabled selectedSelect one/option option value=None of these/option option value=love itLove It/option option value=hate itHate 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] On Fri, Oct 24, 2008 at 11:14 AM, Tab Atkins Jr. [EMAIL PROTECTED]wrote: On Fri, Oct 24, 2008 at 11:57 AM, Andy Lyttle [EMAIL PROTECTED] wrote: On Oct 24, 2008, at 8:23 AM, Tab Atkins Jr. wrote: 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 optgroups 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? 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. 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
Re: [whatwg] [WF2] select required
The official documentation for the http://msdn.microsoft.com/en-us/library/ms533732(VS.85).aspx disabled Property (BUTTON, INPUT type=button, INPUT type=checkbox, ...): contains the following: Note For http://msdn.microsoft.com/en-us/library/ms535876(VS.85).aspx OPTGROUP and http://msdn.microsoft.com/en-us/library/ms535877(VS.85).aspx OPTION, the functionality specified by the http://www.w3.org/tr/rec-html40/ HTML 4.0 World Wide Web link standard is not currently implemented. You can define your own functionality. _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Weston Ruter Sent: Friday, October 24, 2008 9:40 PM To: [EMAIL PROTECTED] Cc: Ian Hickson; Tab Atkins Jr.; Joao Eiras; Simon Pieters; Robert Subject: Re: [whatwg] [WF2] select required 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 itLove It/option option value=hate itHate It/option /select One may set two attributes, @disabled and @selected, on the first OPTION: select option disabled selectedSelect one/option option value=None of these/option option value=love itLove It/option option value=hate itHate 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/ image001.gif
Re: [whatwg] [WF2] select required
Kristof, you are right. This is not implemented in IE 7. However, Microsoft has implemented it in IE 8 Beta 2; that's what I tested in. On Fri, Oct 24, 2008 at 12:52 PM, Kristof Zelechovski [EMAIL PROTECTED] wrote: The official documentation for the disabled Property (BUTTON, INPUT type=button, INPUT type=checkbox, ...)http://msdn.microsoft.com/en-us/library/ms533732%28VS.85%29.aspx: contains the following: *Note* For OPTGROUPhttp://msdn.microsoft.com/en-us/library/ms535876%28VS.85%29.aspxand OPTION http://msdn.microsoft.com/en-us/library/ms535877%28VS.85%29.aspx, the functionality specified by the HTML 4.0http://www.w3.org/tr/rec-html40/ [image: World Wide Web link] standard is not currently implemented. You can define your own functionality. -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Weston Ruter *Sent:* Friday, October 24, 2008 9:40 PM *To:* [EMAIL PROTECTED] *Cc:* Ian Hickson; Tab Atkins Jr.; Joao Eiras; Simon Pieters; Robert *Subject:* Re: [whatwg] [WF2] select required 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 itLove It/option option value=hate itHate It/option /select One may set two attributes, @disabled and @selected, on the first OPTION: select option disabled selectedSelect one/option option value=None of these/option option value=love itLove It/option option value=hate itHate 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/ image001.gif
Re: [whatwg] [WF2] select required
On Mon, 2 Oct 2006, Simon Pieters wrote: The required= attribute doesn't apply to selects in the current draft of WF2. As an author I'd expect it to apply to select. I've seen a case where a select is used and the user is required to change its value, as in: select name=test required option value=Select one: optionFoo optionBar /select Now this can be done with radio buttons instead, but why can't the above be supported? That is, make required apply to selects and if the value is empty then required is not satisfied. (Same for select multiple.) (I realise that radio buttons and checkboxes satisfy required even if the value is empty.) On Wed, 4 Oct 2006, Robert wrote: Submitting an empty value may be wanted, and since a select by definition is a list of predefined valid values, it would make little sense to prevent the user from selecting some of them. However, I agree with the use case of the invalid starter value so users must consciously select a value they wanted instead of the default one. This use case is definitely something we want to consider, but I don't think it's about required=. It's about an option in the select being a non-option (as it were). select by definition can't have nothing selected. That's what it means. The issue about a placeholder value is listed as an open issue in the spec, and will probably be addressed at some future point. I hope this addresses your comments satisfactorily. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [WF2] select required
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 Weston On Thu, Oct 23, 2008 at 5:31 AM, Ian Hickson [EMAIL PROTECTED] wrote: On Mon, 2 Oct 2006, Simon Pieters wrote: The required= attribute doesn't apply to selects in the current draft of WF2. As an author I'd expect it to apply to select. I've seen a case where a select is used and the user is required to change its value, as in: select name=test required option value=Select one: optionFoo optionBar /select Now this can be done with radio buttons instead, but why can't the above be supported? That is, make required apply to selects and if the value is empty then required is not satisfied. (Same for select multiple.) (I realise that radio buttons and checkboxes satisfy required even if the value is empty.) On Wed, 4 Oct 2006, Robert wrote: Submitting an empty value may be wanted, and since a select by definition is a list of predefined valid values, it would make little sense to prevent the user from selecting some of them. However, I agree with the use case of the invalid starter value so users must consciously select a value they wanted instead of the default one. This use case is definitely something we want to consider, but I don't think it's about required=. It's about an option in the select being a non-option (as it were). select by definition can't have nothing selected. That's what it means. The issue about a placeholder value is listed as an open issue in the spec, and will probably be addressed at some future point. I hope this addresses your comments satisfactorily. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [WF2] select required
On Oct 23, 2008, at 5:31 AM, Ian Hickson wrote: This use case is definitely something we want to consider, but I don't think it's about required=. It's about an option in the select being a non-option (as it were). select by definition can't have nothing selected. That's what it means. The issue about a placeholder value is listed as an open issue in the spec, and will probably be addressed at some future point. This is an interesting point I hadn't considered. It's *very* common to use the first option in a select as a non-choice such as Choose one..., setting the value to something unique (often but it could be something else if is a valid choice) so it can be treated as a non-selection. This serves *precisely* the same purpose as the placeholder attribute on text input fields, which I had assumed wouldn't be valid for select. I suggest that the placeholder attribute should indeed apply to select, and the behavior should be similar to the current practice of using the first option. In particular, the placeholder should appear both on the collapsed menu, and at the top of the open menu, although it should not be selectable. But the question is, when the menu is collapsed, when should the placeholder be displayed instead of one of the options? Any time the value is ? Only until the user selects something? Somebody smarter than me, please figure this out. :-) -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] [WF2] select required
On Thu, Oct 23, 2008 at 12:45 PM, Andy Lyttle [EMAIL PROTECTED] wrote: On Oct 23, 2008, at 5:31 AM, Ian Hickson wrote: This use case is definitely something we want to consider, but I don't think it's about required=. It's about an option in the select being a non-option (as it were). select by definition can't have nothing selected. That's what it means. The issue about a placeholder value is listed as an open issue in the spec, and will probably be addressed at some future point. This is an interesting point I hadn't considered. It's *very* common to use the first option in a select as a non-choice such as Choose one..., setting the value to something unique (often but it could be something else if is a valid choice) so it can be treated as a non-selection. This serves *precisely* the same purpose as the placeholder attribute on text input fields, which I had assumed wouldn't be valid for select. I suggest that the placeholder attribute should indeed apply to select, and the behavior should be similar to the current practice of using the first option. In particular, the placeholder should appear both on the collapsed menu, and at the top of the open menu, although it should not be selectable. But the question is, when the menu is collapsed, when should the placeholder be displayed instead of one of the options? Any time the value is ? Only until the user selects something? Somebody smarter than me, please figure this out. :-) Very nice; I like the idea of expanding the proposed placeholder/hint attribute, and this does indeed seem perfect for it. 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. ~TJ
Re: [whatwg] [WF2] select required
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. 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? 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. -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] [WF2] select required
Well, the option element could be extended with a new attribute 'invalid'
which hold prevent that option to be selected.
Robert [EMAIL PROTECTED] escreveu:
On Mon, 02 Oct 2006 16:35:32 +0200, Simon Pieters [EMAIL PROTECTED]
wrote:
I've seen a case where a select is used and the user is required to
change its value, as in:
select name=test required
option value=Select one:
optionFoo
optionBar
/select
Now this can be done with radio buttons instead, but why can't the
above be supported? That is, make required apply to selects and if
the value is empty then required is not satisfied. (Same for select
multiple.)
Submitting an empty value may be wanted, and since a select by
definition is a list of predefined valid values, it would make little
sense to prevent the user from selecting some of them. However, I agree
with the use case of the invalid starter value so users must consciously
select a value they wanted instead of the default one.
The following script will do exactly what you wanted, although Opera
doesn't seem to use the custom error message for some reason. I'm not
sure if that's my fault or Opera's due to my lack of experience with
WF2, but it does prevent form submissions just fine as long as there are
invalid selects.
The script works in Opera 9.02.
script type=text/javascript![CDATA[
function checkSelect(e){
var test = e.target;
if(e.target.value == '')
e.target.setCustomValidity('You must select a value.');
else
e.target.setCustomValidity(null);
}
// Use '//select' for html documents, or use a wrapper function
// that strips namespace prefixes for plain 'ol html.
var res = document.evaluate('//html:select',document,
function(pfx){return 'http://www.w3.org/1999/xhtml';},4,null);
var elem=null;
while(elem = res.iterateNext()){
if(!elem)break;
checkSelect({'target':elem}); // do initial check
elem.addEventListener('change',checkSelect,false);
}
]]/script
--
Robert Græsdal
Re: [whatwg] [WF2] select required
On Wed, 04 Oct 2006 02:32:27 +0200, Simon Pieters [EMAIL PROTECTED] wrote: Then don't mark the select as being required. Or do you mean that there are cases where the user has to change the value to ? What would that be? One case could be that an old web application is configured serverside to interpret an empty value as none of the above. For the author, it would be risky to change this as opposed to just slapping on some added functionality for modern browsers on the client side. So should there be a declarative way to express this? I say yes, but I think pattern is a better candidate than required, or as Joao Eiras suggested, marking certain options as invalid - or all of the above. - Robert Græsdal
