A client recently asked me to produce an accessible video player, and one of the features she was very keen to have is audio descriptions. Audio descriptions are intended for people who are blind or have impaired vision, providing additional spoken information to describe important visual details.

Traditionally, audio-described videos have to be made specially, with the audio encoded in a separate track of the single video file. It takes pretty specialised video-editing equipment to encode these audio tracks, and that raises the bar for most content producers beyond a practical level.

All the audio-described content I’ve seen on the web is like this. For example, BBC iPlayer has a selection of such content, but the video player doesn’t give you control over the relative volumes, and you can’t turn the audio-descriptions off — you can only watch separate described or non-described versions of the program.

Enter HTML5

The HTML5 video specification does provide an audioTracks object, which would make it possible to implement an on/off button, and to control the audio and video volumes separately. But its browser support is virtually non-existent — at the time of writing, only IE10 supports this feature.

In any case, what my client wanted was audio descriptions in a separate file, which could be added to a video without needing to create a separate version, and which would be easy to make without specialised software. And of course, it had to work in a decent range of browsers.

So my next thought was to use a MediaController, which is a feature of HTML5 audio and video that allows you to synchronise multiple sources. However browser support for this is equally scant — at the time of writing, only Chrome supports this feature.

But you know — even without that support, it’s clearly not a problem to start two media files at the same time, it’s just a case of keeping them in sync. So can we use existing, widely-implemented features to make that work?

Video Events

The video API provides a number of events we can hook into, that should make it possible to synchronise audio playback with events from the video:

• The "play" event (which fires when the video is played).
• The "pause" event (which fires when the video is paused).
• The "ended" event (which fires when the video ends).
• The "timeupdate" event (which fires continually while the video is playing).

It’s the "timeupdate" event that’s really crucial. The frequency at which it fires is not specified, and practise it varies considerably — but as a rough, overall average, it amounts to 3–5 times per second, which is enough for our purposes.

I’ve seen a similar approach being tried to synchronise two video files, but it isn’t particularly successful, because even tiny discrepancies are very obvious. But audio descriptions generally don’t need to be so precisely in sync — a delay of 100ms either way would be acceptable — and playing audio files is far less work for the browser anyway.

So all we need to do is use the video events we have, to lock the audio and video playback together:

• When the video is played, play the audio.
• When the video is paused, pause the audio.
• When the video ends, pause the video and audio together.
• When the time updates, set the audio time to match the video time, if they’re different.

After some experimentation, I discovered that the best results are achieved by comparing the time in whole seconds, like this:

if(Math.ceil(audio.currentTime) != Math.ceil(video.currentTime))
{
  audio.currentTime = video.currentTime;
}

This seems counter-intuitive, and initially I had assumed we’d need as much precision as the data provides, but that doesn’t seem to be the case. By testing it using a literal audio copy of the video’s soundtrack (i.e. so the audio and video both produce identical sound), it’s easy to hear when the synchronisation is good or bad. Experimenting on that basis, I got much better synchronisation when rounding the figures, than not.

So here’s the final script. If the browser supports MediaController then we just use that, otherwise we implement manual synchronisation, as described:

var video = document.getElementById('video');
var audio = document.getElementById('audio');
if(typeof(window.MediaController) === 'function')
{
  var controller = new MediaController();
  video.controller = controller;
  audio.controller = controller;
}
else
{
  controller = null;
}
video.volume = 0.8;
audio.volume = 1;
video.addEventListener('play', function()
{
  if(!controller && audio.paused)
  {
    audio.play();
  }
}, false);
video.addEventListener('pause', function()
{
  if(!controller && !audio.paused)
  {
    audio.pause();
  }
}, false);
video.addEventListener('ended', function()
{
  if(controller)
  {
    controller.pause();
  }
  else
  {
    video.pause();
    audio.pause();
  }
}, false);
video.addEventListener('timeupdate', function()
{
  if(!controller && audio.readyState >= 4)
  {
    if(Math.ceil(audio.currentTime) != Math.ceil(video.currentTime))
    {
      audio.currentTime = video.currentTime;
    }
  }
}, false);

Note that the MediaController itself is defined only through scripting, whereas it is possible to define a controller using the static "mediagroup" attribute:

<video mediagroup="foo"> ... </video>
<audio mediagroup="foo"> ... </audio>

If we did that, then it would work without JavaScript in Chrome. It would sync the media sources, but the user would have no control over the audio (including not being able to turn it off), because the browser wouldn’t know what the audio represents. This is the case in which it would be better to have the audio encoded into the video, because then it could appear in the audioTracks object, and the browser could recognise that and be able to provide native controls.

But since we have no audioTracks data, that’s rather a moot point! So if scripting is not available, the audio simply won’t play.

Here’s the final demo, which will work in any recent version of Opera, Firefox, Chrome, Safari, or IE9 or later:

• Audio Descriptions Demo

This is just a simple proof-of-concept demo, of course — there’s no initial feature detection, and it only has the basic controls provided by the native "controls" attribute. For a proper implementation it would need custom controls, to provide (among other things) a button to switch the audio on and off, and separate volume sliders. The interface should also be accessible to the keyboard, which is not the case in some browsers’ native controls. And it would need to handle buffering properly — as it is, if you seek past the point where the video has preloaded, the audio will continue to play freely until the video has loaded enough to bring it back into sync.

I might also mention that the descriptions themselves are hardly up to professional standards! That’s my voice you can hear, recorded and converted using Audacity. But such as it is, I think it makes an effective demonstration, of how low the technical barrier-to-entry is with this approach. I didn’t have to edit the video, and I made the audio in an hour with free software.

As a proof of concept, I’d say it was pretty successful — and I’m sure my client will be very pleased!

I’d like to show you three cunning things you can do with regular expressions, that provide neat solutions to some very sticky problems:

1. Removing Comments
2. Using Replacement Callbacks
3. Working With Invisible Delimiters

1. Removing Comments

Regular expressions make light work of single-character delimiters, which is why it’s so easy to remove markup from a string:

str = str.replace(/(<[\/]?[^>]+>)/g, '');

It’s the negation in the character class that does the real work:

[^>]

Which means “anything except <”. So the expression looks for the starting tag-delimiter and possible slash, then anything except the closing tag-delimiter, and then the delimiter itself. Easy.

However comments are not so simple, because comment delimiters are comprised of more than one character. Multi-line comments in CSS and JavaScript, for example, start with /* and end with */, but between those two delimiters there could be any number of unrelated stars.

I often use multiple stars in comments, to indicate the severity of a bug I’ve just noticed, for example:

/*** this is a bug with 3-star severity ***/

But if we tried to parse that with a single negation character, it would fail:

str = str.replace(/(\/\*[^\*]+\*\/)/g, '');

Yet it’s not possible with regular expressions to say: “anything except [this sequence of characters]”, we can only say: “anything except [one of these single characters]”.

So here’s the regular expression we need instead:

str = str.replace(/(\/\*([^*]|(\*+[^*\/]))*\*+\/)/gm, '');

The expression handles unrelated characters by looking at what comes after them — stars are allowed as long as they’re not followed by a slash, until we find one that is, and that’s the end of the comment.

So it says: “/ then * (then anything except * OR one or more * followed by anything except * or /)(and any number of instances of that) then one or more * then /”.

(The syntax looks particular convoluted, because "*" and "/" are both special characters in regular expressions, so the ambiguous literal ones have to be escaped. Also note the "m" flag at the end of the expression, which means multi-line, and specifies that the regular expression should search across more than one line of text.)

Using the same principle then, we can adapt the expression to search for any kind of complex delimiters. Here’s another one that matches HTML comments:

str = str.replace(/(<!\-\-([^\-]|(\-+[^>]))*\-+>)/gm, '');

And here’s one for CDATA sections:

str = str.replace(/(<\!\[CDATA\[([^\]]|(\]+[^>]))*\]+>)/gm, '');

2. Using Replacement Callbacks

The replace function can also be passed a callback as its second parameter, and this is invaluable in cases where the replacement you want can’t be described in a simple expression. For example:

isocode = isocode.replace(/^([a-z]+)(\-[a-z]+)?$/i,
  function(match, lang, country)
  {
    return lang.toLowerCase()
      + (country ? country.toUpperCase() : '');
  });

That example normalizes the capitalisation in language codes — so "EN" would become "en", while "en-us" would become "en-US".

The first argument that’s passed to the callback is always the complete match, then each subsequent argument corresponds with the backreferences (i.e. arguments[1] is what a string replacement would refer to as "$1", and so on).

So taking "en-us" as the input, we’d get the three arguments:

0. "en-us"
1. "en"
2. "-us"

Then all the function has to do is enforce the appropriate cases, re-combine the parts and return them. Whatever the callback returns is what the replacement itself returns.

But we don’t actually have to assign the return value (or return at all), and if we don’t, then the original string will be unaffected. This means we can use replace as a general-purpose string processor — to extract data from a string without changing it.

Here’s another example, that combines the multi-line comment expression from the previous section, with a callback that extracts and saves the text of each comment:

var comments = [];
str.replace(/(\/\*([^*]|(\*+[^*\/]))*\*+\/)/gm,
  function(match)
  {
    comments.push(match);
  });

Since nothing is returned, the original string remains unchanged. Although if we wanted to extract and remove the comments, we could simply return and assign an empty-string:

var comments = [];
str = str.replace(/(\/\*([^*]|(\*+[^*\/]))*\*+\/)/gm,
  function(match)
  {
    comments.push(match);
    return '';
  });

3. Working With Invisible Delimiters

Extracting content is all very well when it uses standard delimiters, but what if you’re using custom delimiters that only your program knows about? The problem there is that the string might already contain your delimiter, literally character for character, and then what do you?

Well, recently I came up with a very cute trick, that not only avoids this problem, it’s also as simple to use as the single-character class we saw at the start! The trick is to use unicode characters that the document can’t contain.

Originally I tried this with undefined characters, and that certainly worked, but it’s not safe to assume that any such character will always be undefined (or that the document won’t already contain it anyway). Then I discovered that Unicode actually reserves a set of code-points specifically for this kind of thing — so-called noncharacters, which will never be used to define actual characters. A valid Unicode document is not allowed to contain noncharacters, but a program can use them internally for its own purposes.

I was working on CSS processor, and I needed to remove all the comments before parsing the selectors, so they wouldn’t confuse the selector-matching expressions. But they had to be replaced in the source with something that took up the same number of lines, so that the line-numbers would remain accurate. Then later they would have to be added back to the source, for final output.

So first we use a regex callback to extract and save the comments. The callback returns a copy of the match in which all non-whitespace is converted to space, and which is delimited with a noncharacter either side:

var comments = [];
csstext = csstext.replace(/(\/\*([^*]|(\*+([^*\/])))*\*+\/)/gm,
  function(match)
  {
    comments.push(match);
    return '\ufddf' + match.replace(/[\S]/gim, ' ') + '\ufddf';
  });

That creates an array of comments in the same source-order as the spaces they leave behind, while the spaces themselves take-up as many lines as the original comment.

Then the originals can be restored simply by replacing each delimited space with its corresponding saved comment — and since the delimiters are single characters, we only need a simple character class to match each pair:

csstext = csstext.replace(/(\ufddf[^\ufddf]+\ufddf)/gim,
  function()
  {
    return comments.shift();
  });

How easy is that!

There are a few expressions that are commonly seen in JavaScript, but which some programming purists will tell you are never a good idea. What these expressions share is their reliance on automatic type conversion — a core feature of JavaScript which is both a strength and a weakness, depending on the circumstances and your point of view.

So in this article I’d like to look at two of these expressions in particular, and consider the circumstances in which they are — and are not — a good idea.

The first of these expressions is a simple if() condition:

if(foo)
{
}

The second is a variable assignment with a choice of possible values:

var x = foo || bar;

If the foo and bar in those examples are both boolean values, then the expressions are simple: the first condition passes if foo is true; the second expression assigns foo to x if foo is true, or assigns bar to x if not.

But what if they’re not simple booleans — what if foo is an object, a string, or undefined? What if foo and bar are different data-types? To understand how these expressions will be evaluated, we need to understand how JavaScript automatically converts between data-types.

