[whatwg] select element should have a required attribute

Jonas Sicking jonas at sicking.cc
Mon Aug 9 17:15:16 PDT 2010


On Mon, Aug 9, 2010 at 4:54 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> On Mon, Aug 9, 2010 at 4:35 PM, Ian Hickson <ian at hixie.ch> wrote:
>> On Fri, 18 Jun 2010, Mounir Lamouri wrote:
>>>
>>> I'm wondering why select element do not have a required attribute.
>>
>> It's impossible to submit a <select> element (without a size="" attribute
>> or multiple="" attribute) without it having a value -- essentially,
>> required="" is already implied.
>>
>>
>> On Thu, 22 Jul 2010, Mounir Lamouri wrote:
>>>
>>> 1. A typical use case of <select> is to have <option value=''>Choose an
>>> option</option> as a default value. Having @required would prevent
>>> authors to write any js check when they are using <select> like that.
>>
>> That seems like an invalid use of <option> to me. It would be better as:
>>
>>   <label> Choose an option: <select> ... </select> </label>
>
> Many times you want the user to make an explicit choice, rather than
> just leaving whatever was already selected. What many websites do is:
>
> <label>Choose an option:
>  <select>
>    <option></option>
>    <option>value 1</option>
>    <option>value 2</option>
>    <option>value 3</option>
>  </select>
> </label>
>
> Or
>
> <select>
>  <option value="">Choose an option:</option>
>  <option>value 1</option>
>  <option>value 2</option>
>  <option>value 3</option>
> </select>
>
> It would be good if it was possible to use @required together with
> these usage patterns. I don't believe that any other feature of HTML
> supplies the same, or similar, functionality? While authors could do
>
> <label>Choose an option:
>  <select>
>    <option>value 1</option>
>    <option>value 2</option>
>    <option>value 3</option>
>  </select>
> </label>
>
> I think there is a reason they haven't done so so far, and I don't see
> that HTML5 changes any of those reasons.
>
> While I guess we could wait for v2 for this feature, it seems like a
> glaring omission and inconsistency in the way that @required works.

There is another reason to introduce @required on select now, rather
than in v2. We're already seeing a small amount of complexity in
introducing @required because it's preventing existing sites from
working due to sites already having elements with a 'required'
attribute. And this is in a situation where @required has never been
part of any specificiation.

It is likely that if @required gains traction, which I think we're all
hoping for, that sites will use 'required' attributes on <select>
elements. This might work just fine as long as browsers ignore this
attribute. However once browsers attempt to deploy v2, there is a big
risk that many of these sites will stop working.

We could specify in v1 that @required on <select> always prevents the
form from submitting, that would make it easier for browsers to
implement v2. However that would make it harder for sites to deploy v2
since it would prevent the site from working in any old browsers that
only support v1.

Thus I recommend that we add @required now.

/ Jonas



More information about the whatwg mailing list