In these cases, the trick is to use ontouchstart instead of onclick.

It is the images on the top right.

I wrote this in Object Oriented format so you can use it again and again on the same page.

Javascript:

var ImageGallery = new Function();

ImageGallery.prototype = {
 initialize: function(mainImage, listWrapper){
  // large image that is shown
  this.mainImage = document.getElementById(mainImage);
  // a list of all the anchors for the thumbnails. Must be a tags for graceful degradation
  this.thumbnails = document.getElementById(listWrapper).getElementsByTagName("a");
  // 0 image is shown already so the first one we want to switch to is the next image or 1
  this.i = 1;
  // this is a work around to allow calling this within nested functions
  var Scope = this;
  // Here starts the rotating of the image by first focusing the thumbnail, then switch the primary image
  this.start = setInterval(function(){
   Scope.focusCall();
  // Here we choose 5 seconds in between each image change. You may want to change this.
  }, 5000);
  // This lets the browser know to do something if one of the thumbnails is clicked
  this.clickEvent();
 },

 // This stops the rotation of the thumbnails. We do that if the user clicks one of them
 stop: function(){
  if (this.start)
   clearInterval(this.start);
 },

 // When an thumbnail loses focus we must use this css class now
 resetBorderColor: function(reset){
  reset.getElementsByTagName("img")[0].className="thumbnailDefault";
 },

 // When the thumbnail gains focus we most give it the corresponding styles
 focusBorderColor: function(focused){
  focused.getElementsByTagName("img")[0].className="thumbnailFocus";
 },

 // Here we grab the href of the a tags and make their path be the path of the current image
 imageRotator: function(){
  this.mainImage.src = this.thumbnails[this.i].href;
  this.previousImage = this.thumbnails[this.i];
  this.i++;
  // This closes the loop for the rotation
  if (this.i == this.thumbnails.length)
   this.i = 0;
 },

 // We focus the thumbnail
 focusCall: function(){
  // reset the last image that was shown
  if (typeof this.previousImage != 'undefined')
   this.resetBorderColor(this.previousImage);
  // Remember the newer one
  this.currentImage = this.thumbnails[this.i];
  // Give the newer image some focus
  this.focusBorderColor(this.currentImage);
  var Scope = this;
  // Les that have image rotate to the new one 300 miliseconds after the thumbnails get the css focus
  window.setTimeout(function(){
   Scope.imageRotator()
  // You may want to change this number
  }, 300);

 },

 // This is what happens when you click the thumbnails
 clickEvent: function(){
  var Scope = this;
  for (k = 0; k < this.thumbnails.length; k++) {
   this.thumbnails[k].onclick = function(){
    if (typeof Scope.previousImage != 'undefined')
     Scope.resetBorderColor(Scope.previousImage);
    Scope.focusBorderColor(this);
    // Stop the rotation
    Scope.stop();
    // This is where the switching happens for the click
    Scope.mainImage.src = this.href;
    Scope.previousImage = this;
    // Make sure to not allow default behavior of the a tag
    return false;
   }
  }
 }

}

This is to load it on the window object and create an instance of the viewer

var imageGallery1 = new ImageGallery();

// Not sure where I got this.. I didn't write this but it allows you to load multiple functions on the window.onload.
function addLoadEvent(func) {
 var oldonload = window.onload;
 if (typeof window.onload != "function") {
  window.onload = func;
 } else {
  window.onload = function() {
   oldonload();
   func();
  }
 }
}

var onLoad = function() {
 imageGallery1.initialize("index_largepic_display", "index_thumbnail_display");
}

addLoadEvent(onLoad);

For the version on my homepage alexgrande.com here is the CSS and HTML. The CSS is up to you but I suggest following a similar mode with the HTML

HTML:

