As with any good book, the first chapter outlines what the subject matter is. The authors talk about jQuery itself and touch briefly on the DOM. You have to remember that this book is aimed at developers or designers that don’t really know that much about JavaScript, the DOM, or jQuery, so the book is accordingly written in such a way that it won’t confuse the pants off your typical photshop-wizz turned HTML/CSS guy.

So if you know JavaScript well, you might not enjoy this book — it will probably annoy you, simply because it doesn’t go into a huge amount of detail on what’s happening behind the scenes. But, for those that it’s aimed at, I think it does a pretty good job.

One thing that we have a problem with, in the jQuery community bubble, is the overzealous generation of redundant nomenclature. This book doesn’t fall short on this front. jQuery’s methods are referred to as “actions”.

The second chapter covers the most basic usages of jQuery, selecting stuff and doing stuff. It’s all innocent and simple — I like it. To keep the reader focused the authors have slipped in “A few tricks”. Among them is the popular add-a-class-on-mouseover, remove-it-on-mouseout.

Nearing the end of chapter two, the book has the following to say about the hover method:

“It requires two functions as parameters: one to handle the mouseover event, and one to handle the mouseout event.”

The book does claim to be 1.4-ready, so I think it’s only right to mention this. In jQuery 1.4 the hover method accepts either one or two parameters, and they don’t correspond to the mouse(over|out) events; they correspond to the mouse(enter|leave) events, although I guess they’re not totally incorrect on this because jQuery simulates these events using mouse(over|out) in non-supporting browsers, but it is nevertheless an oversight.

Not soon after that did I find what I consider to be a grievous anti-pattern:

$('.spoiler').hide();
$('<span class="revealer">Tell me!</span>')
    .insertBefore('.spoiler');
$('.revealer').click(function() {
    $(this).hide();
    $(this).next().fadeIn();
});

It seems that in their desperation to keep it simple, the authors have chosen to spare the readers of what would be some very good advice. When you add something to the DOM, and it doesn’t need to be referenced within a CSS StyleSheet, then giving it a class or ID, and then getting a reference to that element via that hook, is normally an almost-entirely redundant process. This would be a far better approach:

var spoilers = $('.spoiler').hide(),
    buttons = $('<span>Tell me!</span>').insertBefore(spoilers);
 
buttons.click(function() {
    $(this).hide().next().fadeIn();
});

Or, even:

$('.spoiler').hide().before(
    $('<span/>', {
        text: 'Tell me!',
        click: function(){
            $(this).hide().next().fadeIn();
        }
    })
);

If I was the author, I don’t know what I would have done in this situation… since it’s a teaching exercise, do you show the readers how it should be done, or do you show them in the simplest way possible, so as to not bulldoze them with complexities?

Moving on, the book is very cookbook’y and focuses heavily on an imagined client that has lots of strange requirements (quite typical of your average client). From the introduction to chapter three:

“The client is extremely happy [...] he believes flashy animations will help boost sales.

‘I think it needs some of that Web 2.0 that I’ve been hearing about,’ he says confidently. ‘Can you make it look more like a Web 2.0?’

‘Errrm, indeed we can,’ you assure him, as he passes you his next wish list chock-full of exciting changes—a list that will allow us to move beyond simply hiding and showing, and closer to our goal of being a jQuery ninja.”

I have a soft spot for these kind of tongue-in-cheek introductions, they’re quite popular in other programming books too, and I think it does well to mentally elevate the reader — and to develop that all-important reader-author relationship.

Before you know it, you’re into the third chapter. Chapter three exhaustively covers animation. The detail is great and the authors even take the time touch on jQuery UI’s animation capabilities in addition to covering all of the core methods. I liked this chapter, — it seemed to cover pretty much everything, although I found myself disappointed with some of the code again:

$('<div id="navigation_blob"></div>').css({
    width: $('#navigation li:first a').width() + 10,
    height: $('#navigation li:first a').height() + 10
}).appendTo('#navigation');

Let’s introduce some basic optimisations:

var nav = $('#navigation'),
    firstAnchor = nav.find('li:first a');
 
