[whatwg] Form Control Group Labels

[Tab Atkins Jr.]

On Tue, Oct 28, 2008 at 11:39 AM, Markus Ernst <derernst at gmx.ch> wrote:

> 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.


FWIW, I completely agree with Markus re: the semantic similarity between
<select> <input radio> and <input checkbox>.  In my own programming
utilities I have a function which does exactly what Markus talks about; it
takes an array of value/text pairs, a display specifier
("collapsed"/"expanded"), and a multiplicity specifier ("single/multiple")
(also some arguments to specify @name and #id prefixes and such, but that's
not relevant here).  It uses this to transform the array into a <select>,
<select multiple>, <input radio> group, or <input checkbox> group as
necessary.  This is very easy precisely because of the clear semantic
mappings between the four types of input.

I haven't given it serious thought, but as far as I can tell his proposed
solution (piling all four display types onto the <select> tag) would work
wonderfully as a semantic consolidation/simplification, and be nicely
backwards-compatible.  There are still good reasons to support keeping the
<input> types of radio and checkboxes, of course (frex, wrapping a form
around a list, and putting an <input> within each <li>), but this proposal
would simplify the most common case.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081028/255879df/attachment-0001.htm>