<div id="gallery">
     <ul id="index_thumbnail_display">
        <li>
   <a href="images/index/fernlarge.jpg" >
  <img class="thumbnailDefault" src="images/index/fernthumb.jpg" alt="A picture of a fern just as it is unraveling in front of a log." />
   </a>
 </li>

        <li>
   <a id="partythumb" href="images/index/partylarge.jpg" >
      <img class="thumbnailDefault" src="images/index/partythumb.jpg" alt="Downtown Seattle at night." />
   </a>
 </li>

        <li>
   <a id="alexthumb" href="images/index/alexlarge.jpg" >
      <img class="thumbnailDefault" src="images/index/alexthumb.jpg" alt="I'm on a laptop at night in a field on using the internet via hacking a telephone box...legally." />
   </a>
 </li>
        <li>
   <a href="images/index/trucks.jpg" >
     <img class="thumbnailDefault" alt="Trucks lined up in Sodo in Seattle at night." src="images/index/trucksthumb.jpg" />
   </a>
        </li>
      </ul>
      <img id="index_largepic_display" src="images/index/fernlarge.jpg" alt="A picture of a fern just as it is unraveling in front of a log." />
</div>

CSS:

div#gallery {
 position:relative;
 float: left;
 overflow: hidden;
 width: 65%;
}

img#index_image_display {
 border:1px black solid;
 margin-bottom:20px;
}

ul#index_thumbnail_display {
 list-style-type:none;
 position:absolute;
 top: 0;
 left: 0;
 margin-top: 15px;
}

ul#index_thumbnail_display li a {
 padding:10px;
}

.thumbnailDefault {border: 1px solid gray !important;}

.thumbnailFocus {border: 1px solid red !important;}

The effects of losing application state can range from
minor annoyances like losing what page you’re on, to
all-out frustration after losing a carefully-typed message
because you accidentally triggered the browser’s back
button. (It’s easier than you think– hitting backspace
when the document is in focus triggers the back button in
most browsers). Couple this with the fact that some users
may expect pages to save form data, because of their prior
experience to that effect, and it becomes apparent that a
robust strategy for preserving application state must be
devised.

Browsers automatically save data entered into form
fields, but all JavaScript variables are lost when the user
leaves the page. Furthermore, any form fields that were
created by JavaScript will also be lost. So, for all but
the most simple applications, JavaScript must have a
strategy for saving state that deals with these
limitations.

Some sites like “http://www.thesixtyone.com”>thesixtyone.com
reside entirely on a single page and capture users’ back
button clicks with named anchors. But, try writing a wall
post on Facebook and you’ll find that it does not save the
post if you leave the page. Accidentally pressing backspace
is all too easy in cases like this where typing is
involved, which is why sites like Gmail and Blogger warn
users that they will lose data before leaving the page.

How To Warn Users Before Leaving the Page

One way you can do this is by assigning a confirmation
message to the return value of the
window.onbeforeunload event handler. The user will
be presented with two choices, OK and
Cancel, along with a custom message of your
choosing.

In the following example, we regsiter an anonymous
function as the event handler for
window.onbeforeunload, and add our own custom
message:

Using window.onbeforeunload to confirm if a
user wants to leave the page ( “/examples/saving-state/example-1.html”>example 1)

window.onbeforeunload = function() {
  return "You will lose any unsaved information.";
};

The browser displays your custom message, given in the
return statement of the onbeforeunload event
handler, along with the browser default message. In
Firefox, the result is:

Are you sure you want to navigate away from this
page?
You will lose any unsaved information.
Press OK to continue, or Cancel to stay on the current
page.

Retaining Data When Users Do Leave the Page

You may opt to silently save the user’s data when they
leave the page. This may give a better user experience
since they are not confronted with a choice, and their data
is saved automatically.

This is one of the times where Ajax comes in handy.
However, there are also other ways to do this without using
Ajax, such as cleverly storing information in named anchors
or hidden form fields. We’ll examine each of these
practices in more depth, but suffice it to say that the
hidden form fields approach works better for conventional
websites that are spread across many pages, whereas storing
data in named anchors is better for single-page, pure
JavaScript applications.

It turns out that while you could (and should) save
state to the server using Ajax, for some cases you will
want to avoid Ajax altogether and use a simpler,
clientside-only model.

Using Hidden Form Fields to Save State

