I’ve never been particularly complimentary about the official jQuery Plugin Registry. The team are working on it, but perhaps the kindest observation is that it’s “ctional” — functional with all the “fun” removed. The system lacks an easy interface, good search facilities, online demonstrations, developer ratings and reviews.

As an alternative, why not try unheap.com — a new independent jQuery plugin repository…

The benefits of unheap.com become apparent the moment you use it:

• The site has a gorgeous dynamic and responsive interface — it’s a pleasure to use
• Plugins are categorized in sections and sub-sections for interface, inputs, media, navigation and miscellaneous code.
• The search facility works well.
• Plugin lists have direct links to demonstration pages and videos.
• Related plugins are listed.
• User views, votes and bug reports are recorded.
• Social media sharing facilities are provided.
• An RSS feed of new and updated plugins is available for you to check in Google Reader, erm, a compatible RSS Reader.
• The plugin submission process is easy and straight-forward.
• Almost 700 plugins are available at the time of writing.

I’m impressed. Unless the jQuery team can produce a system as nice as unheap.com, perhaps they should give up now and adopt it as the “official” repository?

Unless you’ve found something better?…

In part 1 we took a look at some of the UI layout implementation details of the InstaFuzz app.  You can get the source code for the app from here if you wish to run it locally.  In this installment we’ll take a look at some of the other bits such as how drag/drop, File API, Canvas and Web Workers are used.

Drag/Drop

One of the things that InstaFuzz supports is the ability to drag and drop image files directly on to the big blackish/blue box.  Support for this is enabled by handling the “drop” event on the CANVAS element.  When a file is dropped onto an HTML element the browser fires the “drop” event on that element and passes in a dataTransfer object which contains a files property that contains a reference to the list of files that were dropped.  Here’s how this is handled in the app (“picture” is the ID of the CANVAS element on the page):

var pic = $("#picture");
pic.bind("drop", function (e) {
    suppressEvent(e);
    var files = e.originalEvent.dataTransfer.files;
    // more code here to open the file
});
 
pic.bind("dragover", suppressEvent).bind("dragenter", suppressEvent);
 
function suppressEvent(e) {
    e.stopPropagation();
    e.preventDefault();
}

The files property is a collection of File objects that can then subsequently be used with the File API to access the file contents (covered in the next section).  We also handle the dragover and dragenter events and basically prevent those events from propagating to the browser thereby preventing the browser from handling the file drop.  IE for instance might unload the current page and attempt to open the file directly otherwise.

File API

Once the file has been dropped, the app attempts to open the image and render it in the canvas.  It does this by using the File API.  The File API is a W3C specification that allows web apps to programmatically access files from the local file system in a secure fashion.  In InstaFuzz we use the FileReader object to read the file contents as a data URL string like so using the readAsDataURL method:

var reader = new FileReader();
reader.onloadend = function (e2) {
    drawImageToCanvas(e2.target.result);
};
reader.readAsDataURL(files[0]);

Here, files is the collection of File objects retrieved from the function handling the “drop” event on the CANVAS element. Since we are interested only in a single file we simply pick the first file from the collection and ignore the rest if there are any.  The actual file contents are loaded asynchronously and once the load completes, the onloadend event is fired where we get the file contents as a data URL which we then subsequently draw on to the canvas.

Rendering the filters

Now the core functionality here is of course the application of the filters.  In order to be able to apply the filter to the image we need a way to access the individual pixels from the image.  And before we can access the pixels we need to have actually rendered the image on to our canvas.  So let’s first take a look at the code that renders the image that the user picked on to the canvas element.

Rendering images on to the canvas

The canvas element supports the rendering of Image objects via the drawImage method.  To load up the image file in an Image instance, InstaFuzz uses the following utility routine:

App.Namespace.define("InstaFuzz.Utils", {
    loadImage: function (url, complete) {
        var img = new Image();
        img.src = url;
        img.onload = function () {
            complete(img);
        };
    }
});

This allows the app to load up image objects from a URL using code such as the following:

function drawImageToCanvas(url) {
    InstaFuzz.Utils.loadImage(url, function (img) {
        // save reference to source image
        sourceImage = img;
 
        mainRenderer.clearCanvas();
        mainRenderer.renderImage(img);
 
        // load image filter previews
        loadPreviews(img);
    });
}

Here, mainRenderer is an instance created from the FilterRenderer constructor function defined in filter-renderer.js.  The app uses FilterRenderer objects to manage canvas elements – both in the preview pane as well as the main canvas element on the right.  The renderImage method on the FilterRenderer has been defined like so:

FilterRenderer.prototype.renderImage = function (img) {
    var imageWidth = img.width;
    var imageHeight = img.height;
    var canvasWidth = this.size.width;
    var canvasHeight = this.size.height;
    var width, height;
 
    if ((imageWidth / imageHeight) >= (canvasWidth / canvasHeight)) {
        width = canvasWidth;
        height = (imageHeight * canvasWidth / imageWidth);
    } else {
        width = (imageWidth * canvasHeight / imageHeight);
        height = canvasHeight;
    }
 
    var x = (canvasWidth - width) / 2;
    var y = (canvasHeight - height) / 2;
    this.context.drawImage(img, x, y, width, height);
};

That might seem like a lot of code but all it does ultimately is to figure out the best way to render the image in the available screen area considering the aspect ratio of the image.  The key piece of code that actually renders the image on the canvas occurs on the last line of the method.  The context member refers to the 2D context acquired from the canvas object by calling its getContext method.