Automatic Type Conversion

JavaScript is a "loosely typed" language, which means that whenever an operator or statement is expecting a particular data-type, JavaScript will automatically convert the data to that type. The if() statement in the first example expects a boolean value, therefore whatever you define in the brackets will be converted to a boolean. The same is true for while() and do...while() statements.

JavaScript values are often referred to as being "truthy" or "falsey", according to what the result of such a conversion would be (i.e. true or false). The simplest way to think of it is like this: a value is truthy unless it’s known to be falsey; and in fact there are only six falsey values:

• false (of course!)
• undefined
• null
• 0 (numeric zero)
• "" (empty string)
• NaN (Not A Number)

Notable exceptions are "0" (string zero) and all types of object — which are truthy — and this includes all primitive constructors, which means that new Boolean(false) evaluates to true! (Kinda confusing, but in practice you never need to create primitive values that way.)

Note: comparing two falsey values won’t always produce the result you might expect, for example (null != false) even though both are falsey values. There are some rather complex algorithms that determine how equality evaluations work, and it’s beyond the scope of this article to discuss them. But if you’re interested in the details, have a look at the The Abstract Equality Comparison Algorithm which is part of ECMAScript 5.1.

The Condition Shortcut

The if() example I showed you at the start converts its expression to a boolean, and since objects always evaluate to true while null evaluates to false, we can use a condition like that to test for the existence of DOM elements:

var element = document.getElementById("whatever");
if(element)
{
  //the element exists
}
else
{
  //the element doesn't exist
}

That will always work reliably when dealing with DOM elements, because the DOM specification requires that a non-existent element returns null.

However, other cases are not so clear-cut, like this example:

function doStuff(foo)
{
  if(foo)
  {
    ...
  }
}

Conditions like that are frequently used to mean "if the foo argument is defined", but there are several cases where that would fail — namely, any cases where foo is a falsey value. So if, for example, it’s boolean false or an empty string, then the conditional code would not be executed, even though foo is defined.

This is what we want instead:

function doStuff(foo)
{
  if(typeof foo != "undefined")
  {
    ...
  }
}

Arguments (and other variables) which have not been defined, have a data-type of "undefined". So we can use the typeof comparator to test the argument’s data-type, and then the condition will always pass if foo is defined at all. The if() expression is still evaluating a boolean, of course, but the boolean it’s evaluating is the result of that typeof expression.

The Assignment Shortcut

The second example I showed you at the start uses a logical operator, to determine which of two values should be assigned to a variable:

var x = foo || bar;

Logical operators do not return a boolean, but they do still expect a boolean, so the conversion and evaluation happens internally. If foo evaluates to true then the value of foo is returned, otherwise the value of bar is returned. This is immensely useful.

This expression is commonly seen in event-handling functions, where it’s used to define an event argument according to the supported model:

element.onclick = function(e)
{
  e = e || window.event;
};

So e is evaluated as a boolean, and that will be truthy (an event object) if the event-argument model is supported, or it will be falsey (undefined) if not; if it’s truthy then e is returned, or if not then window.event is returned.

The same kind of expression is also commonly used to assign event properties, finding the supported property by evaluating each possibility:

var target = e.target || e.srcElement || window;

So each of those references is evaluated in turn (from left to right), and the first to evaluate to true will be returned. The first case handles the standard model, the second is for Internet Explorer, while the third is for Internet Explorer when the event might fire on the window object (which has no srcElement property).

But expressions like this are equally prone to failure, in cases where the truthy-ness of the data isn’t known. For example, another common use-case is to define defaults for optional arguments, but this is not good:

function doStuff(foo)
{
  foo = foo || "default value";
}

Now if you know for sure that foo will always be either a string or undefined, and assuming that an empty string should be treated as undefined, then that expression is safe. But if not, it will need to be re-defined to something more precise, like this for example:

function doStuff(foo)
{
  if(typeof foo != "string")
  {
    foo = "default value";
  }
}

By testing the type against "string" we can handle multiple cases — where foo is undefined, and also where it’s mis-defined as a non-string value. In that case we also allow an empty string to be valid input, but if we wanted to exclude empty strings, we’d have to add a second condition:

function doStuff(foo)
{
  if(typeof foo != "string" || foo == "")
  {
    foo = "default value";
  }
}

There are other, surprisingly subtle cases where this can be a gotcha. For example, we might have a date function that creates a unix timestamp, unless an input timestamp is optionally defined:

function doDateStuff(timestamp)
{
  timestamp = timestamp || new Date().getTime();
}

That would fail if the input is 0 — because zero is a falsey value, but it’s also a valid timestamp.

General Principles

The general lesson to take from all this is simple — think about how type conversion will affect evaluations, and take care not to fall into the gotchas we’ve encountered. With due care and attention, you can still take advantage of automatic type conversion, to shorten conditions and logical expressions wherever it’s appropriate.

It does rather beg the question though — if we know that explicit testing using typeof is always safe, while relying on automatic type conversion sometimes isn’t — then why not just be explicit all the time? Certainly, if the only reason for preferring the shorter syntax, is that it’s quicker to type, then that’s a lazy and sloppy reason.

But the fact is, JavaScript usually runs across a public network, in situations where file size makes a difference. Smaller files are faster loading, and use less bandwidth, and little syntax shortcuts can really add-up.

Taking advantage of shorter expressions is not an optimization as such, it’s just a coding style that makes the best of language features.

This is part two of two in the series describing how to create a jQuery plugin to detect and respond to swipe gestures.

In the first part, we saw how to create a plugin that changes a carousel’s pictures to correspond to the position of the finger on screen. In this part, we will extend that to detect a swipe gesture. This improves the carousel by creating fixed intervals so that a swipe changes the carousel to show the next/previous picture in its entirety.

var Swiper = function (el, callbacks, options) {
  ...
  this.opts = options;
  this.swipeDone = false;
  //perform binding
  this.el.addEventListener('touchend', function (evt) {
    tis.stop(evt);
  });
  ....
};
Swiper.LEFT = - 1;
Swiper.RIGHT = 1;
...
$.fn.swiper = function (callbacks, options) {
  var opts = $.extend({}, $.fn.swiper.defaults, options);
  if (typeof callbacks.swiping !== 'function') {
    throw '"swiping" callback must be defined.';
  }
  if (typeof callbacks.swiped !== 'function') {
    throw '"swiped" callback must be defined.';
  }
  if (typeof callbacks.swipeCancel !== 'function') {
    throw '"swipeCancel" callback must be defined.';
  }
  this.each(function () {
    ...
    if (!swiper) {
      tis.data('swiper', (swiper = new Swiper(this, callbacks, opts)));
    }
  });
};
$.fn.swiper.defaults = {
    tolerance: 100
};

In the above listing, we see that the class constructor for Swiper is modified to accept a third parameter options that holds a single property tolerance. The parameter is assigned to an internal property opts. The touchend event is proxied to the stop() instance method of the Swiper class.

Additionally, two callback functions have been added (swiped and swipeCancel) to handle the swiping. The default value for tolerance is set as 100 (pixels). Notice there are also two class properties Swiper.LEFT and Swiper.RIGHT. They represent a left swipe and a right swipe respectively and will be used in subsequent listings.

The plugin definition is also modified to accept a second, optional, parameter that provides the choice to override the default threshold of 100 pixels.

We need to extend the plugin to recognise when a swipe has occurred and modify the carousel correspondingly. There are several scenarios we need to consider. The first, and most straightforward, is when the user drags a finger across the screen and releases it. If the finger covers a distance that is more than or equal to the tolerance value, we consider that a swipe, and the carousel should advance to the next image when the finger is lifted off the screen. The figure below illustrates this scenario.

On the other hand, if the finger covers a distance that is less than the tolerance value, the movement is not considered a swipe and the carousel should revert to its original position.

Remember that the plugin moves the carousel to mirror the movement of the finger for the duration of contact with the screen. The decision as to whether to advance or revert the carousel position is taken when the finger is lifted off the screen (binding for the touchend event).

Swiper.prototype.stop = function (evt) {
  if (!this.swipeDone) {
    this.cbs.swipeCancel();
  } else {
    this.cbs.swiped(this.getDirection());
  }
};

If a swipe is detected, invoke the callback for advancing the carousel (swiped()), otherwise revert the carousel (swipeCancel()).

One thing to note is that we are returning the direction of the movement to the “advancing” callback as determined by the getDirection method. This is required as the callback needs to know which direction to advance the carousel to.

Swiper.prototype.getDirection = function () {
  var direction = this.diff();
  if (direction < 0) {
    return Swiper.LEFT;
  }
  if (direction > 0) {
    return Swiper.RIGHT;
  }
};

This method uses the diff() method defined in Part 1 of this series to get the displacement of the finger. If the difference is negative, it is a left swipe, otherwise it is a right swipe.

We now need to know how to determine whether a swipe is generated i.e. setting of the swipeDone flag. Before we delve into that though, let’s consider the next scenario.

If the user brings a finger to the screen, drags it beyond the threshold value, and then brings it back to within the threshold value before removing the finger, we don’t want to advance the carousel as the user’s intention, by bringing the finger back, is that he/she does not want to advance the carousel.

Similarly if the user brings the finger back beyond the tolerance value before removing the finger, his/her intention is to advance the carousel.

As you can imagine, the determination of when the gesture is detected is done while the finger is dragging on the screen, and not when the finger is lifted. We therefore have to make some changes to the move() instance method of the Swiper class.

Swiper.prototype.move = function (evt) {
  if (Math.abs(this.diff()) >= this.opts.tolerance) {
    this.swipeDone = true;
  } else {
    this.swipeDone = false;
  }
  if (evt.targetTouches && evt.targetTouches.length === 1) {
    if (evt.targetTouches[0].offsetX) {
      this.points[1] = evt.targetTouches[0].offsetX;
    } else if (evt.targetTouches[0].layerX) {
      this.points[1] = evt.targetTouches[0].layerX;
    } else {
      this.points[1] = evt.targetTouches[0].pageX;
    }
    this.cbs.swiping(this.diff());
  }
};

At the beginning of the move() method, we check if the distance moved by the finger has exceeded the tolerance value. The difference is encompassed in a Math.abs() function because a left movement will always generate a negative value which is less than any positive value. By taking its absolute value, we can check the distance for both left and right movements. If it is determined that the distance is larger than or equals to the tolerance value, we consider it a swipe.

A key point about making this work is the removal of the line this.points[0] = this.points[1]; from the move() method. This is absolutely critical because we want to take reference from the point where the finger came into contact with the screen (touchstart). If we retain this line of code, the reference point will keep changing with each movement of the finger and we will not be able to perform the calculation that we want. With the removal of this line of code though, the value that diff() returns will also be different from before. We then have to change the definition of the swiping() callback function.

One last change to make to the Swiper class is to its start() instance method. This change basically says that every time a finger is first placed on screen, the swipeDone flag to false, which is natural since a swipe cannot have been generated when the finger first touches the screen.

Swiper.prototype.start = function (evt) {
  if (evt.targetTouches && evt.targetTouches.length === 1) {
    this.swipeDone = false;
    ...
  }
};

We are pretty much done with the plugin itself. Changing the application code to utilise the plugin requires a paradigm shift in how we manipulate the carousel’s position while the finger is still dragging on screen. Remember that the carousel is supposed to “snap” to positions that show any of the images in its entirety. As a result, the value of the position is always a multiple of the width of each image. Thus it is easiest to represent the position as a percentage. Note that since we are treating the currPos value as a percentage, the values of MAX_LEFT and MAX_RIGHT need to be converted into percentages too.

We still want to retain the mirroring effect of the carousel on the finger. To do that, a new variable adhocPos is introduced in the swiping() callback. This value holds the position of the carousel as the finger drags on the screen. It uses the baseWidth variable which is set to 330 pixels (the width of each image in the carousel). This value must be changed if the width of an image in the carousel changes.

...
MAX_LEFT = -300,
MAX_RIGHT = 0,
baseWidth = 330;
cb = {
  swiping: function (displacement) {
    var adhocPos = currPos / 100 * baseWidth;
    adhocPos += displacement;
    pictures.css('left', adhocPos + 'px');
  },
  ...
}