As mentioned, all JavaScript objects are lost when the
user leaves or refreshes the page. But, browsers will
retain data in form fields, provided that the form elements
were not generated using JavaScript. Given this limitation,
it is necessary to save JavaScript variables (or the
serialized JSON strings of such objects) to hidden form
fields if they need to be retained.

Here is a basic example showing how variables can be
stored to hidden form fields and restored on page load:

Saving data in hidden form fields ( “/examples/saving-state/example-2.html”>example 2)

// The variable userData is some necessary information we need from the user.
// The first time the user visits the page, they must enter this data manually.
// But, when leaving and returning to the page (or refreshing the page), we'll check
// if they already entered the data, and if so, restore it from a hidden form field.

var userData;

// Register event handlers
window.onload = function() {
 restoreState();
 if (!userData) {
    userData = prompt('Please enter the data to save', 'test');
 }
 document.write("userData: " + userData);
}

window.onbeforeunload = saveState;

// This function is called onbeforeunload and writes the userData to the hidden form field
function saveState() {
   document.getElementById('saved-data').value = userData;
}

// This function is called onload and checks if any data is present in the hidden form field
// If so, it defines userData to be the saved data
function restoreState() {
   var savedData = document.getElementById('saved-data').value;
   if (savedData != "") {
        userData = savedData;
   }
}

In the above example, all we’re saving is one string
from the user. But what about cases where we need to save
many different values? For instance, what if we’re using
object-oriented code and have numerous nested objects
within objects we need to store? At times like this,
serializing objects with JSON is the
easiest way to store the data. Without using JSON, you’d
have to create a hidden form field for each value you want
to save, whereas JSON can create string representations of
complex data structures that you can easily eval
back into JavaScript objects once they’re fetched from the
DOM.

So What is JSON, Anyway?

JSON (pronounced “Jason”), short for JavaScript
Object Notation is a lightweight, human- and
machine-readable way to represent the string serializations
of objects. These strings can be evaluated back into
JavaScript objects as needed. For instance, say I create a
JavaScript object to represent a person (in this case,
me):

var person = new Object();
person.name = "Jonah";
person.age = 24;
person.gender = "male";
person.location = "Seattle, WA";

The JSON representation of this object is as
follows:

{
    'person': {
        'name': 'Jonah',
        'age': 24,
        'gender': 'male',
        'location': 'Seattle, WA'
    }
}

Then, if you need to reconstruct the object at a later
point, you can simply eval the JSON string:

var jsonString = "{'person': {'name': 'Jonah', 'age': 24, 'gender': 'male', 'location': 'Seattle, WA'}}";
var person = eval( '(' + jsonString + ')' );    

console.assert(person.name == 'Jonah');
console.assert(person.age == 24);
console.assert(person.gender == 'male');
console.assert(person.location == 'Seattle, WA');

If you’ve written JavaScript using object literal syntax
before, this should be familiar to you. The only minor
difference between JSON and the standard JavaScript object
literal syntax is that JSON requires quotes around key in a
key/value pair. So, name is a valid JavaScript key
but in JSON it would have to be ‘name’. (Note: It
doesn’t matter if you use single- or double-quotes, as long
as they are matched).

Stringifying Objects in JSON

To use JSON, it’s necessary to include a library of JSON
methods. Don’t worry, the library is quite small. The
entire thing shouldn’t be more than 2k and can be obtained
from json.org.
Eventually, the JSON methods will be included as part of
the core JavaScript language, but for the time being, we’re
left to use the methods provided by json.org or those found
in libraries such as MooTools, Prototype and jQuery.

Depending on the library used, the method names for
serializing an object into a JSON string are different.
But, they are all used in rather similar fashion. For now,
we’ll assume you’re using the library from “http://www.json.org/js.html”>json.org and use the
method names provided in its API.

Saving complex JavaScript data structures as JSON
strings (example 3)

// The variable userData is some necessary information we need from the user.
// The first time the user visits the page, they must enter this data manually.
// But, when leaving and returning to the page (or refreshing the page), we'll check
// if they already entered the data, and if so, restore it from a hidden form field.