Fetching pixels from the canvas

Now that the image has been rendered we will need access to the individual pixels in order to apply all the different filters that are available.  This is easily acquired by calling getImageData on the canvas’s context object.  Here’s how InstaFuzz calls this from instafuzz.js.

var imageData = renderer.context.getImageData(
    0, 0,
    renderer.size.width,
    renderer.size.height);

The object returned by getImageData provides access to the individual pixels via its data property which in turn is an array like object that contains a collection of byte values where each value represents the color rendered for a single channel of a single pixel.  Each pixel is represented using 4 bytes that specify values for the red, green, blue and alpha channels.  It also has a length property that returns the length of the buffer.  If you have a 2D co-ordinate you can easily transform that into an index into this array using code such as the following.  The color intensity values of each channel ranges from 0 through 255.  Here’s the utility function from filters.js that accepts as input an image data object along with 2D coordinates for the pixel the caller is interested in and returns an object containing the color values:

function getPixel(imageData, x, y) {
    var data = imageData.data, index = 0;
 
    // normalize x and y and compute index
    x = (x < 0) ? (imageData.width + x) : x;
    y = (y < 0) ? (imageData.height + y) : y;
    index = (x + y * imageData.width) * 4;
 
    return {
        r: data[index],
        g: data[index + 1],
        b: data[index + 2]
    };
}

Applying the filters

Now that we have access to the individual pixels, applying the filter is fairly straightforward.  Here, for instance is the function that applies a weighted grayscale filter on the image.  It simply picks intensities from the red, green and blue channels and sums them up after applying a multiplication factor on each channel and then assigns the result for all 3 channels.

// "Weighted Grayscale" filter
Filters.addFilter({
    name: "Weighted Grayscale",
    apply: function (imageData) {
        var w = imageData.width, h = imageData.height;
        var data = imageData.data;
        var index;
        for (var y = 0; y < h; ++y) {
            for (var x = 0; x < w; ++x) {
                index = (x + y * imageData.width) * 4;
                var luminance = parseInt((data[index + 0] * 0.3) +
                                         (data[index + 1] + 0.59) +
                                         (data[index + 2] * 0.11));
                data[index + 0] = data[index + 1] =
                    data[index + 2] = luminance;
            }
 
            Filters.notifyProgress(imageData, x, y, this);
        }
 
        Filters.notifyProgress(imageData, w, h, this);
    }
});

Once the filter has been applied we can have that reflected on the canvas by calling the putImageData method passing in the modified image data object.  While the weighted grayscale filter is fairly simple most of the other filters use an image processing technique known as convolution.  The code for all the filters is available in filters.js and the convolution filters were ported from the C code available here.

Web Workers

As you might imagine doing all this number crunching to apply the filters can potentially take a long time to complete.  The motion blur filter for instance uses a 9×9 filter matrix for computing the new value for every single pixel and is in fact the most CPU intensive filter among them all.  If we were to do all this computation on the UI thread of the browser then the app would essentially freeze every time a filter was being applied.  To provide a responsive user experience the app delegates the core image processing tasks to a background script using the support for W3C Web Workers in modern browsers.

Web workers allow web applications to have scripts run in a background task that executes in parallel along with the UI thread.  Communication between the worker and the UI thread is accomplished by passing messages using the postMessage API.  On both ends (i.e. the UI thread and the worker) this manifests as an event notification that you can handle.  You can only pass “data” between workers and the UI thread, i.e., you cannot pass anything that has to do with the user interface  – you cannot for instance, pass DOM elements to the worker from the UI thread.

In InstaFuzz the worker is implemented in the file filter-worker.js.  All it does in the worker is handle the onmessage event and apply a filter and then pass the results back via postMessage.  As it turns out, even though we cannot pass DOM elements (which means we cannot just hand a CANVAS element to the worker to have the filter applied) we can in fact pass the image data object as returned by the getImageData method that we discussed earlier. Here’s the filter processing code from filter-worker.js:

importScripts("ns.js", "filters.js");
 
var tag = null;
onmessage = function (e) {
    var opt = e.data;
    var imageData = opt.imageData;
    var filter;
 
    tag = opt.tag;
    filter = InstaFuzz.Filters.getFilter(opt.filterKey);
 
    var start = Date.now();
    filter.apply(imageData);
    var end = Date.now();
 
    postMessage({
        type: "image",
        imageData: imageData,
        filterId: filter.id,
        tag: tag,
        timeTaken: end - start
    });
}

The first line pulls in some script files that the worker depends on by calling importScripts.  This is similar to including a JavaScript file in a HTML document using the SCRIPT tag.  Then we set up a handler for the onmessage event in response to which we simply apply the filter in question and pass the result back to the UI thread by calling postMessage.  Simple enough!

The code that initializes the worker is in instafuzz.js and looks like this:

var worker = new Worker("js/filter-worker.js");

Not much is it?  When a message is sent by the worker to the UI thread we handle it by specifying a handler for the onmessage event on the worker object.  Here’s how this is done in InstaFuzz:

worker.onmessage = function (e) {
    var isPreview = e.data.tag;
    switch (e.data.type) {
        case "image":
            if (isPreview) {
                previewRenderers[e.data.filterId].
                    context.putImageData(
                        e.data.imageData, 0, 0);
            } else {
                mainRenderer.context.putImageData(
                    e.data.imageData, 0, 0);
            }
 
            break;
        // more code here
    }
};

