I copied this from a response of mine. I think it deserves it's own post. Here's a little experiment you can to do to understand why using IDs is a problem in jQuery Mobile.
I haven't put this in a jsFiddle, etc, because I want to keep it as dead-simple as possible. I want people to create a file locally and experiment with their browser console. (Or, if you prefer, add console.log statements.)
<html lang="en" >
<meta charset="utf-8" />
<div class="first" id="a">This is the first div</div>
<div class="second" id="a">This is the second div</div>
How many items do you see in the result list? Did you expect to see two? Do you see two? What item(s) do you see?
Hint: you will see ONE. Which one you see is browser-dependent. In fact, with some browsers, you might not even see any, because this is a invalid condition. What should the browser do with an invalid condition?
EVERYBODY READING THIS FORUM SHOULD TRY THIS EXPERIMENT.
Then, forgot about using IDs. Or, at least, duplicating them. Keep in mind that JQM always loads at least two pages in the DOM at once, at least if you ever change pages. The old page and the new page. Also, the first page visited always stays in the document. If you are making a website, the user might enter the site from any page, so you really need to make sure you never duplicate an ID on *any* page.
If you want to use IDs in your project, have fun making sure you never duplicate one in any pair of pages that might be loaded together. (This might include the *same* page if you ever do a same-page transition...) It's a lot easier not to ever use IDs.
For extra credit, try this in the console:
This time, you will get a list of two elements.
So, should you still use IDs, and use this construct instead of $("#a")?
Well, you can do that if you are simply stubborn. It is one of the slowest queries - much slower than a class query. You lose any benefit from using IDs.
credit: extend the experiment. Load jQuery Mobile as well, and
experiment with IDs duplicated on two or more pages. What happens now?
By definition, IDs should be unique in a doc or a jQM application. Therefore, it does not make sense to have two elements with same ID. Sorry Watusiware, with all due respect, this is not a very good example.
This was taken from a response to a problem that was posted here.
The original poster duplicated an ID within the same page, and insisted that the ID selector would select both elements. That is incorrect.
I wanted to show the most simple example that shows what happens when you duplicate an ID and use an ID (#) selector.
You are right, it does not matter if the IDs are on the same page or not - so long as they are in the document.
But, if you don't believe that duplicating an ID within the *same* page is a problem, you will never be convinced that it will be a problem across pages. And, so, I wanted to demonstrate the most fundamental issue about IDs and jQuery Mobile. You first have to understand the special nature of IDs - that they must be unique within the document. This illustrates that.
Anyone who is skeptical that this will not fail in the same way across multiple pages (that is, multiple pages that are loaded in the document) can extend the experiment.
Note that limiting scope to a particular page by using .find() does not mitigate the problem. The browser only keeps-track of *one* of the duplicated IDs. A .find() will start with the one element with a given ID that the browser knows about, and then, if it is not within the scope of the first selector you will get zero elements.
where the class a has been used on more than one page, and both pages are loaded in the DOM.
Even though there might be an element with ID a in both first-page and second-page, only one of these will return a result. The other will return a list of zero elements:
Which one returns one element, and which one returns zero elements, is dependent on which browser you use.
Again, you can extend the experiment yourself to prove this. I would prefer that developers experiment and understand.
For some reason, it is particularly difficult to convince developers of this. I suppose it is because we simply aren't used to the concept of a document containing many pages, and the implications of that.
I think the only way to convince them is to get them to do experiments themselves. Still, I expect many will simply ignore this post and continue to create maintainence nightmares with IDs in jQuery Mobile projects.
I totally understand your frustration. I deal with some of that daily!
The moment a developer begins to duplicate IDs in a doc or across pages of a jQM app, the IDs lose their meaning. And I agree with you 100% that such should rather be advised to use classes if they can't make the extra effort to understand fully how IDs work and how they should be used.
The exchange is an excellent example of superb teaching through the Internet. Thank you both Godsbest and watusiware (what does that handle stand for ?) for all your contributions. Your efforts on this forum teach me something on most days of the week. For free! Thanks.
I'm convinced that my use of IDs is potentially hazardous... though I namespace them with the page name for each page to avoid collisions between pages (and wonder why the framework doesn't just do that...). I'm careful not to duplicate them on the same page, of course. Still, I'd prefer your suggested avoidance of ids altogether, if I could figure out a good way to, for example, target a popup from a button created from an anchor. The examples given in the JQM docs explicitly say to use the id of the div designated with the data-role of "popup" as the way to make a button open a popup. How can that behavior be replicated without an id?
Also, I use an id on tables so that I can append a new row to them. I tried to replace the id with a class, but the append no longer works... any suggestion about how to avoid ids in that situation?
I enjoy your many thoughtful posts, and learn a lot from them, so please consider this a request for help, not a criticism, but I can't see how it's possible to eliminate id's altogether. I would if I could...
Here's a link to an example (on a different topic) where ids are used for both the situations described above: on js Bin. Show me how to work around that, and this will become even more definitive...