Explore

Frontend

Formvalidering

I frontenden räcker det att ni har samma form-validering som vi har i backenden.

Before submitting data to the server, it is important to ensure all required form controls are filled out, in the correct format. This is called client-side form validation, and helps ensure data submitted matches the requirements set forth in the various form controls. This article leads you through basic concepts and examples of client-side form validation.

Förkunskaper

Förkunskaper

Prerequisites:

Objective:

Computer literacy, a reasonable understanding of HTML, CSS, and JavaScript.

To understand what client-side form validation is, why it's important, and how to apply various techniques to implement it.

There are no rows in this table

⁠

Client-side validation is an initial check and an important feature of good user experience; by catching invalid data on the client-side, the user can fix it straight away. If it gets to the server and is then rejected, a noticeable delay is caused by a round trip to the server and then back to the client-side to tell the user to fix their data.

However, client-side validation should not be considered an exhaustive security measure! Your apps should always perform security checks on any form-submitted data on the server-side as well as the client-side, because client-side validation is too easy to bypass, so malicious users can still easily send bad data through to your server. Read

Website security⁠

for an idea of what could happen; implementing server-side validation is somewhat beyond the scope of this module, but you should bear it in mind.

⁠
`What is form validation?`⁠
⁠

Go to any popular site with a registration form, and you will notice that they provide feedback when you don't enter your data in the format they are expecting. You'll get messages such as:

