CSS3 Pseudo-Classes and HTML5 Forms

Hello! I’m Doctor Peter and I’m here to treat you with a dose of complementary CSS3. Don’t worry, this won’t hurt a bit.

Contrary to what HTML5 Please and the W3C would have you believe, CSS3 is not part of HTML5. “But this is HTML5 Doctor,” I imagine you saying. “Why are you talking about CSS3 here?” Well, I want to talk about a very specific part of CSS3, one that works in perfect tandem with HTML5, specifically with the new form functions that are available.

One of the killer features that HTML5 introduces is client-side form validation without using JavaScript. Now, I know the other doctors haven’t discussed this yet, and as I’m just a locum, you might feel as if I’m putting the cart before the horse (#mixedmetaphors), but I’m hoping to explain just enough to let you know how it works, and then your regular doctors can provide the details at a later date.

A pseudo-class is information about an element that’s in the document tree but not available through any specified attributes. For example, the :first-child pseudo-class applies to elements which are the first child of their parents. You can get that information from the DOM tree, but there’s no first-child attribute.

In CSS2.1, there were a handful of pseudo-classes available, notably the link states (:link, :visited) and those of user actions (:active, :hover). In CSS3, that handful becomes a basketful, with pseudo-classes of structure (:nth-child, :nth-of-type), UI element (:enabled, :checked), and the ones we’ll look at now, of form validation.

So as I mentioned at the beginning, HTML5 introduces client-side form validation without the need for JavaScript. When you attempt to submit a form, your browser will validate all of the fields and return an error if any of the fields is incorrect. This will happen mostly automagically — provided your browser has the capability — and will look something like what’s shown in Figure 1:

Figure 1: A form validation error message

Those error messages are browser and OS specific, and hard to modify (which I documented on my blog), but you can change the way the errors appear on the elements themselves with the new validation pseudo-classes, which are part of the CSS3 Basic UI module.

I’ll cover current browser support as we go through the article, but in a nutshell:

Firefox and IE10 support some of it.

Opera and Chrome support all of it.

Safari supports all of it too, but form validation is disabled by default.

That being the case, I’d recommend using Chrome, Opera, or Safari to view the examples I’ll be showing you.

If you want to keep up to date with browser support for form validation, I suggest keeping an eye on When can I use.

So with all of the boring technical guff out of the way, let’s get on with the interesting technical guff and take a look at some examples of form validation.

One of the most common patterns of validation is that of mandatory (that is, required) values — the fields that the user must complete in order to progress. To mark a form element as mandatory, you need only add the required attribute to it:

<input type="text" required>

If you want to apply styles to this in order to show that requirement, you can use the new :required pseudo-class, which applies rules to any matched element which has the required attribute. For example, you may want to put an asterisk after the text of the label:

input:required + label::after { content: "*"; }

The exact rules you use depends on how you’ve marked up your document. The rule in this example is based on the markup having this structure:

<input type="text" required id="foo">
<label for="foo">Foo</label>

The opposite of required is, of course, optional. And wouldn’t you know it, we have a pseudo-class for that too, logically named :optional. It affects any form element that doesn’t have a required attribute. For example, you may want to make those have a lighter border:

Figure 3: Showing the use of the :valid (top) and :invalid (bottom) pseudo-classes

Two extra things to note about this example: first, in order to use my own JavaScript, I’ve prevented the form from automatically validating by using the novalidate attribute on the submit button; and second, Firefox puts a coloured glow around elements depending on their validation state, which I’ve over-ruled by using their proprietary :-moz-ui-invalid selector. View the source of the demo to see how these are used.

Some of the new input types, such as number, allow a range of values using the min and max attributes, like so:

<input type="number" max="10" min="1">

Although form controls will usually prevent the user from entering a value outside of this range, there may be occasions (such as when JavaScript is used to provide values) where the value provided to the input does exceed the range:

<input type="number" max="10" min="1" value="11">

When this happens, you can use the :out-of-range pseudo-class for your styling:

input[type='number']:out-of-range { border-color: red; }

And, as you’d expect, there’s a counterpart known by the name of :in-range:

input[type='number']:in-range { border-color: green; }

In Figure 4 you can see these two pseudo-classes at work, and once more there’s also a live example to view.

Reading and Writing

You may have a form field that’s pre-filled with a value that you don’t want the user to be able to edit, such as terms and conditions in a textarea. If that’s the case, you can add the readonly attribute:

<textarea readonly>Lorem ipsum</textarea>

You can style elements which have the readonly attribute applied, using…can you guess? You are correct, imagined reader: the :read-only pseudo-class. You could combine it with the user-select CSS property to prevent the user from being able to select the text (in the example, I’ve also changed the border style to make it more obvious):

textarea:read-only { user-select: none; }

And if you should need it, there is of course a :read-write pseudo-class for elements which don’t have the attribute applied:

textarea:read-write { user-select: text; }

You can see the results in Figure 5, and as before there’s a live example too.

Figure 5: The textarea on the left is styled using :read-write, and the one on the right, with :read-only

Firefox and IE10 have actually implemented the readonly attribute, but don’t yet have support for these pseudo-classes.

I hope I’ve given you enough to whet your appetite for finding out more about HTML5 Form Validation. There’s plenty more to it, including a full JavaScript API (you can read about this in the HTML5 spec, but ).

38 Responses on the article “CSS3 Pseudo-Classes and HTML5 Forms”

You say “Safari supports all of it too, but form validation is disabled by default.” That kind of implies that Safari’s form validation can be turned on, but searching the net I wasn’t able to come up with a technique for turning form validation on in Safari. If you know how to do this, I’d love for you to share.

In CSS3 the before and before and after pseudo-elements have a double colon instead of a single so as to differentiate them from pseudo-classes. Pseudo-elements with double colons will not working in IE versions 8 and below

@Andy:
We used them aregularly. Users filled in a very long form for our insurance. When they submitted, they were presented with a final page: first, showing what they had filled in, to check that it was correct and give them the opportunity to change anything… then, a textarea with some legally required legal mumbo (emulating any desktop software users typically install, so something they already have experience with) inside a form with a checkbox (“I agree”). That form is actually their final submission. Using a scrolling div outside the form pretty much would require multiple forms on a single page with ultimately a single submit, which would require Javascript finagling we don’t want. (The ability to link form inputs who are outside a form, as HTML5 allows, was then not yet available… and today still not cross-browser enough to be safe for corporate users.)

@Jason another reason readonly rather than disabled: so far as I understand, disabled inputs may be ignored by AT such as screen readers. Read only does imply it should be read, and usually can be.
Disabled implies “this label-input pair is currently not relevant” and is to be completely ignored.

Re form validation: wish there weren’t so many issues with language in those error messages. I’ve had a case where I avoided HTML5 input types because the languages were always incompatible with the form due to differences in chosen browser language (or inherited from the OS settings) or back-end region settings. That and some of them (default error messages) are rather unhelpful (esp with pattern attribute). This makes Javascript/client-side validation still necessary but now needs extra code to override the defaults.
Very off-topic, wish auto-complete was not “on” by default. If I understand correctly, I have to manually add it as “off” on all relevant inputs every time. Arg.

“Contrary to what HTML5 Please and the W3C would have you believe, CSS3 is not part of HTML5.”

Maybe we educate people without discrediting our peers? Just a thought. Also if you’re going to explicit name call like that the least you can do is explain what you’re talking to about to your readers so they can understand what you’re talking about.

To me that read something like, ‘The established sites are wrong about A. Today, I’m going talk about B which is sort of related.’

Jon, I wasn’t really being critical of either of the two bodies I mentioned, just poking a bit of light-hearted fun; I’d hoped that was clear from the tone of the rest of my introduction, but maybe it wasn’t.

I will cop to the fact that the publishing process meant that the reference is less topical than it was when I wrote it.

Outstanding article! There are some pseudo classes combined with siblings (+) that I’ve never thought to use! And here a little add for this excelent article. For those like me don’t want those small up and down arrows on input type=”number” just use this:

The article (examples) depend on not following w3c recommendation regarding the positioning of labels by putting labels after the non-radio / non-checkbox inputs.
I think it should at least be mentioned so everybody can make an educated decision if it is worth it to make use of a convenience provided by css while not following best practice in html.

‘Check that there is a label element that identifies the purpose of the control before the input, textarea, or select element’
‘Check that there is a label element that identifies the purpose of the control after the input element [For all input elements of type checkbox or radio]’

I didn’t find the email validation particularly useful. It is successful after x@x.

@LouieGeetoo actually Opera seems to support some of these. I did my own set of experiments on required fields and email addresses and it worked well. Android’s default browser was terrible and inconsistent. You can find a link to what I did here:

@type=”email” is still wrong specified in HTML5 and wrong implemented in browsers as it allows only ASCII characters in E-mail addresses. IDN addresses like ivan@россия.рф would be rejected but should not.

@Gunnar — you’re partially right in that some browsers don’t take Internationalized Domain Name (IDN) values into account for validation. Because of this I think it’s best to use type="email" only to trigger an email-specific keyboard layout on mobile devices. For HTML5 email validation you can use pattern="[^ @]*@[^ @]*", but if using both pattern will only restrict type="email", not broaden its scope. Because of this if you’re using type="email" you also want to use formnovalidate. On the bright side this is a browser bug, so eventually Peter’s swish CSS3 will work as expected for everyone.

As for the spec, IDN support is a UI issue as international email addresses use punycode behind the scenes, so it’s not something the spec dictates. Given that, note the spec says:

User agents may transform the value for display and editing; in particular, user agents should convert punycode in the value to IDN in the display and vice versa.

Do you have any sources to support your statement that HTML5 Please and the W3C would have us believe CSS3 was a part of HTML5?
Otherwise I tend to think: Contrary to what you would have us believe, neither HTML5 Please nor the W3C would do that.

The distinction between HTML5 and CSS3 is pedantic and isn’t very meaningful. They are highly related and the difference between the two is only important to people working directly with the specs. Practically, it boils down to the exact same thing — new features for a more interactive web that reduce the amount of JS you need with varying degrees of browser support.

Damn, I wish there was a way to stop my browser honouring these validations. I don’t really care if I give a server data that they do not want, or if I do not provide data they do want, or provide them with false data.

There aren’t legitimate reasons to use this, the server still has to validate the data (or you are trusting the client, and on a public network that is a stupid thing to do).

My main gripe currently with this feature is how it annoyingly implements what businesses will want: as much accurate data as they can get hold of, and the user’s privacy desires take 2nd fiddle. The user is in less of a position of power and control over what they disclose. Features like this form validation in the browser just play into the hands of the anti-social.

This very form implements the irritations, you make out that an email address isn’t actually required when you say it will not be published, then say it is required, then back that up with HTML 5 BS.

Ahhh, the FF element inspector thing manually lets me override your form’s wishes, and then your server has to step in and do the job you tried to tell my browser to do:

ERROR: please fill the required fields (name, email).

As ever I have provided an email address where if it leads to spam you will get the spam, postmaster@html5doctor.com . If you don’t bother validating email addresses then people will not have to put in valid ones, and if it is their email address with a risk of spam, or yours, then the choice is obvious.