$('<div id="navigation_blob"></div>').css({
    width: firstAnchor.width() + 10,
    height: firstAnchor.height() + 10
}).appendTo(nav);

Chapter four is all about images, and takes the reader through the process of creating a simple lightbox effect. It also shows you how to download and “install” your typical jQuery lightbox plugin (in this case, ColorBox). It continues to show you how to create a simple slideshow.

The bulk of this book was obviously written before 1.4 was released. I get the impression that, upon 1.4’s release, the authors quickly went through adding in some “actions” only made possible with 1.4. They covered the new way of creating elements in jQuery 1.4, which involves passing an object as the second argument to jQuery():

$('<div/>', {
    text: 'foo',
    click: function(){},
    id: 'muah'
});

The book had the following to say:

“If you use a jQuery method name like text, html, or val, it will use the jQuery methods to set the property. Everything else will be treated as an attribute, as done with the src property.”

This isn’t entirely accurate. jQuery only uses certain methods — not all of them. Methods available for usage in this way are specified under jQuery.attrFn.

Continuing…

Chapter five brings with it a lot of UI icing… tooltips, menus, tabs and accordions. The book takes the reader through the processes involved in creating these interface elements. Just like all the other chapters, chapter five is littered with little titbits of useful information. For example, it covers event propagation and default event actions in pretty decent detail.

The next chapter is probably my favourite — it covers code construction and best practices, including namespacing, encapsulation, commenting, DRY, templating and feature detection! I was pleasantly surprised to see these topics covered in a book like this. Their templating techniques were a little lacking — I would’ve liked to see some custom-typed <script> elements (like in Resig’s solution), or perhaps some templates stuffed into HTML comments.

Chapter six continues by explaining Ajax and showing the reader what jQuery offers in the way of Ajax/XHR utilities. You’re also taken through the process of creating an Ajax-driven image gallery among some other gems.

I’m going to stop outlining the chapters now… I’m bored, and you’re probably not getting much from that (heck, you could probably just look through the TOC). The rest of book covers forms, controls, dialogs, validation, lists, trees, tables, plugins, themes and some “advanced topics”. There’s also a hefty appendices that has bunch of useful information, including a brief JavaScript tutorial for those new to the language.

Just so we’re clear, this is a good book, and if you fit the bill of a front-end wizz that wants to pick up jQuery, then this book will easily deliver. There are a couple of oversights, but in a book over 400 pages long I’d say that’s pretty amazing! Earl Castledine and Craig Sharkie have done a pretty awesome job!

~~something;

The bitwise NOT operator (~) will take its operand, convert it to a 32-bit integer, and will invert each bit so that each 0 becomes a 1 and vice versa.

00000000000000000000000000001001
...becomes
11111111111111111111111111110110

The effect of this, given the expression ~foo is -(foo + 1). A double bitwise NOT operation (~~foo) will therefore result in -(-(foo + 1) + 1). This only remains true for integers though; given all the potential operands, the real equivalent expression to ~~ is probably something like:

typeof foo === 'number' && !isNaN(foo) && foo !== Infinity
    ? foo > 0 ? Math.floor(foo) : Math.ceil(foo) : 0;
// This is ONLY _effectively_ the same... this is
// NOT what happens internally!

This is obviously a fair bit slower than ~~.

If the operand is a number and it’s not NaN or Infinity then ~~ will have the effect of rounding it towards zero (Math.ceil for negative, Math.floor for positive). If it’s not a number, then I believe the internal ToInt32 function converts it to zero.

Here are some examples of the double-bitwise NOT operation in all its glory:

~~null;      // => 0
~~undefined; // => 0
~~0;         // => 0
~~{};        // => 0
~~[];        // => 0
~~(1/0);     // => 0
~~false;     // => 0
~~true;      // => 1
~~1.2543;    // => 1
~~4.9;       // => 4
~~(-2.999);  // => 2

~~’s flooring capabilities make it a better alternative to Math.floor if you know you’re dealing with positives — it’s faster and takes up less characters. It’s not quite as readable though, but I’m hoping that ~~ will slowly become a very well-known technique in the JS arena, so we can all use it without fearing accusations.