The currPos value is treated as a percentage which is set in the swiped callback below:

swiped: function (direction) {
  currPos += (direction * 100);
  if (currPos < MAX_LEFT || currPos > MAX_RIGHT) {
    //i.e. exceeded limit
    currPos -= (direction * 100);
  }
  pictures.css('left', currPos + '%');
}

The callback is passed a direction parameter which, as we saw earlier, is either 1 or -1. This is then multiplied with 100 to convert into a percentage value before summing up with currPos. The if statement checks to make sure that the value remains within the boundaries so that the carousel does not scroll into empty space. This was previously done in the swiping() callback. By placing this check in the swiped() callback, we get the effect that when the user drags the carousel beyond the last image, we see white space but as soon as the finger is lifted, the carousel jumps back, thereby creating a sort of “bouncing” effect.

Lastly, there is the swipeCancel() callback which sets the carousel back to its original position before the dragging started.

swipeCancel: function () {
  pictures.css('left', currPos + '%');
}

With the modifications we made to the plugin in this article we have a decent swiping carousel that works almost like a native app in your browser. Similarly, the plugin has been tested in the same browsers as stated in the first article. You can see the demo or download the source code and have fun with them!

This article will explain the steps to create a jQuery plugin that detects the horizontal swiping motion on touch devices such as the iPhone and Android-based devices. This article is the first in a two-part series. In this article, we will be creating an image carousel that can respond to the user’s input and change the position of the carousel accordingly. The second article will extend the plugin by adding swipe detection.

HTML & CSS

Before we go on to the JavaScript, let’s take a look at the HTML and CSS for the image carousel which will be used to demonstrate the Swiper plugin. The HTML is shown below.

<div style="width: 330px; height: 200px;">
  <div id="target">
    <div>
      <div><img alt="" src="rexy.jpg" /></div>
      <div><img alt="" src="xena.jpg" /></div>
      <div><img alt="" src="xenaagain.jpg" /></div>
      <div><img alt="" src="rexyagain.jpg" /></div>
    </div>
  </div>
</div>

Similarly, the carousel’s CSS is shown below.

img { /*100% width to scale the height proportionately*/
  width: 100%;
  margin: 0;
}
.frame {
  width: 100%;
  height: 100%;
  border: 1px solid #ccc;
  overflow: hidden;
  position: relative;
}
.pictures {
  position: absolute;
  width: 400%; /*change accordingly*/
  left: 0%;
}
.pictures:after {
  content: "\0020";
  display: none;
  height: 0;
}
.pictures .pic {
  width: 25%; /*change with respect to .pictures*/
  float: left;
}

The inner container (.pictures) is set to 400% to contain four images. Each image’s container (.pic) is set to 25% so that the images end up at a width of 330 pixels. If you change the number of images or use absolute values instead of percentages, you’d want to change the width value of the .pictures and .pic elements accordingly.

The images are made to line up horizontally by floating to the left. The frame (.frame) is made to show only one image at a time. With this setup, we can then “slide” the carousel by changing the left property of the .pictures <div> element.

JavaScript

Here is the skeleton of the plugin:

(function ($) {
  'use strict';
  var Swiper = function (el, callbacks) {
  }
  $.fn.swiper = function (callbacks) {
    if (typeof callbacks.swiping !== 'function') {
      throw '"swiping" callback must be defined.';
    }
    this.each(function () {
      var tis = $(this),
        swiper = tis.data('swiper');
      if (!swiper) { //i.e. plugin not invoked on the element yet
        tis.data('swiper', (swiper = new Swiper(this, callbacks)));
      }
    });
  };
}(jQuery));

This listing is boilerplate code for creating a jQuery plugin. The bulk of the complexity is handled by the internal class Swiper, whose methods are not yet defined. Swiper is responsible for reading the events produced by the browser and invoking the callback. The plugin is defined in a closure so that the Swiper class will not be mistakenly overridden by external code. The plugin is also prevented from binding to an element more than one time by associating the instantiated Swiper class with the swiper data attribute.

var Swiper = function (el, callbacks) {
  var tis = this;
  this.el = el;
  this.cbs = callbacks;
  this.points = [0, 0];
  //perform binding
  this.el.addEventListener('touchstart', function (evt) {
    tis.start(evt);
  });
  this.el.addEventListener('touchmove', function (evt) {
    evt.preventDefault();
    tis.move(evt);
  });
};

In the above listing, the Swiper constructor instantiates the object’s properties and event handlers. The points property is a two-celled array that stores the starting position of the finger in the first cell, and the ending position in the second cell. We will see the usage of this array in subsequent listings. Its values are both initially zero.

The constructor binds the touchstart and touchmove events, and proxies the events to the corresponding methods in the Swiper class. The touchstart binding initializes the points array with the initial position of the finger. The touchmove binding gives us the movement of the finger, which we will pass to the callback function to offset the carousel accordingly.

Swiper.prototype.start = function (evt) {
  if (evt.targetTouches && evt.targetTouches.length === 1) {
    if (evt.targetTouches[0].offsetX) {
      this.points[0] = evt.targetTouches[0].offsetX;
    } else if (evt.targetTouches[0].layerX) {
      this.points[0] = evt.targetTouches[0].layerX;
    } else {
      this.points[0] = evt.targetTouches[0].pageX;
    }
    //make initial contact with 0 difference
    this.points[1] = this.points[0];
  }
};

The listing above shows the start() method, which takes the event and reads the set of touches generated on screen. In devices with multi-touch capability, which means nearly all modern smartphones and tablets, this property is an array storing the locations of all contact points with the screen. In this implementation, we are keeping track of one contact point as we are tracking a single swipe gesture which is done using one finger.

We are checking for the different properties of the touch event to accommodate the different implementations of the touch behaviour on different devices. This used to be required to make it work for different devices. Today, however, the devices that I have tested all generate the pageX property.

Since we are checking only for a horizontal swipe gesture, we ignore the pageY property. We also set the cells of the points property to the same value so that the initial difference between the starting and ending points is zero.

The function binding for the touchmove event and other helper methods are listed below.

Swiper.prototype.diff = function () {
  return this.points[1] - this.points[0];
};
Swiper.prototype.move = function (evt) {
  if (evt.targetTouches && evt.targetTouches.length === 1) {
    if (evt.targetTouches[0].offsetX) {
      this.points[1] = evt.targetTouches[0].offsetX;
    } else if (evt.targetTouches[0].layerX) {
      this.points[1] = evt.targetTouches[0].layerX;
    } else {
      this.points[1] = evt.targetTouches[0].pageX;
    }
    this.cbs.swiping(this.diff());
    this.points[0] = this.points[1];
  }
};

The diff() method simply calculates the difference between the last point (which changes as the user moves the finger) and the previous point. This is illustrated by the following figure.

The move() method also checks through the different properties to get the right one for storing into the second cell of the points property. After storing the value, the callback function is invoked with the difference between the previous position and the new position of the finger. The callback function is responsible for changing the position of the carousel. This is explained below.

After invoking the callback, the previous position’s value is replaced with the current position’s value. The next time the callback is invoked, the difference will be the displacement between the current position and the previous position instead of the starting position. This is required if we want the movement of the carousel to mirror that of the finger. Without this line, the carousel’s movement accumulates the difference and the result is a large displacement of images in response to a small movement of the finger, which is clearly undesirable for a smooth user experience.

The listing below invokes the plugin.

var target = $('#target'),
  pictures = $('.pictures', target),
  MAX_LEFT = -990,
  MAX_RIGHT = 0,
  currPos = 0,
  cb = {
    swiping: function (displacement) {
      currPos += displacement;
      if (currPos > MAX_RIGHT) {
        currPos = MAX_RIGHT;
      } else if (currPos < MAX_LEFT) {
        currPos = MAX_LEFT;
      }
      pictures.css('left', currPos + 'px');
    }
  };
target.swiper(cb);

We get the element using its id. We also need a handle to the .pictures element within the target because the carousel’s positioning is changed by changing the left CSS property of this element.

We set the left and right limit of the carousel’s position with the MAX_LEFT and MAX_RIGHT variables. These values have to change in relation to the carousel’s size. They are used so that the user does not scroll the carousel to empty spaces. The MAX_RIGHT variable determines how far right the finger can drag the carousel to hit the left-most image. Naturally, this value is 0. The MAX_LEFT variable limits how far left the finger can move the carousel. Since there are four images, to display the right-most one, the three images on the left have to be displaced. The values are derived like this:

330 (width of one image) * 3 = 990

We also have a variable, currPos, that stores the current position of the carousel. Alternatively, we can get the position of the carousel like so:

currPos = parseInt(pictures.css('left'));

The preferred approach is to use the variable. The only reason is that of performance – retrieving the left property of the element and converting it into an integer definitely consumes more processing power than accessing a variable’s value. This is cognizant of the fact that we are adding behavior on top of a browser’s interface, so it is important that we keep the plugin lean.

The callback is specified as a property within a JSON literal. Why not simply pass it as a function? Well, this is to set the stage for part two of this series, where we will explain how to add swipe gesture detection to the plugin.

A final note: on iOS devices (iPhones and iPads), there is a bouncing effect on the browser window when you scroll the carousel. This is apparent if the carousel is near the bottom or the top (as is the case here) of the page. To prevent that from happening, we call the preventDefault() method on the touchmove event. Incidentally, by calling the preventDefault() method, it prevents the event from bubbling up the DOM hierarchy, which in turn leads to better performance, especially apparent on slower devices such as the Nexus One. I’ve tested the plugin on the iPad 2 (iOS 6.0.1), Nexus One (Android 2.3.6), and Galaxy Note II (Android 4.1.2). If you have used any other devices/OS, feel free to let us know in the comments!

• Online Demo
• Download Source Code

With the rise in mobile devices and tablets, web applications are frequently being loaded in slow and low memory environments. When building a web application, one may consider making design choices which reduce the amount of memory consumed by your application, so that the user experience remains fast and responsive.

The general idea of reducing your application’s footprint is to reduce the amount of code in your application, thereby reducing the amount of physical memory it occupies. This includes functions, variables, event handlers, housekeeping code, etc.

Tip 1: Use One Event Listener Over Multiple Event Listeners

It is common to do the following to add event listeners to multiple nodes of the same group.

$("#list .countries").on("click", function() {
  $("box").value = this.innerHTML;
});

If your website has 100 nodes, then you are adding an event listener 100 times. That means each of those 100 nodes is modified to respond to an onclick event, and every modification consumes extra memory in the form of reference pointers and state flags.

Next time consider doing it like this:

$("#list").on("click", function() {
  if($(this).hasClass("countries")) $("box").value = this.innerHTML;
});

With this, you only need to listen to one parent node for the onclick event and saved 99 other nodes from getting fat, at the cost of a negligible amount of execution time.

Tip 2: Use Inline Event Handlers Over External Event Handlers

<div onclick="menus.activate(event);">activate</div>

This tip will certainly get some people worked up. It is taken for granted that one should migrate away from inline event handlers, because it mixes behavior with content. With no disrespect to the “best practice” reasons for not using them, you will find that inline event handlers can add a lot of savings to your footprint.

First of all, you won’t need to write event registration code (i.e., addEventListener()/removeEventListener()) which will save you several lines of code at the very least. Your application also won’t need to spend time executing your JavaScript (your event registration functions), which is much slower than native code (the DOM parser). And as a side benefit, you won’t have to worry about memory leaks due to forgetting to unregister a handler, since the handler dies with the node.

You also won’t need to assign an ID to the node in order to reach it within your code, nor do you need to walk the DOM to find that node (a method popularized by jQuery). You just saved some footprint there, as well as preventing your application from doing extra work.

And, since inline event handlers can preserve context, it allow you to conserve memory by eliminating the need to create closures to encapsulate context. You may not be aware, but whenever you wrap an event handler with an anonymous function, you are creating that closure:

node.addEventListener("click", function(e) {
  menus.activate(e);
}, false);

Some libraries hide this behind a helper function, but it is the same issue nonetheless:

node.addEventListener("click", menus.activate.bind(menus), false);

