I am using jQuery and I am just wondering, does ID have to be always unique in the whole page? Class, I know, can be repeated as many times as you like, what about ID?
Yes, it must be unique.
HTML4:
https://www.w3.org/TR/html4/struct/global.html#h-7.5.2
Section 7.5.2:
id = name [CS]
This attribute assigns a name to an element. This name must be unique in a document.
HTML5:
https://www.w3.org/TR/html5/dom.html#element-attrdef-global-id
The id attribute specifies its element's unique identifier (ID). The
value must be unique amongst all the IDs in the element's home subtree
and must contain at least one character. The value must not contain
any space characters.
Does an ID have to be unique in the whole page?
No.
Because the HTML Living Standard of March 15, 2022, clearly states:
The class, id, and slot attributes may be specified on all HTML elements. …….
When specified on HTML elements, the id attribute value must be unique amongst all the IDs in the element’s tree and must contain at least one character. The value must not contain any ASCII whitespace.
and a page may have several DOM trees. It does, for example, when you’ve attached (Element.attachShadow()) a shadow DOM tree to an element.
TL; DR
Does an ID have to be unique in the whole page?
No.
Does an ID have to be unique in a DOM tree?
Yes.
from mdn
https://developer.mozilla.org/en/DOM/element.id
so i guess it better be...
Technically, by HTML5 standards ID must be unique on the page - https://developer.mozilla.org/en/DOM/element.id
But I've worked on extremely modular websites, where this is completely ignored and it works. And it makes sense - the most surprising part.
We call it "componentization"
For example, you might have a component on your page, which is some kind of widget. It has stuff inside with their own unique IDs eg "ok-button"
Once there are many of these widgets on the page, you technically have invalid HTML. But it makes perfect sense to componentize your widgets so that they each, internally, reference their own ok button eg if using jquery to search from it's own root it might be: $widgetRoot.find("#ok-button")
This works for us, though technically IDs shouldn't be used at all, once they're not unique.
As cited above, even YouTube does it, so it's not so renegade.
Jan 2018, here is Youtube HTML , you can see id="button" id="info" are duplicated.
That's basically the whole point of an ID. :) IDs are specific, can only be used once per page. Classes can be used as pleased.
Browsers used to be lenient on this (many years ago when css was young) and allow the ID to be used more than once. They have become more strict.
However, yes ID's are to be unique and only used once.
If you need to use css formatting more than once use CLASS.
With Javascript, you can only reference to one element using ID. document.getElementById and jQuery's $ selector will return only the first element matching. So it doesn't make sense using the same ID on multiple elements.
There are great answers for the same question at https://softwareengineering.stackexchange.com/questions/127178/two-html-elements-with-same-id-attribute-how-bad-is-it-really.
One tidbit not mentioned above is that if there are several identical ids one the same page (which happens, even though it violates the standard):
If you have to work around this (that's sad), you can use $("*#foo") which will convince jQuery to use getElementsByTagName and return a list of all matched elements.
Yes, IDs are unique. Class are not.
IDs always have to be unique.
Everybody has a unique identification number (ex. Social Security number), and there are lots of people in a social class
I'm adding to this question, because I feel it has not been answered adequately in any of the above,
As a point reference: I've implemented non-unique id's, and all works just fine (across all browsers). Importantly, when coding, I've not run into any css logic errors, which is where the rubber hits the road (IMO) on this question. Have also not run into any conflicts in js (as one can glean out id's in context with classes)
So, why do id's have to be unique? Obvious answer (as stated and re-stated above) is 'cause the 'standards' say so. The missing part for me is why?
i.e. what actually goes awry (or could theoretically go awry) if (heaven forbid) someone inadvertently used the same id twice?
The reference with all browsers these days?
Makes div possible in such terms of being used multiple times.
There is no rule that it must be unique. When all browsers understand:
<script>div#some {font-size: 20px}</script>
<div id="some"><p>understand</p></div>
<div id="some"><h1>me too</h1></div>
When you add new style CSS codes you have the possibility to use the addition of styles. Since that even is not supposed to be unique it describes the opposite use, so make more styles but do not make more objects? And as you can; assign several div objects, so why didn't they tell you that class must be unique? That's because the class does not need unique value. And that makes the ID in legal terms obsolete if not being unique.
<script>.some {font-size: 25px}</script>
<div class="some"><p>enter</p></div>
<div class="some"><h1>enter</p></div>
"When there is no rule when a rule is said. Then the rule is not fulfilled. It's not inherent to exist. By only in the illusion of all rules that it should have existed only to make life much harder."
Just because some people say div must be unique, this might be right, but at least through their professional perspective to say it, they have to say it. Unless they didn't check the modern browsers, which from nearly the beginning were able to understand the code of several different div objects with the same style.
ID must be unique - One reason for that is, that in the Browser-JavaScript-Context exists a methode: Document.getElementById()
This method can only return one element.
If a Document has not unique IDs, this function behaves in an undocumented and unforeseeable way.
I think, this is reason enough to only use one ID per Document.
Reference:
https://developer.mozilla.org/en-US/docs/Web/API/Document/getElementById
Related
I am using jQuery and I am just wondering, does ID have to be always unique in the whole page? Class, I know, can be repeated as many times as you like, what about ID?
Yes, it must be unique.
HTML4:
https://www.w3.org/TR/html4/struct/global.html#h-7.5.2
Section 7.5.2:
id = name [CS]
This attribute assigns a name to an element. This name must be unique in a document.
HTML5:
https://www.w3.org/TR/html5/dom.html#element-attrdef-global-id
The id attribute specifies its element's unique identifier (ID). The
value must be unique amongst all the IDs in the element's home subtree
and must contain at least one character. The value must not contain
any space characters.
Does an ID have to be unique in the whole page?
No.
Because the HTML Living Standard of March 15, 2022, clearly states:
The class, id, and slot attributes may be specified on all HTML elements. …….
When specified on HTML elements, the id attribute value must be unique amongst all the IDs in the element’s tree and must contain at least one character. The value must not contain any ASCII whitespace.
and a page may have several DOM trees. It does, for example, when you’ve attached (Element.attachShadow()) a shadow DOM tree to an element.
TL; DR
Does an ID have to be unique in the whole page?
No.
Does an ID have to be unique in a DOM tree?
Yes.
from mdn
https://developer.mozilla.org/en/DOM/element.id
so i guess it better be...
Technically, by HTML5 standards ID must be unique on the page - https://developer.mozilla.org/en/DOM/element.id
But I've worked on extremely modular websites, where this is completely ignored and it works. And it makes sense - the most surprising part.
We call it "componentization"
For example, you might have a component on your page, which is some kind of widget. It has stuff inside with their own unique IDs eg "ok-button"
Once there are many of these widgets on the page, you technically have invalid HTML. But it makes perfect sense to componentize your widgets so that they each, internally, reference their own ok button eg if using jquery to search from it's own root it might be: $widgetRoot.find("#ok-button")
This works for us, though technically IDs shouldn't be used at all, once they're not unique.
As cited above, even YouTube does it, so it's not so renegade.
Jan 2018, here is Youtube HTML , you can see id="button" id="info" are duplicated.
That's basically the whole point of an ID. :) IDs are specific, can only be used once per page. Classes can be used as pleased.
Browsers used to be lenient on this (many years ago when css was young) and allow the ID to be used more than once. They have become more strict.
However, yes ID's are to be unique and only used once.
If you need to use css formatting more than once use CLASS.
With Javascript, you can only reference to one element using ID. document.getElementById and jQuery's $ selector will return only the first element matching. So it doesn't make sense using the same ID on multiple elements.
There are great answers for the same question at https://softwareengineering.stackexchange.com/questions/127178/two-html-elements-with-same-id-attribute-how-bad-is-it-really.
One tidbit not mentioned above is that if there are several identical ids one the same page (which happens, even though it violates the standard):
If you have to work around this (that's sad), you can use $("*#foo") which will convince jQuery to use getElementsByTagName and return a list of all matched elements.
Yes, IDs are unique. Class are not.
IDs always have to be unique.
Everybody has a unique identification number (ex. Social Security number), and there are lots of people in a social class
I'm adding to this question, because I feel it has not been answered adequately in any of the above,
As a point reference: I've implemented non-unique id's, and all works just fine (across all browsers). Importantly, when coding, I've not run into any css logic errors, which is where the rubber hits the road (IMO) on this question. Have also not run into any conflicts in js (as one can glean out id's in context with classes)
So, why do id's have to be unique? Obvious answer (as stated and re-stated above) is 'cause the 'standards' say so. The missing part for me is why?
i.e. what actually goes awry (or could theoretically go awry) if (heaven forbid) someone inadvertently used the same id twice?
The reference with all browsers these days?
Makes div possible in such terms of being used multiple times.
There is no rule that it must be unique. When all browsers understand:
<script>div#some {font-size: 20px}</script>
<div id="some"><p>understand</p></div>
<div id="some"><h1>me too</h1></div>
When you add new style CSS codes you have the possibility to use the addition of styles. Since that even is not supposed to be unique it describes the opposite use, so make more styles but do not make more objects? And as you can; assign several div objects, so why didn't they tell you that class must be unique? That's because the class does not need unique value. And that makes the ID in legal terms obsolete if not being unique.
<script>.some {font-size: 25px}</script>
<div class="some"><p>enter</p></div>
<div class="some"><h1>enter</p></div>
"When there is no rule when a rule is said. Then the rule is not fulfilled. It's not inherent to exist. By only in the illusion of all rules that it should have existed only to make life much harder."
Just because some people say div must be unique, this might be right, but at least through their professional perspective to say it, they have to say it. Unless they didn't check the modern browsers, which from nearly the beginning were able to understand the code of several different div objects with the same style.
ID must be unique - One reason for that is, that in the Browser-JavaScript-Context exists a methode: Document.getElementById()
This method can only return one element.
If a Document has not unique IDs, this function behaves in an undocumented and unforeseeable way.
I think, this is reason enough to only use one ID per Document.
Reference:
https://developer.mozilla.org/en-US/docs/Web/API/Document/getElementById
This question already has answers here:
What is the difference between id and class in CSS, and when should I use them? [duplicate]
(15 answers)
Closed 8 years ago.
It looks like ids and classes are the exact same thing and have the same functionality, however ids are used just to show the coder/designer that they are only changing one item in those other similar items... Is that true?
I watched this helpful video http://www.youtube.com/watch?v=UZ4s1AvIDPM and that's the only difference I could tell.
It looks like ids and classes are the exact same thing and have the same functionality
Look again.
id specifically identifies an element. Each element can have no more than one id and each id must be unique throughout the DOM.
class describes an element in a more generic way, associating it logically with other elements of the same class. An element can have many classes, and the same class can be used many times throughout the DOM.
ids are used just to show the coder/designer that they are only changing one item in those other similar items... Is that true?
No, that's not true at all. ids uniquely identify (hence "id") elements. They can be used by a developer or a designer to target a specific element for some purpose (altering it, styling it, observing it, and so on).
The fact that the person is selecting an id does guarantee that they are targeting only one element (assuming that element exists, otherwise zero elements) as long as the document is well-formed (doesn't break the rule of not re-using id values, in which case the code is incorrect and behavior is undefined).
Conversely, when selecting based on a class value, any number of elements may be selected. So any developer and/or designer (or any other role) would bear that in mind and not assume that there's only one element.
I'm doing a code academy course and they ask me to use left and right column classes as opposed to id's. I'm not sure why...
It seems to me that I'm only going to have one Div that is left column, and one Div that is right column... so why would I use a class instead of an ID for this?
They probably want you to refer to the element in order to move it somehow to left. It is better to use a class because it is possible that at some point you'll want to move another element to left. If you use id instead of class there may be need to repeat the same CSS rule for two different elements (different IDs). Code repetition is considered a bad practice and should be avoided, if possible at design level (no need to rewrite anything later), hence the suggestion to use class instead of id.
IDs always perform well because they are unique per page, but somehow Code Academy could have the same ID. They might also want to avoid using IDs because of the dynamic application and structure, so we cannot predict how their skeleton is. I think it is as per their application logic.
I need to find a way to implement the concept of "scoped IDs" in HTML/XML.
I know that the id attribute of an element must hold a unique value for the entire document, but I'm wondering if there's a workaround ('hack', 'cheat', whatever) that I can do to create scoped IDs. That is, for any particular sectioning/containing element, IDs would be unique, but outside of the container, those IDs would be hidden and couldn't be referenced. With nested sections, inner sections will still be able to access their parent section's element's IDs but not the other way around.
I thought about using <iframe>s, but those are just icky.
Maybe there's a solution using JavaScript/jQuery?
Not possible.
This is exactly what classes are for though. Give unique IDs to each "section" or container element and then use classes for the common descendant elements you wanted to use recurring IDs for, then target them with #unique-container .common-element selectors.
I find it hard to imagine a situation in which you would want to do what you described anyway. You are basically just asking if you can use IDs as classes, but that's why classes exist in the first place.
I suppose you could make some kind of psuedo-scoped-ID by adding custom HTML5 attributes to the elements and processing them / doing whatever you want to do with them in Javascript but again without any context as to why you want to do this it's hard to really recommend anything here.
How should my class names be?
For example, a CSS class for a vote count, how should I name it?
.vote-count-post (1) // SO uses this
.VoteCountPost (2)
.voteCountPost (3)
.vote.count-post (4)
.vote .count-post (5)
.vote .count.post (6)
What are the advantages and disadvantages of each?
Which is most used and why?
Are there any implications in any of these?
May I have any uppercase in my CSS?
4, 5 and 6 are special
.vote.count-post matches elements with class="vote count-post", or class="count-post vote" or even class="vote something-else count-post".
.vote .count-post matches elements with class="count-post" that are subelements of an element with class="vote"
and .vote .count.post is a mix of those both
Between 1, 2 and 3, all that matters is preference of style. Some people prefer one over another just as they do in programming languages. So just choose whatever you personally prefer, or what is more appropriate for you.
I vote for (1) to always use lower case for your CSS. That way you don't have to remember where you capitalize stuff. So that eliminates (2) and (3).
(5) is really two different elements so can't apply to a single element.
(4) and (6) are invalid for a single element. (4) assumes you are applying two classes to the same element such as class='vote count-post'. (6) is a combination of (4) and (5).
It's just naming, so it's up to you what you like. Either of your examples would work fine. Just pick one and stick to it.
The three first selectors addresses single elements, the fourth addresses a single element with two classes, the fifth addresses an element inside another, and the sixth does the same but with the inner ellement having two classes.
I would probably put class="Vote" on the surronding element, and out class="count" on the count element inside it to address it. I use pascal case for surrounding elements and lowercase for child elements inside them, so I would use:
.Vote .count
I see the first approach a lot (the jQuery UI CSS framework uses it and I find it a very good example for good CSS).
I personally don't like camelcasing in class names from (2) and (3) because it is really easy to get it wrong (just write VotecountPost and it won't work).
(4), (5), (6) are not really a convention thing but rather different selectors as others pointed out already.
I agree with Keltex above that always using lower case is easier and more maintainable ... especially for others who might need to troubleshoot or modify your work.
Yet, I'd also suggest adding a prefix your css class names. In large projects this helps to quickly identify their source and what they apply to. It also helps prevent name collisions (and unpredictable behavior) in a heterogeneous environment.
There's no "right" answer in my opinion. I tend to do what's more readable so I choose (3). In my opinion there's enough word-word-word style text in html/css already. And when styling up e.g. Wordpress I think it's like a mixer full of dashes, hard to navigate.
But it's my opinion, I think you should just get a feel for what you prefer. What you find easy to read, when you look 8 hours per day on these you should choose something you're comfortable with.
i suggest use this .VoteCountPost less space and readable..
In my projects that use jQuery I have determined that I use class names in two distinct ways. The first is for styling where definitions are almost exclusively in a .css file. The second is for jQuery selectors which tend to be isolated to a single function and are more related to the scripting. Because of this split I choose to follow #1 for styling and #2 for jQuery element selectors. If someone chooses to View Source they can now determine the functions of each type of class.