var userData;

// Register event handlers
window.onload = function() {
 restoreState();
 if (!userData) {
    userData = new Object();
    userData.name = prompt('Please enter a name', 'Jonah');
    userData.age = parseInt(prompt('Please enter an age', '24'));
    userData.gender = prompt('Please enter a gender', 'male');
    userData.location = prompt('Please enter a location', 'Seattle, WA');
 }
 displayData(userData);
}

window.onbeforeunload = saveState;

// This function is called onbeforeunload and writes the userData to the hidden form field
function saveState() {
   document.getElementById('saved-data').value = JSON.stringify(userData);
}

// This function is called onload and checks if any data is present in the hidden form field
// If so, it defines userData to be the saved data
function restoreState() {
   var savedData = document.getElementById('saved-data').value;
   if (savedData != "") {
        userData = eval( '(' + savedData + ')' );
   }
}

// This is a helper function that iterates through each property in an object and renders it in HTML.
function displayData(obj) {
 var list = document.createElement('ul');
 for (var property in obj) {
    var text = document.createTextNode(property + ': ' + obj[property])
     var line = document.createElement('li');
     line.appendChild(text);
     list.appendChild(line);
 }
 document.getElementsByTagName('body')[0].appendChild(list);
}

This example is pretty similar to the previous one where
we saved a string. The only difference is that in this
case, the string is a representation of a complex
JavaScript object. In fact, you can save the entire state
of your application in one JSON string, as long as the
application state is completely stored as properties of a
single object. There are a few minor gotchas, such as
having to add parentheses around the JSON string when
evaluating it. But, overall this is a clean and
straightforward approach that is very useful when complex
data structures must be retained.

Using Named Anchors to Save State

An alternate option for retaining state is to not
actually let the user leave the page at all. Rather, when
following links on the site, update the named anchor
(everything after the number sign in a URL), instead of
changing the actual document being displayed.

The problem that this is trying to solve is the fact
that Ajax applications will normally break the back button.
A user loads the application on the homepage and clicks to
visit a different page, but since the new page is loaded in
via Ajax, the browser URL doesn’t change. Then the user
clicks the back button and leaves the application
altogether– not the intention of the user, who just wanted
to get back to the homepage.

Storing data in named anchors offers a solution to this
problem. Each time the application state changes,
JavaScript updates the named anchor with a token
representing the application state. When the page is
loaded, data is read from the named anchors and the state
can be restored.

Say you’re on the homepage of an ecommerce Ajax
application and click on a product you’d like to view.
Instead of changing URLs to the detail page, the
application loads in new data with Ajax. So, when a user
clicks on the new Brad Mehldau CD for instance, instead of
going to a different URL (yoursite.com/brad-mehldau/) the
document URL remains the same, but JavaScript updates the
named anchor: yoursite.com/#brad-mehldau.

One site which does this unbelievably well is “http://www.thesixtyone.com”>thesixtyone.com
(Thanks, Derek!). The entire site resides in one document,
truly a rich JavaScript application if I’ve ever seen one.
But, despite the fact that the entire application is
contained in a single document URL, due to clever use of
named anchors, the site has full back button support and
you can even email working links to friends.

Implementing code to save state in named anchors is out
of scope for this article, but you can see how it is
somewhat similar to saving data in hidden form fields. In
this case, there are a few more issues to mitigate and it’s
somewhat tricky, but the reward is an Ajax site with fully
functional back button support and the ability to share
links — worth all the effort, in my book.

So What Use is Ajax, Then?

Since we’ve made it this far, you might think that there
is no use for Ajax in all this. Actually, Ajax is great for
saving state to the server, especially for saving data
beyond the lifespan of the browser session. Ajax can be
used to save messages periodically (like how Gmail and
Google Docs automatically save on a timer every few
minutes). It can also be used to send data when the user
leaves the page by capturing the onbeforeunload
event, but this is unreliable and I would not depend on
this Ajax request to complete. Instead, try to save the
data before the user attempts to leave the page, by either
firing the Ajax request on a timer or another event on the
page (leaving focus on a form element, for example).

