[whatwg] Form Control Group Labels

[Markus Ernst]

Ian Hickson schrieb:
> On Tue, 31 Oct 2006, Lachlan Hunt wrote:
>> There are workarounds using fieldset and legend for the question, like 
>> this.
>>
>> <fieldset>
>>   <legend>Gender:</legend>
>>   <label for="m"><input type="radio" id="m" name="gender" value="m">
>>     Male</label>
>>   <label for="f"><input type="radio" id="f" name="gender" value="f">
>>     Female</label>
>> </fieldset>
> 
> That's not a workaround. It's exactly what you're supposed to do. 
> <fieldset> lets you group a set of controls with a common legend, which is 
> exactly the problem you described.

IMO Lachlans opinion about the fieldset solution being a workaround 
reflects a basic problem with those form elements: they are highly 
presentational. Your example:

<fieldset>
   <legend>Gender:</legend>
   <label for="m"><input type="radio" id="m" name="gender" value="m">
     Male</label>
   <label for="f"><input type="radio" id="f" name="gender" value="f">
     Female</label>
</fieldset>

serves the same purpose as this one:

<label for="gender">Gender:</label>
<select id="gender" name="gender">
   <option value=""> </option>
   <option value="m">Male</option>
   <option value="f">Female</option>
</select>

Both provide a list of values, of which zero or one can be selected. The 
only real difference is in the presentation, but structurally they are 
totally different. Now consider this:

<fieldset>
   <legend>Sender:</legend>
   <label for="n"><input type="text" id="n" name="n" value="">
     Name</label>
   <label for="m"><input type="text" id="m" name="m" value="">
     E-mail</label>
</fieldset>

This is structurally the same as the radio button example, except some 
attribute values, but serves a totally different purpose. If you look at 
it this way, calling the fieldset solution for grouping a group of radio 
buttons (which are actually grouped by their common name attribute 
value) a workaround does not seem totally wrong to me.

I consider a total re-thinking of select, input type="checkbox" and 
input type="radio" elements as highly desirable, though I see that this 
might cause more serious backwards compatiblity problems than for 
example removing the font tag. One possible solution could be using the 
select tag with a type attribute:

<label for="gender">Gender:</label>
<select id="gender" name="gender" type="boxgroup">
   <option value=""> </option>
   <option value="m">Male</option>
   <option value="f">Female</option>
</select>

Like this, the appearance would be controlled by the type and multiple 
attributes; type="boxgroup" in combination with multiple would create a 
group of checkboxes, without multiple a group of radio buttons. And 
older UAs would render it as a selectbox in all cases, thus preserving 
usability of the form.

And the label question would be consistently solved.