jQuery Forum

Yes, it is a bad practice. Just think that you may want to manipulate your elements after one page is being loaded. How do you point to the right element?

Antonio Alonso
R & D Software Engineer
Embarcadero Technologies

Easily, if your body on each page has a unique ID, you could use a descendant selector, like so:

Got it, that's what I figured, just wanted to verify. Thanks!

As jQuery mobile is supposed to help make the developer's life easier...  this ID restraint is quite a nuisance...
especially if existing content or server-side framework is being adapted for mobile..  Today was my first day to delve into jQuery mobile... and one of my first snags was ID collision.

One of the config options for JQMobile is "ns" to set the namespace for the data-__ attributes
Perhaps there could be a non-current-page-id-ns type option
the pagehide event could do something like the following to the "page" being unloaded

$('*[id]').each( function()
{
      this.attr('id',function(i, val)
      {
            return 'namespace_' + val;
      });
});

so that now all the ids of the outgoing page are prepended with 'namespace'
inversely, pageshow could remove the namespace prefixes
In theory the result would be not needing to worry about what node $('#idInMultiplePages') will return...

Decent idea, or crazy talk?

I'm a JQM newbie so bare with me. What's best practice when it comes to class/id in JQM? I know using id in a view that will be shown multiple times cause problems, but how do I go about solving that using classes? Let's say I have a list of items in one view and clicking on one opens up another view, a detailed view, of each item. Using id:s that won't work since JQM injects two views with the same id into the DOM, but does changing from id to class solve everything? Instead of:

<div data-role="page" id="myPage">
      //Detailed View
      <p id="lat">
      <p id="lon">
</div>

you use:

<div data-role="page" class="myPage">
      //Detailed View
      <p class="lat">
      <p class="lon">
</div>

If I append to the class "myPage" won't that occur in every opened view with that class and thus being heavy? Or is there a way to pinpoint which instance of myPage, lat and lon class that was opened last, thus only appending to those?

I hope I made myself clear.

EDIT: Or should one delete the id from the DOM with every pagehide event that occurs?

I'm not sure of best practices (I'm very green still), but for now I found a solution which works for me using data-cache="false" on the page - http://forum.jquery.com/topic/stale-data-returned-by-a-javascript-query-on-a-reused-page

@ bkdotcom : I do understand that it's not your fault, but since an ID is supposed to be... an ID (which is well known to be unique in IT), your framework/other code shouldn't create different contents with the same ID... So far, I'm not sure we can complain to jQM.

@jdebon: So one should give unique classes for every instance of a "myPage"? How do I go about the same thing when it comes to a page that uses Google maps? I now have one page with a div-id = map and I use the following code to make a google maps object: map = new google.maps.Map(document.getElementById("map"), mapDefaults). How do I go about doing the same thing using classes instead?

No one has an answer to above question?

cplee70's workaround:

$("div.ui-page-active .lat")
instead of just:
$(".lat")

I agree with bkdotcom: I would write a plugin 'namespacer', which would namespace elements, based on which page they are. The plugin would e.g. have the following functions:

'_addNamespace' - (private) called before new page is added to the DOM, called on each pagebeforeload; this function would add a namespace before each id in the new page.
'get' - (public) used by your code to get a page, e.g $.namespacer.get(pageId, elementSelector); this function returns a element using the element's original id

@cplee70 isnt it bad practice to 'misuse' the class-attribute as an id-attribute replacement?

Very strong +1 on koosvdkolk and bkdotcom ideas regarding namespacing ids within inactive pages.

One reason for not having multiple instances of an ID that was not mentioned is that it's not allowed according to HTML specifications. An ID should only appear on a single element within a document. The result of violating this restriction is undefined and browser-dependent.

I think that in many cases, a data- element might be an appropriate substitute. I've started using data- elements to provide RESTful IDs in lists. It just seems awfully neat and tidy to include an ID on each <li> element.

For example, I have a list of Places. I add a data-place-id element to each <li>. This has great utility. For example, I have a button in each list item in that needs to make an Ajax request (to a local Rhodes server on a mobile device) using Javascript.

If you have a click handler, for example, for any descendant of the <li> that passes "this" to a function, then the function can easily get the ID. For example, this click handler:

1. peepr.show_muc = function(obj) {
2.   $.get("/app/Place/chat/" + $(obj).closest('li.place-item', $.mobile.activePage).attr("data-place-id"));
3.   return false;
4.   }

.closest gets me the nearest ancestor that matches the given selector.

(I don't use the response. The server code forces a load into a separate webview on a different native tab.)

Sure, I could have just provided an href in the link, and accessed the href from the function. But there is other utility in having the ID present on the <li> element. For example you might want to do continuous scrolling and you could use th IDs to manage trimming and adding items to the head/tail of the list as the user scrolls.

data- attributes don't have any restriction on multiple occurrences in a document.

HTML5 is not unique in trying to make the best of incorrect markup. Browsers have had to do this pretty-much from Day One. One aspect of HTML5 is an explicit acknowledgement of the current state of "browser soup". HTML5 acknowledges that browsers should be tolerant of mistakes when possible.

I would not tempt fate and mis-use IDs by duplicating them. That it works in a reasonable way now is no guarantee that it will in the future, or that there is not some subtle case that hasn't been tested that fails.

I think it would be a mistake for the JQM team to spend any effort trying to make incorrect markup work in the framework.

Maybe I'm missing something, but it's still not clear what the final word is on this. The docs say:

You can duplicate IDs of child elements that appear on different pages as long as those pages will never be loaded into the DOM at the same time.

As a practical matter, it's not worth it. Make sure all your IDs are unique.