The code should be fairly self-explanatory.  It simply picks the image data object sent by the worker and applies it to the relevant canvas’s context object causing the modified image to be rendered on screen.  Scheduling a filter for conversion with the worker is equally simple.  Here’s the routine that performs this function in InstaFuzz:

function scheduleFilter(filterId,
                             renderer,
                             img, isPreview,
                             resetRender) {
    if (resetRender) {
        renderer.clearCanvas();
        renderer.renderImage(img);
    }
 
    var imageData = renderer.context.getImageData(
        0, 0,
        renderer.size.width,
        renderer.size.height);
 
    worker.postMessage({
        imageData: imageData,
        width: imageData.width,
        height: imageData.height,
        filterKey: filterId,
        tag: isPreview
});
}

Wrapping it up

The source for InstaFuzz is available for download here.  We saw that fairly intricate user experiences are possible today with HTML5 technologies such as Canvas, Drag/Drop, File API and Web Workers.  Support for all of these technologies is quite good in pretty much all modern browsers.  One thing that we did not address here is the question of making the app compatible with older browsers.  That, truth be told, is a non-trivial but necessary task that I will hopefully be able to talk about in a future article.

When I started out on this app I was only really just interested in seeing if the web platform had really evolved to a point where an app like the hugely popular Instagram app could be built using just HTML, JavaScript and CSS.

As it turns out we can in fact do exactly that.  This article walks you through the technologies that make this possible and shows how it is entirely feasible today to build interoperable web applications that provide a great user experience no matter what brand of browser the user is running.

If you happen to be one of the two or so people who have not heard about Instagram then you might be pleased to hear that it is a hugely popular photo sharing and social networking service that allows you to take pictures, apply interesting digital filters on them and share them with the world.  The service became so popular that it was acquired by Facebook for a bag full of cash and stock in April of 2012.

InstaFuzz is the name of the app I put together and while I don’t expect to be acquired by Facebook or anybody else for a billion green it does, however, make the case that an app such as this one can be built using only standards compliant web technologies such as Canvas, File API, Drag/Drop, Web Workers, ES5 and CSS3 and still manage to run well on modern browsers such as Internet Explorer 10, Google Chrome and Firefox.  And you could easily use the code to build a Windows Store app too.

About the app

If you’d like to take a look at the app, then here’s where it is hosted:

http://blogorama.nerdworks.in/arbit/InstaFuzz/

As soon as you load it up, you’re presented with a screen that looks like this:

The idea is that you can load up a photograph into the app either by clicking on the big red “Add” button on the bottom left hand corner or drag and drop an image file into the blackish/blue area on the right. Once you do that you get something that looks like this:

You’ll note that a list of digital filters listed on the left of the screen shows a preview of what the image would look like if you were to apply the said filter.  Applying a filter is a simple matter of clicking on one of the filter previews on the left.  Here’s what it looks like after applying the “Weighted Grayscale” filter followed by a “Motion Blur”.  As you can tell filters are additive – as you keep clicking on filters, they are applied on top of what was applied earlier:

Let’s next take a look at how the UI layout has been put together.

UI Layout

The HTML markup is so little that I can actually reproduce the contents of the BODY tag in its entirety here (excluding the SCRIPT includes):

<header>
    <div id="title">InstaFuzz</div>
</header>
<section id="container">
    <canvas id="picture" width="650" height="565"></canvas>
    <div id="controls">
        <div id="filters-list"></div>
        <button id="loadImage">Add</button>
        <input type="file" id="fileUpload"
           style="display: none;"
           accept="image/gif, image/jpeg, image/png" />
    </div>
</section>
&nbsp;
<!-- Handlebar template for a filter UI button -->
&nbsp;
<script id="filter-template" type="text/x-handlebars-template">
    <div data-filter-id="{{filterId}}">
        <div>{{filterName}}</div>
        <canvas width="128" height="128"></canvas>
    </div>
</script>

There’s nothing much going on here.  Pretty much everything should be standard fare.  I will however draw attention to the fact that I am using the Handlebars JavaScript templating system here for rendering the markup for the list of filters on the left of the screen.  The template markup is declared in the HTML file (the SCRIPT tag in the snippet shown above) and then used from JavaScript.  The template markup is then bound to a JavaScript object that supplies the values for handlebars expressions such as {{filterId}} and {{filterName}}.  Here’s the relevant piece of JS from the app with a bit of DOM manipulation help from jQuery:

var templHtml = $("#filter-template").html(),
    template = Handlebars.compile(templHtml),
    filtersList = $("#filters-list");
 
var context = {
    filterName: filter.name,
    filterId: index
};
 
filtersList.append(template(context));

As you can tell from the HTML markup, all the filter preview boxes feature a CANVAS tag, as does the big box on the right where the final output is rendered.  We’ll go into a bit more detail later on in the article as to how canvas technology is used to achieve these effects.

The app also uses CSS3 @font-face fonts to render the text in the header and the “Add” button.  The fonts have been taken from the excellent Font Squirrel site and here’s what the declaration looks like:

@font-face {
    font-family: 'TizaRegular';
    src: url('fonts/tiza/tiza-webfont.eot');
    src: url('fonts/tiza/tiza-webfont.eot?#iefix')
           format('embedded-opentype'),
         url('fonts/tiza/tiza-webfont.woff') format('woff'),
         url('fonts/tiza/tiza-webfont.ttf') format('truetype'),
         url('fonts/tiza/tiza-webfont.svg#TizaRegular') format('svg');
    font-weight: normal;
    font-style: normal;
}

