[whatwg] required attribute for checkbox/select

Ian Hickson wrote:

>>2) Why can't the required attribute apply to a select field?  It is common
>>for application designers to want to force the user to manually select an
>>option.  They will do something like <option value="">Please select a valid
>>option</option>. You could easily word the document to say that:
>That's, IMHO, semantic abuse. That isn't an option, and shouldn't be 
>called an option.
It may be semantic abuse, but I think it is pretty common usage in 
actual web development practice.  It's technically not a valid option, 
but it's the best we've got in HTML if you don't want the browser to 
preselect an option in your select box. There are times in a form where 
you want to force a manual selection and this is really the only way. It 
just seems odd to be able to require all other form controls in browser, 
but have to validate at server in the case of select/multi-select.  I 
suppose it is not the end of the world if this isn't supported -- and 
maybe you've thought it through more than I have. I am very happy my 
checkbox change made it in. More on the select issue below...

>>Or, you may not even need to re-word the document, but just remove 
>>select from the list of unsupported controls, since the final catch-all 
>>of this section explains "Any non-empty value satisfies the required 
>>condition, including a simple whitespace character."
>What would that mean for <select multiple>?
I would think as long as at least one option with a non-empty value is 
selected, then a select box (multiple or not) would satisfy the required 
attribute.  In a multi-select, almost all real-world cases have entirely 
non-empty values on the options.  This is because if no option contains 
a "selected" attribute, none are selected by the browser by default.  
Therefore, if one or more options are selected (any one of which 
contains a non-empty value attribute) then it would satisfy "required".  
With a single-select box, even if the designer has no option "selected" 
by default, the browser will choose one (the first).  This is why in 
many cases designers opt to have an empty-value option listed first that 
requests the manual selection of a valid option.

I simply think that my original proposal makes the most sense from a 
real-world web-apps implementation standpoint. Why deny authors the 
ability to require a select element when this method would match up with 
normal day-to-day usage of the element while not causing any negative 
side-effects (that I know of)?

However, if you cannot get past the semantic conflict, wouldn't it at 
least make sense to allow the required attribute on the select tag and 
have it say that at least one option must be selected? For any single 
select it would always be satisfied (since one option is always selected 
by the browser), but for a multiple select at least one option would 
have to be selected (since one is not always selected by the browser by 

Thanks for considering my input,

Matt Wright

Received on Sunday, 20 March 2005 20:22:13 UTC