The problem escalates because some libraries will create a new anonymous function for every event handler registration, which means the number of closures will grow linearly with the number of handler registrations, which means precious memory is wasted. With inline event handlers, you don’t need to create the extra function or the closure.

<div onclick="menus.activate(event);">activate</div>

Tip 3: Use Templates Over DOM Creation

If you are creating anything other than a few nodes, it takes less code to generate a DOM tree by assigning a string of HTML to the innerHTML property, than it does to create the nodes one by one with document.createElement(). And, you don’t have to worry about your HTML content being confined within your JavaScript code, because you can hide it safely within your website, as shown below.

<body>
  <script type="text/html" id="mytemplate1">
    <div>hello</div>
  </script>
</body>

Notice how the HTML content won’t be rendered, because it is placed inside a <script> tag. The <script> tag also uses a text/html mimetype so that the browser won’t confuse it for JavaScript. You can retrieve the string with the following code.

var text = document.getElementById("mytemplate1").innerHTML;

Often times we don’t want just plain text, but want text with embedded symbols that allow for dynamic variable substitutions. That is the job of the template library and it makes DOM creation using templates much more powerful. A small template library should reduce your footprint over DOM creation code in the long run.

Tip 4: Consider Stateless Singletons over Stateful Objects

Applications are composed of components, and each component is typically a DOM node backed by a JavaScript object to store data. The more components there are, the more JavaScript objects there are. But, if you can share the same JavaScript object with multiple DOM nodes, then you can save some memory by reusing the JavaScript object. Achieving this requires designing your JavaScript objects to behave like singletons. The component will have no state, and only serve to call the singleton to perform a generic function. Alternatively, it can store some basic data as an attribute on the DOM node and the singleton can read that data from the node and act on it.

In a more complex scenario, the DOM node can store a unique ID as an attribute and the singleton can map the ID to a complex data object stored elsewhere. (Further complexity is best left for a future article.)

This technique is most suited for components where a lot of them are used at the same time such as list items, or for components which are very simple and stateless such as buttons. For example:

<input type="button" onclick="GenericButton.onclick(event);" data-command="copy">

GenericButton.onclick = function(e) {
  e = e.target || e.srcElement;
  var cmd = e.getAttribute("data-command");
  if(cmd == "copy") //...
};

Tip 5: Make Full Use of Prototypical Inheritance

If you are instantiating a lot of objects of the same type, choose prototypical inheritance over property injection. When you inject properties into an object, you are copying references onto each object. This causes the number of references to grow linearly with the number of objects.

function A() {
  this.value = 100;  //injecting value into this object
}
var obj1 = new A();
var obj2 = new A();

If you instead, allow those properties to be inherited, those references only exist once on the prototype of that object. Then, the number of references does not grow linearly unless the property’s value is modified later.

function A() {
}
A.prototype.value = 100;
var obj1 = new A();
var obj2 = new A();

Tip 6: Use the Publish-Subscribe System to Simplify Communication

Rather than use the observer pattern (e.g., addActionListener()) to communicate between components, consider using the publish-subscribe pattern to communicate between them. The publish-subscribe pattern uses less code to engage in communication and allows your application to be more decoupled, thereby not requiring as much code to maintain the coupling. There are lots of implementations of the publish-subscribe system available on the web that are thrift with memory that you can use.

Tip 7: Use Smaller Libraries When Possible

This last tip is the most obvious. Large libraries consume a lot of memory, and small libraries consume less. There is a site dedicated to showcasing tiny libraries called microjs where you may be able to find a library that just serves up your needs and nothing more.

HTML5 has introduced many new interesting APIs, including WebSockets. WebSockets allow developers to create powerful real time applications by establishing socket connections between the browser and the server. In other words both the client and server can exchange data at any time because of a persistent connection. This tutorial explains how to use WebSockets to create real time web applications.

The Problem

In real time applications, the connection between server and client must be persistent. So, in order to create an illusion of server initiated transfer long polling is usually used. WebSockets solve this issue by establishing a persistent socket connection between the client and server. Once the connection is established, it remains open until the client or server wants to close it. It significantly reduces the burden on the server and is best suited for low latency applications.

Getting Started

Opening a WebSocket connection is fairly simple. You just need to call the WebSocket() constructor to create a connection.

var connection=new WebSocket("ws://localhost:8787",['soap','json']);

ws: and wss: are the URL schemas for normal and secured WebSocket connections, respectively. The second parameter is used to define the sub protocol name which can be an array of strings or a string. However, the server will accept only one sub protocol. During the lifetime of the connection the browser will receive several events such as connection opened, message received and connection closed. To handle these events use the following code:

var connection=new WebSocket("ws://localhost:8787",'json');
connection.onopen = function () {
  connection.send('Hello, Server!!'); //send a message to server once connection is opened.
};
connection.onerror = function (error) {
  console.log('Error Logged: ' + error); //log errors
};
connection.onmessage = function (e) {
  console.log('Received From Server: ' + e.data); //log the received message
};

As soon as the connection is opened, the browser sends a message to the server using connection.send(). If an error is encountered, the above code simply logs it. If at any time the server sends a message to the browser, the onmessage callback is fired. The event handler gets an event object, with the data property of the object containing the received message.

The connection.send() method can be used to send binary data as well. To do so you can use either a Blob or an ArrayBuffer. The following code demonstrates using an ArrayBuffer to send an image drawn on canvas to server.

var image = canvas2DContext.getImageData(0, 0, 440, 300);
var binary_data = new Uint8Array(image.data.length);
for (var i = 0; i < image.data.length; i++) {
  binary_data[i] = image.data[i];
}
connection.send(binary_data.buffer);

Similarly, the received message can be a string or binary data. The binary data can be received as a blob or an arraybuffer.

Simple WebSocket Application

In order to a create a working application, you also need a server side implementation. It’s possible to use technologies like node.js, Java, .NET, Ruby, or C++ to create server side implementation. This section will show you how to create a simple application using WebSockets.

The sample application will allow the user to ask specific questions to server. The server side implementation is done using the Java jWebSocket framework on Windows 7. So, to get the environment set up follow these simple steps. I assume you have already installed the latest JDK (JDK 7)on your Windows 7 PC.

Step 1

Head over to jWebSocket Downloads and download the first zip which is marked as server.

Step 2

Unzip the archive, and place it somewhere in your C:\. Then, create a new environment variable named JWEBSOCKET_HOME, which references the root of your jWebSocket installation. This is the path to the jWebSocket-1.0 folder. Add the following JARs to your class path:

• JWEBSOCKET_HOME/libs/jWebSocketServer-1.0.jar
• JWEBSOCKET_HOME/libs/jWebSocketServerAPI-1.0.jar
• JWEBSOCKET_HOME/libs/jWebSocketCommon-1.0.jar

Step 3

Create a new Java Source file and name it SocketListener.java. Add the following code to this file.

import java.util.Date;
import java.text.SimpleDateFormat;
import org.jwebsocket.factory.JWebSocketFactory;
import org.jwebsocket.server.TokenServer;
import org.jwebsocket.kit.WebSocketServerEvent;
import org.jwebsocket.api.WebSocketServerListener;
import org.jwebsocket.api.WebSocketPacket;
import org.jwebsocket.config.JWebSocketConfig;
import org.jwebsocket.instance.JWebSocketInstance;
class JWebSocketListener implements WebSocketServerListener {
  public void processOpened(WebSocketServerEvent event) {
    System.out.println("Connection Opened");
  }
  public void processPacket(WebSocketServerEvent event, WebSocketPacket packet) {
    switch(packet.getString()){
      case "1":
        packet.setString("My Name is jWebSocketServer");
        break;
      case "2":
        packet.setString("Windows 7 64 Bit");
        break;
      case "3":
        SimpleDateFormat sdf=new SimpleDateFormat("hh:mm:ss");
        packet.setString(sdf.format(new Date()));
        break;
    }
    event.sendPacket(packet);
  }
  public void processClosed(WebSocketServerEvent event) {
  }
}
public class SocketListener{
  public static void main(String[] args){
    JWebSocketFactory.printCopyrightToConsole();
    JWebSocketConfig.initForConsoleApp(new String[]{});
    JWebSocketFactory.start();
    TokenServer server = (TokenServer)JWebSocketFactory.getServer("ts0");
    if(server!=null) {
      server.addListener(new JWebSocketListener());
    }
    while (JWebSocketInstance.getStatus() != JWebSocketInstance.SHUTTING_DOWN){
      try {
        Thread.sleep(250);
      }
      catch (InterruptedException e) {
      }
    }
  }
}

Explanation

The code implements the WebSocketServerListener interface. The interface declares the following three methods which should be implemented in our class, JWebSocketListener.

• processOpened()
• processPacket()
• processClosed()

processOpened() is called once a connection is opened. An example use of this will be starting a thread that sends updates to client in regular intervals. Similarly, processClosed() is called when the connection closes so that you can perform any clean ups.

In our application, the major processing is done in processPacket(). This method is called whenever the browser sends a message to the server. It receives two objects, of types WebSocketServerEvent and WebSocketPacket. First, we use WebSocketPacket#getString() to read the message (which is a question asked by the client). Depending on the question the server sends an answer. The message to be sent is wrapped inside a WebSocketPacket using WebSocketPacket#setString(). Then, we call WebSocketServerEvent#sendPacket(), passing the packet as an argument. Next, we create a public class called SocketListener. This class starts a WebSocket implementation server and registers our custom listener to it.

Step 4

Compile SocketListener.java, and start your server using the command java SocketListener.

Step 5

Now that you have done the server side implementation, it’s time to create the client that will interact with the server. The following is our initial HTML markup:

<html>
  <head>
    <title>WebSocket Test</title>
    <style>
      #response{
        width: 200px;
        background: #F2F2F2;
        padding: 120px 0px 120px 0px;
        font-size:18px;
      }
    </style>
  </head>
  <body>
    <div align="center">
      Choose a question to ask:
      <select id="question" name="question" onchange="sendMessage(this.value);">
        <option value="1">What's Your Name</option>
        <option value="2">Which OS You Are Running On?</option>
        <option value="3">What Time Is It?</option>
      </select>
      <br/><br/>
      <div id="response">
        My Name is jWebSocketServer
      </div>
    </div>
  </body>
</html>

Now, add the following JavaScript to the HTML:

<script type="text/javascript">
var connection = new WebSocket('ws://localhost:8787', 'json');
connection.onopen = function () {
  console.log('Connection Opened');
};
connection.onerror = function (error) {
  console.log('WebSocket Error ' + error);
};
connection.onmessage = function (e) {
  if(e.data.indexOf("subProtocol")==-1)
    document.getElementById("response").innerHTML=e.data+"<br/>";
};
function sendMessage(msg){
  connection.send(msg);
}
</script>

Explanation

We created an HTML file that allows users to choose questions from a drop down menu. When an onchange event fires, we take the value of the selected item and send that value to the server. The server then processes the request and sends back an answer to the browser. When the message from the server is received, the onmessage callback is executed, which shows the response in the response <div>. The line if(e.data.indexOf("subProtocol")==-1) is not mandatory. I have included it because initially when the connection is opened, the server sends a long string containing information to the browser. As we don’t want to show this string, I have included the above condition.

Note: Don’t directly open this HTML file. Put it in the localhost server and then access it in the browser.

Conclusion

Using the WebSocket API, you can create very powerful real time applications. But, keep in mind that cross origin communication is allowed by WebSockets. So, you should only communicate with servers and clients that you trust. The following are a few example apps that you can create with this API:

• Realtime Social Stream Updating
• HTML5 Multiplayer Games
• Online Chat Applications

Check out Mozilla Developer Network to learn more about the WebSockets API.

How do you take a nebulous idea and turn it into a game — to get from technical details, to something interesting and challenging? Well recently, I found myself wondering whether CSS transitions could be used to make some kind of game. This article is about the exploration of that idea, and its development into an elegant and (as far as I know) unique kind of game-play.

The Basic Idea

The basic idea was to animate the left and top positions of an object, using a slow transition that the player partly controls. So, we’re going to need a playing area — let’s call that the board, and an animated object — let’s call that the ball:

<body>
  <div id="board">
    <span id="ball"></span>
  </div>
</body>

The board has an aspect ratio of 3:2, while the ball is 5% of its width. Neither of those values are particularly crucial, they’re just what seemed most fitting — the aspect ratio was chosen so that it could (eventually) fit onto an iPhone screen, and the ball made relatively small so it has plenty of space to move around. The basic layout, with the ball at the top-left corner of the board is shown in the following demo.

• Demo 1: The Board and Ball

The ball has negative margins, to offset it by half its own width and height, so that whatever position we set on the ball will be its center origin (e.g. the ball in that first demo is positioned at 0,0). Here’s the CSS for that demo:

#board
{
  position:relative;
  display:block;
  width:720px;
  height:480px;
  margin:24px auto 0 auto;
  border-radius:2px;
  background:#fff;
  box-shadow:0 0 16px -2px rgba(0,0,0, 0.5);
}
#ball
{
  position:absolute;
  left:0;
  top:0;
  display:block;
  width:36px;
  height:36px;
  margin:-18px 0 0 -18px;
  border-radius:18px;
  background:#f00;
  box-shadow:inset 0 0 0 2px rgba(0,0,0, 0.35), 4px 10px 10px rgba(0,0,0, 0.15);
}

Ideally we would apply the board and ball sizes dynamically, based on the available window or screen space (this would be essential to port the game to mobile browsers), but to keep these examples simple, the dimensions are fixed — the board is 720×480 and the ball is 36×36.

The range of possible movement for the ball can now be described in percentage co-ordinates — from 0%,0% at the top-left to 100%,100% at the bottom-right. Using percentages is simpler than calculating pixels, and will allow for future flexibility in the sizes.

Now we can easily control the position by applying some simple JavaScript, that sets the left or top position according to directional key-presses, i.e. if the Left Arrow is pressed then set style.left to "0", or if the Down Arrow is pressed then set style.top to "100%":

var
ball = document.getElementById('ball'),
positions =
{
  37  : ['left', '0'],
  38  : ['top', '0'],
  39  : ['left', '100%'],
  40  : ['top', '100%']
};
document.addEventListener('keydown', function(e, data)
{
  if(data = positions[e.keyCode])
  {
    ball.style[data[0]] = data[1];
    e.preventDefault();
  }
}, false);

The positions array defines a property and value for each arrow keyCode, and is also used in the first condition to know whether an arrow-key was pressed at all, in which case we have to use preventDefault() to block its native action (so that the page can’t scroll at the same time). Again for the sake of simplicity, I haven’t done any feature-detection to filter older browsers. In practice we would want to pre-test the browser, to make sure that the transitions are fully supported. The following demo allows moving the ball to any corner.

• Demo 2: Moving The Ball

Next, let’s add a slow transition rule to animate movements. Notice the inclusion of vendor prefixes.

#ball
{
  -moz-transition:all 5s ease;
  -ms-transition:all 5s ease;
  -o-transition:all 5s ease;
  -webkit-transition:all 5s ease;
  transition:all 5s ease;
}

Now the arrow-key changes don’t trigger a snap movement, they trigger a slow and gradual movement of the ball across the board. And since each key-press only changes the left or top position (never both), the overall effect is a novel and rather elegant kind of movement — a kind of “elasticity” that would be much more complex to script:

• Demo 3: Elastic Movement

Try, for example, the following actions in that demo:

1. Refresh the page to reset the ball
2. Then press Right Arrow once
3. Wait until the ball is half-way across (after 2.5 seconds)
4. Then press Down Arrow once

Pressing Right Arrow will start a transition that moves the ball rightwards, then pressing Down Arrow will trigger a second transition that moves it downwards. But the second transition doesn’t affect the first, which will still be going, and the overall effect is a smooth curve — describing an arc from the top-center down to the bottom-right.

Refining the Game Play

We can now move the ball anywhere inside the board, using the arrow-keys to suggest a direction of movement. This provides control, but not full control, and therein lies the basic challenge that makes for a playable game. The amount of control we have also varies, because of the way the transitions are applied. For example, if the ball is at "left:0" when you press the Right Arrow, it will take five seconds to reach the right-edge (as expected). However, if the ball is already at "left:80%" when you press the Right Arrow, it will still take the full five seconds to travel that much smaller distance to the right-edge. In other words, the speed of the ball depends on how close it is to the direction you specify, when changing to that direction.

The choice of transition timing-function also makes a big difference. In these examples I’ve used the "ease" function, which equates to the following bezier curve:

[image src="http://jspro.com/files/2013/02/ease-bezier.png" caption="The "ease" timing-function represented as a bezier curve"]

The graph shows relative speed, and illustrates how it accelerates at the start, then decelerates towards the end. So the ball will move more slowly near the start and end of the transition, and this will make it slightly easier to control at those points. In fact you could make the ball almost stand still, by rapidly and continually changing its direction.

Adding the Real Challenge

We’ve got a nice playable action now, but we still don’t have a game. There has to be something challenging — something you actually have to do within that restricted control. Perhaps we can use the same transition to add that extra something?

Since we’ve already defined the transition to apply to "all" properties, we can simply extend the JavaScript so that each arrow-key also applies a change in background color, with a different bold color to correspond with each direction:

var
ball = document.getElementById('ball'),
positions =
{
  37  : ['left', '0'],
  38  : ['top', '0'],
  39  : ['left', '100%'],
  40  : ['top', '100%']
},
colors =
{
  37  : '255,0,0',
  38  : '255,255,0',
  39  : '0,0,255',
  40  : '0,255,255'
};
document.addEventListener('keydown', function(e, data)
{
  if(data = positions[e.keyCode])
  {
    ball.style[data[0]] = data[1];
    ball.style.backgroundColor = 'rgb(' + colors[e.keyCode] + ')';
    e.preventDefault();
  }
}, false);

And now, by pressing the arrow-keys, we not only change the ball’s position but also its primary color. Let’s also shift the ball’s default position to the center, and set its default color to gray (i.e. to a medium-bright color it will never have during play):

• Demo 4: Color Change

But of course, the color doesn’t instantly change, it gradually fades from one to another over the course of a single transition, passing through various intermediate shades along the way. For example, if the ball is red and then you press Right Arrow, it will change from red to blue via various shades of purple (as well as moving to the right).

Since each direction has a different color, it’s also possible for the same movement to result in different colors. For example, if you press Right Arrow then quickly press Down Arrow, the ball will travel to the bottom-right corner and fade to cyan (because cyan is mapped to down). However, if you press those keys in the opposite order (down and then right), the ball will still move to the same corner, but this time fade to blue (because blue is mapped to right). So for any given physical position, there are any number of possible shades of color that the ball might have.

And now I think, we have everything we need to make a game. If it’s difficult to fully control the ball, and difficult to get it to be a specific color, then we can create a game challenge by saying that you have to get the ball to a specific position and a specific color.

The Final Game Prototype

We’ll add a series of additional elements with different background colors — let’s call them the targets — and then add scripting that monitors the position and color of the ball. If the ball is inside a target area while it’s also the same color, then we call that a match, and the target disappears. That’s easy to describe, but it’s rather convoluted to actually script, as shown below.

var targets =
[
  { "color" : [220,180,40], "coords" : [5,5,12,35] },
  { "color" : [210,80,80], "coords" : [45,2.5,10,40] },
  { "color" : [160,90,60], "coords" : [65,5,20,20] },
  { "color" : [100,100,150], "coords" : [2.5,75,35,15] },
  { "color" : [150,70,100], "coords" : [55,65,10,20] },
  { "color" : [70,230,150], "coords" : [87.5,60,10,20] }
];
for(var len = targets.length, i = 0; i < len; i ++)
{
  var target = document.createElement('div');
  target.className = 'target';
  target.style.left = targets[i].coords[0] + '%';
  target.style.top = targets[i].coords[1] + '%';
  target.style.width = targets[i].coords[2] + '%';
  target.style.height = targets[i].coords[3] + '%';
  target.style.backgroundColor = 'rgb(' + targets[i].color.join(',') + ')';
  targets[i].target = ball.parentNode.insertBefore(target, ball);
}
var tracking = window.setInterval(function()
{
  var ballcolor = window.getComputedStyle(ball).backgroundColor.replace(/[^0-9,]/g, '').split(',');
  for(var n = 0; n < 3; n++)
  {
    ballcolor[n] = parseInt(ballcolor[n], 10);
  }
  for(var i = 0; i < targets.length; i ++)
  {
    if
    (
      ball.offsetLeft > targets[i].target.offsetLeft
      &&
      ball.offsetLeft + ball.offsetWidth < targets[i].target.offsetLeft + targets[i].target.offsetWidth
      &&
      ball.offsetTop > targets[i].target.offsetTop
      &&
      ball.offsetTop + ball.offsetHeight < targets[i].target.offsetTop + targets[i].target.offsetHeight
    )
    {
      var match = 0;
      for(var n = 0; n < 3; n ++)
      {
        if(Math.abs(ballcolor[n] - targets[i].color[n]) < 40)
        {
          match ++;
        }
      }
      if(match === 3)
      {
        targets[i].target.parentNode.removeChild(targets[i].target);
        targets.splice(i, 1);
        if(targets.length === 0)
        {
          window.clearInterval(tracking);
          window.setTimeout(function(){ alert('Yay!'); }, 250);
        }
      }
    }
  }
}, 62.5);

We have to allow for a certain amount of leeway when comparing the colors. We can’t expect the ball and target to be exactly the same (that would be all-but impossible), so we subtract one from the other and allow for a maximum difference. It’s because we need to do that, that the colors are applied using RGB, since RGB values are easier to work with programatically:

var match = 0;
for(var n = 0; n < 3; n ++)
{
  if(Math.abs(ballcolor[n] - targets[i].color[n]) < 40)
  {
    match ++;
  }
}
if(match === 3)
{
  //... all three channels are sufficiently close
}

The tracking code itself is wrapped in a single setInterval() loop, which (as far as I know) is the only way of continually monitoring the ball’s properties — using getComputedStyle() along with offset properties, to get the ball’s color and position at each iteration. The interval shouldn’t be so fast as to put excessive strain on the browser, but it does still have to be fast enough to be accurate — based on the size and speed of the ball. Since the ball is 5% of the board, and moves the whole distance in five seconds, the ball will take an average 250ms to move by its own width. So whatever proportion of that we use for the interval, will represent the maximum tracking drift as a proportion of the ball size, i.e. the maximum amount of discrepancy between the ball’s interval-calculated position, and its actual position. The speed I’ve set is 62.5ms, which gives a maximum drift of one-quarter the ball’s size. Frankly, that’s a little faster than I’d have liked, but any slower than that will not be sufficiently accurate, and could give rise to a failure to detect valid matches.

It would all be much easier if there were some kind of per-frame callback event for CSS transitions, but there isn’t — the only event we have is a transitionend event, which fires at the end of a transition, but that’s no use to us here.

But anyway — we have a game now! Try the finished prototype below and see how you get on — the object of the game is to match every target until the board is clear:

• Demo 5: Final Prototype

Beyond the Prototype

Nothing really happens when you’ve finished though, and it only has this one round! This is just a prototype, and even as it is, there are still refinements we could make. For example, if we restricted the ball’s movement so it’s not allowed to touch the edge, that would make the game-play more challenging and more edgy.

So join me soon for the second and concluding part of this article, in which we’ll look at how (and indeed, whether) we can develop this prototype further, into a finely-honed and distributable game.

In the meantime, you can download a zipfile of all this article’s demos:

• Download the demos

Data types are an essential component of every programming language, and numbers are perhaps the most important of all data types. After all, computers are really just expensive calculators. Like any worthwhile programming language, JavaScript supports numerical data. However, like many other aspects of JavaScript, numbers have several intricacies which can bite you if you’re not careful. This article explores numerical data and some of its quirks.

Note - Before reading this article, you should have a basic familiarity with JavaScript data types.

The Number Type

In JavaScript, all numbers are represented using the Number data type. This includes integers, real numbers, hexadecimal numbers, and numbers written in scientific notation. The following example verifies this by applying the typeof operator to a variety of numbers. Each application of typeof in this example returns number.

