Release: Validation Plugin 1.14.0

The first stable release of the jQuery Validation Plugin, 1.0.0, came out in June 2007, making the project now a little over 8 years old, pretty seasoned for a JavaScript library. According to, its the 25th most popular JavaScript library, with over 1.3 million websites using it. I’m happy to announce the 14th release (discounting various patch releases) of the project, bringing it up to 1.14.0. While a lot of people contributed to this release in some form, I’d like to give Markus Staab a special call out. He’s been helping with ticket triage along with addressing some issues himself, overall being a big help in keeping the project alive.

The release itself brings a lot of small improvements and fixes, along with several new localizations. The plugin now relies of jQuery’s .on() and .off() method, making jQuery 1.7.0 the minimallay supported jQuery version. For a full list of all the changes, check out the changelog below.

Download this release.

If you use the plugin, please donate or ask your boss to make a donation! This helps to run the plugin site and makes releases like this one possible.

Click here to lend your support to: jQuery Validation Plugin and make a donation at!

33 people contributed to this release. A big thank you to: a-barry, Ajay Singh, Brahim Arkni, Calinou, Carles Jove i Buxeda, Daniel DeGroff, Darshan Jani, David Weston, dnomak, Florent, hanumanum, Igor, James, jered, Jesus, Maks, Maks3w, Manuel Dalla Lana, Marek ‘saji’ Augustynowicz, Markus Staab, Merab Tato Kutalia, Michael J, Nadi, Pietu1998, rskm1, Ryley Breiddal, sekander, Shimmy, Shonetow, Stefano Stoduto, wozzo, Yair Sladowsky, Zen Chua.

  • Please post questions to the official Using jQuery Plugins Forum, tagging your question with (at least) “validate”. Keep your question short and succinct and provide code; a testpage makes it much more likely that you get an useful answer in no time.
  • Please post bug reports and other contributions (enhancements, features, e.g. new validation methods) to the GitHub issue tracker

The full changelog:


  • Remove unused removeAttrs method
  • Replace regex for url method
  • Remove bad url param in $.ajax, overwritten by $.extend
  • Properly handle nested cancel submit button
  • Refactor attributeRules and dataRules to share noramlizer
  • dataRules method to convert value to number for number inputs
  • Update url method to allow for protocol-relative URLs
  • Remove deprecated $.format placeholder
  • Use jQuery 1.7+ on/off, add destroy method
  • IE8 compatibility changed .indexOf to $.inArray
  • Cast NaN value attributes to undefined for Opera Mini
  • Stop trimming value inside required method
  • Use :disabled selector to match disabled elements
  • Exclude some keyboard keys to prevent revalidating the field
  • Do not search the whole DOM for radio/checkbox elements
  • Throw better errors for bad rule methods
  • Fixed number validation error
  • Fix reference to whatwg spec
  • Focus invalid element when validating a custom set of inputs
  • Reset element styles when using custom highlight methods
  • Escape dollar sign in error id
  • Revert “Ignore readonly as well as disabled fields.”
  • Update link in comment for Luhn algorithm


  • Update dateITA to address timezone issue
  • Fix extension method to only method period
  • Fix accept method to match period only
  • Update time method to allow single digit hour
  • Drop bad test for notEqualTo method
  • Add notEqualTo method
  • Use correct jQuery reference via $
  • Remove useless regex check in iban method
  • Brazilian CPF number


  • Update messages_tr.js
  • Update messages_sr_lat.js
  • Adding Perú Spanish (ES PE)
  • Adding Georgian (ქართული, ge)
  • Fixed typo in catalan translation
  • Improve Finnish (fi) translation
  • Add armenian (hy_AM) locale
  • Extend italian (it) translation with currency method
  • Add bn_BD locale
  • Update zh locale
  • Remove full stop at the end of italian messages

Rule of Thumb

A rule of thumb describes an approach based on intuition, in contrast to one based on rationality and calculation. I think its fair to say that science is all about rational, calculating, data-driven approaches, where intuition is considered irrational and unreliable. The scientific method is, among other aspects, about eliminating the effect of various biases, like the availability bias (the first thing that comes to mind is seen much more favourable than other options; Daniel Kahneman describes many of these in “Thinking, Fast and Slow”). In this article I want to provide examples where rules of thumb are a better alternative to scientific research for making personal decisions.