It’s quite useful for normalizing arguments that you expect to be integers too. Take this example from what the MDC recommends for providing Array.prototype.indexOf to non-supporting browsers:

/*Array.prototype.indexOf = function...*/
var from = Number(arguments[1]) || 0;  
from = (from < 0)  
     ? Math.ceil(from)  
     : Math.floor(from);

In goes ~~:

/*Array.prototype.indexOf = function...*/
var from = ~~arguments[1];

Go forth and double-NOT!

Libraries like jQuery aren’t very small when uncompressed. Traversing a long source file trying to look for a specific method’s implementation is far from ideal. I have frequently found myself in this situation with jQuery, so today I decided to do something about it, and the result is viewable at http://james.padolsey.com/jquery.

It allows you to study specific parts of jQuery’s source. You can type in a method name and you’ll see its implementation straight away, in all its syntax-highlighted glory! It will also link’ify all function names within the presented source:

You can link directly to a method using the following URL pattern:

http://james.padolsey.com/jquery/[version/]methodName
 
E.g.
http://james.padolsey.com/jquery/css
http://james.padolsey.com/jquery/1.3.2/attr
http://james.padolsey.com/jquery/jQuery.proxy
 
-OR-
http://james.padolsey.com/jquery/#v=version&fn=methodName

If you don’t specify a version then 1.4 is assumed.

The source that’s shown won’t be identical to the actual source, since this source viewer only works by toString()‘ing the functions. I might eventually implement something a little more robust, but it’s going to take time — finding a specific function’s declaration in a source file is tricky, especially when they’re not all defined with the straightforward method: function(){...} or function foo(){...}.

I didn’t really intend it to be an accurate depiction of the real source anyway — just something I (and others) could use to see how certain things are implemented within jQuery.

I hope you find it useful… I know I will!

If you have a read through that thread you’ll notice none other than the infamous David Mark. This is the same person that slammed jQuery (oh, and MooTools) for not being able to “do *anything* right” and then, not too long ago, threatened the jQuery project with legal action over some DOM attributes tests.

David had the following to say about jQuery Lint:

Well, sort of. It’s not so much the Johnny-come-lastly advisor plug- in, but the fact that it is just another horrible plug-in for an equally bad pile of JS [he means jQuery]. Anyone who would use jQuery enough to want to write a plug-in is not going to be the best candidate to wtite a browser scripting “lint.” I can’t see it.

He continues:

The idea (which is sound) is to warn developers when they are doing something incorrect (or ill-advised). I haven’t looked at the code for it (and I’m sure I never will). I find I don’t have to do that anymore as the basic rules always apply.

David doesn’t stop! He still continues:

[Scott Sauyet]
> It seems to be a tool to help new users learn things like that although this code is legal:

$("selector").css("color", "red").css("margin", 0);

> This would be more efficient:

$("selector").css({color: "red", margin: 0});

[David Mark]
You dump it and replace it with something better (and faster). In this case, something like:

el.style.color = "red"; 
el.style.margin = '0';

That’s smaller, faster, more readable, makes no function calls, creates no new objects and is impervious to upgrades to jQuery (typically poison). And, as we all know, jQuery doesn’t work worth a shit anyway as the “logic” in the script is mostly a diary of confused browser watchers. Get the picture?
> That doesn’t indicate anything wrong with the library any more than > any lint program indicates problems with its target environment.
Of course, you don’t need a lint to see what is wrong with the library. It’s as obviously unsuitable as a dissertation written in crayon.

According to David we should be sparing ourselves the obvious folly of abstraction and spend more time writing “smaller, faster, more readable” JavaScript:

// We say:
$('#elem').css({
    fontWeight: 700,
    width: 200,
    height: 100,
    color: '#000'
});
 
// He says:
var elem = document.getElementById('elem');
elem.style.fontWeight = '700';
elem.style.width = '200px';
elem.style.height = '100px';
elem.style.color = '#000';

David, if you’re reading this, maybe you could offer us a response, detailing why you think jQuery “doesn’t work worth a shit” and also perhaps you could enlighten us why verbose and old-fashioned DOM scripting is miles better than progressive abstractions like the one jQuery offers? And if not too much trouble, I would appreciate if you could spare us your slander and ad hominem.