Some frameworks like Prototype have serialize() methods
that return URL query string representations of objects.
This is perfect for saving data through GET requests. Yes,
GET requests have a 2000-character limit and other
limitations, but in most cases this won’t be an issue. Even
without helper methods to serialize objects, it’s a fairly
simple matter to construct an Ajax request that will save
the necessary data to the server.

Wrapping Up

To re-cap, it is a good practice to check if users are
sure they want to leave a page when they are entering
information, but it’s even better to silently save that
information for them. (Arguably you would want to do both,
like how Gmail and Blogger save state and ask
users if they are sure they want to leave the page). There
are many different ways to save state, some purely
client-side and others relying on saving data to the server
with Ajax. The solutions which save data to the server are
suitable for times when the data needs to be saved beyond
the browsing session.

Of the two client-side solutions explored, hidden form
fields and named anchors, the former is more suitable for
conventional websites spanning many pages while the latter
better suits single-page Ajax applications. Using named
anchors also has the added benefit of allowing users to
bookmark and send links to the JavaScript application in
various states, and the state is preserved beyond the
browsing session.

Whatever strategy you follow, your users will thank you
for the time saved and frustration avoided of having to
re-enter lost information.

I can’t say that I’ve used much recursion in production code, but it’s a fun topic to write about, as there are plenty of fun uses of recursion to explore.

Let’s start with a basic use of recursion, and replace a for() loop with a recursive function. In this case, we’ll implement a simple function to reverse a string, first using iteration and then recursion.

// Iterative
function reverseString(str) {
    var rev = new String();
    for (var i = str.length - 1; i >= 0; i--) {
        rev += str[i];
    }
    return rev;
}

console.log(reverseString('test')); // Logs 'tset'

// Recursive
function reverseString(str) {
    var firstLetter = str.charAt(0);

    function iterate(str) {
        if (str.charAt(str.length-1) != firstLetter) {
            var charToReverse = str.charAt(str.length-1);
            str.charAt(str.length-1) = '';
            return iterate(charToReverse + str);
        }
    }
    return iterate(str);
}

console.log(reverseString('test')); // Logs 'tset'

Microsoft has released a free beta version of a plugin for Internet Explorer that looks for memory leaks. The plugin, plainly titled JavaScript Memory Leak Detector (download), is available immediately and tests for both IE6 and IE7 leaks. Apparently, IE6 has far more leaks — any time when you have a circular reference between DOM objects and JavaScript objects a leak would occur.

Why are leaks a problem? Because the RAM leaked by a page will remain in use until the browser is closed. For developers of websites with heavy JavaScript usage, memory leaks can be a nightmare. I once worked on a site that would climb to hundreds of megabytes after a few pages of data loaded in through Ajax. Then, the RAM would continue to stay in use until I closed and restarted the browser.

Excerpt from the article “JavaScript Memory Leak Detector”

The IE team has been working hard to solve the problem. With the initial versions of Internet Explorer 6 practically all circular references between Javascript and DOM objects caused a memory leak.

It seems than an update to IE6 alleviated this problem somewhat, but there are probably still many users who haven’t upgraded, and even the later versions of IE6 and current versions of IE7 still have problems. Most of the problems are caused by closures, which really shouldn’t be an issue, as Firefox, Opera and Safari generally handle them fine. I use closures all the time in my code so I shudder to think of what leaks lie beneath. But, I’m about to download this leak detector and give it a try. From the screenshots, it doesn’t look too appealing, but I’m curious to find what it will detect on the past few sites I’ve made.

Getting Started

First, make sure you’re running Firefox. If you aren’t, get Firefox now. You won’t be disappointed. Next, install Firebug by following the link and clicking “Install Now.” After installing, restart Firefox and continue.

Now you can click the small icon in the bottom right corner of the Firefox window to open Firebug. Go ahead and open it– the first time running, you may have to choose to enable it for sites on the world wide web.

Using the Console

