The Search for an Efficient Form Validator

I’ve been working on a contact form for A6X. My plan was to do inline validation as well as serverside validation. Ideally, everything gets validated on the client end and the server just does a double check, instead of having to output an error message.

My conditions were:

  • the javascript validator needed to be HTML5-compatible
    • recognize html5 form elements, with graceful fallbacks
    • replaces built in html5 validation tooltips (i’m actually surprised at how bad these look in chrome…)
  • validate only after text is written, NOT specifically on blur/focus/click/mouseover(i’ve seen this before. why?!)/whatever
    • smart enough to not validate placeholder text
  • allows the option to either validate on submit or onblur (see above point)
  • ideally uses html5 validation methods whenever possible, with a fallback to inline js regex
  • submit button is disabled with javascript and enabled only when everything validates

Of course, I haven’t been able to find a single plugin which meets all of these conditions. Only one even comes close and I still have a lot of issues with it. For instance, I had to rewrite the phone regex because it was not flexible. The e-mail regex doesn’t even allow uppercase letters. Um, HELLO?!?! Lots of people add uppercase letters to their e-mail addresses to help distinguish specific words.


Tell me, which is easier to read? Exactly.

And I really don’t understand why most validation scripts validate directly on blur. Or on focus. Validation needs to work like this:

  1. Disable the form submit button on page load
  2. On input blur (input loses focus), check whether the input is a) blank or b) the placeholder text.
    1. If it’s the default text, do nothing.
    2. If it’s not the default text, validate it.
  3. If an input is determined to be invalid, it gets an invalid CSS class.
    1. You should be able to define how far up the DOM the class is added. I.e. parent or up the DOM until it finds a specific class/element/etc
    2. Any error message is enabled with this class as well.
      1. for example: .invalid .error-message {display: block;}
  4. If an input is determined to be valid, it either receives a valid class or does nothing
  5. Upon determining that everything is valid, the submit button is re-enabled.

No javascript? No problem. Since the submit button is disabled with javascript, any no-js browser will still be able to submit the form. And that’s where the serverside validation comes in.

Check out how the serverside validation would occur:

  1. With JS, you would either add/remove a hidden form element. In this case, we’ll add a hidden element called “uses-js”.
  2. When the form is submitted, serverside detection is used to see if a hidden element called “uses-js” is posted.
  3. If it is, the server assumes that the form is valid.
  4. If it isn’t, the server will validate.
  5. Once validated, the form gets its further processing (stored in database, e-mailed, whatever)

Obviously, this isn’t perfect. Any bot targeting the system directly could inject that input. And the form could be submitted using javascript from the console.

However, as long as you have some sort of anti-bot code and sanitize your data, you can just relax and move on. Note that I’m also a huge advocate for using alternative methods to CAPTCHA, but that’s for a different post.

I did just come across html5ifv which seems to be pretty extendable, but it still requires too much on my part to make it function the way I want.

It’s possible that what I’m asking for is very specific. But regardless, I think that’s essentially how form validation should be designed. I don’t think it’s difficult to achieve. I’ll probably end up creating something and posting it on github.


One response to “The Search for an Efficient Form Validator”

  1. I accidentally posted this on the wrong page, sorry. I just wanted to re-post it in the correct place.

    Hey there,

    This is Justin Kimbrell from Objective HTML. I just read your article on form validation and appreciate your thoughts and input. I completely agree with most of what you said.

    To be clear, my form validation script is really a work in progress, It’s something I have been studying for the past few years, and slowly implementing over time. It has gotten somewhat stagnant in the past several months, really just due to a lack of feedback. I get a good deal of traffic to my site in regards to form validation, but never do I get any feedback. It wasn’t until I was checking my site referrals and stumbled upon this page did I read any real constructive criticism.

    The regex library is still pretty raw and has received the least amount of my attention and is really the newest addition to the plugin. I wasn’t aware that the email address field didn’t accept uppercase letters. I am tweaking this stuff all time, apparently the latest expression didn’t account for capital letters. Also, the phone regex wasn’t intended to be a one-size-fits all deal. International phone numbers are almost impossible to predict. Instead, it’s more or less meant to be a framework so you can define whatever regex you desire. You can easily change the regex or add your own. I would like to make this portion more extendible, but not really for sure which directions to take it just yet.

    If you any thoughts or ideas on ways to improve it outside of what is in your article, let me know. I would definitely like to discuss form validation. I have a lot of time and work invested in this plugin, and want it to be the best it can be. I’m honored that my plugin could be “the only that even comes close”. Nothing is perfect in this world, but the being the closest thing to perfection is pretty damn good in my book.

    When I have some more free time, I will take a look at your post some more and try to incorporate the specs you outlines. 90% of what you posted can be accomplished with my plugin.

    Hope to hear from you soon,
    Justin Kimbrell
    Objective HMTL

Leave a Reply

Your email address will not be published. Required fields are marked *