HTML5 gives us a lot of really good advantages. Besides the usual suspects like the unified error model, the introduction of new semantic tags or a simplified document type, one of the greatest improvements is constraint validation for forms. What would the web be without forms?

Constraint validation tries to improve the usability of web forms. Instead of sending a form to the server, which will then be evaluated as invalid, returned to the client and finally adjusted by the user, the browser can directly inform the user about the possibility of invalid values. This not only reduces network communication, but also improves the usability of the page.

It is important to remark that constraint validation cannot replace server-side validation. Also a JavaScript-based solution might still be useful. In general we always have to implement the server-side validation. If we use a good architecture, the model constraints on the server will be reflected automatically in the transmitted HTML code. That way we get constraint validation for free. Now we could enhance the experience even more with JavaScript, which either acts as a complement to the constraint validation or as a polyfill.

We will start our journey with non-validating forms. Then we will integrate a JavaScript-based solution. Finally we’ll introduce the constraint validation of HTML5. In the last section we’ll have a look at cross-browser oddities that may be encountered.

Non-Validating Form Submission

The most classic version of an HTML form is one that does not come with any client-side validation logic. We only need to provide a standard form without any special attributes. As already noted in the introduction, we need to take special care for this kind of form submission—always.

Even though we definitely want to protect our form already on the client-side, we can never be sure about the state of the submitted data. The techniques to protect and enhance form validation on the server depend highly on the programming framework and language being used. We will therefore skip such a discussion. Instead we will now discuss form submission in general.

In the second part of the “HTML5 Mastery” series we already mentioned how important the form encoding type is. We also had a look at the three well-established encoding types. The remaining question is: How are the values actually built? The browser’s exact behavior depends on the protocol that is specified for the action. We now assume HTTP or HTTPS to keep it simple.

In principle, the browser has two options:

1. Change the action to carry the form’s values.
2. Submit the values via the request’s body.

Both share approximately the same procedure. In short we find the following steps:

1. Construct a dataset with the right encoding.
2. Create a request with the dataset and encoding type.
3. Send the request.

The construction of the form dataset implies a few subtle issues, which are not very well known. For instance, it makes a difference if a button has been clicked to submit the form. In this case the value of the button is transmitted to the server. This can be used to determine which button has been pressed.

<form>
	<input type=submit name=foo value=bar>
	<input type=submit name=foo value=baz>
</form>

If we press the first button then the following content will be sent to the server.

foo=bar

Triggering the form submission from JavaScript will result in no content being transmitted. The JavaScript code uses the submit() method of the HTMLFormElement instance.

Another interesting aspect is the submission of click coordinates for input elements with the image type. The image input type was quite popular a while ago and people thought it would be a good idea to check where users clicked. Maybe the shown image indicates several possibilities. The server would then take care of evaluating the user’s request.

The following sample illustrates this behavior.

<form>
	<input type=image src=test.png name=foo value=bar>
</form>

If we click on the image to submit the form, the data of foo will be considered. The name-value pair will only be inserted if a value exists. Additionally we need to name the input element, otherwise nothing will be transported.

The content of the requests may then look similar to the following snippet.

foo.x=71&foo.y=38&foo=bar

Additionally, we should be aware that disabled fields are not considered. This makes sense. Therefore the following form, which considers the first two examples with two input fields, one enabled and one disabled, can be constructed as a proof of concept.

Submitting the form programmatically will result in a single value being transmitted.

Basic Form Validation

Even without constraint validation or JavaScript, the browser gives us some simple form validation already. As we’ve seen previously, the state (such as enabled or disabled) and the submitter of the form are taken into account. However, none of these things will prevent the form from being submitted. An easy way is to write some JavaScript to take care of potentially aborting the process.

One of the first usages of JavaScript was actually to provide enhanced capabilities for forms. The basic idea is to be notified with an event once the form is about to be submitted. At this point we can check all the values and abort the process. Of course we might refine the whole idea to always do checks once any value changes. Nevertheless, in the end we will—depending on our last evaluation—potentially abort the submission.

var form = document.querySelector('form');
form.addEventListener('submit', function (ev) {
	// always abort!
	ev.preventDefault();
}, false);

Doing live validation is easy in theory. However, the specified DOM events may work differently than intuitively guessed. For instance, the change event of a textbox is triggered only after the textbox lost its focus. This may happen when the user clicks the submit button. The interaction with the validation is therefore broken and does not feel live.

Instead it makes sense to use the keyup or input event. While the former is a working solution in case of a textbox, the latter works for all input elements (as expected). The only limitation is that it has been introduced with HTML5 and may be not supported by some older browsers.

With that in mind, let’s compare the various events to see the order of execution. The following test code helps us.

var input = document.querySelector('input');

