I am a little unclear on what semantically connect a Label to a Field.
In this code…
<li>
<label for="name">Name:</label>
<input id="name" name="name" class="name" type="text" />
</li>
…does “ID” or “NAME” or “CLASS” make the connection?
Also, isn’t it redundant to have both an ID and CLASS using the same value?
TomTees
The way you have to think is like this … the names you assign to classes or ID do NOT matter. They are for YOUR (and possibly future coders) mental organization. IDs MUST be unique, class can, and should, repeat.
unless there will be other tags with class=“email” you could consolidate all your rules form that class into ID “email” and get rid of the class in the mark up… the question is… is the class email applied to anything else in your html?
it is possible as I was trying to say earlier that the ID email, if used to style that that, may have been there to add, or override, something in class “email” in which case thats a tidy way to do do it? see?
eh, no?
since they are read as completely different things, they are redundant (and a phantasmagoricy) only when used on the same element, since it will make the class attribute apply to a single element as well (having unique id/class pairs), which defeats the class attribute purpose?
you could however have #it for an element and .it for some other elements and it wouldn’t be redundant at all 
Stevie D,
Thanks for the clarifications!
And I agree with what you are saying about giving IDs and CLASSES different names to avoid confusion. My exact point!
TomTees
actually I thought … it was “for” links to “name” you can have an input without giving it an ID… but it NEEDS a name.
Generally if you have an ID it’s for CSS use. IDs and Classes are for styling purposes and have no semantic value, per se.
I dont know what you mean by “ID and CLASS using the same value?” so here is a shot gun answer:
the ID “it” and class “it” for example… are read as completely different things by the browser. They are declared separately as well as such:
#it{…css} /the ID/
.it{…css}/the Classs/
It is redundant if you have the same declaration for both… for example:
#it{color:red} /the ID/
.it{color:red}/the Classs/
it’s important , however to take note of specificity. ofr example… given ONLY the following rules:
#it{color:yellow} /the ID/
.it{color:red}/the Classs/
.other{color:green}
<p id=“it” class=“it”>hello world</p>
the text will appear in yellow. Yes , even tho the class declaration came after the ID in the css? why… because IDs have a higher specificity value than tags or classes.
if you had simply used <p class=“it green”>hello world</p> (no ID, but two classes} the last class in the order of the CSS would be the dominant one.
In essence, IF you created a class with general declarations and wanted to make some tweaks to a UNIQUE ELEMENT that was part of that class you can easily do so by using an ID is a good way to make tweaks. If you are putting exactly the same declarations in the ID as the class… you have to ask youself WHY?
Incidentally, this is all from the point of CSS. IDs also serve to identify a specific element for js using: “GetElementById”. So sometimes an ID is simply there not for styling, but to help js find the element.
hopes this clears up some things
I’ve checked and double-checked this one.
As I said before, you can have
<ul>
<li>Option 1 <input type="radio" name="option"></li>
<li>Option 2 <input type="radio" name="option"></li>
<li>Option 3 <input type="radio" name="option"></li>
</ul>
Now say you want to put <label> tags around the “Option #” text. What are you going to be in the “for” attribute for each one? It has to be unique, because it’s attaching a label to one specific form control.
No, an input doesn’t need an ID … but it doesn’t need a label either. If you want to give it a label, you have to either include the input within the <label> element, or give it an ID.
There may be times when you want to put an ID and a class on an element, serving different purposes. It may be that the obvious name to use for the ID is the same as the obvious name to use for the class. Technically, that isn’t a problem - as Dresden says, as far as your computer is concerned, #name is different from .name, and computers are good at details like that. Practically, however, it’s a really bad idea, because people are not good at details like that, and if you’re anything like a normal person, you will regularly stuff up your website by using the ID instead of the class, or putting styling in the wrong place, and generally mixing the two up. Give them different names and that’s less likely to happen.
That’s what I thought too. :-/
Generally if you have an ID it’s for CSS use. IDs and Classes are for styling purposes and have no semantic value, per se.
Agreed.
I dont know what you mean by “ID and CLASS using the same value?”
<input id="email" name="email" class="email" type="text" />
so here is a shot gun answer:
the ID “it” and class “it” for example… are read as completely different things by the browser. They are declared separately as well as such:
#it{…css} /the ID/
.it{…css}/the Classs/
It is redundant if you have the same declaration for both… for example:
#it{color:red} /the ID/
.it{color:red}/the Classs/
it’s important , however to take note of specificity. ofr example… given ONLY the following rules:
#it{color:yellow} /the ID/
.it{color:red}/the Classs/
.other{color:green}
<p id=“it” class=“it”>hello world</p>
the text will appear in yellow. Yes , even tho the class declaration came after the ID in the css? why… because IDs have a higher specificity value than tags or classes.
Okay.
That is interesting.
I guess I just meant, “Why have an ID and CLASS with the same name?”
Also, “Why have an ID and a CLASS with the same name when you aren’t using both?”
if you had simply used <p class=“it green”>hello world</p> (no ID, but two classes} the last class in the order of the CSS would be the dominant one.
In essence, IF you created a class with general declarations and wanted to make some tweaks to a UNIQUE ELEMENT that was part of that class you can easily do so by using an ID is a good way to make tweaks.
Okay.
Incidentally, this is all from the point of CSS. IDs also serve to identify a specific element for js using: “GetElementById”. So sometimes an ID is simply there not for styling, but to help js find the element.
Okay.
TomTees
So if you had no “ID” but you had a “Label” and, say, “Name” or “Class” with the same values, then what would that do to a Screen Reader?
Having identical ID and class names may not be redundant, assuming the class is used elsewhere (you may have more than one element that you want to apply a class to, and it may be that “name” is just as appropriate to that whole group as to the specific one here for the ID), but it is a really bad idea - it makes it very likely that you will make a mistake at some point when working on the styling and get your IDs and classes muddled up and use the wrong one.
I’m sorry, can you say that again, because you just wrote an entire paragraph that is one sentence?! 
TomTees
Right. But my point was - maybe not clear - is that it seems like people put ALL attributes in there (i.e. ID, CLASS, NAME, etc) whether they are needed or not and they give them all the same names?!
unless there will be other tags with class=“email” you could consolidate all your rules form that class into ID “email” and get rid of the class in the mark up… the question is… is the class email applied to anything else in your html?
Exactly.
it is possible as I was trying to say earlier that the ID email, if used to style that that, may have been there to add, or override, something in class “email” in which case thats a tidy way to do do it? see?
Yep.
Thanks,
TomTees
really it may not.
<ul>
<li>Option 1 <input type="radio" id="op1" class="op1" name="option"></li>
<li>Option 2 <input type="radio" id="op2" class="op2" name="option"></li>
<li>Option 3 <input type="radio" id="op3" class="op3" name="option"></li>
</ul>
having unique id/class pairs technically it’s a problem. having id attribute value equals class attribute values, repeatedly, as you can see above, defeats the whole class attribute purpose.
for a class to be effective, it should really be like this:
<ul>
<li>Option 1 <input type="radio" id="op1" class="op" name="option"></li>
<li>Option 2 <input type="radio" id="op2" class="op" name="option"></li>
<li>Option 3 <input type="radio" id="op3" class="op" name="option"></li>
</ul>
and that’s why
Practically, however, it’s a really bad idea
it nullifies the class purpose.
and it’s true: id is the key. the name attribute is used, for example, for linking:
[
Destination anchors in HTML documents may be specified either by the A element (naming it with the name attribute), or by any other element (naming with the id attribute).
](http://www.w3.org/TR/html401/struct/links.html)
like this:
[...]
<A href="#section1">Introduction</A>
[...]
<A name="section1">Introduction</A>
and xhtml brings something new: [URL=“http://www.w3.org/TR/xhtml1/#h-4.10”]
HTML 4 defined the name attribute for the elements a, applet, form, frame, iframe, img, and map. HTML 4 also introduced the id attribute. Both of these attributes are designed to be used as fragment identifiers.
[…]
Note that in XHTML 1.0, the name attribute of these elements is formally deprecated, and will be removed in a subsequent version of XHTML.
‘for’ links with ‘id’.
You can have multiple inputs with the same name (eg, a group of radio buttons) so it wouldn’t make sense to assign a label to a group of inputs, but IDs have to be unique so you can assign a label to them. Likewise, one class can apply to any number of elements including non-form elements, so you couldn’t possibly use it to link to a label.
Having identical ID and class names may not be redundant, assuming the class is used elsewhere (you may have more than one element that you want to apply a class to, and it may be that “name” is just as appropriate to that whole group as to the specific one here for the ID), but it is a really bad idea - it makes it very likely that you will make a mistake at some point when working on the styling and get your IDs and classes muddled up and use the wrong one.
no.
i really can’t think of situations where identical values for (multiple) id/class pairs on a page would be anything else but a mistake.
you are not developing for “now”. you are developing for “forever”. in the event a new element requiring to " add, or override, something in the class “email” " emerges, which is quite possible it will (99.99%) this whole theory loses any ground it may have regarding any mental organization.
what i see in this is a logical trap, that goes against the whole id and class theory.