And when I say “detailing why you think jQuery doesn’t work worth a shit” I don’t mean having a go at petty code inconsistencies and syntax peculiarities.

Unlike JSLint, jQuery Lint is a runtime reporter. To use it, you need to include it, after jQuery, in your document:

<script src="jquery.js"></script>
<script src="jquery.lint.js"></script>

jQuery lint’s main objective is to notify you of incorrect usages of jQuery’s API. So, if you pass incorrect arguments to any method then jQuery Lint will let you know. It compares your arguments to the argument signatures in jQuery’s API. It reports via Firebug, although you can quite easily plug-in your own console mechanism.

It has four different error-reporting levels (accessible via jQuery.LINT.level), zero reports nothing, three will report everything, including small things like using css().css().css() instead of css({...}). It’s quite configurable too. You can add your own checks. E.g.

jQuery.LINT.special[1].jQuery = jQuery.LINT.special[1].jQuery || [];
 
// Add check on error-reporting level one.
// Check jQuery method.
jQuery.LINT.special[1].jQuery.push(function(selector, context) {
 
    if (selector === '*') {
        return "Don't use the universal selector!";
    }
 
});

jQuery Lint tries to help you in determining where the problem occurred in your code. It’s not much help to you if it just says, “Err, you called css() incorrectly!”. If it occurred as a result of an event then Lint will say so, and if you’re using a browser that provides a stack-trace as part of its Error object (like Firefox) then Lint will also provide you with the file-name and line number. E.g.

You can read more about jQuery Lint and download it at Github:

jQuery Lint @ Github

The idea of a lint-like script for jQuery has been floating around for some time. I want to thank Dave Methvin in particular, for it was his idea that sparked my interest originally.

This is quite a young project, so there will be bugs. Please report them!

Instead of asking for JSON format, ask for XML, but also add a callback parameter to your query. Voila!

So, in short, YQL allows us to make cross-domain GET requests!

Chris also posted a demo!

With a bit of hacking, we can make jQuery work with YQL for all cross-domain GET requests. UPDATE: I’ve decided to put this in my “jQuery Plugins” repo at Github:

Cross-Domain Ajax mod @ Github

With this mod, any GET request made via jQuery.ajax to another domain will work!

$('#container').load('http://google.com'); // SERIOUSLY!
 
$.ajax({
    url: 'http://news.bbc.co.uk',
    type: 'GET',
    success: function(res) {
        var headline = $(res.responseText).find('a.tsh').text();
        alert(headline);
    }
});
 
// Works with $.get too!

Have fun!

Before you stop paying attention, I’d like to wish everyone a Happy New Year! I hope you find the new design more consistent and cleaner.

May the flaming commence…

Prefixxing all jQuery objects with “$”

It’s ugly, and my text editor doesn’t like it! But mainly, it’s ugly, and is only useful for beginners. Hungarian notation is a hotly debated technique — like Marmite (and Jade Goody?), you either love it or hate it!

var $body = $('body');
$body.click(function(){
    $this = $(this);
});

I won’t say much more; I appreciate that it’s a sensitive topic for some and is mostly about personal preference.

Concatenating a bunch of things together to make a selector

I see a lot of this! It looks dirty, and just screams, “I’m succumbing to the API because I don’t know what else to do!”

$('.' + className + '[' + attrLookup + '^=' + attrPrefix ']:not(.' + notClass + ')');

This is why I think jQuery needs some other way of filtering DOM elements (possibly something like my filter hack). For now, seperating out our selectors will have to suffice:

$('.' + blah.className)
    .filter('[' + attrLookup + '^=' + attrPrefix ']')
    .not('.' + notClassName);

To be truthful, I’m on the fence with this… Maybe I’m just against string concatenation!

Going over the top with chaining

Some developers have obviously been dared to never exit a chain, ever!

$('a').addClass('reg-link')
    .find('span')
        .addClass('inner')
    .end().end()
    .find('div')
        .mouseenter(mouseEnterHandler)
        .mouseleave(mouseLeaveHandler)
    .end()
    .explode();

Long chains are okay, as long as you’re not doing a massive amount of DOM traversing in them… they can become unwieldy beasts!

