Forward Thinking Form Validation

by Ryan Seddon

38 Reader Comments

Back to the Article
  1. enhanced_2.html does not accept https urls in IE8
    Copy & paste the code below to embed this comment.
  2. very nice val.
    and also i hope all IE’s die(), exit(), quit() disappear
    Copy & paste the code below to embed this comment.
  3. There are too many validation errors: # when I enter only 1 digit in a password field, it says it’s valid;
    # ‘daaa@sssb’ in email field is valid;
    # ‘http://’ in website is valid; Firefox 3.6.10, very last example. In Chrome it works better, but still not perfect.
    Copy & paste the code below to embed this comment.
  4. Chrome 6:
    email accepts a@b.c
    website accepts http://w which while it strictly is a URL it isn’t a FQDN making it of little to no use.
    And it allows http://. which isn’t a URL I do like the spinner though. Any particular reason for not using the HTML5 DOCTYPE? ATM it is invalid XML…
    Copy & paste the code below to embed this comment.
  5. I think this is a requirement of ALA (using XHTML), but if they’re going to be putting out demos with HTML 5, they should allow you to use the correct doctype. That aside, it’s nice to look forward and see how might use these features down the road. Thanks
    Copy & paste the code below to embed this comment.
  6. Nice article. Chrome renders little up/down arrows at the right side of a number field that overlap the validation icon in the demo.
    Copy & paste the code below to embed this comment.
  7. Not allowing spaces, brackets, dashes, slashes in phone numbers is a habit from the stoneage of form usability, as is requiring the protocol identifier, “http://”, which noone is used to enter into their browser’s location bar. Deleting characters of valid inputs, making them invalid, does not always alter their state of recognition, i.e. they keep being labeled as valid.
    Copy & paste the code below to embed this comment.
  8. “¦Â also ZIP or post codes often are not numbers, even if they look like such and may not contain letters or other characters. In Germany, for instance, they always consist of five digits, but may have leading zeros, i.e. <input type=“text” pattern=”\\d{5}”>. Even if the demo was correct for Australia, it’s not a good example.
    Copy & paste the code below to embed this comment.
  9. What happens if a field is dependent on another field? For instance, let’s say for password confirmations? Or, what about if the field is only required if another field has a value of 1?
    Copy & paste the code below to embed this comment.
  10. This article may give the impression that client-side validation obviates server-side validation. On the contrary: client-side validation does nothing for your security or data integrity, and should be provided solely as a service to your users. The bouncers in the cartoon should, if anything, be carrying the user on a litter.
    Copy & paste the code below to embed this comment.
  11. The end result is twice as much CSS, highly inefficient CSS selectors (stacked pseudo selectors is horrible for efficiency) and still end up with the JavaScript you would have had to write without doing any of this new stuff. Working on large scale projects where we are writing off IE6 entirely, we would always go with the solution that is the lightest. We can’t realistically look at pseudo/sibling selectors as an option until IE7 bites the dust (one :hover selector on a non-anchor can render IE7 completely useless with a large DOM). These ideas are really cool but even with the degradation this won’t be a viable option for at least a decade. I sure hope I am wrong.
    Copy & paste the code below to embed this comment.
  12. @scriptin bq.
    when I enter only 1 digit in a password field, it says it’s valid; Passwords fields cannot be evaluated using javascript for security reasons. Entering anything will automatically validate in browsers that don’t support the constraint validation API natively. bq.
    “˜daaa@sssb’ in email field is valid; The email regular expression is pretty loose. It’s more there to guide people rather than enforce super strict rules. bq.
    ‘http://’ in website is valid; That’s considered a valid entry in natively supporting browsers. Again it’s guiding and not enforcing.
    Copy & paste the code below to embed this comment.
  13. bq. On the contrary: client-side validation does nothing for your security or data integrity, and should be provided solely as a service to your users. I certainly wasn’t advocating client-side validation only, you should always have server side validation, as you’ve stated, for security and data integrity. What I am saying though is client-side validation creates a much nicer user experience compared to server-side. Hence use of the word evolving.
    Copy & paste the code below to embed this comment.
  14. I like the article a lot, thanks for the writeup! The only thing I’d like to suggest as an improvement is, since we are dealing with HTML5/CSS3 anyway, to take the CSS-only route a little further by also replacing all HTML error messages with CSS generated content messages: input.password:focus:required:valid:after {
      display: block;
      padding: 2px;
      background: green;
      color: #fff;
      border: 1px solid #912C2C;
      font-size: 12px;
      white-space: pre;
      content: “Your password meets our requirements, thank you.”;}
    } input.password:focus:required:invalid:after {
      display: block;
      padding: 2px;
      background: red;
      color: #fff;
      border: 1px solid #912C2C;
      font-size: 12px;
      white-space: pre;
      content: “Minimum 8 characters, one number, one uppercase letter and one lowercase letter.”;}
    } OR: <input type=“password”
    name=“password”
    class=“password”
    data-valid=“Your password meets our requirements, thank you.”
    data-invalid=“Minimum 8 characters, one number, one uppercase letter and one lowercase letter.” /> + input.password:focus:required:valid:after {
      display: block;
      padding: 2px;
      background: green;
      color: #fff;
      border: 1px solid #912C2C;
      font-size: 12px;
      white-space: pre;
      content: attr(data-valid); // HTML5 data-attribute
    } input.password:focus:required:invalid:after {
      display: block;
      padding: 2px;
      background: red;
      color: #fff;
      border: 1px solid #912C2C;
      font-size: 12px;
      white-space: pre;
      content: attr(data-invalid); // HTML5 data-attribute
    } That way you won’t have any more “bloat” in your document tree.
    Copy & paste the code below to embed this comment.
  15. Unfortunately :after and :before cannot be applied to replaced elements aka inputs, textarea etc. While some browsers allow this it’s technically violating the spec, “see replaced content”:http://www.w3.org/TR/css3-content/#replacedContent bq. The box model defines different rules for the layout of replaced elements than normal elements. Replaced elements do not have “˜::before”˜ and “˜::after”˜ pseudo-elements;... I discussed this very subject on one of “my posts”:http://www.thecssninja.com/css/custom-inputs-using-css on my blog with a “test case”:http://www.thecssninja.com/demo/form_generated-content/ However, I was actually playing with using data-* attributes today using the exact idea you just demonstrated but by using an empty span with the attributes on it. Still some extra markup but less than there is now. e.g. <input />
    <span data-valid=“Your password meets our requirements, thank you.”
    data-invalid=“Minimum 8 characters, one number, one uppercase letter and one lowercase letter.”></span> input:focus:required:valid + span:after { content: attr(data-valid); }
    input:focus:required:invalid + span:after { content: attr(data-invalid); } IE8+ will ignore any attr() calls to unregonised attributes, but all the other browsers manage fine.
    Copy & paste the code below to embed this comment.
  16. Thanks, great read.
    FF 4 Beta 6 now supports most features,
    There are a few layout inconsistencies across browsers though these could be easily met with a few lines of CSS.
    I notices that disabled and required attributes doesn’t play nice together.
    Copy & paste the code below to embed this comment.
  17. Australian postcodes are 4 digits, but can also start with “0”. According to the form, the Darwin postcode “0800” is out-of-range.
    Copy & paste the code below to embed this comment.
  18. Some very cool ideas in this article and some new concepts introduced. Looking forward to trying this out soon.
    Copy & paste the code below to embed this comment.
  19. bq. Australian postcodes are 4 digits, but can also start with “0”. According to the form, the Darwin postcode “0800” is out-of-range. Correct and they go above 8000 too. I was just using it as a loose example of what one could do to use the min, max and step attributes.
    Copy & paste the code below to embed this comment.
  20. Nice! Though as BryanRSmith said above, the spinner arrows on number inputs cover your icons. I had this very problem yesterday on a project I’m working on, it’s annoying. In my case, the arrows sat on top of placeholder text I had on some small dd/mm/yyy fields. If you set a width on an input, you have to allow for the arrows. But if you leave space for the arrows, then you’ve got weird extra space in browsers that don’t support them. Even if you’re happy to allow extra space for the arrows, it’s still a bit of a guessing game… who knows how big they’ll be in other browsers or what they’ll look like?
    Copy & paste the code below to embed this comment.
  21. Yeah the spinners can be a bit of an issue and the extra padding on the end, in addition with the sporadic differences between browsers makes styling number inputs a real pain. The background issue could be fixed by targeting the number inputs and aligning the background image to the left. That however does break the consistent styling from other fields. Selects would have the background image appear behind the arrow also. A solution could be: input[type=number], select { background-position: 3px -61px; }
    Copy & paste the code below to embed this comment.
  22. What a great piece of information. Congrats on the library too.
    Copy & paste the code below to embed this comment.
  23. Seems to work great in Chrome.  But in FF3+ and Safari the validation allows the form submission even if the form is not complete.  Chrome prevents sumbmission… wondering if anyone has the same issue?
    Copy & paste the code below to embed this comment.
  24. bq. Seems to work great in Chrome. But in FF3+ and Safari the validation allows the form submission even if the form is not complete. Chrome prevents sumbmission… wondering if anyone has the same issue? Yes the browsers vendors seemed to of changed their mind on this functionality. While Chrome 6 does block it, Chrome 7 made an update to no longer block form submission. Safari 5 blocked invalid form submission, but Safari 5.0.1 made and update to remove that. Firefox 4 beta6 which just added native support for the constraint validation API also doesn’t block invalid form submission. Opera 10.6 still blocks form submission so that is the only browser left which does it. The spec, while a bit ambiguous as to exactly what the UA should do, seems to indicate that it should block a form submission if it is invalid. My theory is that it broke a lot of legacy forms possibly using conflicting attributes that cause the browser to flag it as invalid and show nothing, confusing users.
    Copy & paste the code below to embed this comment.
  25. To me, the new HTML5 interaction additions are a step in the right direction. At one level, they convey a desire to see the web not as a bunch of pages, but as a conglomerate of applications. I always say, “Give me an application platform and I can built a document delivery platform on top of it. But give me a document delivery platform, and I’ll struggle to build an application platform on top of that.” I think that’s one of the biggest problems with the web today. It’s a document delivery platform that we’re trying to bend into an application platform. JavaScript, the DOM, HTML Form elements, SVG, and other technologies are ways in which we have achieved some success in this venture. The new HTML5 form element properties ease this, but not enough. Really, if we were measuring the new version of the language from an interaction standpoint, we would call it HTML 4.5.
    Copy & paste the code below to embed this comment.
  26. What I really enjoy about HTML5 is the simplicity with which data are manipulated visually but also on the structure of its page. The bad thing is that despite the fact that it can still display alright in older browsers, some things such as this article’s subject need code manipulation in order to achieve the same result on older browsers. We’re lucky IE6 is finally fading faster than before, but this is not enough.
    Copy & paste the code below to embed this comment.
  27. Does anyone have any real world examples of production sites that are using HTML5 forms attributes?
    Copy & paste the code below to embed this comment.
  28. Form validation might be annoying when too rigid. Browser implementors should allow for non-ASCII characters in E-mail addresses. Currently, neither Chrome nor Opera accepts ‘джон.доу@россия.рф’. In phone numbers, users not only would want to use separators (spaces, parentheses, dashes) but also ‘+’ at the beginning. And don’t forget about vanity numbers!
    Copy & paste the code below to embed this comment.
  29. bq. Browser implementors should allow for non-ASCII characters in E-mail addresses. Currently, neither Chrome nor Opera accepts “˜Ð´Ð¶Ð¾Ð½.доу@россия.рф’. That to me is a bug, it should support UTF-8 characters and therefore that email should be valid. I tested Firefox 4 and Safari 5, they also don’t accept “˜Ð´Ð¶Ð¾Ð½.доу@россия.рф’ as a valid email. bq. In phone numbers, users not only would want to use separators (spaces, parentheses, dashes) but also “˜+’ at the beginning. And don’t forget about vanity numbers! That’s why a native tel input won’t enforce a particular syntax due to the many possible variations a telephone number can be represented. I do enforce a particular syntax in my demo but that was purely for an example of how the pattern attribute works.
    Copy & paste the code below to embed this comment.
  30. This is indeed a great post on form validation when using HTML5 and CSS3.
    I think you have already answered weirdan’s question in your post that these sort of techniques will become a viable option as soon as browser support improves. I quite liked the section ‘Additional types and attributes to help us’. Thanks for sharing such a vast knowledge with us.
    Copy & paste the code below to embed this comment.
  31. The page has code: <li>              <label for=“email”>Email *</label>
                  <input type=“email” id=“email” name=“email” placeholder=“e.g. ryan@example.net” title=“Please enter a valid email” required />
    <span class=“invalid”>Please enter a valid email address e.g. ryan@example.com</span>
    <span class=“valid”>Thank you for entering a valid email</span>          </li> I believe to be accessible the code would need to be: <li>              <label>Email *
                  <input type=“email” id=“email” name=“email” placeholder=“e.g. ryan@example.net” title=“Please enter a valid email” required />
    <span class=“invalid”>Please enter a valid email address e.g. ryan@example.com</span>
    <span class=“valid”>Thank you for entering a valid email</span>          </label></li> so that the validation text is associated with the field it applies to.
    Copy & paste the code below to embed this comment.
  32. it helped me a lot ...i wish in few days i will also be able to contribute to this
    Copy & paste the code below to embed this comment.
  33. Great post I am a believer in server and client validation (Just to be sure).
    Copy & paste the code below to embed this comment.
  34. I’ve written a jQuery plugin that’s about to enter production on a site that gets millions of visits per month. The intention of my script was just to make practical client-side validation easy using the HTML5 required and pattern attributes. Practical use of those features today was the primary aim, as opposed to a complete polyfill for the entire HTML5 form validation spec. As a consequence it handles “pattern” and “required” really well (supporting 14 verified browsers, including old browsers, iPhone, Android, and Palm WebOS), but it does not yet support all the custom input types, nor does it support the validation JavaScript API. If you’re interested in a jQuery validation plugin that’s usable today, this is it: http://ericleads.com/h5validate
    Copy & paste the code below to embed this comment.
  35. That aside, it’s nice to look forward and see how might use these features down the road.
    This article may give the impression that client-side validation obviates server-side validation
    Copy & paste the code below to embed this comment.
  36. Will be good when html5 support matures
    Copy & paste the code below to embed this comment.
  37. Very interesting article about validation.
    We can use now less js.
    Copy & paste the code below to embed this comment.
  38. This is quite good to use into code thus we don’t need to check JavaScript validation. input[type=‘text’]:focus{
      border: 1px solid skyblue;
      -moz-transition:border ease 1s;
      -webkit-transition: border ease 1s;
      -0-transition: border ease 1s;
    } Good way to style the input box. But some browser still not fully supports CSS3 and HTML5. For this reason we still need JavaScript to design the pages.
    Copy & paste the code below to embed this comment.