While this is a 3-year-old post, this particular issue remains unchanged
- it is probably the #1 issue that new JQM developers run into trouble
with.
The above ^ solution is only a partial one, I am afraid, and will
fail in some edge cases. The script name or page name does not
necessarily make the ID unique.
Consider a page with a list of song titles, and you can navigate
from the song titles to details about the song. You might have a popup
used for some reason on the index page, and also one on the detail page.
If you use an ID of, say, popupIndex on the list
page and popupDetail on the
detail page, it works so long as your navigation is vertical. It
fails, though, if navigation is lateral. That is, navigate from from
song detail page directly to the next song detail page.
You often may not discover this immediately. Perhaps you only
have vertical navigation to start, but later somebody decides
they'd also like lateral navigation. Now, suddenly, what was
working no longer works.
The solution is that when you absolutely HAVE to use an ID (I
avoid them if at all possible!) they need to be truly unique -
across all pages and across an entire user session.
For that, I use a simple sequential ID generator in server code,
Static Site Generator code, or client MVC code. e.g. id1, id2, id3, etc.
I use this only where HTML or the client-side framework actually
requires an ID, such as when tying a label to an input where you
cannot wrap the input with the label, or tying a navigation element to
popup content.
Assuming you use some sort of templates, call the unique ID
generator and store an ID in a variable in your template. Then, use
that variable in the two places needed.
A simple example, in ERB. unique_id is a little
function that I wrote in Ruby that returns id1 the first time it is
called, id2, the
second time, etc. The progression is carried across pages and
documents by the server MVC framework. (The sequential number is held
in a class variable in a Ruby module.)
-
<%
-
username_id =
unique_id
-
password_id =
unique_id
-
%>
-
-
<label
id='<%= username_id' %>>User
Name</label>
-
<span
class='contrived'>This span is just here to contrive
a reason for not wrapping the input with
the label</span>
-
<input
id='<%= username_id %>'
name='username'>
-
-
<label
id='<%= password_id
%>'>Password</label>
-
<span
class='contrived'>Another contrived
example</span>
-
<input
id='<%= password_id %>' name='password''>
As you can see, it is a contrived example. Absent the span, you
could just wrap the input with the label, and dispense with the ID
completely. But many CSS and JS/CSS platforms - for example, jQuery
Mobile and Bootstrap - have widgets that aren't friendly toward
wrapping inputs with labels. And, so, this is how I deal with
necessary IDs.
I NEVER use an ID in a CSS or jQuery selector, though! That is
why my IDs never have semantic meaning. These IDs are there for the
browser only, and have no meaning to humans. I give them abstract
names that hopefully clearly indicate that.
I never give an ID to a page! They get classes. (Often more than one.)
There is almost always a better way than using IDs when you need
a selector, typically using CSS classes (perhaps in combination with
tags) and localized search.
IMO, IDs have been mis-used by too many web developers for way
too many years. CSS classes were introduced in 1995 (along with
CSS! IDs predate CSS...). They are more appropriate than IDs for
MOST of the places I see IDs used in HTML. Some habits die hard.
It's ironic that this is probably done just as much by
developers who were only toddlers ( or weren't even born yet) in
1995, and have just adopted the bad habits of those that went before them.
Most uses of IDs just need to die, along with abominations like
<font>,
<center>,
and inline styles! They were mistakes made by the early designers of
HTML who just didn't know yet what a bad idea they were.