This directive causes the user agent to embed the font in the page and make it available under the name assigned to the font-family rule which in this case is “TizaRegular”.  After this we can assign this font to any CSS font-family rule like how we normally do.  In InstaFuzz I use the following rule to assign the font to the header element:

font-family: TizaRegular, Cambria, Cochin, Georgia, Times,
    "Times New Roman", serif;

You might also have noticed that there is a subtle shadow being dropped on the page by the container element.

This is made possible using the CSS3 box-shadow rule and here’s how it’s used in InstaFuzz.

-moz-box-shadow: 1px 0px 4px #000000, -1px -1px 4px #000000;
-webkit-box-shadow: 1px 0px 4px #000000, -1px -1px 4px #000000;
box-shadow: 1px 0px 4px #000000, -1px -1px 4px #000000;

This causes the browser to render a shadow around the relevant element.  Each comma separated section in the value specifies the following attributes of the shadow:

1. Horizontal offset
2. Vertical offset
3. Spread distance – positive values have the effect of softening the shadow
4. Shadow color

One can specify multiple shadow values separated by comma as in fact has been done above.  Note that I’ve also specified the shadow using vendor prefix syntax for Firefox and Chrome/Safari using the moz and webkit prefixes.  This causes the shadow to continue to work in versions of those browsers where support for this capability was provided using the vendor prefixed version of the rule.  Note that the W3C version of the rule – box-shadow – is specified last.  This is done deliberately to ensure that in case the browser supports both the forms then only the W3C behavior is actually applied to the page.

One often finds that web developers either fail to include vendor prefixed version of a given CSS3 rule for all the browsers that support that rule and/or fail to include the W3C version as well.  Often developers just put the webkit version of the rule ignoring other browsers and the W3C standard version.  This causes two problems – [1] poor user experience for users who are using non-webkit browsers and [2] it ends up resulting in webkit becoming a de-facto standard for the web.  Ideally we want W3C to be driving the future of the web and not one specific browser implementation.  So here are some things to remember when playing with experimental implementations of CSS features:

1. Use vendor prefixed versions of CSS rules by all means but remember to specify the rule for all supported browsers and not just the one that you happen to be testing the page in (if you’re using Visual Studio to edit your CSS then you might be interested in the supremely excellent extension for Visual Studio called Web Essentials that makes the job of managing vendor prefixes about as simple as it can possibly get).
2. Remember to specify the W3C version of the rule as well.
3. Remember to order the occurrence of the rules so that the W3C version shows up last.  This is to allow clients that support both the vendor prefixed version and the W3C version to use the W3C specified semantics for the rule.

That’s all for now.  In the next and final article in this series, we’ll take a look at how the app supports drag/drop of files, the use of File API, how the filters themselves work and how we prevent the UI thread from freezing by delegating the core number crunching work to web workers.

The second branch of the web’s most popular JavaScript library was released on April 18, 2013. jQuery 2.0 is now available for download but don’t rush off and install it just yet — there is one major change…

No More Support for IE6/7/8

(or IE9 and IE10 if they’re used in “Compatibility View” mode).

I still think it’s a little premature to abandon IE8 but the team couldn’t wait any longer. jQuery 2.0 removes all the legacy IE code for node selection, DOM manipulation, event handling and Ajax.

This has resulted in a 11% file size reduction from 32,819 bytes to 29,123 bytes. That’s 3.6Kb for the gzipped minified version — it’s unlikely to be noticeable even on a dial-up connection. Admittedly, the team hoped to save more but discovered that Android/Webkit 2.x browsers still required many workarounds.

If you need to support IE8 and below, stick with jQuery 1.9.x for now. You could conditionally load version 2.0 in all other browsers, but:

1. conditional loading will offset any gains in file size reduction and processing, and
2. you may encounter differences between the two jQuery branches. The team has pledged to minimize API divergence but there will almost certainly be issues. jQuery 1.10 will address known compatibility problems.

Custom Builds

The custom build feature has been refined in version 2.0 so you can exclude any of 12 unused modules and shrink jQuery below 10Kb. The modules which can be omitted are:

• ajax: all Ajax functionality, transports, and event shorthands.
• ajax/xhr: XMLHTTPRequest Ajax transport only.
• ajax/script: <script> Ajax transport only.
• ajax/jsonp: JSONP Ajax transport only (depends on ajax/script).
• css: The .css() method plus non-animated .show(), .hide() and .toggle().
• deprecated: deprecated methods (currently .andSelf() only).
• dimensions: .width() and .height() methods, including inner- and outer- variations.
• effects: the .animate() method and its shorthands such as .slideUp().
• event-alias: event attaching/triggering shorthands such as .click().
• offset: the .offset(), .position(), .offsetParent(), .scrollLeft(), and .scrollTop() methods.
• wrap: the .wrap(), .wrapAll(), .wrapInner(), and .unwrap() methods.
• sizzle: the Sizzle selector engine. When this module is excluded, it is replaced by a rudimentary selector engine based on the native querySelectorAll method which does not support some advanced jQuery selectors.

For example, if you are using CSS3 animations rather than jQuery methods, you could omit the effects module and possibly dimensions, offset, wrap and sizzle.