The first tab that’s open in Firebug is the console. The console tab shows JavaScript error messages, as well as having a command line interface (CLI) where you can enter JavaScript and execute it in real time.

Using the CLI, you can call functions, define variables, or even write new functions.

The JavaScript error messages are are also helpful for debugging since they show you which line the error occurred on, as well as a stack trace.

Another interesting feature is the ability to log messages to the console by using the method console.log(). Note that this will throw an error in browsers which don’t have Firebug installed, so it’s just for development purposes.

Logging messages can be very useful when debugging complex JavaScript applications that have a lot of moving parts. It can also be used for page profiling. Here’s an example of how you might use logging to the console to add some rudimentary speed profiling of a JavaScript function:

function doStuff() {
var startTime = new Date().getTime(); // The current time in epoch milliseconds

// Add code here to be profiled

var endTime = new Date().getTime() - startTime;
console.log("The function doStuff() took " + endTime + " milliseconds to complete.");
}

This would result in a message being logged to the console with the amount of milliseconds it took for that code to execute. Nothing fancy, but it gets the job done!

DOM Inspection

Clicking the next tab over in Firebug, to HTML, you’ll find a two-paned window that allows you to browse the DOM on the left and edit CSS on the right.

Start opening HTML tags and mousing over them. You’ll notice that the HTML element on the screen lights up when you hover over the tag. It’s a nice feature that lets you quickly orient yourself in the code.

The highlighted area also shows how much space an element is taking up on the screen. The color blue denotes the element’s height and width, while yellow is margin and purple is padding.

Clicking the Inspect button (next to the bug icon in the top left corner of Firebug) will toggle a mode where you can click on HTML elements on the screen and it will go to that tag in the code.

There’s another tab for DOM inspection, the aptly-named DOM tab. Here you will find all of the DOM objects created by JavaScript, such as variables and functions, as well as the core DOM API (for example, the window and document objects can be inspected here).

I check this page when I want to view the current state of the page and watch it change as JavaScript executes. For example, say I have a variable that keeps track of how many items are in a shopping cart. I could watch this variable in the DOM tab to make sure that it’s incremented when I add an item to the cart.

Editing CSS on the Fly

Going back to the HTML tab, notice that the pane on the right shows CSS styles for whichever element is currently selected. You can choose an element in the left pane (or by clicking Inspect and then clicking the element), and the CSS styles for that element will be displayed. Furthermore, you can edit the properties and even add new ones.

Firebug has a different take on CSS editing than some other debugging programs, namely the Microsoft Web Developer Toolbar, so I’ll clarify how it works: In Firebug, when you change a CSS style, it updates it for every element on the page. Conversely, in Microsoft Web Developer Toolbar, changing CSS styles only affects the currently selected element.

By way of example, say you have the CSS rule p {padding: 10px;}. You then select a P tag and change it to padding: 20px; using Firebug. The result is that every P tag will now have 20px padding, unlike other programs where it would only affect the styles of the selected tag.

To add a new style, simply click twice in the whitespace inside of a style block, next to the existing declarations. Firebug even has a convenient auto-complete feature for writing CSS.

In the right page, there are three tabs: Style, Layout and DOM. So far, we’ve been editing CSS in the Style tab, but make sure to check out the other two as well. The Layout tab offers an alternate view of the box model for the selected element, along with pixel-precise measurements of its dimensions. The DOM tab shows all properties and methods for that element.

Page Profiling and Network Metrics

Nothing’s worse than making a great site only to have it suffer from poor front end performance. (OK, well, a lot of things are worse — but it’s still frustrating!). The Firebug Net profiler can help get to the source of that slowness.

Although it is far from robust, the Net tab offers semi-reliable metrics on the download speed of all assets including the HTML document, CSS, JavaScript, images and any other linked files.

You can see which files are being downloaded concurrently and which are blocking (hint: it’s the JavaScript), and how many connections are being opened with a given domain.

For more extensive page profiling, be sure to check out YSlow!, a plugin for Firebug (I guess that makes it an extension-of-an-extension) developed by Yahoo.