I’m not surprised to see more and more “lightweight” JavaScript libraries pop up as jQuery has grown in size. The pendulum tends to swing hard from one direction to the other with these things.

One that I came across recently is Minified.js:

Minified.js is a client-side JavaScript library, comparable to jQuery and MooTools in scope. Its features include DOM manipulation, animation, events, cookies and HTTP requests.

The size of the JavaScript file you send across the wire is certainly one factor to consider, especially for mobile users. I’m more curious to see what the performance looks like when using similar features. In some cases that is even more important than the size of the file.

jQuery Edit In Place ( JEIP ) 0.2.0

Justin Hall was kind enough to suggest a fix for jQuery Edit In Place ( JEIP ) to work with version 1.9.x of jQuery. Version 0.2.0 of JEIP is needed if you are using jQuery 1.9.x.

I also moved the code to GitHub as well – – so fork away.

I’ve updated the links on the JEIP page and demo page to JEIP 0.2.0 and jQuery 1.9.1.

Automatically Loading a Gravatar Image Based on Form Field Input

I’ve seen several examples of automatically loading a Gravatar image on the fly based on an input form field. After coming across another one recently and not finding a Javascript library that would do this for me, I sat down to play with this process a bit. I knew the process wasn’t complex, but at the same time it seemed like something that should have an easy to use drop in module to make it work. The result is a simple jQuery plugin I’m calling form2gravatar.

The source code is available at, along with a simple demo at To get started you need a form field, and a target image element:

	Email <input type="text" name="email" id="email">
	<img src="http:////" id="gravatar" alt="Gravatar" height="64" width="64">

Assuming you’ve loaded jQuery and form2gravatar.js you can then trigger a Gravatar image lookup with:

$( '#email' ).form2gravatar( { target: '#gravatar' } );

This tells form2gravatar to watch the keystrokes in the #email element and update the #gravatar image. By default it will check the form value several times a second, which makes it easy to update the image rapidly, but might be a waste in some cases. So there is an option to only do an image update when the form field loses focus (use_blue).

For pages with several form fields setting use_blur to true will still provide a good experience and have almost no performance impact on the page. If you only have a few form fields (like on a log in page) I’d stick with the default behavior. You can adjust how frequently the form field is checked with the timer_interval option.