Creating your own custom build is not for the faint-hearted and you’ll require some knowledge of Git, Node.js and Grunt. Full instructions are available but, longer term, I hope the team can implement an online build process similar to Modernizr.

Should I Upgrade?

It’s important to understand that jQuery 2.0 has API parity with jQuery 1.9. There are a small number of bug fixes but no new features.

However, if you’re one of those lucky developers who has dropped support for IE6/7/8, grab jQuery 2.0 and don’t look back.

One of the techniques we talk about in Jump Start Responsive Web Design is called Selective Content Loading (SCL). This technique is really useful in situations where you want to load small pieces of data into an already loaded page in a structured way. When would this be useful?

• When you have serious bandwidth issues between your server and the end user’s device (for example, on a mobile connection that is moving on a poor network with lots of errors and having to deal with cell handoff).
• When your pages are largely the same structurally from page to page and simply reloading the content saves many requests.
• If you have chunked your content nicely and want to simply load in the next piece in the sequence (for example, infinite scrolling on a Twitter feed)

Some of these issues can be dealt with by good caching and using local storage and these should definitely be explored as good practices generally. However, even with smart asset caching you still require server round trips to retrieve a document, all the page HTML still has to be sent to the browser and then the browser still has to render the page.

If your page has only added a couple of additional bits of data (for example, a tweet) or is only changing a small amount of content (for example, the details for a product) then SCL may be a good option for you. This doesn’t work in every circumstance and it also causes a number of possible issues with URLs, browser history and what content gets spidered on a “page” by search engines (if this important to you).

Recapping our approach from Jump Start RWD, this is what we’re going to do conceptually:

• On the first page request we’ll load up all of the page content including the site navigation, content layout, CSS and JS files as normal.
• After the page has loaded we’ll override all of the links in our page to make them XHRs rather than a standard request for a document.
• We’ll then process the response (the XHR response will only be the internal page content in JSON rather than the entire page) and overwrite the content that was in the page.
• We can then use pushState() to modify our browser history (so the URL updates to something shareable and we can go backwards if needs be).

Here’s an example that should illustrate the point simply. The content has been truncated purposefully in order to keep this concise.

We’re going to set up a page that can load content about books without having to reload the entire page, just the pertinent content. We’ll also use pushState() from the History API to ensure that if the user wants to share or come back to the URL they’ll be able to do so.

To make things simple to express, we’re going to use jQuery for the DOM manipulation and a JavaScript templating library called Handlebars.js. If you haven’t checked out JavaScript templating options and what they can do, Handlebars is an excellent choice to get your feet wet.

The core of our solution relies on the fact that URLs can respond differently depending on whether they are an XHR or a normal HTTP request. If the server gets a normal request then the view will deliver the full HTTP response (containing all the document and then the JS, CSS etc). If the server gets an XHR, it will respond with JSON which only contains data about the book requested.

So, as an example, the standard HTTP response for the “Frankenstein” page looks like this:

<!DOCTYPE html>
<html>
<head>
  <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js"></script>
 
var original = null;
var backtostart = true;
 
  <script type="text/javascript">
      ($(document).ready(function() {
          var source = $("#story-template").html();
          var template = Handlebars.compile(source);
 
          var story_link_handler = (function(evt) {
              evt.preventDefault();
              $.get(this.href, function(data) {
                  $("#contentarea").html("");
                  $("#contentarea").html(template(data));
                  history.pushState({url:data.location}, data.title, data.location);
              }, "json");
          });
 
          $("ul#storylist li a").bind("click", story_link_handler);
 
          $(window).bind("popstate", function(evt) {
              if (event.state) {
                  url = event.state.url;
                  $.get(url, function(data) {
                      $("#contentarea").html("");
                      $("#contentarea").html(template(data));
                  }, "json");
               backtostart = false;
              } else {
               if (! backtostart) {
                  backtostart = true;
                      $("#contentarea").html("");
                      $("#contentarea").html(original);
               } else {
                 original = $("#contentarea").html();
                    backtostart = false;
               }
            }
          });
 
      }));
  </script>
</head>
<body>
  <ul id="storylist">
      <li><a href="mobydick">Moby Dick</a></li>
      <li><a href="gulliverstravels">Gulliver's Travels</a></li>
      <li><a href="frankenstein">Frankenstein</a></li>
  </ul>
  <div id="contentarea">
      <article id="story">
          <h1>Frankenstein</h1>
              <h2>Mary Shelley</h2>
              <p>Doctor creates artificial life</p>
          </article>
      </div>
<script type="text/javascript" src="handlebars.js"></script>
      <script id="story-template" type="text/x-handlebars-template">
      <article>
          <h1>{{title}}</h1>
          <h2>{{author}}</h2>
          <p>{{synopsis}}</p>
      </article>
      </script>
  </body>
</html>

NB you can download code used in this article in a zip file linked at the end of this article

However, the equivalent JSON response for an XHR will look like this instead:

{
  "location": "/frankenstein",
  "title": "Frankenstein",
  "author": "Mary Shelley",
  "synopsis": "Mad doctor creates artificial life"
}

All the code required to make the selective loading work is requested and loaded in the first request. After that, we only get the data and then load it into the template. Let’s take a look at how the code works.

  <script id="story-template" type="text/x-handlebars-template">
      <article>
          <h1>{{title}}</h1>
          <h2>{{author}}</h2>
          <p>{{synopsis}}</p>
      </article>
  </script>

