While client-side validation provides a possibly snappier user experience, developers should constantly be reminded that the client cannot be trusted. Data integrity checks and conformance validation that matters must take place at the other end of the transaction.
There isn't really any way to dovetail client-side validation with server-side validation.
Client-side validation should always be assumed to be disabled completely - view it as merely a convenience for your users. Help them switch dates into a correct format, make sure their userids aren't taken before they finish filling out their forms, that sort of thing.
I am still implementing form validations as server-side validations and not sure I will ever change that.
Super easy to deal with on a simple ajax request and it's in place for all requests. If a POST/PUT is done with an ajax request simply return the error message. Otherwise, set the HTTP status code and render the form with the error as the response.
While we're on the topic of lightweight JS validation libraries, I released my own and have used it for well over a year on a number of production sites. It's quite feature rich and also very low on LOC. It already includes much of the support you guys mentioned here, including live validation and support for passing params. It's garnered towards those already utilizing jQuery sitewide who like things short and sweet. You can override and customize everything, but it also provides you with decent defaults.
The version I use now is tweaked with improvements. I'll gladly share it; I've just been busy and not posting much to the site. If you see problems with the validation methods, they've been fixed over the year in the new version.
I feel that the individual fields that have errors should be highlighted. While it's useful to say "The password field is required." at the top, it's more obvious to the user when the password field itself is highlighted in some way. A quick visual scan of the fields then lets you know where action needs to be taken.
It gets a +1 for being a non-jquery solution (jquery's fine for abstracting the DOM for animation and UX niceties, but you don't need to include what adds up to 2000 lines of code uncompressed just to find the contents of a text field and compare it), but this is the clincher.
The actual field that doesn't validate needs to be highlighted, because otherwise the disconnect between the error and the source makes it difficult to actually identify the source. The only other thing it needs is to position the error message adjacent to the invalid field.
When HTML5 is implemented better these things could be used more effectively. But HTML5 validation as it is now isn't useful until you can style the browser's errors.
It might be a better idea to hold off on the HTML5 stuff and work on polishing up the output :) Unless there's more control over the fancy new features now.
I've seen several projects named "validate.js". May I suggest coming up with a different name to let devs know which of the several libraries by that name they're working with? ("valid8.js" is already used too)
I really like seeing simple utility libraries like this be posted on github. It makes everyone's sites better when a lot of people contribute to a good library. Nice job, and kudos for working with everyone on pull requests.
Have you thought about adding support for boolean operators in the rule declarations? For example, "empty||valid_email" => "empty or a valid email", or "valid_email&&matches[email]" => "valid email and matches the 'email' field"? Basically, support for !, && (easy since this is the default behavior), and ||. To be honest, the use cases for this functionality is pretty limited but I think it'd be a nice feature to add just for the sake of practice. It would make handling error messages a little more complex though.
I tried to add something like this to a small validation library I wrote about a year ago. I think that part worked pretty well but otherwise it wasn't very well designed. Another problem I ran into was the lack of support for rules that depended on asynchronous operations.
I think you should have params to the validators, specifically for the regex case, in which the callback_ approach, with registration and such, is quite onerous.
I like this idea a lot. I chose to start out with the callback_ approach due to trying to mimic the CodeIgniter API. However, this would be much easier especially for just a regex.
Inline, instant validation would make this very useful as a compliment to full server-side validation. I agree that client-side validation can significantly improve the ux for forms.
The hope is that one day, browsers could have a native VRS implementation, and until that day Javascript and serverside scripting could pick up the slack.
I don't this this is much use because it's pretty much made to be a stand alone library. I think what we all want int 2011 is a ways to lift validation rules from the server to the UI automatically. Otherwise we still obviously need to do all the work on the server. Maintain two parallel sources that need to match their behavior is PITA.