Consider food. The 20th century has seen many trends come and go, arguing for some aspect in one decade, arguing against the same aspect in the next. Fat is good, fat is bad; carbs are good, carbs are bad. When it comes to the cancerogenic or cancer preventing effects of food, there are many medical studies involved, but have those gotten us any further? Consider this graph from a article about news about medical studies:


Note the headline on that graph: “Everything we eat both causes and prevents cancer”. I feel like that’s still the wrong way to think about it. Consider this instead: Food doesn’t cause or prevent cancer. Human bodies are not machines that all have the same requirements, they are more complicated, flexible and unique. As long as given the right nutrients, your body will function regardless of the specific food you eat. As the author concludes: “As we turn away from the magic pills and miracle treatments, I think we’ll focus more on the things that actually matter to health — like education, equality, the environment.”

Education, equality, the environment, these are all interesting areas, but then food is certainly important to us as well, and surely has influence on our health. But can medical studies really help us decide what food to eat, when they contradict each other so much? In this case a rule of thumb is likely our best bet. To answer the question of “What should I eat (to not get cancer)?”, the rule of thumb given by Michael Pollen in his book “In Defense of Food” could work pretty well:

Eat food. Not too much. Mostly plants.

Note that this doesn’t require peer-reviewed studies published in journals to understand. This rule of thumb itself seems pretty intuitive to me. But more importantly, it’s simple, easy to remember, and easy to apply. It’s not precise, it leaves plenty of ambiguity, and that’s fine. It can help make quick decisions about what and how much to eat, without getting you into decision paralysis, where you can’t decide among too many options or contradicting recommendations. And if this rule of thumb doesn’t work for you personally, then you can look for another one.

If the idea of using rules of thumb as outlined above is intriguing to you, I can highly recommend the book “Risk Savvy: How to Make Good Decisions” by Gerd Gigerenzer (also available in German as “Risiko: Wie man die richtigen Entscheidungen trifft”). The author covers various other rules of thumb (for example, for picking food from a restaurant menu), but also discusses risk and decision making from other perspectives. Its among a few books that influenced my thinking quite a lot lately.

PS: Thank you Lars, Tomasz and Enes for reviewing drafts of this post and providing valuable feedback.

jQuery Foundation 2014 roundup

In January 2014, now 11 months ago, the jQuery Foundation published its new mission statement:

To improve the open web, making it accessible for everyone, through the development and support of open source software, and collaboration with the development community.

I was one of the directors of the jQuery Foundation who worked on that statement, along with the more detailed explanations. There are two areas in particular that I want to go into, explaining what we’ve done in those areas in the past, this year in particular and what we’ve planned for the future. This is my own perspective.


Working with standards bodies, such as W3C, WHATWG, and TC39, to build the open standards that browser vendors and developers rely on.

The jQuery Foundation became a member of both W3C and ECMA when we founded it in early 2012. Since then we’ve had Yehuda Katz and Rick Waldron, as representatives of the jQuery Foundation, on the TC39 committee, which is responsible for the ECMAScript specification, also known as JavaScript. Rick has been publishing notes of the meetings, providing visibility into the complete proceedings. Yehuda has also been involved in various groups at the W3C, like the TAG (there’s a photo here with the TAG from 2013, including Yehuda and Tim Berners-Lee). There’s probably a lot more going on, but without a somewhat abstract overview, it is rather difficult to follow. This is one of the problems we’ve been discussing on the board: How can we communicate to the public what we’re doing for web standards? We want the attention and feedback of web developers that eventually have to use those standards, once implemented in web browsers. Following the many W3C and other standards mailing lists is hardly practical for most web developers.

I intend to write more about this in the future. Maybe I can interview Yehuda every once in a while and then write about his standards activities. Or work with Rick to create summaries of his meeting notes, that are more accessible to those not attending the meetings, by focusing on the higher level concepts, not so much the nitty gritty details of the language specification.

Libraries and tools

Working with individuals and organizations to implement libraries, frameworks and tools for web developers.

This is something I’ve been involved in much more directly. An important point here is that those libraries, frameworks and tools don’t have to be owned by the jQuery Foundation. In some cases that makes sense, but there are many projects where we collaborate with other projects.

jQuery Core