Not caching collections

$('a').click(function(){
    $('a').not(this).addClass('wow');
});

Cache please!

var anchors = $('a');
anchors.click(function(){
    anchors.not(this).addClass('wow');
});

That is, unless you have a good reason not to, e.g. new anchors are constantly being added to the document.

HTML

Long strings of HTML scarring your otherwise beautiful code. Keep the HTML… in the HTML, no in the JavaScript!

$('#something')
    .append('<div class="gall"><a href="javascript:void(0)">Linky</a></div>')
    .append('<div class="gall"><a href="javascript:void(0)">Linky</a></div>')
    .append('<button onclick="app.doStuff()">Button</button>');

I added a couple of other code smells (really bad ones!) in there. Please, oh please, learn how to use jQuery for your event handling!

Here’s a nicer smelling (and more readable) alternative:

var div = $('<div/>').addClass('gall').append(
    $('<a/>').click(function(){
        return false;
    })
);
 
$('#something')
    .append(div)
    .append(div.clone(true))
    .append(
        $('<button>Button</button>').click(function(){
            app.doStuff();
        })
    );

Leave a comment: Submit your own code smell! Or… tell me why I’m wrong!

But, when the time comes, and you’re faced with the decision to either create a jQuery plugin or to simply create a regular function, everything suddenly becomes quite complicated. First, you’ll wonder whether the piece of behaviour you want to abstract is best kept under the jQuery namespace, and then you’ll doubt its applicability to the DOM-centred jQuery chain, and then sometimes you’ll recede to something you’re much more comfortable with, a regular ol’ JavaScript function.

If we forget about the plugins available online, and we simply focus on your plugins, made and used within a specific project, then the question of whether a plugin is really the right route becomes all the more difficult to answer. Are you going to benefit from extending jQuery’s API? Will the readability of your code benefit?

For example:

function applyColors(elems) {
    $(elems).css({
        color: config.color,
        backgroundColor: config.bgColor,
        borderColor: config.bdColor
    });
}
 
// Call it:
var myElems = $('div.something');
applyColors(myElems);

applyColors encapsulates some behaviour that is needed frequently, and that’s why it’s been abstracted into a function. To some, this approach is lacking in that it doesn’t harness the full power of jQuery, and more specifically, jQuery’s plugin mechanism. How about this:

