I've been doing quite a bit of work recently with form elements, in particular trying to best apply more semantic markup to my form layout, so that I can provide easily styleable forms with little or no extraneous markup such as divs, spans etc which offer little extra meaning to the form, in a semantic sense.
After using the label as a housing element for both input and title of element, I've noticed that there seems to be some ambiguity (in my own mind at least - please feel absolutely free to clarify the point if possible) regarding its use in terms of normal inputs and radio/check arrays.
If I can explain with a brief example...
<label>Amount<input type='text' name='amount' value='1' /></label>
The above code is fair enough. The label tag encapsulates both the form element and label text 'Amount' giving meaning to the title in the context of it being the label for the input. That seems fine... yeah?
but consider the following radio sets...
SET A:
<label>Colour
<span><input type='radio' name='colour' value='red' />Red</span>
<span><input type='radio' name='colour' value='white' />Blue</span>
<span><input type='radio' name='colour' value='blue' />White</span>
</label>
SET B:
<span>Colour
<label><input type='radio' name='colour' value='red' />Red</label>
<label><input type='r开发者_C百科adio' name='colour' value='white' />Blue</label>
<label><input type='radio' name='colour' value='blue' />White</label>
</span>
Please note the use of <span>
as an encapsulation element in both cases is purely incidental, and could be any element realistically.
I'm tending to err on the side of SET A myself, as I would sort of think the entire radio/check box array/set as a whole would the part of the markup that would require the label tag in a contextual sense, but does anyone have any thoughts they can throw into the mix with this one?
After looking at the microformat spec (unfinished as with the rest of the web) I'm looking at using p-v pairing for provision of colour (or any other set/array) info. To this end my original SET A outline should suffice in providing both the rendered and spidered views of the page with all the necessary hierarchical info I'd be wanting to properly categorise these snippets of info I think.
I'm perhaps looking at going down this road at the moment. (Please point out any glaring stupidity please)
SET A [revised]:
<somecontainerparentelement class="hproduct">
<label "p-v"><em class="property">Colour</em>
<span><input type='radio' name='colour' value='red' /><em class="value">Red</em></span>
<span><input type='radio' name='colour' value='white' /><em class="value">Blue</em></span>
<span><input type='radio' name='colour' value='blue' /><em class="value">White</em></span>
</label>
</somecontainerparentelement>
Sort of issue with this method is that I'm unsure whether the p-v will allow the existance of a single Parameter (ie the <em>Colour</em>
) with multiple Values (ie the class='value'
elements within <labels>
).
Although the non issue with it would be that I don't have to lose any sleep, hair or teeth trying to style a legend in IE (I assume the loss of teeth from banging my face against my desk and keyboard)...
What I would do there is this...
<fieldset>
<legend>Colour</legend>
<label><input type="radio" name="colour" value="red" />Red</label>
<label><input type="radio" name="colour" value="white" />Blue</label>
<label><input type="radio" name="colour" value="blue" />White</label>
</fieldset>
Also, you can have your label
element separate and link its for
attribute to the id
attribute of the element. It generally makes styling them easier IMO.
<fieldset>
<legend>Colour</legend>
<input type="radio" name="colour" value="red" id="colour-red" />
<label for="colour-red">Red</label>
<input type="radio" name="colour" value="white" id="colour-white" />
<label for="colour-white">White</label>
<input type="radio" name="colour" value="blue" id="colour-blue" />
<label for="colour-blue">Blue</label>
</fieldset>
Note that the legend
element is notoriously difficult to style cross browser.
The HTML5 draft spec specifically covers the SET A situation. It says:
If the for attribute is not specified, but the label element has a labelable form-associated element descendant, then the first such descendant in tree order is the label element's labeled control.
Which means that
<label>Colour
<span><input type='radio' name='colour' value='red' />Red</span>
<span><input type='radio' name='colour' value='white' />White</span>
<span><input type='radio' name='colour' value='blue' />Blue</span>
</label>
is semantically equivalent to
<label>Colour
<span><input id="control1" type='radio' name='colour' value='red' />Red</span>
</label>
<span>
<input id="control2" type='radio' name='colour' value='white' />
<label for="control1">White</label>
</span>
<span>
<input id="control3" type='radio' name='colour' value='blue' />
<label for="control1">Blue</label>
</span>
which isn't what I think you intend.
This also has practical consequences. If you put that markup on a web page, and then click the words "White" or "Blue", in some browsers it will result in the 'Red' radio button being selected.
Ideally, Alex's solution would be used, but as you've found, styling legend
is a PITA. There are some workarounds but nothing wholly satisfactory IMO.
The best solution is usually to connect the elements using the id:
<input id="test1" type="text"/><label for="test1">Test 1</label>
<input id="test2" type="text"/><label for="test2">Test 2</label>
精彩评论