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.