Why is it a bad thing to have multiple HTML elements with the same id attribute?

Why is it bad practice to have more than one HTML element with the same id attribute on the same page? I am looking for a way to explain this to someone who is not very familiar with HTML.

I know that the HTML spec requires ids to be unique but that doesn't sound like a convincing reason. Why should I care what someone wrote in some document?

The main reason I can think of is that multiple element开发者_StackOverflow中文版s with the same id can cause strange and undefined behavior with Javascript functions such as document.getElementById. I also know that it can cause unexpected behavior with fragment identifiers in URLs. Can anyone think of any other reasons that would make sense to HTML newbies?

---

Based on your question you already know what w3c has to say about this:

The id attribute specifies a unique id for an HTML element (the id attribute value must be unique within the HTML document).

The id attribute can be used to point to a style in a style sheet.

The id attribute can also be used by a JavaScript (via the HTML DOM) to make changes to the HTML element with the specific id.

The point with an id is that it must be unique. It is used to identify an element (or an anything: if two students had the same student id schools would come apart at the seems). It's not like a human name, which needn't be unique. If two elements in an array had the same index, or if two different real numbers were equal... the universe would just fall apart. It's part of the definition of identity.

You should probably use class for what you are trying to do, I think (ps: what are you trying to do?).

Hope this helps!

---

Why should I care what someone wrote in some document?

You should care because if you are writing HTML, it will be rendered in a browser which was written by someone who did care. W3C created the spec and Google, Mozilla, Microsoft etc... are following it so it is in your interest to follow it as well.

---

Besides the obvious reason (they are supposed to be unique), you should care because having multiple elements with the same id can break your application.

Let's say you have this markup:

<p id="my_id">One</p>
<p id="my_id">Two</p>

CSS is forgiving, this will color both elements red:

#my_id { color:red; }

..but with JavaScript, this will only style the first one:

document.getElementById('my_id').style.color = 'red';

This is just a simple example. When you're doing anything with JavaScript that relies on ids being unique, your whole application can fall apart. There are questions posted here every day where this is actually happening - something crucial is broken because the developer used duplicate id attributes.

---

Because if you have multiple HTML elements with the same ID, it is no longer an IDentifier, is it?

Why can't two people have the same social security number?

---

You basicaly responded to the question. I think that as long as an elemenet can no longer be uniquely identified by the id, than any function that resides on this functionality will break. You can still choose to search elements in an xpath style using the id like you would use a class, but it's cumbersome, error prone and will give you headaches later.

---

The main reason I can think of is that multiple elements with the same id can cause strange and undefined behavior with Javascript functions such as document.getElementById.

... and XPath expressions, crawlers, scrapers, etc. that rely on ids, but yes, that's exactly it. If they're not convinced, then too bad for them; it will bite them in the end, whether they know it or not (when their website gets visited poorly).

---

Why should a social security number be unique, or a license plate number? For the same reason any other identifier should be unique. So that it identifies exactly one thing, and you can find that one thing if you have the id.

---

The main reason I can think of is that multiple elements with the same id can cause strange and undefined behavior with Javascript functions such as document.getElementById.

This is exactly the problem. "Undefined behavior" means that one user's browser will behave one way (perhaps get only the first element), another will behave another way (perhaps get only the last element), and another will behave yet another way (perhaps get an array of all elements). The whole idea of programming is to give the computer (that is, the user's browser) exact instructions concerning what you want it to do. When you use ambiguous instructions like non-unique ID attributes, then you get unpredictable results, which is not what a programmer wants.

Why should I care what someone wrote in some document?

W3C specs are not merely "some document"; they are the rules that, if you follow in your coding, you can reasonably expect any browser to obey. Of course, W3C standards are rarely followed exactly by all browsers, but they are the best set of commonly accepted ground rules that exist.

---

The short answer is that in HTML/JavaScript DOM API you have the getElementById function which returns one element, not a collection. So if you have more than one element with the same id, it would not know which one to pick.

But the question isn't that dumb actually, because there are reasons to want one id that might refer to more than one element in the HTML. For example, a user might make a selection of text and wants to annotate it. You want to show this with a

<span class="Annotation" id="A01">Bla bla bla</span>

If the user selected text that spans multiple paragraphs, then the needs to be broken up into fragments, but all fragments of that selection should be addressable by the same "id".

Note that in the past you could put

<a name="..."/> 

elements in your HTML and you could find them with getElementsByName. So this is similar. But unfortunately the HTML specifications have started to deprecate this, which is a bad idea because it leaves an important use case without a simple solution.

Of course with XPath you can do anything use any attribute or even text node as an id. Apparently the XPointer spec allows you to make reference to elements by any XPath expression and use that in URL fragment references as in

http://my.host.com/document.html#xpointer(id('A01')) 

or its short version

http://my.host.com/document.html#A01

or, other equivalent XPath expressions:

http://my.host.com/document.html#xpointer(/*/descendant-or-self::*[@id = 'A01'])

and so, one could refer to name attributes

http://my.host.com/document.html#xpointer(/*/descendant-or-self::*[@name = 'A01'])

or whatever you name your attributes

http://my.host.com/document.html#xpointer(/*/descendant-or-self::*[@annotation-id = 'A01'])

Hope this helps.