How to fix jQuery 1.7 Date Validation for UK dates in Webkit browsers

Turns out the jQuery date validation in jQuery Validate from 1.7 is pretty screwed… it prevents valid UK dates from being submitted in Chrome and Safari and allows nonsense like 31/31/2012 through in Firefox.

Lots of people use the fix here:

But it doesn’t seem to work in Safari: luckily commenter ‘Mad’ points to an alternate solution in Microsoft’s AJAX library which seems to work great everywhere:

		// Fix for international date validation woes in jQuery Validate
		// as described here, but fix only for chrome:
		// alternate method as linked from comments here
		// assign class 'date_international' to target datepicker text field instead of 'date'
			function(value, element) {
				var check = false;
				var re = /^\d{1,2}\/\d{1,2}\/\d{4}$/;
				if( re.test(value)){
					var adata = value.split('/');
					var gg = parseInt(adata[0],10);
					var mm = parseInt(adata[1],10);
					var aaaa = parseInt(adata[2],10);
					var xdata = new Date(aaaa,mm-1,gg);
					if ( ( xdata.getFullYear() == aaaa ) && ( xdata.getMonth () == mm - 1 ) && ( xdata.getDate() == gg ) )
						check = true;
						check = false;
				} else
					check = false;
				return this.optional(element) || check;
			"Please enter a correct date"

Slightly edited from


Mustache.js and ICanHaz.js

The server-side has never been in better shape, but on the client-side I still wrestle with how to structure applications so I don’t end up with gigantic piles of crap consisting of hundreds of nested anonymous functions. According to Rebecca Murphey, Dojo offers more grown-up approaches to keeping code well organised, but I still like jQuery and I want to keep using it. Besides which, in the contracting world you often don’t get to choose your toolset, but have to work with what’s already there. And jQuery is the game in town at the moment.

In large part thanks to Rebecca’s tutorials and videos, I’ve gone up a gear with my jQuery and now know how to structure it inside an object which makes it much cleaner and easier to write and maintain. But that’s only the start; there are a bunch of other pain points too, and a host of new libraries that are emerging as potential standard approaches to dealing with these issues.

There’s problems of approach when migrating functionality from server-side to the client. Firstly, if you can do all this stuff on the server side, lots of developers don’t get why you’d want to duplicate things like templating in JavaScript. PHP _is_ a templating language, why duplicate this stuff? Secondly, how to reconcile the longstanding web standards approach of progressive enhancement with this new world where the temptation – and even the best practice – seems to be to build functionality that only works with JavaScript on.

Do we need to do everything twice?

There seem to be at least four additional areas of concern beyond the basics of just getting it to work in the first place.

  1. MVC on the client side (e.g. backbone.js)
  2. Unit testing for JavaScript code (e.g. jUnit)
  3. Supplementing the basic language and smoothing over browser differences even more (e.g. underscore.js)
  4. Templating (e.g. mustache.js and icanhaz.js)

And a lot of libraries are expanding to cover more than one of these areas.

Honestly, the whole thing is a jungle right now. There are no clear winners and little evidence of consensus emerging as to which approaches are to be considered best practice yet.

At the moment, my take on it is that unless you’re building a single page app (think Gmail) then things like backbone are probably overkill just now. I’m still coming at this from the progressive enhancement end.

I’d like to look into the unit testing side at some point, but I don’t really have a good handle on this on the server-side yet either, so I’m leaving that for a bit.

I don’t really understand the need for the supplemental libraries like underscore; I’m not aware of having any problems that they solve, so ignoring them for now.

The scenario I’m looking into just now is a page which loads content initially as HTML, but then adds Ajax functionality once the page has loaded. Like a to-do list, where the list elements need to be iterated over on the server side when the page is loaded, and then repopulated on the client side as items are edited and added without a full page load.

I wanted to find some nice microtemplating approach not just for the client side itself, but where the same microtemplate could be used on the server side to build the page initially, as well as embedded into the page for later manipulation.

Turns out mustache has both JavaScript and server-side support, so that’s where I’m starting.

<p id="output"></p>
<li id="user_{{">
Hello I'm {{ name }}

$(function () {

var users = {data: [
{id: 1, name: 'ian'},
{id: 2, name: 'susan'}
var user = ich.user(users);