typeof(100);
typeof(3.14);
typeof(0xDEADBEEF);
typeof(7.89e2);

In the previous example, the numbers took on a variety of formats. However, internally, all JavaScript numbers are actually represented as IEEE 754 floating point data. This is important because it means that JavaScript has no concept of integers, despite the language’s parseInt() function. It also means that JavaScript math is not 100% accurate. For example, consider the following expression.

(0.1 + 0.2) === 0.3

If you are unfamiliar with floating point numbers, you would certainly expect this expression to evaluate to true. After all, 0.1 + 0.2 does equal 0.3. However, due to the way floating point numbers work, the sum is actually 0.30000000000000004. The difference is slight, but it is enough to cause the entire expression to evaluate as false.

Positive and Negative Zero

Another quirk of the IEEE 754 standard is the signed zero. This results in two zeroes – a positive zero, +0, and a negative zero, -0. This may seem strange, but the fun is just beginning. Clearly, these are two distinct values, otherwise there would only be a single zero. However, if you display either of the zeroes, the sign is dropped. For example, the following code attempts to display the two zero values, side-by-side.

alert((+0) + " " + (-0));
// displays 0 0

To make matters worse, JavaScript’s comparison operators can’t seem to tell the two values apart either, as shown in the following example.

alert((+0 === -0));
// displays true
alert((-0 < +0));
// displays false

There is a fairly simple workaround for this problem. In JavaScript, division by zero yields Infinity. Similarly, division by negative zero yields -Infinity. Therefore, to determine if a number is equal to -0, we must check that it is a zero, then perform division with it as the denominator, and check for -Infinity as shown below.

function isNegativeZero(x) {
  return (x === 0 && (1/x) === -Infinity);
}

Not-a-Number

JavaScript actually defines a number named Not-a-Number, or NaN. NaN is a falsy value that is used to represent non-numbers as numbers. This value is interesting because its very name precludes it from being a number, yet typeof(NaN) is number. NaN is also fun because it is the only value in JavaScript that does not equal itself. For example, the following code will return false.

alert((NaN === NaN));
// displays false

Instead of using the comparison operators, you can test for NaN using the isNaN() function, as shown below.

isNaN(1);
// returns false
isNaN(NaN);
// returns true

However, isNaN() is also fun because it can be misleading. If you pass in a value that can be coerced to a number, isNaN() will return false. In the following example, isNaN() is called with several values that are clearly not numbers. However, each call returns false.

isNaN(true);
isNaN(false);
isNaN("");
isNaN(null);
// all return false

A better way to check for NaN is by exploiting the fact that it is not equal to itself. The following function tests for NaN using strict inequality. This function will only return true for the value NaN.

function isNotANumber(x) {
  return x !== x;
}

Other Fun Times

There are a few other scenarios which can lead to problems with numbers. For starters, you should beware of old browsers that allow global properties like Infinity, NaN, and undefined to be redefined to new values. For example, the following code could create a lot of problems if NaN is used frequently. Luckily, modern browsers will ignore assignments to the previously mentioned properties. Strict mode goes one step further by turning these silent failures into errors.

NaN = 1;
...
isNaN(NaN);
// now returns false

Another fun to diagnose error comes from adding a number and a string. An example of this is shown below. In this case, string concatenation overrides addition. This causes foo to be converted to the string "100". The final result is the string "1001", which is much different from the expected value of 101. This type of error is more common than you think, and tends to occur when reading user input.

var foo = 100;
var bar = "1";
alert(foo + bar);
// displays "1001"

Conclusion

This article has explored some of the idiosyncrasies of numbers in JavaScript. Hopefully, you now understand why these issues arise, and how you can avoid them. And, although you may not run into cases like the negative zero very often, at least now you are prepared.

jQuery makes event handling in JavaScript easy. However, the more event handlers you define, the more memory you use, which can end up decreasing performance and making the UI sluggish. This article looks at how event delegation can help prevent this, and how you can apply event delegation with jQuery.

Event delegation is an event handling technique where, instead of attaching event handlers directly to every element you want to listen to events on, you attach a single event handler to a parent element of those elements to listen for events occurring on it’s descendant elements. When handling the event, you check which element fired the event, and respond accordingly. Event delegation relies on event bubbling in the DOM. This is the process whereby an event triggered on a child element propagates up the DOM tree to its parent element, and its parent’s parent element, etc., until the document is reached. Bubbling can also be stopped by the programmer using event.stopPropagation(). Note that not all DOM events propagate – focus, blur, load, and unload don’t.

Event delegation uses less memory because you replace multiple event handlers with a single event handler. For example, if you attach event handlers to each link in a list of ten links, you’d have ten event handlers taking up space in memory. If, instead, you use event delegation and handle events at the parent <ul> element, you only create one event handler and use less memory than you would’ve attaching to each link individually. In addition to reduced memory consumption, event delegation also has the following benefits.

• No need to manually manage events when elements are added or removed from the DOM. If we used traditional event handling, we’d have to attach event handlers to elements added to the DOM, and remove event handlers from elements removed from the DOM.
• Less code to manage, through fewer event handling functions. This can leave us with simpler code, without any duplicated event handling logic, which can help keep our JavaScript nice and DRY.

An Example of Event Delegation in jQuery

Suppose you’re developing a single page application that sells pictures of kittens. When the page loads, the first 20 kittens are displayed. As the user scrolls down the page, more kittens are loaded. Our HTML is shown below.

<section id="cats">
  <ul>
    <li>
      <img src="http://placekitten.com/200/200" alt=""/>
      <a href="/moreinfo">More info</a>
      <button>Add to cart</button>
    </li>
    ...
  </ul>
</section>

With traditional event handling, we’ll need to wire up event handlers to:

1. Display a larger picture when the user clicks on a thumbnail.
2. Display more info when the user clicks on the ‘More info’ link.
3. Add the picture to the shopping cart when the user clicks ‘Add to cart’.
4. Attach these three events to the new DOM elements that are added as the user scrolls down the page.

This code will resemble the following example. Note that this is boilerplate code intended to show how attaching event handlers to individual elements differs from using event delegation, so no implementation is given for the loadImage(), moreInfo(), addToCart(), and loadNewKittens() functions.

$(document).ready(function() {
  var cats = $('#cats');
  cats.find('img')
    .on('click', function() {
      loadImage();
    })
  cats.find('a')
    .on('click', function(event) {
      event.preventDefault();
      moreInfo();
    });
  cats.find('button')
    .on('click', function() {
      addToCart();
    });
  $(window).scroll(function() {
    var fragment = loadNewKittens();
    // attach event handlers for new DOM elements
    fragment.find('img')
      .on('click', function() {
        loadImage();
      });
    fragment.find('a')
      .on('click', function(event) {
        event.preventDefault();
        moreInfo();
      });
    fragment.find('button')
      .on('click', function() {
        addToCart();
      });
    fragment.appendTo('#cats ul');
  });
});

That’s quite a bit of code. Now let’s see how our code looks if instead we use event delegation:

$(document).ready(function() {
  $('#cats')
    .on('click', 'img, a, button', function(event) {
      event.preventDefault();
      var target = event.target;
  switch(target.tagName.toLowerCase()) {
    case 'img':
      loadImage();
      break;
    case 'a':
      moreInfo();
      break;
    case 'button':
      addToCart();
      break;
    default:
      // do nothing
  }
});
  $(window).scroll(function() {
    var fragment = loadNewKittens();
    fragment.appendTo('#cats ul');
  });
});

The key is the optional second argument to on(). By passing a selector here, on() knows it’s dealing with a delegated event handler rather than a directly bound event handler.

Our event handling code is a lot simpler now too. By getting a hold of event.target, and switching on it’s tagName, we can tell which element fired the event and can respond appropriately. Plus, we no longer have to attach event handlers for elements loaded in $(window).scroll, as the events fired by these new elements are delegated to the parent element.

A potential ‘gotcha’ to be aware of when using event delegation is that any event handlers attached to child elements are handled before the deletated event handler fires. Therefore, it’s possible for a child event handler to call event.stopPropagation() or return false, which will prevent the event from bubbling up to the delegated event handler, and leave you scratching your head as to why your event isn’t being delegated.

Conclusion

In this article we’ve looked at event delegation. We’ve seen how it can help improve the performance of your site by lessening the event handling load it has to bear. We’ve also seen how to implement event delegation in jQuery via the on() function.

jQuery is one of the most popular JavaScript libraries among web developers and designers. And, many new plugins with amazing effects are created every day. Developers and users tend to select jQuery plugins whenever possible. If you’re still on the fence about jQuery, this article will help you understand why they are so popular.

A plugin is an independent module that adds custom functionality to an application. Enabling or disabling a plugin does not affect the core system or other plugins. As developers, we tend to look for quick fixes rather than focusing on maintainable solutions. With experience we change our approach to consider maintainability and future enhancements. To understand why plugins are such an attractive option, we must first understand what life would be like without them.

Developing Without Plugins

Assume that we have been given the task of converting a menu comprised of unordered lists into a select box. This will be a very handy feature to have in our responsive web design toolkit. So, we are going to use it as our base example for understanding why we develop jQuery plugins. Let’s look at a basic jQuery implementation.

<script>
$(document).ready(function(){
  var select = $('<select>');
  $('#menu li').each(function() {
    var link  = $(this).find('> a');
    var level = $(this).parents('li').length;
    var indent = '';
    for(i=0;i<level;i++){
      indent += '-';
    }
    var option = $('<option>').text(indent + ' ' + link.text())
       .val(link.attr('href'))
       .appendTo(select);
  });
  $('#menu').replaceWith(select);
});
</script>

The code snippet above converts the unordered list items into options inside a select box. You can see that the unordered list ID is hard coded. If we wanted to convert another list to a select box, we would have to duplicate the existing code, which can be error prone. Instead, we convert the code into a function to make it reusable. The code should be similar to the following:

<script>
function convertMenusToSelect(menu){
  // Previous code with dynamic item instead of hard coding #menu
}
</script>

Now, we have a common function that we can reuse over and over again. But, suddenly a new customer requirement comes in with the following two tasks.

• Selected menu options should be highlighted in a given color.
• The indentation sign used for the sub menus should be dynamic.

The immediate solution would be to add another two parameters to the convertMenusToSelect() function to handle both color and indentation sign. However, as more requirements comes in, we will have to add additional parameters, making it hard to maintain. Instead, we can consider passing parameters as an object, as shown below.

<script>
function convertMenusToSelect(params){
}
var params={menuID: '#menu', color:'#EEE', indentMark : '#' };
convertMenusToSelect(params);
</script>

There can be both mandatory and optional parameters within the object, so we need to check for the parameters manually in order to extract the correct values. As new requirements comes in, our solution is becoming very hard to maintain. So, let’s look at a solution using a jQuery plugin and see how it handles the changing requirements.

Developing With jQuery Plugins

We started the list-to-select box converter with plain jQuery code, and converted it to a reusable function in the process. Now, let’s look at a jQuery plugin implementation using the following code.

<script>
(function($){
  $.fn.extend({
    selectConvert: function(options) {
      var defaults = {
        color: '#EEE',
        indentMark: '-',
      }
      var options =  $.extend(defaults, options);
      this.each(function() {
        var o = options;
        var currentItem = $(this);
        var select = $('<select>');
        $(currentItem).find('li').each(function() {
          var link  = $(this).find('> a');
          var level     = $(this).parents('li').length;
          var indent = '';
          for(i=0;i<level;i++){
            indent += o.indentMark;
          }
          var option = $('<option>').text(indent + ' ' + link.text())
            .val(link.attr('href')).css('background',o.color)
            .appendTo(select);
        });
        $(currentItem).replaceWith(select);
        return select;
      });
    }
  });
})(jQuery);
</script>

In the above code selectConvert will be our plugin name, and will be a separate namespace inside the jQuery.fn object. Each of the plugin methods will be placed inside the selectConvert() function. The plugin function uses a variable called options to handle the data passed on initialization. The defaults variable contains all of the allowed variables and their default values. We can also assign functions to the defaults section.

