- Update: November 10, 2012: I found out via a this tweet that the CSS Selectors 4 has a (draft) pseudo-class for
:user-errorwhich may address the issues discussed here with way less CSS code. I may be implementing an experimental polyfill for
:user-errorin a future version of HTML5Forms.js.
- For more information about HTML5 forms, take a look at my previous articles, Creating Cross Browser HTML5 Forms Now, Using modernizr, webforms2 and html5Forms and Cross Browser Styling of HTML5 Forms — Even In Older Browsers.
I have been playing around with HTML5 Forms for a while now, and have used it in production in a variety of projects. One of my favorite parts of the spec is the use of CSS3 pseudo-classes to show the validation state of the form fields to the user. I believe these validation hints make a better user experience and makes the process of filling out the form less frustrating. In my humble opinion, however, I think there are some shortcomings in the existing psuedo-classes that produce these validation hints, and would like to start a discussion for a possible solution that could be easily added to the CSS3 UI specification.
If you look at the form below, you will see that:
- if a form element is mandatory, a star appears after the field label
- if it has an invalid value, a red X appears in the background
- if it has a valid value, a greed tick appears in it’s background
In order to produce these effects, we use the CSS3
:focus pseudo-classes (if you are not familiar with them, you may want to read my previous article Cross Browser Styling of HTML5 Forms — Even In Older Browsers before you continue). However, after using them on a few projects, I keep hearing from users and clients that it is confusing for focused form elements to have red x’s next to them if they have not even been filled in yet, unless this element has lost focus. Also, it would be great if the user could see all the invalid form fields at once if a form submission has been attempted. Unfortunately, the way the HTML5 psuedo-classes are set up today, it is impossible to implement these use-cases.
The “Solution” (For the Time Being)
In order to work around these issues (and after an interesting discussion with my friend and colleague Dan Van Brunt, I added the above functionality into my HTML5 Forms polyfill,
html5Forms.js. This is implemented using three special classes:
.wf2_notBlank– these classes are applied to form field when a form element is blank/not blank repectively.
.wf2_lostFocus-this class is applied to a form element when a form field loses focus.
.wf2_submitAttempted– this class is applied to a
<form>tag when a form submission is attempted.
These classes exist when html5Forms.js is included in your document. For those of you not familiar with this library, html5Forms.js includes a modified version of Weston Ruter’s webforms2.js polyfill that is only loaded into a document if the browser doesn’t support HTML5 Forms natively. These classes, however, will be applied to the document whether or not the polyfill is loaded, so even if the browser is using a native implementation of HTML5 Forms, the browser will still use these classes.
The “Solution” (For the Long Term)
I added this functionality to html5Forms.js as a proof of concept to show how this improves the usability of the HTML5 Forms module. I believe it would be nice to have these classes be converted into pseudo-classes (i.e.
:submitAttempted) and have included in CSS3, if possible. To that end, I have submitted a simplified “clean-room” page with the example above (no IE support to make the CSS simpler to follow) and submitted a small blurb about these proposed pseudo-classes to the W3C’s www-style mailing list. I don’t know if it will go anywhere (I sent this out in July and didn’t hear anything back about it), but what do you think? If you are front-end developer and believe this kind of functionality would be useful, even if you think there is a better way to implement them, please add yourself to the list and reply to the thread on this subject, or submit your opinion in the comment form below. If you passionately disagree, I would love to know why. I think this discussion is worth having now while HTML5 Forms implementations are in their infancy and currently not fully implemented in any web browser.