NB you can download code used in this article in a zip file linked at the end of this article

Handlebars uses a script element to create a template for what an article looks like (this content won’t be rendered by the browser as it won’t take an action on its type). Variable locations are defined using {{variable}} syntax. You can do a lot more with Handlebars (conditionals, loops, block execution etc) that we aren’t using in this instance though. Note the ID for the script, we need this so we can pass it into the Handlebars template compiler.

In our document ready function, we grab the HTML from the template script tag we defined above and then we compile it into a template object we can use with new data later.

  var source = $("#story-template").html();
  var template = Handlebars.compile(source);

Next, we define a function we can use for our link onclick event handler. Here we’re simply stopping the actual request to the file by preventing its default behaviour. From there we make a jQuery XHR that returns JSON to the URL that was defined in the link’s HREF attribute.

  var story_link_handler = (function(evt) {
      evt.preventDefault();
      $.get(this.href, function(data) {
          $("#contentarea").html("");
          $("#contentarea").html(template(data));
          history.pushState({url:data.location}, data.title, data.location);
      }, "json");
  });

When the response comes back, we simply overwrite the div content area that holds all our book data.

$("#contentarea").html(template(data));

We also use pushState() to push the URL we just requested onto the browser history so we can go backwards using the back button.

history.pushState({url:data.location}, data.title, data.location);

That’s not quite the whole picture with pushState(), though, in order for it to “just work” for the user. We next create a popstate event handler on the window so that when the user hits the back button we can update the content with the appropriate data for the book. In this case we’re going and getting the data again using an XHR. With pushstate, it’s possible to store data in a state object. In our case the amount of data is small and it’s bad practice to load up the user’s browser with additional data (especially on mobile) so only do it if you can guarantee it’s a tiny amount.

  $(window).bind("popstate", function(evt) {
      if (event.state) {
          url = event.state.url;
          $.get(url, function(data) {
              $("#contentarea").html("");
              $("#contentarea").html(template(data));
          }, "json");
      }
  });

One of the things we need to consider with this technique is what happens when the browser gets back to the start of the list. That is, you’ve popped all of your XHRs off the stack and you’re back to where you started.

To remedy this, we use a flag to determine if we’re back to the start or not and we save the content that was in #contentarea so we can replace it. You can use other techniques such as simply hiding the original content area or storing the original document’s JSON.

We then update the popstate event to check if there’s no event.state. If so, we revert to our original form.

$(window).bind("popstate", function(evt) {
              if (event.state) {
                  url = event.state.url;
                  $.get(url, function(data) {
                      $("#contentarea").html("");
                      $("#contentarea").html(template(data));
                  }, "json");
               backtostart = false;
              } else {
               if (! backtostart) {
                  // revert the content to the original
                  backtostart = true;
                      $("#contentarea").html("");
                      $("#contentarea").html(original);
               } else {
                 // store original content to retrieve later
                 original = $("#contentarea").html();
                    backtostart = false;
               }
            }
          });

Finally, we add our click event handler to all the relevant links. In our instance, we’re just using the links in the list, but in practice you could do this to a whole range of links based on class or HREF attributes.

$("ul#storylist li a").bind("click", story_link_handler);

The rest of the page is the page structure and the actual content that was requested – in this case the /frankenstein URL.

As can be seen, this approach gives us a nice, responsive setup. The initial page request is a little heavier (in this case about 1Kb) but provides all of the scaffolding needed to layout the page and provide the interactions. Subsequent requests get the benefit of only having to return very small snippets of data, which are then loaded into the template.

The URL is updated using pushState() which means the user can still share the URL using intents or copy and paste and that URL will work properly for whomever it is shared with. You also get the benefit that each document still exists properly – this means search engines can still correctly index your site, if that’s needed.

One of the things we need to be careful of with this technique is that if we have content that exists in many different templates, the benefits from only loading the snippets of data via XHR will be destroyed by having to load all of the different content templates into the first page request and masking it from the user until it’s used. Don’t forget, all of the HTML still has to be loaded, regardless of whether it’s used or not.

Where this technique works particularly well is in an “infinite scroll” scenario such as a stream of content or very long article. The content type doesn’t change almost at all (or only within a very defined way)—this technique does for “page content” as a whole what the lazy loading technique does for images within a page. If you’ve taken the time to chunk your content, this can be especially effective as it means you can avoid the user hitting “goto page 2” even though search engines will follow happily.

Download code files used in this article

Delve further into the world of responsive web design in Andrew’s new book with Craig Sharkie: Jump Start Responsive Web Design.

Owing to my rapidly increasing age I’ve used many, many IDEs and text editors over the years. Visual Studio, Aptana, Eclipse, HomeSite, CoffeeCup, Bluefish, Komodo, Vim, Crimson, jEdit, TextPad, PSPad, ConTEXT, PHPEdit, ScITE — I’ve probably forgotten more than I remember. Most annoy me. They often miss features I want or add bloat I don’t need. My current editor of choice is Notepad++: it’s simple, lightweight and very configurable.

Historically, HTML editors have been fairly awful. Many IDEs forced you to create dumb projects, insisted on particular doctypes, or favored deprecated tags. JavaScript editing could be worse: the editor programmers didn’t understand the language so even basic features such as function lists could fail.

