[whatwg] How not to fix HTML

Lachlan Hunt wrote:
> Matthew Raymond wrote:
>>    Here's a thought:
>>
>> | <p>
>> |   <grouplabel for="gender">Gender:</grouplabel>
>> |    <label><input type="radio" name="gender" value="m">Male</label>
>> |    <label><input type="radio" name="gender" value="f">Female</label>
>> | </p>
>>
>>    The element <grouplabel> gives the label for the group.
> 
> That's similar to the <label group=""> idea I posted.

   True, but it eliminates the need for an |info| attribute on every
element. When you get into the dozens of radio buttons, you don't want
to have to add an attribute to every element. You want to be able to
just add the element for the group label.

>> The |for| attribute in this case takes a name rather than and ID,
> 
> I think that could be somewhat confusing using the same attribute name 
> for different, but somewhat related, features.  That's why I like the 
> group attribute, because then there's no chance for confusion about 
> whether it takes a name or id in this context.

   Yeah, that bugged me a little too. A better solution would be to use
<input group="">, where the value of |group| is the value of the
controls' |name| attributes and not the value of |info| attributes, thus
eliminating the need for |info|.

Example:

| <p>
|   <label group="gender">Gender:</label>
|
|   <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>
| </p>

> Also, <label> already supported, so there's fewer backwards 
> compatibility issues.

   I somewhat agree, but the standard presentation for an unassociated
<label> is typically just to treat it as a <span>. It does, however,
make it easier to style on browsers that don't allow styling on unknown
elements, so you have a point in that regard.

Received on Wednesday, 1 November 2006 04:03:19 UTC