Monthly Archives: June 2014

Javascript Faux Pas

When transcribing thought to code, one should not break this set of coding etiquette.

Etiquette 1: Use less commas
When you finish speaking a sentence, there should be a sense of finale. Don’t end it in a high note like a question. Don’t end it with an “and” followed by a long pause and…

For code, when constructing a comma-separated set of items, make sure the last item does not end in a comma. A comma indicates there’s more to follow, but if there isn’t, don’t put it there.
  url: ...,
  type: ...,
  success: function() {
  statusCode: {
    500: function() {
Did you catch the error?
That’s right. Right after the statusCode {}, there’s an unnecessary comma.
Did you catch the 2nd error?
Right after the 500 within the statusCode, there’s another unnecessary comma.

While modern browsers will happily eliminate the extra commas for you, old browsers (e.g. IE) will choke. Not only that, when it chokes, the error message will neither be helpful nor friendly. Most likely, you won’t see an error about an extra comma. Instead some piece of your code in a completely different file will throw an error because it depended on another file that depended on this file which could not be processed correctly. The error may be “undefined function in randomfile.html”

Etiquette 2: Use more semi-colons
Just like you end a sentence with a punctuation, you should end a line of code with a semi-colon;

While javascript does not require you to end all commands with a semi-colon, this is a very good practice. Most modern browsers will fill it in for you, assuming you write clean code. However, if there is a syntax error in the code, the missing semi-colon can make that syntactic error very hard to find. It may point you to a line that is a hundred lines away from the target problem.

Etiquette 3: one command per line
When you speak, you should often space your sentences to let the listener catch up and process what you have to say. You shouldn’t ramble on without pause.

Code should be the same way.

Give each coding command a line of its own.

Something like this will just not do:
var foo =; var bar =; document.write(bar+foo); ...
If something goes wrong, you will not know which of those functions blew up on that line.

These are some lessons I’ve had to learn the hard way over the course of my life. Make good coding decisions now so you spare yourself (and others) the hair-pulling later.

Element ID’s must be unique across all webpages in jquerymobile/ajax navigation

I’m still trying to wrap my head around jQueryMobile and its subtle nuances and differences from regular web programming. I learned the following lesson the hard way.

We know that you shouldn’t have more than one element on a webpage with the same ID. But did you know you should be careful of having the same ID even across pages? I sure didn’t.

jQueryMobile relies on ajax and does something funky with page transitions. When you click on a anchor tag to another page, you’d expect it to discard the old page and load the new one new. But that’s not exactly how it works.

The content of the new page is loaded within the first page. This has some consequences.

First, the DOM of the first page is still lingering around. So if you go to another page with an element of the same ID, guess what happens? Your guess is as good as mine. If you try to reference an element like $(‘#uniqueID’), you’ll be in for a sore surprise. It will arbitrary pick one, or probably the one on the initial page.

So what can you do about this. One solution is to make sure your IDs are unique across all pages. But what if you reference elements by class and that’s shared across pages? Beats me.

I’m still in search of a good solution. Another one proposed is to get the active page and passed that into jquery for reference.

$(document).on("pagecontainershow", function () {
   var activePage = $.mobile.pageContainer.pagecontainer("getActivePage");
   if (activePage.attr("data-url") == "page2.html") {
      // target content within active page
      // Or activePage.find("#content").css...
      $("#content", activePage).css({ color : "green" });

Solution originally provided here.


So that was easy, eh? …wait, don’t forget what happens to any variables you set in the first page (and other pages) as you navigate around.



Here’s another way to refresh the state of everything. You can add data-ajax=”false” to the anchor tag to make it load the new page as if you typed it into the address bar. This will bypass the ajax navigation. Solution suggested by @Omar

Tagged , , ,