Here is a list of all the options in form2gravatar:

	var opt = {
		'default_img'	: 'mm',
		'size'		    : 64,
		'ssl'		    : false,
		'target'	    : false,
		'timer_interval': 100,
		'use_blur'	    : false

The only one that is required is target. The other option many folks will want look at is default_img, which by default uses the mystery man from Gravatar. You can use any of the other Gravatar default options (404, mm, identicon, monsterid, wavatar, retro, and blank) along with a URL to some other image.

The Github repo includes a demo.html file that shows this in use for sign in page. From there you can copy and tweak it into what ever shape you’d like.

Difference Between A Human Click And A Trigger Click With jQuery

I was recently working on a page that had some existing transitions that happened when a user clicked on an item. My thought was to periodically trigger a click event that would automate the process some what, allowing me to take advantage of the existing transition code.

jQuery has a nifty method called .trigger that takes care of firing the click event for me. Very handy, but then I quickly realized that I needed to be able to tell the difference between a human click event and a .trigger‘d click event.

Fortunately I wasn’t the only one to have run into this issue and there is a solution described at The key is event.originalEvent, here is an example from the StackOverflow post:

$( "#click-me" ).click( function( event ) {
    if ( event.originalEvent === undefined ) {
        alert( 'not human' )
    } else {
        alert( 'human' );
} );

You can also try it out on jsFiddle –

This appears to be specific to jQuery, which in this case wasn’t a big deal since all of the other code on the page was using jQuery as well. The Event object documentation mentions event.originalEvent, but doesn’t indicate that it can be used in this way.

Microjs, Long List of Libraries

I don’t recall the last time I’d looked at, but I’m quite sure the list of libraries was much smaller back then.

Some of the libraries listed, like Mustache, I’ve seen and played with before. Skimming through the list this morning, most of them are new to me. The number of libraries listed is impressive.

I’m still not sure that I’ll have a use for many of these, I suspect for most sites being able to rely on jQuery (and jQuery plugins) consistently will out weigh trying to save a few bytes here and there. I’m willing to be proven wrong though, which is why one of the reasons I find the microjs list so fascinating.

Do you have a favorite microjs library, or one that you can’t live without?

Delayed Loading Gravatars

About two months I looked at adding Gravatars to a page, where in most cases there would be 20 different Gravatars on each page view. This seemed like a good time to try out Paul Hammond’s Speed Up Your Site with Delayed Content technique for loading Gravatar images. A few quick hacks later it was working and I was reasonably happy with it.

Fast forward a few more weeks and I found myself wanting to add Gravatars to another page, but this time most of the page views were going involving loading 250 different Gravatar images. I went back to my original script for delayed loading, cleaned it up a bit and applied it to this new page. At this point I realized that this was something that would be nice to have as a simple to use, mostly drop in feature. So I refined it a bit more, made a few more improvements and I’m now making it public as Async Gravatars. The code is open source and available on Github at

The process and the code are actually very simple:

Step 1

Use the same SRC attribute for all of your Gravatar images in the IMG tag, with the md5 of the real Gravatar in the data-gravatar_hash attribute, like so:

<img data-gravatar_hash="713072bbe89035a79c17d19e53dd5d9b"
    class="load-gravatar" height="64" width="64"
    src="" />

For PHP powered sites something like this will do the trick:

<img data-gravatar_hash="<?php echo md5( strtolower( trim( $email ) ) ); ?>"
    class="load-gravatar" height="64" width="64"
    src="" />

It is important to use the same SRC for all of the images, that way your browser only needs to make on request for all of them. And by using a real image with the same dimensions you won’t have issues with the page re-flowing when the real Gravatar gets loaded. I should note that the one SRC value you use doesn’t have to be loaded from, it can be something that you host on your own site.

Step 2

Load the jQuery code and the async-gravatars.js file, then one small piece of Javascript to trigger loading of the real Gravatar images after the page has finished loading:

jQuery( document ).ready( function() {
    $( '.load-gravatar' ).async_gravatars( {
        ssl: true
    } );
} );

The .async_gravatars() function accepts the following options, with these defaults:

		'default_img'	: 'identicon',
		'hash_attr'		: 'data-gravatar_hash',
		'rating'		: 'pg',
		'size'			: 64,
		'ssl'			: false

Step 3

Sit back and enjoy, there is no step 3!


If you want to see it in action I put together a little demo page that loads a sample of Gravatar images for some of my fellow Automatticians. A demo page is also included in the Github project.

The Javascript code that does the work is very simple, so spend a minute or two and take a look. If you have suggestions or improvements let me know.

HTML5 Spec Calls For Altering Your Data

While reading the jQuery 1.6 release announcement I came across this gem:

jQuery 1.5 introduced a feature in the .data() method to automatically import any data- attributes that were set on the element and convert them to JavaScript values using JSON semantics. In jQuery 1.6 we have updated this feature to match the W3C HTML5 spec with regards to camel-casing data attributes that have embedded dashes. So for example in jQuery 1.5.2, an attribute of data-max-value=”15″ would create a data object of { max-value: 15 } but as of jQuery 1.6 it sets { maxValue: 15 }.

The portion of the W3C HTML5 spec mentioned is – and the specific wording in this regard is:

element . dataset
Returns a DOMStringMap object for the element’s data-* attributes.

Hyphenated names become camel-cased. For example, data-foo-bar=”” becomes element.dataset.fooBar.

My feelings on this are simple – this is an absolutely horrible idea! Why would you indicate that implementations of the spec actually alter the attribute names used in the HTML? The only result from this I can see is confusion and wasted time when code breaks from this but it isn’t obvious why.

To make this even more confusing the data attribute section of the spec also mentions:

Note: All attributes on HTML elements in HTML documents get ASCII-lowercased automatically, so the restriction on ASCII uppercase letters doesn’t affect such documents.

So even if you wanted to CamelCase your data attribute names, to avoid the auto conversion described in the spec, you can’t. Using data-CamelCase would become data-camelcase.

Where does all this leave the average web dev? Well, I think the easiest way out is to never, ever, ever use a name for a data attribute that the spec indicates will be altered. This means no dashes any where in the dev controlled section of data attribute names. That isn’t very pretty since the attribute is required to start with data-, but it is the safest route.

In practice this will result in either names with no breaks or using underscores where you would normally use dashes. “Safe” examples would be:

  • data-foobar
  • data-foo_bar

I’m really disappointed to see attribute name changes be part of the HTML5 spec. I’d be really curious to know what the justification was for this move.

jQuery Edit In Place (JEIP) Demo Fixed

I finally got around to fixing the jQuery Edit In Place demo page. The URL has changed – – but there is a redirect for the old one. I’ve had several people ask about this, sorry for the delay in bringing it back.

The styles used in the demo are just a basic example, you can tweak them in any number of ways via CSS.