Fortunately, the situation has improved and NetBeans 7.3 has been released with full support for HTML5, CSS and JavaScript. The cross-platform IDE now includes an HTML project wizard which allows you to select popular boilerplate templates and JavaScript frameworks:

There’s a lightweight internal server, embedded WebKit browser, Chrome integration and responsive web design facilities:

CSS styles can be edited directly or changed within the Inspector-like rule editor:

The JavaScript editor has been rewritten to include better code completion, jQuery support and pattern recognition:

There’s also a new debugger which can analyze code running in the internal browser or Chrome. You can apply breakpoints on lines, when a DOM element changes, when events are raised and when Ajax requests are called. Very useful:

Finally, there’s a great browser log which displays exceptions, errors and warnings as they occur:

Don’t forget that NetBeans also provides first-class development facilities for PHP, Java and C/C++. If you’re into that sort of thing.

It’s great to see client side browser technologies finally receiving the tools they deserve. I’m going to give NetBeans another look … will you?

NetBeans is available for free from netbeans.org.

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

A variety of code playgrounds have appeared during the past couple of years. The majority offer a quick and dirty way to experiment with client-side code and share with others. Typical features include:

• color-coded HTML, CSS and JavaScript editors
• a preview window — many update on the fly without a refresh
• HTML pre-processors such as HAML
• LESS, SASS and Stylus CSS pre-processing
• inclusion of popular JavaScript libraries
• developer consoles and code validation tools
• sharing via a short URL
• embedding demonstrations in other pages
• code forking
• zero cost (or payment for premium services only)
• showing off your coding skills to the world!

The best feature: they allow you to test and keep experimental snippets code without the rigmarole of creating files, firing up your IDE or setting up a local server. Here are seven of the best …

JSFiddle

JSFiddle was one of the earliest code playgrounds and a major influence for all which followed. Despite the name, it can be used for any combination of HTML, CSS and JavaScript testing. It’s looking a little basic today, but still offers advanced functionality such as Ajax simulation.

CodePen

The prize for the best-looking feature-packed playground goes to CodePen. The service highlights popular demonstrations (“Pens”) and offers advanced functionality such as sharing and embedding. The PRO service provides cross-browser testing, pair-programming and teaching options for just $9 per month.

CSS Deck

This may be named CSS Deck, but it’s a fully-fledged HTML, CSS and JavaScript playground with social and collaboration features. It’s similar to CodePen (I don’t know who influenced who!) but you might prefer it.

JS Bin

JS Bin was started by JS guru Remy Sharp. It concentrates on the basics and handles them exceedingly well. As far as I’m aware, it’s also the only option which offers a JavaScript console. Recommended.

Dabblet

Another early playground, Dabblet started life as an HTML5/CSS3 demonstration system by Lea Verou but it’s recently received JavaScript facilities. It looks gorgeous and has one killer feature — browser CSS prefixes are added automatically. There’s no need to enter that -webkit, -moz and -ms nonsense yourself.

Tinkerbin

Tinkerbin is an alpha release and one of the simpler options here. It may not offer features above and beyond the alternatives but it’s attractive and functional.

Liveweave

Liveweave is slightly unusual in that it places your HTML, CSS and JavaScript into a single file. It’s not possible to share your creation, but you can download the result and store or open it locally. It’s ideal for quick and dirty private experimentation.

I guess I missed your favorite?…

The working process of many web designers involves using a wireframe, a static outline of page layout that can be filled with design elements, perhaps drawn from a Photshop comp.

Developers, however, need to build functionality not available in a static wireframe. A web prototype is more like a working model that allows a developer to experiment with how things work on a web page.

In this article, you’ll learn how to create a web prototype with touch gestures using simple and easy HTML, CSS and jQuery.

Prototyping for Touch

For a recent project, I wanted to incorporate a facility to allow appropriate screens to respond to touch gestures.  I designed a static wireframe and then thought to build a rich web prototype to run on tablet devices to demo to the stakeholders.

Considering it was a just a prototype and wasn’t going to be used for actual development, and given that I have a limited knowledge of programming (a common problem for designers), I was looking for an easy JavaScript framework for allowing swipe gestures to work on mobile browsers, specifically tablets and iPads.

The main requirement would be to show the primary navigation bar with sliding animation when the user swipes their finger from left to right.  I started Googling, and tried various frameworks from jQuery mobile to hammer.js. All the frameworks I tried were either too complex to use or not very responsive on mobile browsers.

Finally, I tried another framework called wipetouch.js, and it worked the way I wanted. It is very simple and easy to use and the swipe gesture is very responsive in platforms like iOS and Android.

Note: the demo is primarily made for iPad and tablets but it runs well on desktop browsers, too. For desktop, in place of swipe, the user can slide the mouse pointer. To see the result, open the link on your iPad or Android tablet, then swipe the finger from left to right, right to left and top to bottom.

View Demo

Files used for this exercise

• index.html for html
• style.css for styling
• common.js for JavaScript
• jquery.wipetouch.js – a framework used for swipe gesture
• and link to jQuery files

Images used in this exercise

Swipe from Left to right:
Showing the left menu bar with sliding animation

Swipe from right to left:
Showing the right bar with sliding animation

Swipe from top to bottom:
In this example, I wanted to use a swipe down gesture to add the product without tapping on the + icon, because swiping is easier and quicker than tapping on a small icon.

But, as this touch gesture has a problem of discoverability, the icon to add the product is there in case the user is not aware of this gesture.

Getting Started

