A lot of the attention paid to HTML5 Forms has been centred around the new input types. email, url, date, and the rest are all very convenient, but for me the really useful feature is the built-in validation. In case you’re not aware of it, the browser will now handle all of the validation that we used to use JavaScript for.
This is great for the future, but although you can start using these functions now (in many browsers), they aren’t without their drawbacks — well, one big drawback really. I’m going to explain briefly the problem, and then propose a solution.
How Form Validation Works
The simplest form of validation is to say that a field is required, which is done by adding the required attribute (it’s boolean, so needs no explicit value):
<input type="text" required>
This will check to see if a value is supplied, and returns an error if it isn’t. You can add parameters to validation by using the pattern attribute with a JavaScript regex value; for example, to only accept a numeric value you would use the following:
<input type="text" pattern="[-0-9]+" required>
Some field types have pattern validation baked in; email and url will only accept correctly formatted email addresses and URLs, respectively, while number and range can have maximum and minimum numeric values applied. There’s also a maxlength attribute to restrict the number of characters, which can also cause a validation error.
The Problem With Error Messages
Probably the biggest drawback of the validation process is that the error messages are, for the most part — and there’s no polite way to put this — ugly. Take a look at this image showing the validation error message in (from the top) Chrome, Opera, and Firefox:
I think the Opera message is the better of the three, but I think it’s fair to say that the designers weren’t having their best days when they made these. (I’m using Ubuntu here, but they really aren’t any better in any other OS.) The problem I have with these is that I’d like to use them, but I don’t think any designer I work with would find these acceptable and I’d no doubt end up using a JS implementation just to get some form of consistency.
Using JS is a short term solution, and there’s a good Validation API to aid in using it (which I aim to write about soon). But longer term we will need better-designed messages, or a way to style them ourselves, or both. I don’t think that the error messages need to look identical in every browser on every OS, but I do think they should be more closely aligned with the browser chrome and sympathetic to the OS; they should feel like a natural part of the platform, rather than an add-on.
A Proposal For Styling Error Messages
There’s no formalised suggestion for CSS styling of error messages, but I think it’s probably inevitable that there will be. This could take the form of a pseudo-element, perhaps something like:
input::error {}
This would allow us to set background, colour and font options. It may be necessary to also have a property to set where the validation error message appears in relation to the input it’s attached to; perhaps modifying position with values of above, below, before, or after:
input::error { position: below; }
And, perhaps, another property to set the appearance of the box which contains the message; perhaps the appearance property with values of box for a rectangle, or balloon for the current speech balloon style:
input::error { appearance: balloon; }
There’s also the text inside the validation error; the main message, and an optional extra which can be set with the title attribute (or JavaScript). These could have further pseudo-elements for finer control over the text formatting:
input::error-message { }
input::error-text { }
This is all straight off the top of my head, of course, and no doubt needs plenty of development; but as there’s no formal proposal at the moment, it’s a good time to be thinking about these things.
