Checkbox labels.

[jlizarraga]

Hi all,

Is this bad because the name and id are different?

<input type="checkbox" name="someGroup" id="check1" value="Option 1" /> 
<label for="check1">Option 1</label>

<input type="checkbox" name="someGroup" id="check2" value="Option 2" /> 
<label for="check2">Option 2</label>

Thanks!

[jscheuer1]

No. But having them all the same name might not be too good. It all depends upon what happens when the form is submitted or these elements are acted upon via javascript - that is if any of that's even going to happen, and whether or not what you want to have happen happens or not in the browsers that you are targeting.

But no. There is no reason why the name and the id of elements that can have both need to be the same. Often it is done that way so as to support legacy browsers. In a case like that though, there is usually another way to deal with older browsers if one wants to, and simply having the name and id the same - in and of itself - is no guarantee of backward compatibility.

[Twey]

No? Of course it isn't. Names and IDs can't always be the same, or checkbox groups would be impossible.

I do prefer to nest my labels, though, for clarity, and to avoid having to give all the elements IDs:

<label>
  <input type="checkbox" name="someGroup" value="Option 1">
  Option 1
</label>
<label>
  <input type="checkbox" name="someGroup" value="Option 2">
  Option 2
</label>

Also, beware that pseudo-XHTML /> ending. It probably doesn't mean what you think it does.

[jscheuer1]

I find that for backward compatibility labels should be both nested and use the for attribute.

[jlizarraga]

Sweet, thanks guys.

For the XHTML thing, is that not how you close an input tag in XHTML? I am aware of the differences between the two, and the whole XHTML as HTML/tag soup thing. Is that what you were referring to?

[jscheuer1]

Twey can be more eloquent about this, usually. But the bottom line is - unless you are serving your page as application/xml, there is no reason to use XHTML or an XHTML DOCTYPE. If you do serve as application/xml, then IE will not even display the page, offering instead a save/open with program dialogue. If you're not having that problem, it means that your page is being parsed as HTML - leaving the browser to error correct all of those /> things, which are invalid in HTML.

So, in most cases - use and validate to HTML 4.01 Strict. Or, if you are not up to that - HTML 4.01 Transitional.

[Twey]

The type is application/xhtml+xml for XHTML specifically, although a proper XHTML parser should, I think, be able to understand it from the DTD if served as application/xml.

It is indeed one way to close a content-less element in XHTML (note that in XML <input /> is exactly the same as <input></input>, so you could also say that) but as John says, if you can view the page in IE then you're not actually using XHTML, and shouldn't be using this XHTML-specific syntax (which conflicts with an SGML feature called NET, or Null End-Tags: interpreted according to the SGML standard, using XHTML-style syntax on an HTML page should litter the page with > symbols; probably there would be a lot less confusion if more browsers implemented this).

If you're not up to Strict then you need to learn, because the Web left you behind many years ago. Contrary to what seems to be popular belief, Strict is actually a lot simpler to deal with than Transitional: as the Python folks would say, 'there's only one way to do it'. Transitional includes a lot of deprecated alternatives, and requires considerable expertise in the technologies to choose the correct course of action, since using a deprecated element is poor practice and may have adverse effects on your page; in Strict, all the deprecated elements and nesting practices have been removed, so the validator can easily inform you if you use one.