"This field is required" (You can't leave this field blank).

"Please enter your phone number in the format xxx-xxxx" (A specific data format is required for it to be considered valid).

"Please enter a valid email address" (the data you entered is not in the right format).

"Your password needs to be between 8 and 30 characters long and contain one uppercase letter, one symbol, and a number." (A very specific data format is required for your data).

This is called form validation. When you enter data, the browser and/or the web server will check to see that the data is in the correct format and within the constraints set by the application. Validation done in the browser is called client-side validation, while validation done on the server is called server-side validation. In this chapter we are focusing on client-side validation.

If the information is correctly formatted, the application allows the data to be submitted to the server and (usually) saved in a database; if the information isn't correctly formatted, it gives the user an error message explaining what needs to be corrected, and lets them try again.

We want to make filling out web forms as easy as possible. So why do we insist on validating our forms? There are three main reasons:

We want to get the right data, in the right format. Our applications won't work properly if our users' data is stored in the wrong format, is incorrect, or is omitted altogether.

We want to protect our users' data. Forcing our users to enter secure passwords makes it easier to protect their account information.

We want to protect ourselves. There are many ways that malicious users can misuse unprotected forms to damage the application (see

Website security⁠

Warning:: Never trust data passed to your server from the client. Even if your form is validating correctly and preventing malformed input on the client-side, a malicious user can still alter the network request.

⁠
`Different types of client-side validation`⁠
⁠

There are two different types of client-side validation that you'll encounter on the web:

Built-in form validation uses HTML5 form validation features, which we've discussed in many places throughout this module. This validation generally doesn't require much JavaScript. Built-in form validation has better performance than JavaScript, but it is not as customizable as JavaScript validation.

JavaScript validation is coded using JavaScript. This validation is completely customizable, but you need to create it all (or use a library).

⁠
`Using built-in form validation`⁠
⁠

One of the most significant features of

HTML5 form controls⁠

is the ability to validate most user data without relying on JavaScript. This is done by using validation attributes on form elements. We've seen many of these earlier in the course, but to recap:

OBS OBS!

⁠

required⁠

: Specifies whether a form field needs to be filled in before the form can be submitted.

⁠

minlength⁠

and

maxlength⁠

: Specifies the minimum and maximum length of textual data (strings)

⁠

min⁠

and

max⁠

: Specifies the minimum and maximum values of numerical input types

type: Specifies whether the data needs to be a number, an email address, or some other specific preset type.

⁠

pattern⁠

: Specifies a

regular expression⁠

that defines a pattern the entered data needs to follow.

If the data entered in a form field follows all of the rules specified by the above attributes, it is considered valid. If not, it is considered invalid.

______________

When an element is valid, the following things are true:

The element matches the

:valid⁠

CSS pseudo-class, which lets you apply a specific style to valid elements.

If the user tries to send the data, the browser will submit the form, provided there is nothing else stopping it from doing so (e.g., JavaScript).

When an element is invalid, the following things are true:

The element matches the

:invalid⁠

CSS pseudo-class, and sometimes other UI pseudo-classes (e.g.,

:out-of-range⁠

) depending on the error, which lets you apply a specific style to invalid elements.

If the user tries to send the data, the browser will block the form and display an error message.

Note: There are several errors that will prevent the form from being submitted, including a

badInput⁠

patternMismatch⁠

rangeOverflow⁠

rangeUnderflow⁠

stepMismatch⁠

tooLong⁠

tooShort⁠

typeMismatch⁠

valueMissing⁠

, or a

customError⁠

⁠
`Built-in form validation examples`⁠
⁠

In this section, we'll test out some of the attributes that we discussed above.

⁠
`Simple start file`⁠
⁠

Let's start with a simple example: an input that allows you to choose whether you prefer a banana or a cherry. This example involves a simple text

<input>⁠

with an associated

<label>⁠

and a submit

<button>⁠

. Find the source code on GitHub at

fruit-start.html⁠

and a live example below.

<form>

<label for="choose">Would you prefer a banana or cherry?</label>

<button>Submit</button>

</form>

input:invalid {

border: 2px dashed red;

}

input:valid {

border: 2px solid black;

}

To begin, make a copy of fruit-start.html in a new directory on your hard drive.

⁠
`The required attribute`⁠
⁠

The simplest HTML5 validation feature is the

required⁠

attribute. To make an input mandatory, add this attribute to the element. When this attribute is set, the element matches the

:required⁠

UI pseudo-class and the form won't submit, displaying an error message on submission when the input is empty. While empty, the input will also be considered invalid, matching the

:invalid⁠

UI pseudo-class.

Add a required attribute to your input, as shown below.

<form>

<label for="choose">Would you prefer a banana or cherry? (required)</label>

<button>Submit</button>

</form>

Note the CSS that is included in the example file:

input:invalid {

border: 2px dashed red;

}

input:invalid:required {

background-image: linear-gradient(to right, pink, lightgreen);

}

input:valid {

border: 2px solid black;

}

This CSS causes the input to have a red dashed border when it is invalid and a more subtle solid black border when valid. We also added a background gradient when the input is required and invalid. Try out the new behavior in the example below:

Note: You can find this example live on GitHub as

fruit-validation.html⁠

(see also the

source code⁠

Try submitting the form without a value. Note how the invalid input gets focus, a default error message ("Please fill out this field") appears, and the form is prevented from being sent.

The presence of the required attribute on any element that supports this attribute means the element matches the

:required⁠

pseudoclass whether it has a value or not. If the

<input>⁠

has no value, the input will match the

:invalid⁠

pseudoclass.

Note: For good user experience, indicate to the user when form fields are required. It isn't only good user experience, it is required by WCAG

accessibility⁠

guidelines. Also, only require users to input data you actually need: For example, why do you really need to know someone's gender or title?

⁠
`Validating against a regular expression`⁠
⁠

Another useful validation feature is the

pattern⁠

attribute, which expects a

Regular Expression⁠

as its value. A regular expression (regex) is a pattern that can be used to match character combinations in text strings, so regexps are ideal for form validation and serve a variety of other uses in JavaScript.

Regexps are quite complex, and we don't intend to teach you them exhaustively in this article. Below are some examples to give you a basic idea of how they work.

a — Matches one character that is a (not b, not aa, and so on).

abc — Matches a, followed by b, followed by c.

ab?c—Matches a, optionally followed by a single b, followed by c. ( ac or abc)

ab*c—Matches a, optionally followed by any number of bs, followed by c. ( ac , abc, abbbbbc, and so on).

a|b — Matches one character that is a or b.

abc|xyz — Matches exactly abc or exactly xyz (but not abcxyz or a or y, and so on).

There are many more possibilities that we don't cover here. For a complete list and many examples, consult our

Regular expressions⁠

documentation.

Let's implement an example. Update your HTML to add a

pattern⁠

attribute like this:

<form>

<label for="choose">Would you prefer a banana or a cherry?</label>

<button>Submit</button>

</form>

This gives us the following update — try it out:

Note: You can find this example live on GitHub as

fruit-pattern.html⁠

(see also the

source code⁠

In this example, the

<input>⁠

element accepts one of four possible values: the strings "banana", "Banana", "cherry", or "Cherry". Regular expressions are case-sensitive, but we've made it support capitalized as well as lower-case versions using an extra "Aa" pattern nested inside square brackets.

At this point, try changing the value inside the

pattern⁠

attribute to equal some of the examples you saw earlier, and look at how that affects the values you can enter to make the input value valid. Try writing some of your own, and see how it goes. Make them fruit-related where possible so that your examples make sense!

If a non-empty value of the

<input>⁠

doesn't match the regular expression's pattern, the input will match the

:invalid⁠

pseudoclass.

Note: Some

<input>⁠

element types don't need a

pattern⁠

attribute to be validated against a regular expression. Specifying the email type, for example, validates the inputs value against a well-formed email address pattern or a pattern matching a comma-separated list of email addresses if it has the

multiple⁠

attribute.

Note: The

<textarea>⁠

element doesn't support the

pattern⁠

attribute.

⁠
`Constraining the length of your entries`⁠
⁠

You can constrain the character length of all text fields created by

<input>⁠

<textarea>⁠

by using the

minlength⁠

and

maxlength⁠

attributes. A field is invalid if it has a value and that value has fewer characters than the

minlength⁠

value or more than the

maxlength⁠

value.

Browsers often don't let the user type a longer value than expected into text fields. A better user experience than just using maxlength is to also provide character count feedback in an accessible manner and let them edit their content down to size. An example of this is the character limit seen on Twitter when Tweeting. JavaScript, including

solutions using maxlength⁠

, can be used to provide this.

⁠
`Constraining the values of your entries`⁠
⁠

For number fields (i.e.

<input type="number">⁠

), the

min⁠

and

max⁠

attributes can be used to provide a range of valid values. If the field contains a value outside this range, it will be invalid.

Let's look at another example. Create a new copy of the

fruit-start.html⁠

file.

Now delete the contents of the <body> element, and replace it with the following:

<form>

<div>

<label for="choose">Would you prefer a banana or a cherry?</label>

</div>

<div>

<label for="number">How many would you like?</label>

</div>

<div>

<button>Submit</button>

</div>

</form>

Here you'll see that we've given the text field a minlength and maxlength of six, which is the same length as banana and cherry.

We've also given the number field a min of one and a max of ten. Entered numbers outside this range will show as invalid; users won't be able to use the increment/decrement arrows to move the value outside of this range. If the user manually enters a number outside of this range, the data is invalid. The number is not required, so removing the value will still result in a valid value.

Here is the example running live:

Note: You can find this example live on GitHub as

fruit-length.html⁠

(see also the

source code⁠

Note: <input type="number"> (and other types, such as range and date) can also take a

step⁠

attribute, which specifies what increment the value will go up or down by when the input controls are used (such as the up and down number buttons). In the above example we've not included a step attribute, so the value defaults to 1. This means that floats, like 3.2, will also show as invalid.

⁠
`Full example`⁠
⁠

Here is a full example to show usage of HTML's built-in validation features. First, some HTML:

<form>

<p>

<legend>Do you have a driver's license?<abbr title="This field is mandatory" aria-label="required">*</abbr></legend>

<!-- While only one radio button in a same-named group can be selected at a time,

and therefore only one radio button in a same-named group having the "required"

attribute suffices in making a selection a requirement -->

</fieldset>

</p>

<p>

<!-- The pattern attribute can act as a fallback for browsers which

don't implement the number input type but support the pattern attribute.

Please note that browsers that support the pattern attribute will make it

fail silently when used with a number field.

Its usage here acts only as a fallback -->

<input type="number" min="12" max="120" step="1" id="n1" name="age"

pattern="\d+">

</p>

<p>

<label for="t1">What's your favorite fruit?<abbr title="This field is mandatory" aria-label="required">*</abbr></label>

<input type="text" id="t1" name="fruit" list="l1" required

<option>Banana</option>

<option>Cherry</option>

<option>Apple</option>

<option>Strawberry</option>

<option>Lemon</option>

<option>Orange</option>

</datalist>

</p>

<p>

<label for="t2">What's your e-mail address?</label>

</p>

<p>

<label for="t3">Leave a short message</label>

</p>

<p>

<button>Submit</button>

</p>

</form>

And now some CSS to style the HTML:

form {

font: 1em sans-serif;

max-width: 320px;

}

p > label {

display: block;

}

input[type="text"],

input[type="email"],

input[type="number"],

textarea,

fieldset {

width : 100%;

border: 1px solid #333;

box-sizing: border-box;

}

input:invalid {

box-shadow: 0 0 5px 1px red;

}

input:focus:invalid {

box-shadow: none;

}

This renders as follows:

See

Validation-related attributes⁠

for a complete list of attributes that can be used to constrain input values and the input types that support them.

Note: You can find this example live on GitHub as

full-example.html⁠

(see also the

source code⁠

⁠
`Validating forms using JavaScript`⁠
⁠

You must use JavaScript if you want to take control over the look and feel of native error messages or to deal with legacy browsers that do not support HTML's built-in form validation. In this section we will look at the different ways to do this.

⁠
`The Constraint Validation API`⁠
⁠

Most browsers support the

Constraint Validation API⁠

, which consists of a set of methods and properties available on the following form element DOM interfaces:

⁠

HTMLButtonElement⁠

(represents a

<button>⁠

element)

⁠

HTMLFieldSetElement⁠

(represents a

<fieldset>⁠

element)

⁠

HTMLInputElement⁠

(represents an

<input>⁠

element)

⁠

HTMLOutputElement⁠

(represents an

<output>⁠

element)

⁠

HTMLSelectElement⁠

(represents a

<select>⁠

element)

⁠

HTMLTextAreaElement⁠

(represents a

<textarea>⁠

element)

The Constraint validation API makes the following properties available on the above elements.

validationMessage: Returns a localized message describing the validation constraints that the control doesn't satisfy (if any). If the control is not a candidate for constraint validation (willValidate is false) or the element's value satisfies its constraints (is valid), this will return an empty string.

validity: Returns a ValidityState object that contains several properties describing the validity state of the element. You can find full details of all the available properties in the

ValidityState⁠

reference page; below is listed a few of the more common ones:

⁠

patternMismatch⁠

: Returns true if the value does not match the specified

pattern⁠

, and false if it does match. If true, the element matches the

:invalid⁠

CSS pseudo-class.

⁠

tooLong⁠

: Returns true if the value is longer than the maximum length specified by the

maxlength⁠

attribute, or false if it is shorter than or equal to the maximum. If true, the element matches the

:invalid⁠

CSS pseudo-class.

⁠

tooShort⁠

: Returns true if the value is shorter than the minimum length specified by the

minlength⁠

attribute, or false if it is greater than or equal to the minimum. If true, the element matches the

:invalid⁠

CSS pseudo-class.

⁠

rangeOverflow⁠

: Returns true if the value is greater than the maximum specified by the

max⁠

attribute, or false if it is less than or equal to the maximum. If true, the element matches the

:invalid⁠

and

:out-of-range⁠

CSS pseudo-classes.

⁠

rangeUnderflow⁠

: Returns true if the value is less than the minimum specified by the

min⁠

attribute, or false if it is greater than or equal to the minimum. If true, the element matches the

:invalid⁠

and

:out-of-range⁠

CSS pseudo-classes.

⁠

typeMismatch⁠

: Returns true if the value is not in the required syntax (when

type⁠

is email or url), or false if the syntax is correct. If true, the element matches the

:invalid⁠

CSS pseudo-class.

valid: Returns true if the element meets all its validation constraints, and is therefore considered to be valid, or false if it fails any constraint. If true, the element matches the

:valid⁠

CSS pseudo-class; the

:invalid⁠

CSS pseudo-class otherwise.

valueMissing: Returns true if the element has a

required⁠

attribute, but no value, or false otherwise. If true, the element matches the

:invalid⁠

CSS pseudo-class.

willValidate: Returns true if the element will be validated when the form is submitted; false otherwise.

The Constraint Validation API also makes the following methods available on the above elements and the

form⁠

element.

checkValidity(): Returns true if the element's value has no validity problems; false otherwise. If the element is invalid, this method also fires an

invalid event⁠

on the element.

reportValidity(): Reports invalid field(s) using events. Useful in combination with preventDefault() in an onSubmit event handler

setCustomValidity(message): Adds a custom error message to the element; if you set a custom error message, the element is considered to be invalid, and the specified error is displayed. This lets you use JavaScript code to establish a validation failure other than those offered by the standard HTML5 validation constraints. The message is shown to the user when reporting the problem.

Implementing a customized error message

As you saw in the HTML5 validation constraint examples earlier, each time a user tries to submit an invalid form, the browser displays an error message. The way this message is displayed depends on the browser.

These automated messages have two drawbacks:

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.

Formvalidering

⁠What is form validation?⁠⁠

⁠Different types of client-side validation⁠⁠

⁠Using built-in form validation⁠⁠

OBS OBS!

⁠Built-in form validation examples⁠⁠

⁠Simple start file⁠⁠

⁠The required attribute⁠⁠

⁠Validating against a regular expression⁠⁠

⁠Constraining the length of your entries⁠⁠

⁠Constraining the values of your entries⁠⁠

⁠Full example⁠⁠

⁠Validating forms using JavaScript⁠⁠

⁠The Constraint Validation API⁠⁠

Implementing a customized error message

⁠
`What is form validation?`⁠
⁠

⁠
`Different types of client-side validation`⁠
⁠

⁠
`Using built-in form validation`⁠
⁠

⁠
`Built-in form validation examples`⁠
⁠

⁠
`Simple start file`⁠
⁠

⁠
`The required attribute`⁠
⁠

⁠
`Validating against a regular expression`⁠
⁠

⁠
`Constraining the length of your entries`⁠
⁠

⁠
`Constraining the values of your entries`⁠
⁠

⁠
`Full example`⁠
⁠

⁠
`Validating forms using JavaScript`⁠
⁠

⁠
`The Constraint Validation API`⁠
⁠