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.
Copy & paste the code below to embed this comment.
Rain City
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?
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.
mashour
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.
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.
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!
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.
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.
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.
<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.
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:
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
38 Reader Comments
Back to the ArticleRyan Seddon
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; }
katlim.ruiz
What a great piece of information. Congrats on the library too.
Rain City
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?
Ryan Seddon
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.
mashour
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.
atomic-orange
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.
JoeMarini
Does anyone have any real world examples of production sites that are using HTML5 forms attributes?
Gunnar Bittersmann
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!
Ryan Seddon
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.
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.
maneet puri
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.
Charles Belov SFMTA
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.
neluwebsolution@gmail.com
it helped me a lot …i wish in few days i will also be able to contribute to this
Stu_HGC
Great post
I am a believer in server and client validation (Just to be sure).
dilvie
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
remarkoo
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
GlobuleDesign
Will be good when html5 support matures
federicobucchi
Very interesting article about validation.
We can use now less js.
webdesignerbd
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.