Of course we still maintain jQuery itself, often referred to as jQuery Core. The Core team recently published their plans for jQuery 3.0 and jQuery Compat 3.0 (note that its Compat, from Compability, not Compact). From the announcement:

  • If you need support for the widest variety of browsers including IE8, Opera 12, Safari 5, and the like, use the jQuery-Compat 3.0.0 package. We recommend this version for most web sites, since it provides the best compatibility for all website visitors.
  • If your web site is built only for evergreen leading-edge browsers, or is an HTML-based app contained in a webview (for example PhoneGap or Cordova) where you know which browser engines are in use, go for the jQuery 3.0.0 package.
  • Until we announce otherwise, both packages will contain the same public APIs in correspondingly-numbered major and minor versions. This should make it easy for developers to switch between the two and be maximally compatible with third-party jQuery plugins.
  • The point of the jump to 3.0 is mostly to change jQuery’s implementation of Promises, to make them compatible with the standard. The decision to make that change took a while, since the implementation in jQuery existed long before the standard was written, and breaking code that relies the implementation in jQuery is not something undertaken lightly. But for the sake of standardisation, its going to happen as part of the 3.0 major release.

    jQuery UI

    jQuery UI has been around almost as long as jQuery Core, though I think its future is much more exciting, and where jQuery could be considered almost done, we still have a lot of work ahead of us for jQuery UI. One of the efforts that has been going on for several years by now is the adoption of pointer events, to replace both mouse and touch events. Pointer events provide a sane unified event model, unburdened by Apple’s patent threat. While Chrome recently decided not to implement pointer events, we hope to change their mind by getting to the point where a pointer event polyfill (PEP) is only needed in Chrome, thus making it the slowest browser to handle pointer events, which they hopefully wouldn’t let sit for long.

    Another big effort is in the area of CSS frameworks. jQuery UI introduced its own CSS framework with 1.7, released in March 2009, but since that focused on styling widgets and not generic page elements like headers or forms, it never gained as much popularity as more recent projects like Bootstrap or Zurb Foundation. We’ve looked into adopting an existing CSS framework to replace the one in jQuery UI, and talked to many project teams for that. In the end we’ve decided to start a new effort, yet unnamed, to create a new CSS framework (the GitHub repo will probably be renamed once the project has a name), to be used by jQuery UI and jQuery Mobile, but also, hopefully, many other projects. Even if everyone still rolls their own, we hope to create at the very least naming conventions that can be shared. As Scott wrote:

    The first layer is a set of class names and DOM hierarchies for everyone to follow. Then we’ll build an implementation of that, which hopefully many will use. But the most important thing is that no matter how many implementations may exist, if they all use the same class names and DOM hierarchies, then they’ll all be interchangeable.

    Hopefully we end up with lots of “themes” built on top of our structural work, rather than lots of varying implementations of the structural parts, since we’re trying to reduce the amount of duplicated effort and the overwhelming choice that developers face today.

    Another important point of this new effort is to implement CSS performance testing. This is something the Topcoat team has been doing, and I’m excited about them joining our effort. Again, even if everyone is rolling their own, sharing tools to test and improve the performance of CSS frameworks will benefit everyone.


    A new release of QUnit is right around the corner, introducing better APIs for async testing, ala grunt with an assert.async() method and with direct support for Promises, and many other improvements. In parallel to the new release we’ve also started a project, lead by James Greene, to create a standard for reporters for testing tools. Let’s say you want to run your JavaScript unit tests on BrowserStack or SauceLabs or inside PhantomJS, or on Travis or Jenkins or other CI systems. In each case, you need to report the results back to the user. Currently each testing tool of the above has to write a separate custom integration layer for each unit testing tool, like Mocha, Jasmine or QUnit. This is something the js-reporters projects addresses. So far we’ve worked out a list of event names that can be used by all unit testing frameworks. There’s a lot more to do and as usual with standards efforts, it takes time.


    Globalize is another jQuery Foundation project that has been around for a while. It started with a culture database extracted from Microsoft’s .NET platform. This was a decent starting point, since it covered a lot of cultures, many more than gathering contributions from individual users would have provided. But there were also many issues in this database. Either entries were just wrong, or categories were missing, for example data to format relative time, like “5 minutes ago” or “in 2 years”. The idea to migrate to CLDR as the culture database came up in 2012. The ball got rolling when Rafael Xavier, a member of the jQuery UI project, started looking at the newly released JSON version of CLDR. Since then he rewrote Globalize on top of CLDR, significantly extending the available features, e.g. adding plurals and message formatting.

    A few months into this effort we realized that other projects could benefit from CLDR as well. We suggested collaborating with Moment, probably the most popular library for formatting and parsing dates. Moment still uses a culture database based on user contributions. The maintanence of that database caused the original Moment author, Tim Wood, to abandon the project. Unfortunately migrating to CLDR is a big effort that the current maintainers haven’t been able to make progress on.

    To reduce the effort of using CLDR, Rafael has published two modules: cldr-data makes it easy to specify CLDR as a peer dependency (in npm; in bower it’s a simple dependency), cldrjs simplifies traversal of the CLDR JSON data structure. Both can be used independently of Globalize, for which they’re dependencies. Rafael has started a pull request for IBM’s ECMA-402 (Intl) polyfill to use cldr-data. We’ve also had discussions with the team at Yahoo behind FormatJS to adopt cldr-data, and also to focus efforts on a single Intl polyfill.

    Recently Rafael started a mailing list, to discuss and collaborate on globalization projects for JavaScript. He also created a site and gathered many contributions to list globalization projects, their strength and weaknesses, along with a feature grid. This is both a great help for maintainers of these projects, since they can see what others are doing and where they should concentrate their efforts, and for users, since they don’t have to find and compare all the available solutions.

    We’re currently working towards Globalize 1.0. Once that is done we’ll spend more time looking at ECMA-402 aka Intl, to see if Globalize could wrap or use the formatting APIs (Intl has no parsing). We want to get everyone to use and contribute to a single Intl polyfill (there’s currently at least two). We’d still like to get Moment to switch to CLDR, and discussed them adopting Globalize for their date parser and formatter.

    There is more going on within the jQuery Foundation’s own projects. For the rest of this post, I want to cover one of the projects we’ve been contributing to.


    jscs is the “JavaScript Code Style checker”. Unlike jshint, which looks at code semantics, jscs only cares about code style. Together they are very useful tools for writing consistent JavaScript. jscs was started by Marat Dulin. The two most active maintainers are now Oleg Gaidarenko and Mike Sherov, both members of the jQuery Core project. Within the various projects of the jQuery Foundation, we’re using jscs with its “jquery” preset, one of currently eight presets. The presets are a great way to start using jscs without spending much time configuring it. I’ve recently started using jscs on a project and tried several presets, then picked the one that produced the least number of errors. After fixing the remaining errors, I now have jshint and jscs preventing regressions in code semantics and code style, running locally on each developer’s machine and remote on a continuos integration system.

    There are many more projects we’re contributing to, but that’s also something for another day. For now I hope that this post gives a good idea of what the jQuery Foundation is doing for the open web and web developers everywhere.

    Release: Validation Plugin 1.13.1

    This is a patch release for the jQuery Validation Plugin. It contains a few changes, though most notable is the fix for the newly implemented aria-describedby-based behaviour for error elements introduced in 1.13.0. That turned out to have a few issues which are now addressed.

    Thanks to Markus Staab, who’s have been helping with ticket triage.

    Download this release.

    If you use the plugin, please donate or ask your boss to make a donation! This helps to run the plugin site and makes releases like this one possible.

    Click here to lend your support to: jQuery Validation Plugin and make a donation at !

    4 people contributed code to this release. A big thank you to: Barry vd. Heuvel, colemanw, Damian Mooyman and fernandopasse. Also thank you to everyone who reported issues on GitHub or commented on them.

    As usual:
    • Please post questions to the official Using jQuery Plugins Forum, tagging your question with (at least) “validate”. Keep your question short and succinct and provide code; a testpage makes it much more likely that you get an useful answer in no time.
    • Please post bug reports and other contributions (enhancements, features, e.g. new validation methods) to the GitHub issue tracker

    The full changelog:


    • Add postalcodeBR method (cc6c4a4)
    • Fix pattern method when parameter is a string (4cecd73)


    • Ignore readonly as well as disabled fields. (9f4ba10)
    • Improve id escaping, store escaped id in describedby (#1269, d36d1bc)
    • Escape id/name before using it as a selector in errorsFor (#1275, 20f3e9f)
    • Allow 0 as value for autoCreateRanges (fe14d00)
    • Apply ignore setting to all validationTargetFor elements (f1c611e)
    • Use return value of submitHandler to allow or prevent form submit (#650, 8b2f1e0)
    • Explicit default for focusCleanup option (#676, 0cb3c95)
    • Fix incorrect regexp (#1200, c054707)
    • Don’t trim value in min/max/rangelength methods (#1274, 452b823)