Then, we compare the defaults against the options passed to the plugin using the jQuery extend() function. The final output will contain the passed option values and default values which are not provided in the initialization. Hence, adding new parameters is not such a difficult task with jQuery plugins. Finally, we execute the conversion code with the provided options and returns the converted item.

The Importance of jQuery Plugins

We made the decision to implement a plugin due to the issues we had with the plain jQuery implementation. Now, let’s see why we prefer jQuery plugins over pure JavaScript implementations.

• Prevents Function Conflicts

  We create all the plugin related functions inside a unique namespace. So, the possibility of name conflicts is reduced with plugins.

• Extendability

  jQuery plugins automate the process of extending parameters and functions within the plugin. We can define the default parameters and functions inside the plugin and override them at runtime using extended values and functions. This reduces the work of handling required and optional parameters.

• Chainability

  I would assume chainability is the most powerful factor in jQuery plugins. In pure JavaScript we have to call functions, assign the results to variables, and pass them to the next function. With jQuery, we can call another function or plugin on the same returned results in one line of code. Consider the following code, which combines a jQuery autocomplete select box plugin with our design. You can chain together any number of functions or plugins on the same result set, making it easy to add and remove functionality dynamically.

  <script>
  $(document).ready(function() {
    $('#menu').selectConvert().combobox();
  });
  </script>
  

• Reusability

  jQuery plugins allows us to use the same functionality over multiple elements without duplicating code. We used a single menu in our initialization code as shown below.

  <script>
  $(document).ready(function() {
    $('#menu').selectConvert();
  });
  </script>
  

  Generally, we need to use two lines for converting two menus. But jQuery makes is possible to reuse the same line of initialization code for both menus as shown in the following code.

  <script>
  $(document).ready(function() {
    $('#menu,#menu2').selectConvert();
  });
  <script>
  

• Encapsulation

  We can define both public and private functions inside a jQuery plugin. Therefore, we can encapsulate the logic inside the plugin and decide which components are publicly visible and which are private to the plugin. So, plugin developers and users will only be able to call features publicly available.

• Usability

  Most of the people who uses jQuery plugins are not very experienced with JavaScript or jQuery. As developers, we need to make it as simple as possible to use the plugins. jQuery plugins provides a common initialization technique, where you can call the plugin initialization function on any compatible element. Therefore, users can just copy the initialization code and everything will work.

Conclusion

We have used one of the most basic patterns of jQuery plugins in this tutorial. There are also several advanced patterns which make it even easier to write highly maintainable and extendable code. As a developer, you might be wondering why we can’t do the same with plain JavaScript. jQuery is built using JavaScript, so JavaScript is capable of providing anything jQuery provides. However, we prefer to use jQuery since it abstracts many common tasks and allows us to focus on application logic.

It’s time to share your opinion on jQuery plugins vs pure JavaScript implementation. Do you prefer developing and using jQuery plugins? Let us know. You can also download the code used in this article from the JSPro GitHub page.

For the seventh article in the small-and-sweet functions series, I’d like you show you a function called abbreviate() — the main purpose of which I’m sure you can guess! It abbreviates a string to a specified maximum length, but it does so intelligently — ensuring that the split will never occur in the middle of a word, as well as pre-processing the string to remove extraneous whitespace.

Here’s the abbreviate function’s code:

function abbreviate(str, max, suffix)
{
  if((str = str.replace(/^\s+|\s+$/g, '').replace(/[\r\n]*\s*[\r\n]+/g, ' ').replace(/[ \t]+/g, ' ')).length <= max)
  {
    return str;
  }
  var
  abbr = '',
  str = str.split(' '),
  suffix = (typeof suffix !== 'undefined' ? suffix : ' ...'),
  max = (max - suffix.length);
  for(var len = str.length, i = 0; i &lt; len; i ++)
  {
    if((abbr + str[i]).length &lt; max)
    {
      abbr += str[i] + ' ';
    }
    else { break; }
  }
  return abbr.replace(/[ ]$/g, '') + suffix;
}

The function takes three arguments — the original input string, the maximum output length, and an optional suffix to add to the end of the abbreviated string. If the suffix is not defined then it defaults to " ..." (a space followed by three dots), which is a common and recognisable way of indicating abbreviation.

What the Function’s For

The function can be used whenever you need to limit the length of a string, as a more-intelligent alternative to a simple substr expression. There are any number of possible applications — such as processing form input, creating custom tooltips, displaying message subjects in a web-based email list, or pre-processing data to be sent via Ajax.

For example, to limit a string to 100 characters and add the default suffix, we’d call it like this:

str = abbreviate(str, 100);

Which is notionally equivalent to this substr expression:

str = str.substr(0, 96) + " ..."

But that’s a very blunt instrument, as it will often result in an output string which is split in the middle of a word. The abbreviate function is specifically designed not to do that, and will split the string before the last word rather than in the middle of it. So the output string produced by abbreviate() will often be shorter than the specified maximum — but it will never be longer.

The function also accounts for the space required by the abbreviation suffix, i.e. if the specific maximum if 100 but the suffix itself is 4 characters, then we can only use up to 96 characters of the main input string.

You can specify no suffix at all by passing an empty-string, or if you wanted to abbreviate a markup string then you can define it as an HTML close-tag. For example, the following input:

abbreviate("<p>One two three four five</p>", 15, "</p>");

Would produce this output:

<p>One two</p>

How the Function Works

The key to the abbreviate function is the ability to split an input string into individual words, then to re-compile as many of the words as will fit into the maximum length.

To make this effective, we need to ensure that the splits between words are predictable, and the simplest way to do that is by minimising internal whitespace — converting line-breaks and tabs to spaces, and then reducing contiguous spaces, so that every chunk of internal whitespace becomes a single space. There are other ways of handling that, of course — for example, we could define a more flexible regular-expression for the split, that accounts for all the different kinds of character we might find between words. There’s even a word-boundary character for regular-expressions ("\b") so we could just use that.

But I’ve found that the whitespace pre-processing is useful in its own right, especially when it comes to user input. And splitting by word-boundary doesn’t produce the desired results, since dashes, dots, commas, and most special characters in fact, count as word-boundaries. But I don’t think it’s appropriate to split the words by punctuation characters, unless the character is followed by a space, so that things like hyphenated words and code-fragments are not split in the middle.

So the function’s first job is to do that whitespace pre-processing, and then if the result is already shorter than the specified maximum, we can return it straight away:

if((str = str.replace(/^\s+|\s+$/g, '').replace(/[\r\n]*\s*[\r\n]+/g, ' ').replace(/[ \t]+/g, ' ')).length <= max)
{
  return str;
}

If we didn’t do that, then we might get cases where the string becomes abbreviated when it doesn’t have to be, for example:

abbreviate("Already long enough", 20)

Without that first condition we’d get abbreviated output, since the specified maximum has to account for the length of the suffix:

Already long ...

Whereas adding that first condition produces unmodified output:

Already long enough

So unless we return at that point, we proceed to compile the abbreviated string — splitting the input string by spaces to create individual words, then iteratively adding each word-space pair back together, for as long as the abbreviated string is shorter than the specified maximum.

Once we’ve compiled as much as we need, we can break iteration, and then trim the residual space from the end of the abbreviated string, before adding the suffix and finally returning the result. It may seem a little wasteful to right-trim that residual space, only to add it back with the default suffix, but by doing so we allow for an input suffix to have no space at all.

Conclusion

So there you have it — a simple but intelligent function for abbreviating strings, which also pre-processes the input to remove extraneous whitespace. In my experience, these two requirements are often found together, and that’s why I’ve developed the function to work this way.

Modern web applications can access a user’s browsing history using the History API. As of HTML5 you can also manipulate history entries with great flexibility. This tutorial gives an overview of JavaScript’s History API, and explains how to use this feature while designing modern web applications.

Controlling History

The History API allows developers to add, remove, and replace history entries, altering the behavior of the Back and Forward buttons. Additionally, you can extract state information and use it to manipulate the content of a document. All of this is done using the history object – a property of window.

Moving Backward and Forward

The history object offers two useful methods for cycling through user history, back() and forward(). Calling history.back() will take the user one step back in the browser’s history. This has same effect as hitting the Back button. Similarly, calling history.forward() has the same effect as pressing the browser’s Forward button.

Moving to a Specific History Point

The history object provides another method, go(), which takes the user to a specific history point. For example, if you call history.go(-3) it will take the user back three pages. Similarly, calling history.go(3) will take the user three pages forward. Calling history.go(-1) and history.go(1) have the same effects as calling history.back() and history.forward(), respectively.

Note: IE allows developers to pass URLs to go(). However, this is not standard, and should be avoided.

Counting the Number of History Entries

The number of pages in history can be found by accessing the history object’s length property, as shown below.

alert(history.length);

Manipulating History Entries

The history object provides two methods, pushState() and replaceState(), for adding and replacing history entries.

Using pushState()

Let’s say the following code is executed on http://localhost/index.html:

history.pushState({page:2},"Page 2","page2.html");

This will cause the browser to change the URL of the current page to http://localhost/page2.html. But, it will not change the content of the page or reload it. The browser won’t even check that page2.html exists. It will simply display the URL in the address bar.

Now, suppose you visit http://jspro.com and hit the Back button. The browser will load http://localhost/page2.html as it was added to the history stack previously. As the page is loaded, it will also receive a popstate event. In the above JavaScript code we passed an object to pushState() as the first argument (this is known as state object). We can retrieve this object from the popstate event’s state property and use it to manipulate the content of the document.

The pushState() method takes the following three parameters:

1. State Object – This object is associated with the new history entry that’s being added to the stack.
2. Title – The title of the new history entry. Currently Firefox ignores this parameter, but it may be used in future.
3. URL – The URL to display to the user. It can be absolute or relative, but the URL should be of same origin as the current URL. Otherwise, the method will throw an exception.

To reinforce the concept of pushing states, assume we have three pages: index.html, page1.html, and page2.html. The HTML content of index.html is shown below.

<html>
  <head>
    <title>Demo Page</title>
    <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.9.0/jquery.min.js"></script>
  </head>
  <body>
    <input type="button" id="push" value="Push History"/>
  </body>
</html>

Now the following JavaScript code is added to the document:

$(document).ready(function(){
  $("#push").click(function(){
    history.pushState({page: 1},"Page 1","page1.html");
    history.pushState({page: 2},"Page 2","page2.html");
  });
});

The following JavaScript code is added to page2.html:

$(document).ready(function(){
  window.onpopstate=function(event){
  alert("location: "+document.location+" and state: "+event.state.page);
  }
});

If you load http://localhost/index.html and click the Push History button, it will add two history entries and cause the browser to display the URL http://localhost/page2.html. However, the content of page will not change. If you navigate to some other page and then press the Back button, the browser will load page2.html. The page will also receive a popstate event. The state property of this event will contain a copy of the state object used while adding the history entry with history.pushState().

If you again press the Back button again, the URL will change to http://localhost/page1.html and another popstate event will be received by page2.html. Note that although the URL is changed to page1.html, the content of page2.html is displayed.

Using replaceState()

history.replaceState() acts in the same way as history.pushState(), but it modifies the current history entry instead of adding a new one.

Practical Usage

When you click on a specific photo in a Facebook album you can see that the URL changes and a picture is displayed. All of this happens without reloading the page.

Also check out the Chrome Web Store. When you click on a specific app, all the details of the app are shown in a modal window, and the URL of the page changes. The point is that each app has its own URL that users can bookmark.

We can implement a similar functionality using the History API. In this example, we will create a simple photo gallery. If the user clicks on a specific photo, the picture opens up in a light box style. We enhance the functionality by giving each photo its own URL. When a picture opens, the URL of the page is changed to reflect the currently opened picture’s address.

Step 1

We start by creating a simple HTML page and adding a few images to it, as shown below. Note that I have included prettyPhoto, a jQuery plugin for creating a lightbox effect.

demo.html

