On Tue, Oct 28, 2008 at 11:39 AM, Markus Ernst <span dir="ltr"><derernst@gmx.ch></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Ian Hickson schrieb:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">
On Tue, 31 Oct 2006, Lachlan Hunt wrote:<br>
</div><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
There are workarounds using fieldset and legend for the question, like this.<br>
<br>
<fieldset><br>
  <legend>Gender:</legend><br>
  <label for="m"><input type="radio" id="m" name="gender" value="m"><br>
    Male</label><br>
  <label for="f"><input type="radio" id="f" name="gender" value="f"><br>
    Female</label><br>
</fieldset><br>
</blockquote>
<br>
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.<br>
</div></blockquote>
<br>
IMO Lachlans opinion about the fieldset solution being a workaround reflects a basic problem with those form elements: they are highly presentational. Your example:<div class="Ih2E3d"><br>
<br>
<fieldset><br>
  <legend>Gender:</legend><br>
  <label for="m"><input type="radio" id="m" name="gender" value="m"><br>
    Male</label><br>
  <label for="f"><input type="radio" id="f" name="gender" value="f"><br>
    Female</label><br>
</fieldset><br>
<br></div>
serves the same purpose as this one:<br>
<br>
<label for="gender">Gender:</label><br>
<select id="gender" name="gender"><br>
  <option value=""> </option><br>
  <option value="m">Male</option><br>
  <option value="f">Female</option><br>
</select><br>
<br>
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:<br>
<br>
<fieldset><br>
  <legend>Sender:</legend><br>
  <label for="n"><input type="text" id="n" name="n" value=""><br>
    Name</label><br>
  <label for="m"><input type="text" id="m" name="m" value=""><br>
    E-mail</label><br>
</fieldset><br>
<br>
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.<br>

<br>
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:<br>

<br>
<label for="gender">Gender:</label><br>
<select id="gender" name="gender" type="boxgroup"><br>
  <option value=""> </option><br>
  <option value="m">Male</option><br>
  <option value="f">Female</option><br>
</select><br>
<br>
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.<br>

<br>
And the label question would be consistently solved.</blockquote><div><br>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.<br>
<br>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.<br>
</div></div>