Note: To make the article easy and clean, I will only explain the code used to slide the left menu on swipe from left to right. For right and top menu, the code is pretty much same (and is provided in the actual demo source files).

Step 1 – Link JavaScript and jQuery files

First we’ll link the required jQuery files and wipetouch.js framework for this prototype in the HTML page. We’ll use jQuery for showing the sliding animation and wipetouch.js for the swipe gestures. Common.js is the JavaScript file used for this assignment.

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.5/jquery.min.js"></script>
<script src="http://ajax.googleapis.com/ajax/libs/jqueryui/1.8/jquery-ui.min.js"></script>
<script src="jquery.wipetouch.js"></script>
<script src="common.js"></script>

Filename – index.html

Download wipetouch.js

Step 2 – Add Images

In HTML, we will add the left_menu.png image and give it an ID. We will use this ID in the CSS and JS files.

<img src="images/left_menu.png" width="262" height="600" id="menuLeft">

Filename – index.html

Step 3 – CSS Code

In CSS, we will position the image on the page from where we want the sliding animation to start.

/* Set Position of Left bar */
#menuLeft {
    position:absolute;
    left:0;
    top:0px;
    z-index:99;
}

Filename – style.css

Step 4 – Hide the #menuLeft when page loads

$("#menuLeft").hide();

Filename – common.js

Here menuLeft is the ID applied to left_menu.png.

Step 5 - Show the navigation bar with sliding animation when user swipes from left to right

wipeRight: function(result) {
    $("#menuLeft").show("slide", { direction: "left" }, 1000);
}

Filename – common.js

Here wipeRight is the function from wipetouch.js that is triggered when the user swipes the finger from left to right.

On this swipe action, we show the menuLeft image with sliding animation from the left direction.

Step 6 – Slide back the image on tap

Now we need to slide same image back the when user taps on the image.

$("#menuLeft").click(function () {
    $("#menuLeft").hide("slide", { direction: "left" }, 1000);
});

On tapping on the image, it slides back to be hidden.

Note: To make the article easy and clean, I have only explained the code used to slide the left menu on swipe from left to right. For swiping from right to left and swiping from top to bottom, the code is pretty much same and given in actual demo source files.

Download Demo Source Files

In Conclusion

No doubt the available prototyping tools will soon cover touch gestures, but right now this solution does the trick. I hope this demo provides a good base for you to build a prototype to show touch gestures and basic animation on touch devices using easy simple code.

Please let me know if you have any suggestions for improvements. Please share your thoughts, opinions and ideas in the comments section below.

Further Reading

http://www.netcu.de/jquery-touchwipe-iphone-ipad-library
Another nice demo created using touchwipe.js to slide show on swipe

http://eightmedia.github.com/hammer.js/
Another very popular JS framework for mobile devices

http://www.appliness.com/multitouch-with-hammer-js/
A nice demo created using hammer.js to show drag and drop

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.

The popularity of jQuery continues unabated. At the last count, the JavaScript library has been adopted by 55% of all websites. More impressively, it’s loaded on more than 90% of sites which use a library.

However, not all is perfect in the jQuery world. Despite having a great plugin system, how do you locate a plugin for your needs? The original repository at jquery.com was clunky at best; search results were poor, code was out of date and documentation was sparse. Googling was a better option but finding suitable code was a hit-and-miss affair. Ultimately, it was often easier to develop your own jQuery plugin.

Fortunately, the jQuery team are aware of the issue and have launched a new jQuery Plugin Repository. Their aim is to reduce the fragmentation and distribution problems that can be obstacles for plugin developers and consumers.

How to Download jQuery Plugins

You can search, browse or click tags to locate plugins in the jQuery Plugin Repository. Each plugin page provides a brief description, compatibility information and links to the home page, documentation, demonstrations, issues and downloads.

How to Register New jQuery Plugins

If you’d like to share your amazing jQuery plugin, there are several steps required to publish code on the jQuery Plugin Repository:

1. Choose a unique name. Keep it short, descriptive and don’t use a name which has already been taken. It’s first come, first served.
2. Create a package manifest. This is a JSON file describing the plugin, version, dependencies, developer, license, links etc.
3. Publish your plugin on GitHub. You’ll need to sign-up for an account, create a post-receive hook with the URL http://plugins.jquery.com/postreceive-hook, and push using your preferred Git tool.

First Impressions

The jQuery Plugin Repository is new and has a limited selection of plugins available. The search isn’t the best, plugin descriptions are terse and you need to link out to various information pages which slows down browsing. For me, the most fundamental omission is an absence of user ratings and reviews.

That said, the aim must be to create a repository which is as useful as the WordPress Plugin Directory; a definitive and easy-to-use resource with a thriving developer community. Let’s hope the jQuery team succeed.

Will you publish your code to jQuery Plugin Repository? If you need a plugin, would you head there first?

jQuery 1.9 was released on January 15, 2013 and marks an important milestone on the road to world domination. The code has been streamlined in readiness for version 2.0 which drops IE6, 7 and 8 support.

jQuery has been adopted by 55% of all websites and 90% of those loading a JavaScript library. It’s important to JavaScript coders and almost anyone creating a modern website or application.

Over at SitePoint.com, I discuss What’s New in jQuery 1.9. There are a few new methods but it’s the removed features which will cause most concern for those using older plugins. The jQuery team have great solution, but is their decision to abandon legacy IE browsers a little premature? Read on…