HTML5 in the Web browser: HTML5 forms

When something seems incorrect, the validation will set up a data structure that can be queried. The method validity.patternMismatch, for instance, will return true if a pattern is specified but the data doesn't fit it.

If you want to specify your own validation, you can add a custom message indicating why the data might not be acceptable. You can fire off this routine with an oninput or onchange event.

Problematic input data can also trigger events of their own that you can trap. Data checks can be set off by hitting the checkValidity method.

It's all pretty flexible and built in a way that will be familiar to everyone used to the traditional mechanism of attaching functions that listen for particular events. There are probably three or four different ways to check each form field.

The standard also includes a good reminder that the clients can't be trusted to enforce these rules. Although testing the data locally will save time and energy, it won't be a perfect solution because older browsers may not implement the validity checks. It's also possible that clever users may override some of the methods and block checking. For this reason, any serious data validation rules must be re-evaluated at the server. The browser can't be trusted.

HTML5 forms: Customizable options
Simply validating the data as acceptable or not acceptable is not the only option anymore. HTML5 includes several attributes that let you offer help and suggestions to the visitor.

The simplest option lets you turn on spell-check for any input element that's marked as editable. This will normally apply to form elements like textarea but may also include any part of the document that's marked contenteditable. (Editable content is discussed below.) The attribute spellcheck='true' determines when it applies.

I'm guessing that the spellcheck attribute also toggles the grammar checker, but it's not immediately apparent to me. The title of the section of the spec is "Spelling and grammar checking," but the text only mentions one attribute called spellcheck. If I were designing the spec, I would make them independent, if only because I've found that one feature is much more accurate than the other.

The datalist element lets you add a list of strings that can automatically complete a form element. The structure is like the option tags used in select elements. At this point, only Opera seems to support the feature, and some feel it makes the HTML that much grungier by larding it up with suggested answers. I'm also a bit annoyed by the idea that each potential option comes with a label that is displayed and a value that actually fills up the form element. It seems like a dangerous way to hide functionality from the user and perhaps trick them into thinking that one thing is going in the form (the label), while filling it with another (the value).

I was also confused by the possibility of having an external list of data options stored in an XML file independent of the current HTML form. This would not only simplify the HTML but also make the data reusable in different pages. It seems like a good idea, but the spec doesn't mention it yet. I've found only secondary references to this option.