[whatwg] The legend element

[Markus Ernst]

Ian Hickson schrieb:
> On Mon, 12 Oct 2009, Markus Ernst wrote:
>> Ian Hickson schrieb:
>>>> Additionnally I want to suggest to make it possible to place the 
>>>> legend element outside the fieldset element, providing a "for" 
>>>> attribute (just as it is possible to place the label element apart 
>>>> from it's form field element).
>>> This is significantly harder to pull off, for the same reason that we 
>>> haven't been able to use <legend> for <figure>. I recommend we wait 
>>> for the next version of HTML before doing this.
>> Would it be possible and easy to allow <label> for fieldsets?
> 
> I don't understand the use case.

I am sorry I seem to have missed to make the use case really 
transparent. My use case is a template system with separate placeholders 
for labels and input fields, where input fields can be fieldsets in some 
cases, e.g.:


Relevant part of the template:

<!-- BEGIN form-fields-loop -->
<tr>
   <td><h2>{label}</h2></td>
   <td>{input-html}</td>
</tr>
<!-- END form-fields-loop -->


Placeholder outputs of first row:

{label}: <label for="q1">What is your name?</label>

{input-html}:
<input id="q1" type="text" name="Name">


Placeholder outputs of 2nd row:

{label}: <label for="q2">What is favourite pet?</label>

{input-html}:
<fieldset id="q2">
   <p><label><input type="radio" name="Pet" value="Cat">Cat</label></p>
   <p><label><input type="radio" name="Pet" value="Dog">Dog</label></p>
   <p><label><input type="radio" name="Pet" value="Ant">Ant</label></p>
</fieldset>


Placeholder outputs of 3rd row:

{label}: <label for="q3">When are you born?</label>

{input-html}:
<fieldset id="q3">
   <label>Month:
     <select name="Month">
       <option value="01">January</option>
       ...
     </select>
   </label>
   <label>Year: <input type="text" name="Year" size="4"></label>
</fieldset>


Rows 2 and 3 illustrate the use case. For my original suggestion replace 
<label> with <legend> in those rows.


>> This looks somehow consistent to me:
>>
>> <h2><label for="question1">Favorite pet?</label><h2>
>> <fieldset id="question1">
>>   <p><label><input type="radio" name="q1" value="Cat">Cat</label></p>
>>   <p><label><input type="radio" name="q1" value="Dog">Dog</label></p>
>>   <p><label><input type="radio" name="q1" value="Ant">Ant</label></p>
>> </fieldset>
> 
> Why is this preferable to:
> 
>  <fieldset>
>    <legend>Favorite pet?</legend>
>    <p><label><input type="radio" name="q1" value="Cat">Cat</label></p>
>    <p><label><input type="radio" name="q1" value="Dog">Dog</label></p>
>    <p><label><input type="radio" name="q1" value="Ant">Ant</label></p>
>  </fieldset>

It is in a case where you want to output the label/legend separate from 
the fieldset HTML, as in the above example.

>> or:
>>
>> <label>
>>   <h2>Favorite pet?<h2>
>>   <fieldset>
>>     <p><label><input type="radio" name="q1" value="Cat">Cat</label></p>
>>     <p><label><input type="radio" name="q1" value="Dog">Dog</label></p>
>>     <p><label><input type="radio" name="q1" value="Ant">Ant</label></p>
>>   </fieldset>
>> </label>
> 
> Why is this preferable to the above?

This is not preferable, I just mentioned this as it is the other way 
<label> can be applied.

>>> I don't understand why the <fieldset> and <legend> can't be in the 
>>> template.
>> That is how I do it now. The downside of it is the fact that some 
>> themplate authors might forget it - a relevant number of web designers 
>> in fact don't even know about fieldsets, as forms usually "work" with or 
>> without them. Anyway it is not a big problem; it would just be a nice 
>> enhancement of consistency if the template engine were able to output 
>> *all* form structuring elements.
> 
> I don't understand the problem, but if it's not a big problem, then I 
> would suggest we punt on it until the next version.

I know the HTML5 spec is quite advanced already. Having <label> for 
<fieldset> (or <legend> outside it) would make things easier in some 
special cases, and maybe also promote the use of fieldsets. If this is a 
non-trivial change or even possibly introduces new problems, of course 
it might be better to schedule it for later versions.