HTML5 Form novalidate

By  on  

I've been very skeptical when it comes to HTML5 form validation.  It's a nice addition, don't get me wrong, but let's be honest -- it's not very powerful and it could get in the way of the JavaScript validation you have in place.  If you want HTML5 form validation to be ignored, it's as simple as one attribute on the form element:  novalidate:

<form action="/search" method="get" novalidate>

Adding a novalidate attribute to the form element prevents native validation on form elements (if applied), allowing your JavaScript unobstructed ability to manage all validation.

Form validation, in my opinion, is one of the most difficult tasks in web development.  Client side validation, server side validation, security, styling, etc. -- forms are a pain.

Recent Features

  • By
    Camera and Video Control with HTML5

    Client-side APIs on mobile and desktop devices are quickly providing the same APIs.  Of course our mobile devices got access to some of these APIs first, but those APIs are slowly making their way to the desktop.  One of those APIs is the getUserMedia API...

  • By
    Responsive Images: The Ultimate Guide

    Chances are that any Web designers using our Ghostlab browser testing app, which allows seamless testing across all devices simultaneously, will have worked with responsive design in some shape or form. And as today's websites and devices become ever more varied, a plethora of responsive images...

Incredible Demos

  • By
    Editable Content Using MooTools 1.2, PHP, and MySQL

    Everybody and their aerobics instructor wants to be able to edit their own website these days. And why wouldn't they? I mean, they have a $500 budget, no HTML/CSS experience, and extraordinary expectations. Enough ranting though. Having a website that allows for...

  • By
    Prevent Page Zooming in Mobile Browsers

    Ever since I got my iPhone, I've been more agreeable in going places that my fiancee wants to go. It's not because I have any interest in checking out women's shoes, looking at flowers, or that type of stuff -- it's because my iPhone lets...


  1. René

    Could you give examples of where html5 form validation would not suffice? My experience is that the default form validation is good enough for most webforms.
    The majority of webforms is either just: “Leave a reply”, “Fill in your address”, “Contact us”. Those consist of:
    – Email: Overthinking email validation will surely break things(there are plenty of JS validators that will not even accept your .name tld because they check for 3 chars max) pretty much the only requirement is an @.

    – Name: So, what is not allowed in a name? If someone calls himself “~?(#” in my form I don’t even mind. It’s not more random than filling in “Aeuh Wajjs”

    – Message: I don’t see anything to validate here, except for having a least something.

    – Phone number: Should we not validate 00 as +? Or write dashes between numbers? No, we should just either write a script to transform the phone numbers or enforce a format during typing. Neither methods being part of validation itself.

    – Address: This is so complicated when you go international. Postal codes are different everywhere. Some houses don’t have a number, just a description like ‘Green house with red porch’.

    – File: Giving previews etc is nice but that’s again not a part of validation. Mime type checking is important, but can be done using the accept attribute.

    For edge cases my server side script will still give a nice feedback.
    For all the rest, notifying the users if they forgot something or made an obvious typo seems enough to me. And that’s something html5 form validation does just fine. Putting in nonsense is probably intentional, should we put much effort into that?

    On a sidenote; I would suggest adding novalidate using JavaScript so you still have validation if the script breaks.

    • One quick example is field B being required if field A is of a certain value. Another example could be requiring a certain value for B if A is of a certain value.

    • René

      Those are already quite rare advanced cases, which I have no doubt of that you encounter more often than I do.

      Besides that those cases would already be horrible for accessibility(often solvable with a lot of effort), you can still use the browser validation by dynamically setting and unsetting the required attribute.

      One problem that I have not yet figured out very gracefully is required fields that are hidden. Luckily for usability I try to keep most forms entirely visible anyway.

    • Jamie Zawinski put it best when he said:

      ‘Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems. ‘

      He was referring to the typical Perl development attitude at the time, but I think it still holds true today. Too many people try to re-engineer the validation wheel, and it goes horribly wrong. Email addresses are the most obvious one, but at one point or another everything gets a little mangled, from names being forced to match against [a-zA-Z]+ (so your name wouldn’t validate, for example), to phone numbers only accepting digits. A better way of styling the HTML5 validation error messages would be preferable, maybe in the future?

  2. Huh. Handy little bit of code. I totally and utterly agree with what you said about forms. They are a pain to style, a pain to validate. I’ve been using Laravel lately though and validation using that framework is pretty easy. Server side anyway. There’s still JS validation I have to worry about. :)

  3. Tien Do

    Why not to use HTML5 form validation? Try it and see how browsers display error messages :)

  4. Luke D

    I’ve done this in a few of my websites. Have JavaScript add the novalidate element to my forms, so that the JavaScript can handle the validation.

    If the user has JavaScript turned off for whatever reason, then the novalidate never gets put onto the form, so I can at least have basic validation still.

    • Andrew

      This is an excellent tip, as browsers with disabled JS still get some client-side validation. Cheers!

      Also, David – your comment form uses HTML5 validation ; )

  5. Rob

    I tend to agree with René.

    When designing forms it’s best to stick with “KISS! – Keep It Simple Stupid!”.

    Having fields/states that show and hide based on conditional logic could easily become an accessibility/maintenance nightmare and should be avoided at all costs.

    Also (as has been mentioned) your form above uses HTML5 validation! ;)

Wrap your code in <pre class="{language}"></pre> tags, link to a GitHub gist, JSFiddle fiddle, or CodePen pen to embed!