Validate forms like you’ve never been validating before!
This has been the, a tad silly, tag line for the jQuery Validation Plugin for a few years now. Back in 2006, when Jörn Zaefferer started that plugin, he was still employed as a Java developer, contributing to jQuery mostly in his free time. Of the half-dozens plugins he started then, the Validation Plugin became the most succesful and is still quite popular today (builtwith.com knows about more than 300.000 websites using the plugin).
This is going to change! And you can be a part of that!
Jörn is looking for donations to spend quality time on the project. The roadmap below outlines a lot of work, probably a lot more than than can be covered by the 4000€ he’s currently asking for.
But that also depends on how much people will contribute in other ways. One part of this effort is to build a community around the plugin.
How can you help?
There’s a few things you can do:
- You can directly donate to the campaign, any amount helps.
- You can also help with the project itself: Look at the roadmap below and see if there’s something you can help with directly or indirectly. Know a good designer who could help with logo and website design? See if you can get them in touch with me. Know a technical writer who could help with website copy and documentation? Also very welcome!
The roadmap below is the big master plan. Once some funding is available, I’ll start at the top, while also trying to get people involved to help. The more funding available, the more we can cover.
The roadmap isn’t final. If you have interest in a certain feature, be sure to let me know. Filing an issue on GitHub is the best way for that.
Milestone 1 – RebootThe goal of this stage is a reboot of the plugin project. Once completed, the plugin is more easily available to a larger audience, providing higher quality code and documentation. The tasks include:
The Bugfixing, Website and Tests tasks can start in parallel, while the other two at least partially depend on the Website to be completed.
1.1 BugfixingWhile the plugin had been migrated from Google Code to GitHub in 2009, issue tracking is still scattered across the old jQuery Plugins Site and the GitHub issue tracker. The first step in consolidating these is a full review of the existing tickets on the old tracker, recreating valid ones on GitHub.
The next step is to review all open tickets, labelling critical bugs as such, and fixing them for the next release of the plugin. That release is independent of any other task in this milestone.
1.2 WebsiteCurrently the plugin has four different sites (original, documentation, plugins site, GitHub repository) without any of them actually looking like the primary resource for the plugin. This situation is likely to scare off a lot of potential users.
A new website is required, with its own top-level domain, name and logo consistent with the plugin. This new site will host an overview of the plugin, downloads (zip, cdn links), documentation (API, Getting Started, Reference Guide) and a blog for updates, including new releases. The secondary resource to link to is the GitHub repository, for bug reporting, feature requests and contributing.
Once the site is complete, links and redirects need to be created on existing sites. All search results need to point to this new site for queries like “jquery validation” instead of the existing properties.
1.3 DocumentationCurrently the documentation for the plugin is hosted on a MediaWiki instance on docs.jquery.com/Plugins/Validation. It uses the templates that were created for documenting jQuery, before the migration to api.jquery.com. There is ongoing work for an improved documentation format, based on the work for api.jquery.com, for use by both jQuery Core and jQuery UI.
The goal of this task is migrating the existing documentation to that new format, and hosting it on the new website. The Getting Started guide should be rewritten, the Reference updated.
The material about the Validation Plugin from the jQuery Cookbook’s chapter 10 should be integrated into the existing documentation, or replacing it (the book’s content consist of material under a non-exclusive license and can therefore be reused by the individual authors).
1.4 DemosThe existing demos consist of a mix of basic examples, API showcases and real-world examples. Especially the API showcases are mostly outdated and not helpful.
The goal of this task is to overhaul the existing demos, making them more useful for promoting the plugin and learning how to use it.
The demos should consist of a Getting Started example, API walkthrough (integrated into the actual API documentation) and real-world demos.
There should be a new or improved demo on styling a form with jQuery UI (including custom controls) and combining that with the validation plugin, including overlay error messages with ThemeRoller-styles.
1.5 TestsThe unit test suite, while covering most of the code, is not well structured and usually produces a lot of seemingly unrelated test failures for a single issue.
The goal of this task is to overhaul the existing unit testsuite, for more succinct tests that are easier to maintain and extend for further development.
The testsuite should be structured into more useful modules, based on different units of the actual implementation. This means splitting the overloaded tests/test.js into multiple files and rewriting a lot of the tests to only test one unit, reducing the number of unrelated test failures after a breaking change.
Milestone 2 – Validation Plugin 2.0During this stage the following components are to be implemented:
- Adapt widget factory
- Redesign options, methods and events; custom selectors
- Better internationalization
- Mobile support
- ARIA support
- Plugin repository for additional methods
2.1 Adapt widget factoryBack in 2006, when the plugin got created, patterns for creating plugins like the jQuery UI widget factory didn’t yet exist. And while the practice of exposing only a single plugin method was already in place, is wasn’t practical for the plugin, as it needed a few more methods exposed to the user. The initial design, applying the .validate() to the first selected form element and returning the validator instance, was kept for backwards compatibility over the years.
This design is outdated and should be replaced by making use of the jQuery UI widget factory, which provides a useful abstraction for exposing just a single jQuery plugin method, while underneath creating an instance (replacing today’s validator object/instance) with prototype properties and a way to call these methods directly or through the single plugin method.
The most common usage of the plugin should continue to work once this task is completed. For all breaking changes, proper documentation (updated examples, upgrade guide, optional compatibility plugin) need to be written.
2.2 Redesign options, methods and events; custom selectorsThe current plugin has 25 options, adds four plugin methods, three custom selectors, five public methods on the validator instance and three public functions on the validator object. There is one custom event called “invalid-form”, which overlaps with one of the options. Of the 25 options, a total of 11 options deals with customizing error display.
The plugin as-is makes validating a simple form trivial and most customizations possible. Though by redesigning the options, methods and events, its possible to simplify the overall API while making a lot of tasks even easier and some currently impossible tasks possible.
Potential changes include:
- Merging the rules and messages options. They should be more consistent with specifying inline rules (via type, class or other attributes, e.g. custom data- attributes)
- Merging standalone plugin methods into the validator instance, though need to figure out an API to still allows element-specific queries (valid(), rules()).
- Remove removeAttrs method, use remoteAttr instead, since 1.7 it supports space-separated lists of attributes to remove.
- Replace the one existing event and a good bunch of existing options with a consistent set of events, for valid and invalid forms and elements
- Find alternatives for the custom selectors to drop them or campaign for inclusion in jQuery Core/Sizzle
2.3 Better internationalizationThe validation plugin currently bundles localized default messages in 39 different languages (40 cultures due to support for both portuguese and brazilian portuguese). There are just three localized date-methods.
Extending the coverage on default messages to more languages and cultures requires help from translators. To get more individual contributors or a translation bureau involved requires a list of missing cultures. A simple process for submitting and reviewing translations needs to be set up. Git and GitHub pull requests shouldn’t be the only way to contribute.
For better localized date and number validation the Globalize plugin should be used. It supports over 300 cultures and can parse and format numbers and dates. Using the parser as a validator should be feasible. There’s a related ticket on the Globalize plugin issue list.
2.4 Mobile supportjQuery Mobile is a great tool for building mobile sites, and while it bundles themeing and custom controls for forms, it doesn’t include any support for form validation.
It turns out that the plugin already works well together with jQuery Mobile. Based on that the plugin should bundle a demo and some documentation on how to style the error messages for different layouts.
2.5 ARIA supportThe ARIA specification describes attributes that web applications can use to provide information to screenreaders that otherwise rely on visuals. For example, a red background color on an invalid input is still just an input for a screenreader. By adding the aria-invalid attribute to the input, the screenreader can tell the user about the invalid input.
Just adding these attributes is unfortuantely not enough to make the form validation more accessible. The specification is written primarily for implementers and therefore often leaves a lot of room for interpretation for consumers. Actual implementations are found in just a few screenreaders, and while the free screenreader NVDA is usually very good at implementing the spec, the commercial screenreader JAWS is much more popular but has only bare ARIA support. This support gets better with each JAWS version, but a lot of JAWS users get stuck with one version and rarely upgrade.
To get ARIA support implemented nonetheless, the research and reference implementation by Felix Nagel for a ARIA supporting form validation should help a lot.
2.6 Plugin repository for additional methodsThe plugin will always only bundle a limited amount of validation methods. Custom methods are easy to write, but have mostly untapped potential for reuse. Creating some sort of plugin repository that provides additional methods along with tests, documentation and demos for each, and some way to easily contribute these, would help gathering these custom methods. It should replace the current additional-methods.js as bundled with the plugin so far. The current work in progress new plugin repository (to replace plugins.jquery.com) should be the primary platform for such a repository, maybe by adding enough metadata to make individual repositories that contain additional methods a child of the validation plugin repository, so that they are easy to find when looking for the validation plugin.
Spread the word
Help us get enough donations to get this project the attention it deserves. Share it on Twitter, Facebook, G+, Orkut, in your office, local newspaper, train station, airport, parliament! Call your senator!