['input', 'keyup', 'change'].forEach(function (eventName) {
	input.addEventListener(eventName, function (e) {
		console.log(eventName + ' event triggered');
	}, false);
});

For our test <input> element we see the following result when probing with a few letters. In the end we use the tab key to explicitly take the focus away.

As we can see, the order is set to fire the input event first, then the keyup. Actually that makes sense. First we need the keydown, then the value might have changed, leading to an input event. Finally we release the key, which yields a keyup event. It is worth emphasizing that input is only fired when the value changes, while keyup is independent of actual value changes. As an example, if we press the arrow keys, we will only see keyup events, but no input event.

Doing live validation on all elements could be done by adding an event listener to all form fields. Alternatively we only need to add a single event listener for the input event to the form. Despite being very elegant, this method has a significant drawback.

Consider the following very simple HTML:

<form id=main><input><input><input></form><input form=main>

We use the HTML5 form attribute to declare one field of the <form> outside it. However, the input event just works, because the events will actually bubble up the DOM tree. Hence the particular event fired by the field outside won’t be seen.

The most reliable way is therefore to get the form and iterate over the children given in the elements collection. Here all assigned fields (except the image input type) are collected.

Constraint Validation

Constraint validation means that we are able to specify constraints in the HTML source code, which are then used by the browser to check the form. There are plenty of possibilities available. Many options are related to the input type and cannot be used arbitrarily. Before we dive into the different validations and implementation quirks, let’s have a short look at the overall design.

The chosen API has been designed to enable us to make quick checks. We can probe if the current instance is able to do constraint validation with a single API call.

The API is also quite open so that we can query the results obtained by the browser or extend the browser’s result. The pseudo interface Validation is also inherited by other interfaces, not only HTMLInputElement.

Let’s see some sample code. In the following code we first check if form validation is possible at all. If so, then we care about the validation result for a field with type=date. If the user has chosen a valid date we check the status of the check‑box.

var form = document.querySelector('form');
var date = document.querySelector('#birthday');

if (form.willValidate) {
	if (!date.validity.valid || checkbox.checked)
		checkbox.setCustomValidity('');
	else
		checkbox.setCustomValidity('You need to agree to our terms.');
}

Such conditional logic (validate only under certain circumstances) cannot be implemented using markup alone. But we can nicely combine our custom logic with the integrated functionality.

HTML5 knows quite a lot of different input types. But after all they can be grouped into three classes:

• Text
• Number
• Date

The difference is not visible from the value property. Here we always get the string value. After all, the value will be submitted as text. A consequence of having these three groups is the different behavior regarding certain types of constraints.

The following constraints work almost always the same way:

• required, resulting in valueMissing if the length of value is zero
• minlength, resulting in tooShort if the length of the string is too short
• maxlength, resulting in tooLong if the length of the string is too long

There are, of course, exclusions. For instance, a check-box reacts to required in demanding to be checked. A color selection will validate to valueMissing if it is required and contains an invalid color. Other types react similarly.

The other possible constraints depend on the specific type of input. The type determines how the value is treated. Is it treated like text? Does it represent a number? The constraint reacts to it.

Let’s take the date input type as an example. If a valid date is set, we get a valueMissing if constrained to required. Additionally the badInput is set if something was actually entered. In case of a valid date, however, we may have one or more of the following validation errors:

• rangeUnderflow, if the date is below the one specified in the min attribute
• rangeOverflow, if the date is above the one specified in the max attribute
• stepMismatch, if the date does not satisfy a provided step pattern

The last point is fairly interesting. Here we have to deal with a mechanism that subtracts the base (either a default one or the one provided in the min attribute) and calculates a number that can be taken modulo the step. The calculation is not completely obvious for date input types. It makes a difference what kind of date is actually supplied. The result, however, makes sense from a user’s point of view.

For text input there is also the pattern attribute, which allows us to specify a regular expression for validation. If the input type supports this constraint, a patternMismatch is noted in case of failure.

Conclusion

The constraint validation gives us the ability to give users—even with disabled JavaScript—immediate feedback about the current form status. We do not have to waste network bandwidth going to our server and back, just to display an error message. Nevertheless, we should always keep in mind that form submission is possible in general. Therefore it is inevitable to have some validation on the server‑side.

The possibilities that come with constraint validation are nearly endless. We can use the client-side validation to ensure regular expressions are met, valid ranges for dates and numbers are considered, and certain check-boxes are checked. We can also extend the available checks with JavaScript.

References

• MDN: Constraint Validation
• W3C: Constraints and Form Submission
• Raymond Camden: HTML5 Form Validation – The Constraint Validation API
• Tomomi Imura - HTML5 Input Event Handlers and User-Experience
• TJ VanToll - Constraint Validation: Native Client Side Validation for Web Forms