<html>
  <head>
    <title>Demo Page</title>
    <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.9.0/jquery.min.js"></script>
    <script src="js/jquery.prettyPhoto.js" charset="utf-8"></script>
    <link rel="stylesheet" href="css/prettyPhoto.css"/>
    <script type="text/javascript" src="customurl.js" charset="utf-8"></script>
  </head>
  <body>
    <div align="center">
      <a href="/demos/history/pics/image1.jpg" rel="prettyPhoto" id="1"><img src="pics/image1.jpg" height="300"
      width="300"/></a>
      <a href="/demos/history/pics/image2.jpg" rel="prettyPhoto" id="2"><img src="pics/image2.jpg" height="300"
      width="300"/></a>
      <a href="/demos/history/pics/image3.jpg" rel="prettyPhoto" id="3"><img src="pics/image3.jpg" height="300"
      width="300"/></a>
      <a href="/demos/history/pics/image4.jpg" rel="prettyPhoto" id="4"><img src="pics/image4.jpg" height="300"
      width="300"/></a>
    </div>
  </body>
</html>

Step 2

We proceed to add some JavaScript to the page. The content of customurl.js, which is included in the page, is shown below. First, we create a photo gallery by initializing prettyPhoto. Next, when the user clicks on a link, we grab the image number and create a fake image URL based on the number. Then we push it onto the history stack. Similarly, when the user closes an image we pop the current history entry from the stack. As a result the original URL comes back to address bar.

$(document).ready(function(){
  $("a[rel^='prettyPhoto']").prettyPhoto({
    callback: function(){history.pushState("","","/demos/history/demo.html"); document.title="Demo Page";}
  });
  $("a").click(function(){
    var id=$(this).attr("id");
    var img="image"+id;
    var url="images/"+img+"/";
    history.pushState("","",url);
    document.title=img;
  });
  function getParameter(name){
    if(name=(new RegExp('[?&]'+encodeURIComponent(name)+'=([^&]*)')).exec(location.search))
      return decodeURIComponent(name[1]);
  }
  var image=getParameter("id");
  if(typeof image !='undefined'){
    var event=document.createEvent('MouseEvents');
    event.initEvent('click',true,true);
    document.getElementById(image).dispatchEvent(event);
  }
});

Step 3

What if a user directly accesses the fake image URL? The browser will send a 404 error indicating that the page was not found. To overcome this, we create a server side PHP script. The script gets the image number from the request and redirects the user to demo.html, appending the image number as a query string parameter.

In our JavaScript code inside demo.html, we have defined the getParameter() function which searches the URL to find the image number. We have already given our photo gallery links specific id attributes which represent the image number. If the image number is found from the URL, we create a click event programmatically on the particular link. As a result, the image is displayed with lightbox effect.

You can find a complete working demo here.

Further Reading

You can visit the Mozilla Developer Network to learn more about the History API. Also, check out the history object to learn more about its properties and methods.

The <canvas> element, introduced in HTML5, allows developers to dynamically create bit map graphics using JavaScript. In this tutorial you will learn about some of the basic operations supported by the <canvas> element and create a simple animation using JavaScript.

Canvas was first introduced by Apple in 2004 for use in Mac OS X and Safari. Now it has been adopted by every major browser. Current versions of Mozilla Firefox, Chrome, Opera, Safari, and IE 9 and 10 all support the <canvas> element.

How To Use Canvas

The following code adds a <canvas> element.

<canvas id="canvasDemo" height="400" width="300">
Sorry, your browser does not support canvas.
</canvas>

The id attribute is used so that we can access the <canvas> element from JavaScript. The height and width attributes are used to size the canvas. Whatever you write inside the <canvas> tag will appear if the browser does not support canvases. This acts as a fallback for older browsers. From JavaScript we can access the <canvas> element as shown below.

var canvas=document.getElementById("canvasDemo");
var context=canvas.getContext("2d");

The following example shows how to draw a line on the canvas. The code draws a straight line from coordinate (30, 40) to (145, 120), with the upper left corner of the canvas acting as coordinate (0, 0). It should be noted that <canvas> elements do not maintain any DOM. As a result if you want to alter anything on the canvas, you will probably have to redraw the whole thing.

var canvas=document.getElementById("canvasDemo");
var context=canvas.getContext("2d");
context.strokeStyle="green";
context.moveTo(30,40);
context.lineTo(145,120);
context.stroke();

The modified canvas is shown in the following figure.

[image src="http://jspro.com/files/2013/01/line.png"]

Drawing Basic Shapes

Before moving on to animations, you need to understand the basic shapes that can be drawn on canvas. We will need these basic shapes every time we want to create something. Let’s start with the following operations related to rectangles.

• fillRect(x,y,width,height);
• clearRect(x,y,width,height);
• strokeRect(x,y,width,height);

The first two parameters of each function represent the coordinates of the upper left corner of the rectangle. The next two parameters specify the width and height of the rectangle. Consider the following JavaScript snippet:

var context=document.getElementById("canvasDemo").getContext("2d");
context.strokeStyle="green";
context.fillStyle="red";
context.strokeRect(70,70,80,80);
context.fillRect(80,80,60,60);
context.clearRect(95,95,30,30);

It produces the following output:

[image src="http://jspro.com/files/2013/01/Rectangles.png"]

As you can see, the fillRect() method creates a rectangle and fills it with the color specified by the context.fillStyle property. clearRect() clears a rectangular portion from the canvas, and strokeRect() draws a rectangular outline whose color is determined by the context.strokeStyle property.

Drawing Lines

Lines can be drawn using the lineTo() function. The method takes two parameters which represent the coordinates of the end point. To draw a line you need to first call moveTo(), which represents the starting point of line. The first example in this article draws a line in this fashion.

Drawing Arcs

An arc is drawn using the arc() function, shown below.

arc(x,y,radius,startAngle,endAngle,direction);

The first two parameters represent the center’s coordinate. startAngle represents the starting angle for the arc. To create a circle, set this to zero. The endAngle determines the angle at which the arc ends. While drawing a circle you will set this to 360 degrees. For a semi circle it should be 180 degrees. Note that the angles should be specified in radians. Therefore, you should use the Math.PI constant to convert from degrees. Finally, the direction parameter denotes, whether the arc should be drawn clockwise or counterclockwise.

Consider the following snippet:

var ctx = document.getElementById('canvasDemo').getContext('2d');
ctx.arc(180,180,70,0,Math.PI,true);
ctx.stroke();

It produces the following output.

[image src="http://jspro.com/files/2013/01/arc2.png"]

However, if you want to change the direction to clockwise then you need to call arc() with the last argument set to false. This results in the following output.

[image src="http://jspro.com/files/2013/01/arc1.png"]

Drawing Paths

Usually a path consists of several shapes. Each path is internally represented by a list of sub paths like rectangles, lines, or arcs. Paths can be drawn using the following functions.

• beginPath()
• closePath()
• stroke()
• fill()

Every path maintains a list of sub paths. When beginPath() is called this list is reset and we can start drawing different shapes for the path. The following example shows the path functions in action.

var ctx = document.getElementById("canvasDemo").getContext("2d");
ctx.beginPath();
ctx.arc(180,180,70,0,Math.PI*2,true);
ctx.moveTo(230,180);
ctx.arc(180,180,50,0,Math.PI,false);
ctx.moveTo(155,150);
ctx.arc(150,150,5,0,Math.PI*2,true);
ctx.moveTo(215,150);
ctx.arc(210,150,5,0,Math.PI*2,true);
ctx.fillText("Happy", 165, 270);
ctx.stroke();

The resulting canvas is shown below.

[image src="http://jspro.com/files/2013/01/happy-face.png"]

Drawing Images

Drawing an image on canvas is pretty easy. You can create an Image object and draw it on the canvas as shown below.

var ctx = document.getElementById("canvasDemo").getContext("2d");
var img =new Image();
img.onload=function(){
  ctx.drawImage(img,15,25);
}
img.src="myImg.png";

Another way is to add an image to your document and make it invisible. In JavaScript we can access it by id and draw it as shown below.

var ctx = document.getElementById("canvasDemo").getContext("2d");
var img = document.getElementById("myimage");
ctx.drawImage(img,0,0);

For a complete tutorial about drawing basic shapes you can refer to the Mozilla Developer Network documentation.

Creating a Bouncing Ball Application

This example will create an application containing a bouncing ball. You need to catch the ball with a paddle when it reaches the bottom of the screen. We will use the setTimeout() function to create the animation. We already know that whatever you draw on canvas persists until you clear it. So, to make an object move on canvas you need to call a function periodically that clears the canvas and updates the position of the object.

In our case, a custom draw() function will be called every ten milliseconds. It will clear the entire canvas and update x and y coordinates of the ball. This gives the illusion that the ball is moving continuously.

Place the following JavaScript code in a file named bouncingball.js.

var canvas;
var ctx;
var dx = 1;
var dy = 2;
var bar=new Bar(400,500);
var circle=new Circle(400,30,10);
var dxBar=6;
var timer;
var barImg;
function Bar(x,y){
  this.x=x;
  this.y=y;
}
function Circle(x,y,r){
  this.x=x;
  this.y=y;
  this.r=r;
}
function drawBall(c) {
  ctx.beginPath();
  ctx.arc(c.x, c.y, c.r, 0, Math.PI*2, true);
  ctx.fill();
}
function doKeyDown(e){
  if(e.keyCode==37){
    if(bar.x-dxBar>0)
      bar.x-=dxBar;
  }
  else if(e.keyCode==39){
    if(bar.x+dxBar<canvas.width)
      bar.x+=dxBar;
  }
}
function init() {
  window.addEventListener("keydown",doKeyDown,false);
  barImg=document.getElementById("bar");
  canvas = document.getElementById("canvas");
  ctx = canvas.getContext("2d");
  timer=setInterval(draw, 10);
  return timer;
}
function draw() {
  ctx.clearRect(0, 0, canvas.width, canvas.height);
  ctx.fillStyle = "#FAF7F8";
  ctx.fillRect(0,0,canvas.width,canvas.height);
  ctx.fillStyle = "#003300";
  drawBall(circle);
  if (circle.x +dx > canvas.width || circle.x +dx < 0)
    dx=-dx;
  if(circle.y+dy>bar.y && circle.x>bar.x && circle.x<bar.x+barImg.width)
    dy=-dy;
  if (circle.y +dy > canvas.height || circle.y +dy < 0)
    dy=-dy;
  circle.x += dx;
  circle.y += dy;
  ctx.drawImage(barImg,bar.x,bar.y);
  if(circle.y>bar.y){
    clearTimeout(timer);
    ctx.clearRect(0, 0, canvas.width, canvas.height);
    alert("Game Over");
  }
}

The HTML document which includes the JavaScript code is shown below.

<!doctype html>
<html>
  <head>
    <title>Canvas Demo</title>
    <script type="text/javascript" src="bouncingball.js"/>
  </head>
  <body onload="init();">
    <div>
      <canvas id="canvas" width="800" height="600">
      Sorry, browser does not support canvas.
      </canvas>
    </div>
    <img src="bar.png" id="bar" style="display:none"/>
  </body>
</html>

You can try out the game via the online demo. Note that several optimizations and improvements can be done on this game. First we begin by defining two objects, ball and bar. The bar can reflect the ball when it reaches the bottom of the screen. The variables dx and dy determine how fast the ball moves along the x-axis and y-axis, respectively. dxBar represents how fast the bar moves along the x-axis.

The init() function is called when the body is loaded. Next, we register an event listener which listens for keydown events. If the user presses the left arrow we shift the x value of the bar by dxBar pixels left. If the user presses the right arrow we shift the bar to the right.

Then we initialize the canvas and get a 2D context which initializes the ctx variable. After that, we register the draw() function with setTimeout() so that it will be called every ten milliseconds.

Every time draw() is executed, we clear the canvas and draw the updated ball and bar. Inside the function we check whether the ball collides with the bar. If so, the ball bounces back. If the ball gets off screen, the canvas is cleared and the animation stops, ending the game.

Where To Go From Here

If you’re interested in improving the game, check out the guide to optimizing canvases. You could also use requestAnimationFrame() to perform animation. It instructs the browser to schedule a repaint of the window so that the next animation frame can be rendered. Unfortunately, it’s an experimental technology and its specification has not stabilized yet. You should also learn about various transformations that can be done on the canvas and check out a few animations in MDN.