Parsley.js: never write a single JavaScript line to validate your forms(parsleyjs.org)
parsleyjs.org
Parsley.js: never write a single JavaScript line to validate your forms
http://parsleyjs.org
79 comments
At a past company, we for a period had an (extremely invasive) script hooked up to a form that would log events on every change on the form, keypress by keypress. We could pretty much watch people type by tailing our log for a while... It probably wasn't a very nice thing to do in terms of privacy (I've more than once accidentally pasted stuff into a form that I wouldn't like to submit...), but for the day we did it, it taught us a lot of things about user behaviour we never thought about before (and we made sure to wipe all the data).
E.g. users at the time anyway, had massive problems with dropdown lists (a substantial number of errors were down to users who had clearly started typing, and got what the dropdown moved to as a result of them typing out the correct value). We ended up avoiding them (expiry dates in our billing form, for example).
(This was more than ten years ago, though, so our specific finding might very well be invalid now, with people more used to websites)
I'm not sure how this type of validation would play out. On one hand, if done well, it gives people immediate feedback. On the other hand it gives you no hints about what causes common mistakes like that. I like the idea of logging the values on error...
E.g. users at the time anyway, had massive problems with dropdown lists (a substantial number of errors were down to users who had clearly started typing, and got what the dropdown moved to as a result of them typing out the correct value). We ended up avoiding them (expiry dates in our billing form, for example).
(This was more than ten years ago, though, so our specific finding might very well be invalid now, with people more used to websites)
I'm not sure how this type of validation would play out. On one hand, if done well, it gives people immediate feedback. On the other hand it gives you no hints about what causes common mistakes like that. I like the idea of logging the values on error...
I don't have hard stats on conversions; but I know that when I added some JS to turn form fields a nice green colour when validated filling out the form felt much more satisfying.
What about a hook where every time a user makes a mistake it sends the related data to a centralized location.
I can envision that could be easily to push this to Sentry https://getsentry.com/welcome/ using the Sentry Javascript Client
I can envision that could be easily to push this to Sentry https://getsentry.com/welcome/ using the Sentry Javascript Client
You can do the same thing with Google Analytics events. Use a non-interactive event with "form validation" as category, field name as action and entered value as label. You may miss some events based on the service limits, but the common trends will be obvious.
This is a clean way to solve the low hanging fruit of form validation, stuff like isItAnEmailAddress().
What I always find messy in web frameworks is doing validations which are more complicated.
For example a radio button choice which hides another form element which would otherwise be mandatory but should now not be filled in at all. Or where supplying a value between certain dates changes another date field from optional to mandatory and also must check that these dates are between certain values dictated by the first date field.
What I always find messy in web frameworks is doing validations which are more complicated.
For example a radio button choice which hides another form element which would otherwise be mandatory but should now not be filled in at all. Or where supplying a value between certain dates changes another date field from optional to mandatory and also must check that these dates are between certain values dictated by the first date field.
For one of my new projects, that is precisely what I am doing - making it possible to define complicated validation rules in a simple manner (and lots more). Would there be interest if we open-source it?
Quite possibly.
Though I'm not sure how much this could be generalised since complex validation rules are effectively computer programs in themselves.
Not sure what your approach to this problem is, but perhaps one way to do it would be a validation engine that is inherently functional by design.
Of course, ideally it should be something that can plug in to popular web frameworks easily.
Though I'm not sure how much this could be generalised since complex validation rules are effectively computer programs in themselves.
Not sure what your approach to this problem is, but perhaps one way to do it would be a validation engine that is inherently functional by design.
Of course, ideally it should be something that can plug in to popular web frameworks easily.
Data binding solves this generically. It allows you to build state machine trivially Stuff like angular and ember do this amazingly well though it would be nice to have a nice standalone library. (no idea if one exists)
Using a declarative DSL designed for validation rules should make it much simpler, it would minimize the amount of writing the boilerplate stuff that comes with a general purpose language and would focus solely on the actual validation rules.
It could be used in the same way as templating for javascript is used, a script element with a custom type or validation-src attribute in the form or something.
It could be used in the same way as templating for javascript is used, a script element with a custom type or validation-src attribute in the form or something.
Would love to see something like this, and if it's useful and easy to drop in, I'd use it.
Of course :)
Knockoutjs is nice for that sort of thing. They have a pretty quick tutorial: http://learn.knockoutjs.com/
Looks cool, but the demo right at the top of the "examples" page has two things that IMHO aren't as "UX aware" as described on the landing page:
- The "website" field requires the http:// part of the address - After typing three letters into the "message" fieldarea, an error pops up and tells me the message needs to be at least 20 characters long, while I'm still typing away
I realize this could be tweaked by the user but the demo shouldn't have such logical flaws for a script that's described as "Super #UX focused". ;)
- The "website" field requires the http:// part of the address - After typing three letters into the "message" fieldarea, an error pops up and tells me the message needs to be at least 20 characters long, while I'm still typing away
I realize this could be tweaked by the user but the demo shouldn't have such logical flaws for a script that's described as "Super #UX focused". ;)
Right. The demo form is totally UX un-aware! :)
This is neat.
A couple of points:
1- Client side validation is easy to circumvent. If you use this you have to make sure it is for UI only and that the real validation happens server side.
2- Using regex for email validation is fraught with issues. Probably the most salient one is that there are a million expressions out there. People run a quick google search, grab one and move on without knowing what they just plugged into their code. This particular tool will, for example, pass "[email protected]" as valid.
Other than that, I am sure this is a great time saver.
A couple of points:
1- Client side validation is easy to circumvent. If you use this you have to make sure it is for UI only and that the real validation happens server side.
2- Using regex for email validation is fraught with issues. Probably the most salient one is that there are a million expressions out there. People run a quick google search, grab one and move on without knowing what they just plugged into their code. This particular tool will, for example, pass "[email protected]" as valid.
Other than that, I am sure this is a great time saver.
Virtually every attempt at email address validation is overly strict, because the relevant RFC standards are vastly more liberal than people realise. Non-ascii characters above U+007F are valid since RFC 6530. An IP address in the domain part is valid. An @ in the name part is valid if it's escaped.
"異常.(),:;<>[]\".ຜິດປົກກະຕິ.\"அசாதரண@\\ \"অস্বাভাবিক\".არაჩ"@[IPv6:3ffe:1900:4545:3:200:f8ff:fe21:67cf] is a perfectly valid email address.
"異常.(),:;<>[]\".ຜິດປົກກະຕິ.\"அசாதரண@\\ \"অস্বাভাবিক\".არაჩ"@[IPv6:3ffe:1900:4545:3:200:f8ff:fe21:67cf] is a perfectly valid email address.
1. I agree, of course. Surely, everyone knows this right?
2. True, but you have to do something. :) What exactly is wrong with [email protected]? That could be valid domain at some point, right? You could filter those out but it's almost a preference sort of question. Does anyone think it would make sense to have "warning" level of validation for email addresses and let the user decide on these sort of examples? Just throwing it out there.
2. True, but you have to do something. :) What exactly is wrong with [email protected]? That could be valid domain at some point, right? You could filter those out but it's almost a preference sort of question. Does anyone think it would make sense to have "warning" level of validation for email addresses and let the user decide on these sort of examples? Just throwing it out there.
To fix that, you can do a DNS lookup and check the domain has a valid MX record.
Just be careful when you do this. If you don't use an absolute FQDN you can trigger severe delay in getting a response from the resolver. It can take twenty or thirty seconds (or more) to get a response.
At some point if you want to be absolutely sure, you'll have to send a validation link / email and not doing it frontend in JavaScript ;)
re point 2.
I don't see a problem with using a regex to validate email, unless you get false negatives. Rejecting anything that could be a valid e-mail address is bad and will cause frustration for someone at some point.
I don't think allowing validly formed e-mail addresses that don't have corresponding accounts (or even domains - consider a web app working in offline mode) is a bad thing, especially when taken with point 1, as surely the point of client side validation is a heads up to the user that the data is wrong, rather than actual validation?
I don't see a problem with using a regex to validate email, unless you get false negatives. Rejecting anything that could be a valid e-mail address is bad and will cause frustration for someone at some point.
I don't think allowing validly formed e-mail addresses that don't have corresponding accounts (or even domains - consider a web app working in offline mode) is a bad thing, especially when taken with point 1, as surely the point of client side validation is a heads up to the user that the data is wrong, rather than actual validation?
It's highly application dependent, right?
Say it's a signup form. Your validator lets a bad email through. The potential client/customer left. You can't email them to ask for correct email. They are gone. They may never come back (depends of what they were there for, right?). In that case I would want to do as much as might be reasonable in order to ensure that I capture someone who might eventually translate into revenue.
In other cases it might be just fine to store absolute gibberish and deal with it later. That said, if you have an incredibly popular site and are receiving thousands upon thousands of sign-ups per day, do you really want to store junk? Someone is going to have to go clean it up before it is of any use.
Anyhow, my main point, perhaps, is that one should understand what these magic regex email validators are and are not. That's all.
The reason I bring this up whenever relevant is because I have been bitten by this problem in the past. I only understood the problem when an existing customer informed me that they could not sign-up to receive info on a new product because my email validator was kicking them out. He just picked-up the phone and called me. I never did learn how many people I lost because of that damn regex I grabbed from an authoritative source on the 'net.
Say it's a signup form. Your validator lets a bad email through. The potential client/customer left. You can't email them to ask for correct email. They are gone. They may never come back (depends of what they were there for, right?). In that case I would want to do as much as might be reasonable in order to ensure that I capture someone who might eventually translate into revenue.
In other cases it might be just fine to store absolute gibberish and deal with it later. That said, if you have an incredibly popular site and are receiving thousands upon thousands of sign-ups per day, do you really want to store junk? Someone is going to have to go clean it up before it is of any use.
Anyhow, my main point, perhaps, is that one should understand what these magic regex email validators are and are not. That's all.
The reason I bring this up whenever relevant is because I have been bitten by this problem in the past. I only understood the problem when an existing customer informed me that they could not sign-up to receive info on a new product because my email validator was kicking them out. He just picked-up the phone and called me. I never did learn how many people I lost because of that damn regex I grabbed from an authoritative source on the 'net.
Nobody thinks a regular expression will prevent someone from signing up with an email that doesn't exist.
If you absolutely must have valid email addresses the only sure way is to make them confirm it with information from an email sent to the address.
If you absolutely must have valid email addresses the only sure way is to make them confirm it with information from an email sent to the address.
I think you are missing an important point. This isn't about email addresses that don't exist. You can't fix that. This is mostly about malformed or "illegal" addresses.
Scenario:
I somehow find myself at your landing page.
You have a single field for may email and a "Sign me up!" button.
I enter my email and sign up.
Your regex lies to you by thinking that the email is fine. In reality I made a mistake when I typed it in. I didn't notice it. Neither did your regex.
How are you going to contact me?
OK, if it is a small shop you can probably afford to have a human being review bounced emails and try to make some sense out of them. Well, what if you are signing up a thousand people a day?
Anyhow, the point is that a bad email addresses can cost you money both in customers that might never come back and also potentially in the manual work required to try to fix them manually.
Scenario:
I somehow find myself at your landing page.
You have a single field for may email and a "Sign me up!" button.
I enter my email and sign up.
Your regex lies to you by thinking that the email is fine. In reality I made a mistake when I typed it in. I didn't notice it. Neither did your regex.
How are you going to contact me?
OK, if it is a small shop you can probably afford to have a human being review bounced emails and try to make some sense out of them. Well, what if you are signing up a thousand people a day?
Anyhow, the point is that a bad email addresses can cost you money both in customers that might never come back and also potentially in the manual work required to try to fix them manually.
Why use <input type="text" data-type="email"> rather than... <input type="email"> ? You're already using HTML5 data attributes, so why not use HTML5 input types? Added benefit is that the browser also has an idea of what kind of data goes there - this helps on mobile devices especially, where email fields won't auto-capitalize and might include extra buttons like the ".com" button and "@" right on the normal keyboard.
Right.
jQuery/Zepto $.data() was fast and easy to implement, rather than searching html5 attr.
I'll think about that ;)
jQuery/Zepto $.data() was fast and easy to implement, rather than searching html5 attr.
I'll think about that ;)
It shouldn't be that hard to use a attribute instead: var data = $( self ).attr(type);
Nice.
Improve the demo by removing spellcheck from the name field and capitalizaton for ios (and likely other touch devices) where appropriate.
Along the same lines, demonstrate phone number field (number formatting), currency field, and automatically dealing with urls more nicely.
Improve the demo by removing spellcheck from the name field and capitalizaton for ios (and likely other touch devices) where appropriate.
Along the same lines, demonstrate phone number field (number formatting), currency field, and automatically dealing with urls more nicely.
Speaking with my security hat on: This is a really nice library, but you also do the same validations server side right?
Client side and server side validations need (should!) not be the same — i'd make serverside validation stricter. Client side is for eliminating honest mistakes not preflighting exploits.
Could you give an off the top of your head example?
The web is brimming with examples, here are a few:
1) You can only do a mod 10 check (aka the Luhn algorithm) for client-side credit card validation. Beyond that, you'll need to hit a server to run a CC authorization.
2) In the email check one commenter criticized re: correctly parsing "[email protected]", there are practical limits. Syntactically, that's a correct email address. To that you could add content checks such as validating against known TLDs. Then you've got to ensure that your whitelist is correct and that it remains up-to-date as the TLD namespace changes. As for evaluating the registered domain name client-side, ehhhh.. maybe not. At some point you've just got to go do the DNS lookup and send an email to find out if it's going to work.
In general there are classes of problems for which some lightweight validation is practical on the client, but full validation requires extended information or transactions that are im{practical,possible} on the client.
1) You can only do a mod 10 check (aka the Luhn algorithm) for client-side credit card validation. Beyond that, you'll need to hit a server to run a CC authorization.
2) In the email check one commenter criticized re: correctly parsing "[email protected]", there are practical limits. Syntactically, that's a correct email address. To that you could add content checks such as validating against known TLDs. Then you've got to ensure that your whitelist is correct and that it remains up-to-date as the TLD namespace changes. As for evaluating the registered domain name client-side, ehhhh.. maybe not. At some point you've just got to go do the DNS lookup and send an email to find out if it's going to work.
In general there are classes of problems for which some lightweight validation is practical on the client, but full validation requires extended information or transactions that are im{practical,possible} on the client.
About the only way to validate an email address (short of sending it an email) is to parse the email address using BNF from RFC-2822 (I use LPeg to do that) and if that passes, then do a DNS MX lookup on the domain; if that fails, then do a DNS A lookup on the domain. That will at least tell you that an email can be delivered, not that it will be delivered and short of sending email, that's about the best you can do.
An honest mistake: Your form has 3 required fields but the user only filled out 2. This shouldn't require a trip to the server.
A hack attempt may be a direct POST circumventing any client side checks.
A hack attempt may be a direct POST circumventing any client side checks.
At the risk of spamming (since it's my own blog), anyone still wondering about that question should read this or similar tuts - explaining that question and all the basic mistakes people make in validation & security
http://www.codebyjeff.com/blog/2012/12/web-form-security-avo...
Nothing to do with sexy xss & the like - just some simple foundation points when setting up your server side procesing
http://www.codebyjeff.com/blog/2012/12/web-form-security-avo...
Nothing to do with sexy xss & the like - just some simple foundation points when setting up your server side procesing
Great question. I would usually prefer server side validation, and with the nice integration that Rails provides between form errors and validations on the model, I am not sure how I can use this. Does anybody who uses a Rails stack combine both server side and client side validations?
I thought it was standard to have both. Server side validation to keep bad data out and client side validation to provide a nicer UX for the user than a complete page reload and them searching around for what went wrong.
Yeah, for some reason people always bring up server side validation on these kinds of posts about client side validation ... doesn't server side validation go without saying?
You'd think it goes without saying, but I've seen enough code where people didn't. Including code where the client side JS validation was pretty much a guide to hacking the site (trying in vain to protect against SQL injection attacks in one of the most horrific examples, where the SQL injection checks essentially told you exactly what to try to post directly to their server...)
Adding client side validations offloads some work from your servers. It could reduce the number of total requests that hit your server and overall increase your speed.
This may be premature optimization for a lot of cases but for form heavy apps this could be a useful optimization.
Also saving a round trip to the server can make the UX seem snappier and overall give a better user experience.
This may be premature optimization for a lot of cases but for form heavy apps this could be a useful optimization.
Also saving a round trip to the server can make the UX seem snappier and overall give a better user experience.
From a Django background which also provides form errors very easily, it seems at first glance that this would not be needed (and it technically isn't). However, it's often nice to the user to let them know of silly mistakes like passwords not matching or invalid emails before they hit submit and get bombarded with everything at once.
Javascript validation provides convenience, not security.
Javascript validation provides convenience, not security.
I usually use both for anything public facing. Server side is for security, client side is for UX. keeping it dry is a problem, obviously, but you don't always want the same validations server- and client-side.
Parsley's aim is to have think about validation just once back end and seamlessly do the same front end with no extra work. But yes that do not exempt you to validate backend ;)
I didn't write this, but I would say yes. You would have to check twice just incase someone tried to POST directly to your URI bipassing your form page.
This is fantastic. The jQuery Validation plugin has needed a successor for a long, long time.
Yes but then we need all the different validation methods that come with it. I use phoneUS and the like, I don't want to give that up.
They'll come don't worry ;)
Alright. Give us an example of how to make them and I'll fork, patch, and pull request.
The url validation seems a bit strict, requiring "http:// at the start. No one types that these days, and I think in practice it might be a real roadblock for less computer literate users. I notice also that "ftp://" is valid, but not other protocols like, say, "afp://" or "git://".
Other than that, great job! I'm actually really looking forward to using this in my next project - form validation is usually such a pain.
Other than that, great job! I'm actually really looking forward to using this in my next project - form validation is usually such a pain.
I'll take a look to url RegExp validation rule ;)
The implementation just smacks of AngularJS. In fact, implementing something like this would be just short of trivial using Angular...!
If you like the concept of "extending html" as used here then you should probably checkout AngularJS: http://angularjs.org
If you like the concept of "extending html" as used here then you should probably checkout AngularJS: http://angularjs.org
This looks more like Bootstrap to me. There is no "extending" going on, just adding some data-attributes to the markup.
At first glance, this looks like the best validation library I have seen. It so hard to find validation libs, that don't get into your way.
At first glance, this looks like the best validation library I have seen. It so hard to find validation libs, that don't get into your way.
Sometimes you just don't have or don't need angular or other js framework and just simply want to validate a form ;)
Yes quite, it is nice that is framework independent.
Looks very similar to the unobtrusive validation used in ASP.NET MVC (which in turn relies on jQuery validation) although this does seem to add richer configuration of behaviour (such as when the validation is triggered etc.)
from here: http://bradwilson.typepad.com/blog/2010/10/mvc3-unobtrusive-... <input class="text-box single-line" data-val="true" data-val-length="The field LastName must be a string with a maximum length of 60." data-val-length-max="60" data-val-required="The LastName field is required." id="LastName" name="LastName" type="text" value="" /> <span class="field-validation-valid" data-valmsg-for="LastName" data-valmsg-replace="true"></span>
from here: http://bradwilson.typepad.com/blog/2010/10/mvc3-unobtrusive-... <input class="text-box single-line" data-val="true" data-val-length="The field LastName must be a string with a maximum length of 60." data-val-length-max="60" data-val-required="The LastName field is required." id="LastName" name="LastName" type="text" value="" /> <span class="field-validation-valid" data-valmsg-for="LastName" data-valmsg-replace="true"></span>
I suppose this is more suited to when your models and schema are also defined on the client side?
Having just hit this situation (validating a form client-side), I found the best solution was to transport the form schema from the server (because I use Django, I can easily whip up a ModelForm), then push that into a simple Javascript Form object which renders the schema and adds validation. Maybe there's better ways, but that's what worked for me. Curious what others have done .. :-)
Having just hit this situation (validating a form client-side), I found the best solution was to transport the form schema from the server (because I use Django, I can easily whip up a ModelForm), then push that into a simple Javascript Form object which renders the schema and adds validation. Maybe there's better ways, but that's what worked for me. Curious what others have done .. :-)
Nice to have a full-blown client-side equivalent of schema definitions and validation rules, but for most of my forms, I just add it quickly and dirty. Sometimes it feels bad, but most web toolkits treat JavaScript as a second-class citizen and not an integrated part of its core (and no, throwing in a jQuery does not count).
Yii framework (PHP) supports validation through Ajax (serializes the form, sends for regular server-side validation and displays the errors on the form). A godsend if your form does not change, and impossible to work with if it is dynamic (consider batch entries with "Add line" features, etc.).
I haven't seen a seamless integration on this higher level.
Yii framework (PHP) supports validation through Ajax (serializes the form, sends for regular server-side validation and displays the errors on the form). A godsend if your form does not change, and impossible to work with if it is dynamic (consider batch entries with "Add line" features, etc.).
I haven't seen a seamless integration on this higher level.
Yii can also do client side validation (without an ajax call) for most of its built in validation rules.
Is the form definition-to-JavaScript code open source, by any chance?
I ported django.forms to JavaScript so I could use it with Node.js, but it also runs on the client: https://github.com/insin/newforms
Could be useful to plug the two together.
I ported django.forms to JavaScript so I could use it with Node.js, but it also runs on the client: https://github.com/insin/newforms
Could be useful to plug the two together.
With Rails I did come up with a similar solution to Parley.js. Just add a helper that renders the needed data-attributes and you're done.
Your solution sounds nice for single page apps.
Your solution sounds nice for single page apps.
This library looks great! I really like the functionality and the html requirement definitions.
I don't want to hijack, but I just want to link to the form library I wrote a couple years ago. It has a little less functionality, but it is a little lighter and has no dependencies. It is here: https://github.com/rickharrison/validate.js
I don't want to hijack, but I just want to link to the form library I wrote a couple years ago. It has a little less functionality, but it is a little lighter and has no dependencies. It is here: https://github.com/rickharrison/validate.js
Hey! I use that! Thank you for validate.js. validate.js + humanize.js works very well (but this morning I was considering using parsley.js. I'll evaluate it over the weekend I guess)
Very nicely done. Beat me to it. :(
I am working on a library which takes a data definition, renders the form and then validates it before submitting it via ajax. It supports various hooks like manipulate the data before submission etc.
IMHO form rendering (in a standard way) is also a common pain point along with form validation. Anyone interested in this type of library? Any inputs will be highly appreciated.
I am working on a library which takes a data definition, renders the form and then validates it before submitting it via ajax. It supports various hooks like manipulate the data before submission etc.
IMHO form rendering (in a standard way) is also a common pain point along with form validation. Anyone interested in this type of library? Any inputs will be highly appreciated.
Great. How about internationalization?
Do you allow to replace the english error messages with messages in other languages?
That is what I came here to ask. Is there way to define the error messages somewhere, per language?
Yes, not very handy currently, but you could override all messages in Parsley constructor on each form..
I'll look definitely into a more handy solution soon :)
I'll look definitely into a more handy solution soon :)
i18n is a must for most projects to use it :D, we would love that.
I suggest you do add this on cdnjs ;) https://github.com/cdnjs/cdnjs
Typo in the "Super Free" section on the home page: s/developped/developed
thx! will fix that :)
Very good, I'll give it a fair try in my next project.
"DOM-API" is redundant, as the DOM is an API.
thanks so much! very excited to use this in a project we're working on.
Loved this
Nice lib!
Other comments talked about client-side validation being mainly for UX and user convenience. But I'm wondering if it has a noticeable effect on whether or not people actually submit the form all the way to completion (i.e. no errors).
I made a tool that I have server-side form validation. I found that saving the invalid input so that I could examine it later was extremely valuable in understanding what people were entering, so that I could make the tool smarter. A good example is like with Parsley's demo where it requires http:// for the website URL. After seeing that people tried to enter URLs without http://, I knew I could change my code to automatically infer it. http:// is obvious, but a lot of times, people will surprise you. I don't have stats, but presumably this kind of change increases conversion. I realize this anecdote is a different effect than what I'm asking about client-side validation.