jQuery.fn.applyColors = function( {
    return this.css({
        color: config.color,
        backgroundColor: config.bgColor,
        borderColor: config.bdColor
    });
};
 
// Call it:
$('div.something').applyColors();

Cleaner? More readable? I think so.

Many developers are not prepared to extend jQuery’s API with their own simple abstractions. I don’t know why. But, I hope, that jQuery macros can help in lowering the barrier to extending jQuery.

The humble macro

(the following examples require jQuery.macro, which you can get at Github!)

If we take the example from above, we can create a macro with the same functionality:

jQuery.macro('applyColors').css({
    color: config.color,
    backgroundColor: config.bgColor,
    borderColor: config.bdColor
});
 
// Call it:
$('div.something').applyColors();

jQuery.macro allows you to record a set of jQuery method calls, and it will create a regular jQuery plugin that will play back the macro. A more verbose example:

var myMacro = jQuery.macro('myMacro');
myMacro.css('color', 'red').scrollTop(0).addClass('foo');
 
jQuery('div').myMacro(); // All that stuff happens! css()->scrollTop()->addClass()
 
myMacro.removeClass('bar'); // Record another action
 
jQuery('div').myMacro(); // css()->scrollTop()->addClass()->removeClass()

Calling jQuery.macro will give you a macro object, which you can think of as a blank disc that will record anything you do.

This is obviously not a replacement for regular jQuery plugins; it’s simply an easier way to abstract multiple simple behaviours, without having to get caught up in the plugin dilemma.

// Record a macro:
jQuery.macro('foo').css({
    color:'red',
    border: '1px solid #000'
});
 
// Create a plugin:
jQuery.fn.foo = function() {
    return this.css({
        color:'red',
        border: '1px solid #000'
    });
}
 
//... Both have, effectively, the same result ...

jQuery.macro aims to lower the barrier to extending jQuery’s API — to rid your global namespace of misplaced functions — to spare you the superfluous function notation when creating a plugin that only calls a bunch of jQuery methods.

Like I said, this is certainly not a replacement for regular plugin creation. When recording a macro you are without many luxuries, like a nice closure to work within, plugin arguments/options, using jQuery getters etc.

A jQuery plugin is something that allows you to deeply embed your abstracted behaviour within the jQuery API, a macro is essentially just a list of method calls — even though each macro disguises itself as a plugin, it is meant for a wholly different purpose.

Please download and experiment with jQuery.macro.

To round off this post, a last ditch example:

jQuery.macro('cousins').parent().siblings().children();
jQuery('#elem').cousins(); // YEH!

Well, I had a go, and this is a brief overview of how it works.

Obviously, it wasn’t possible to simply line the images up as a grid, because they all have varying (and unpredictable) widths and heights. Considering this, I only saw one logical way of doing it… progressively!

Place an image — determine the remaining space and use it to place the next image, and so on. Placing the first image is easy; just stick it up in the top left corner and go from there!

A single placement will open up, potentially, three new positions. Out of them, the top-most one could be used for next placement, or the left-most, whichever you fancy.

I chose to track the availability of pixels using a basic two-dimensional array:

// Nine occupied pixels:
[
    [1,1,1,0,0,0,0,0,0,0],
    [1,1,1,0,0,0,0,0,0,0],
    [1,1,1,0,0,0,0,0,0,0],
    [0,0,0,0,0,0,0,0,0,0],
    [0,0,0,0,0,0,0,0,0,0],
    [0,0,0,0,0,0,0,0,0,0],
    [0,0,0,0,0,0,0,0,0,0],
    [0,0,0,0,0,0,0,0,0,0],
    [0,0,0,0,0,0,0,0,0,0],
    [0,0,0,0,0,0,0,0,0,0]
];

The width given to any image upon placement is defined by the amount of pixels free to the right of that image and the height is calculated similarly. There’s a configurable maximum width and height so that the first image doesn’t take up the entire space. Eventually, there is no space left, and the procedure halts.

You can find the code at Github, under “PhotoWall”.

I’ve also put a pretty boring demo online, and yes, I know it’s a bit messed up at the bottom edge — like everything, it’s a work in progress .

Currently, jQuery (1.3) only allows you to specify one easing function per animation. This is perfectly fine in most situations but in some unique cases there is a need for a different easing function for each animated CSS property. I mentioned, in my previous post on the topic, that such a thing could be emulated by initiating two separate animations and disabling the default animation queueing on the first one. It does work, but it’s a bit of a hack, and I felt that the API could be easily extended to serve these types of use cases.

So, as of jQuery 1.4 alpha version 2, jQuery provides you with the possibility of defining an easing function (or rather, the name of an easing function) for each property that you’re animating. It’s done in the following manner:

jQuery(myElement).animate({
    left: [500, 'swing'],
    top: [200, 'easeOutBounce']
});

Another possibility is to define the per-property easing functions within the optional options object, passed as the second argument to animate:

jQuery(myElement).animate({
    left: 500,
    top: 200
}, {
    specialEasing: {
        left: 'swing',
        top: 'easeOutBounce'
    }
});

See a demo!

The conventional easing argument can still be used to set a default easing function for those properties that don’t already specify a “special” easing function:

jQuery(myElement).animate({
    x: [100, 'easeInQuad'],
    y: [100, 'easeOutBounce'],
    z: 100
}, 1000, 'linear');

The z property will be animated using the linear easing function, and the other two properties (x and y) will be animated using their respective easing functions.

Any array specified as a value within the “properties” object (the first argument to animate) is assumed to be specifying both a value and an easing function just for that property. You can continue to use animate in the traditional way; no incompatibilities have arisen!

The easing function you specify is the only easing function that will be used for that property. Unlike the demos shown in my previous post on the topic, the functions are not overlaid — it’s either one or the other.

Note that you must download the easing functions in order to use them in your animations — they’re not included in the jQuery core (other than the default “swing”, and “linear”).