HELPER FUNCTIONS

The first section of this chapter uses plain JavaScript, no jQuery. We will create our own JavaScript file to handle cross-browser issues, it will contain one helper function to create events.

Forms use a lot of event handlers and (as you saw in Chapter 6) IE5-8 used a different event model than other browsers. You can use jQuery to deal with cross-browser event handling. But, if you do not want to include the entire jQuery script just to handle events in older version of IE, then you need to write your own fallback code to handle the events.

Instead of writing the same fallback code every time you need an event handler, you can write the fallback code once in a helper function, and then call that function every time you need to add an event handler to a page.

On the right-hand page you can see a function called addEvent(). It lives in a file called utilities.js. Once that file has been included in the HTML page, any scripts included after it will be able to use this function to create cross-browser event handler:

The function takes three parameters:
i) el is a DOM node representing the element that the event will be added to or removed from.
ii) event is the type of event being listened for.
iii) callback is the function that is to be run when the event is triggered on that element.

The utilities.js file on the website also has a method to remove events.

If you look inside the addEvent() method on the right-hand page, a conditional statement checks whether the browser supports addEventListener(). If it does, a standard event listener will be added. If not, then the IE fallback will be created.

The fallback addresses three points:

• It uses IE's the attachEvent() method.
• In IE5-8, the event object is not automatically passed into the event-handling function (and is not available via the this keyword) see p264. Instead it is available on the window object. So the code must pass the event object into the event handler as a parameter.
• When you pass parameters to an event-handling function, the call must be wrapped in an anonymous function see p256.

To achieve this, the fallback adds two methods to the element the event handler will be placed upon (see steps 5 and 6 on the right-hand page). It then uses IE's attachEvent() method to add the event handler code to the element.

The functions demonstrate two new techniques:

• Adding new methods to DOM nodes: You can add methods to DOM nodes because they are just objects (that represent elements).
• Creating method names using a variable: Square brackets can be used to set a property/method, their content is evaluated into a string.

THE FORM ELEMENT

DOM nodes for form controls have different properties, methods, and events than some of the other elements you have met so far. Here are some you should note for the <form> element.

The DOM methods you saw in Chapter 5, such as getElementById(), getElementsByTagName(), and querySelector(), are the most popular techniques for accessing both the <form> element and the form controls within any form. However, the document object also has something called the forms collection. The forms collection holds a reference to each of the <form> elements that appear on a page.

Each item in a collection is given an index number (a number starting at 0, like an array). This would access the second form using its index number:
document.forms[1];

You can also access a form using the value of its name attribute. The following would select a form whose name attribute has a value of login:
document.forms.login

Each <form> element in the page also has an elements collection. It holds all of the form controls within that form. Each item in the elements collection can also be accessed by index number or by the value of its name attribute.

The following would access the second form on the page and then select the first form control within it:
document.forms[1].elements[0];

The following would access the second form on the page, then select the element whose name attribute had a value of password from that form:
document.forms[1].elements.password;

Note: index numbers in a collection of elements can change if the markup of a page is altered. So, use of index numbers ties a script to the HTML markup (- it does not achieve a separation of concerns).

FORM CONTROLS

Each type of form control uses a different combination of the properties, methods, and events shown below. Note that the methods can be used to simulate how a user would interact with the form controls.

SUBMITTING FORMS

In this example, a basic login form lets users enter a username and password. When the user submits the form, a welcome message will replace the form. On the right-hand page you can see both the HTML and the JavaScript for this example.

The event listener waits for the submit event on the form (rather than a click on the submit button) because the form can be submitted in other ways than clicking on the submit button. For example, the user might press the Enter key.

var form = document.getElementById(‘login’);
var elements = form.elements;
var elUsername = elements.username;
var elMain = document.getElementById(‘main’);
addEvent(form, ‘submit’, function(e) {
  e.preventDefault();
  var msg = ‘Welcome ’ + elUsername.value;
  elMain.textContent = msg;
});

CHANGING TYPE OF INPUT

This example adds a checkbox under the password input. If the user checks that box, their password will become visible. It works by using JavaScript to change the type property of the input from password to text. (The type property in the DOM corresponds to type attribute in the HTML.)

Changing the type property causes an error in IE8 (and earlier), so this code is placed in a try… catch statement. If the browser detects an error, the script continues to run the second code block.

As you saw in Chapter 10, an error can stop a script from running. If you know something may cause an error for some browsers, placing that code in a try… catch statement lets the interpreter continue with an alternative set of code.

SUBMIT BUTTONS

This script disables the submit button when:

• The script first loads. The change event then checks when the password changes and enables submit if the password is given a value.
• The form has been submitted (to prevent the form being sent multiple times).

The button is disabled using the disabled property. It corresponds with the HTML disabled attribute, and can be used to disable any form elements that a user can interact with. A value of true disables the button; false lets the user click on it.

CHECKBOXES

This example asks users about their interests. It has an option to select or deselect all of the checkboxes. It has two event handlers:

• The first fires when the all checkbox is selected; it loops through the options, updating them.
• The second fires when the options change; if one is deselected, the all option must be deselected.

You can use the change event to detect when the value of a checkbox, radio button, or select box changes. Here, it is used to tell when the user selects / deselects a checkbox. The checkboxes can be updated using the checked property, which corresponds with HTML's checked attribute.

RADIO BUTTONS

This example lets users say how they heard about a website. Every time the user selects a radio button, the code checks if the user selected the option that says other, and one of two things happens:

• If other is selected, a text input is shown so they can add further detail.
• If the first two options are selected, the text box is hidden and its value is emptied.

SELECT BOXES

The <select> element is more complex than the other form controls. Its DOM node has a number of extra properties and methods. Its <option> elements contain the values a user can select.

This example features two select boxes. When the user selects an option from the first select box, the contents of the second select box are updated with corresponding options.

In the first select box, users can choose to rent a camera or a projector. When they make their choice, a list of options are shown in the second select box. Because this example is a bit more complex than the ones you have seen so far in this chapter, the HTML and screen shots are shown to the right, and the JavaScript file is discussed on p586-p587.

When the user selects an option from the dropdown list, the change event fires. This event is often used to trigger scripts when the user changes the value of a select box.

The <select> element also has some extra properties and methods that are specific to it; these are shown in the tables below.

If you want to work with the individual options the user can select from, a collection of <option> elements is available.

TEXTAREA

In this example, users can enter a biography of up to 140 characters. When the cursor is in the textarea, a <span> element will be shown with a count of how many characters the user has remaining. When the textarea loses focus, this message is hidden.

HTML5 ELEMENTS & ATTRIBUTES

HTML5 adds form elements and attributes to perform tasks that had previously been performed by JavaScript. However, their appearance can vary a lot between different browsers (especially their error messages).

SEARCH

<input type=“search”
  placeholder=“Search…”
  autofocus>

Safari rounds the corners of its search inputs to match the user interface of the operating system. When you enter text, Safari shows a cross icon which, when clicked or tapped, allows the user to clear the text from the field. Other browsers show an input like any other text input.

EMAIL, URL, PHONE

<input type=“email”>
<input type=“url”>
<input type=“telephone”>

Email, URL, and phone inputs all look like text input fields, but the browser performs checks on the data entered into these inputs to see if it is in the right format to be an email address, URL, or phone number, then shows a message if it is not.

NUMBER

<input type=“number”
  min=“0”
  max=“10”
  step=“2”
  value=“6”>

Number inputs sometimes add arrows to increase or decrease the number specified (also known as spinboxes). You can specify a minimum and a maximum value, a step (or increment), and an initial value. The browser checks that the user entered a number, and shows a message if a number was not entered.

RANGE

<input type=“range”
  min=“0”
  max=“10”
  step=“2”
  value=“6”>

The range input offers another way to specify a number - this time the control shows a slider. As with the spinbox, you can specify a minimum and a maximum value, a step, and an initial value.

COLOR PICKER

<input type=“color”>

At the time of writing, Chrome and Opera are the only browsers to implement a color input. It allows users to specify a color. When they click on the control, the browser will usually show the operating system's default color picker (except for Linux, which offers a more basic palette). It inserts a hex color value based on the user's selection.

DATE

<input type=“date”> (below)
<input type=“month”>
<input type=“week”>
<input type=“time”>
<input type=“datetime”>

There are several different date inputs available. At the time of writing, Chrome was the only browser to have implemented a date picker.

SUPPORT & STYLING

HTML5 form elements are not supported in all browsers and, when they are, the inputs and error messages can look very different.

DESKTOP BROWSERS

At the time of writing, many developers were still using JavaScript instead of these new HTML5 features because:

• Older browsers do not support the new input types (they just show a text box in their place).
• Different browsers present the elements and their error messages in very different ways (and designers often want to give users a consistent experience across browsers).

Below, you can see how the error messages look very different in two of the main browsers.

MOBILE

On mobile devices the situation is very different, as most modern mobile browsers:

• Support the main HTML5 elements
• Show a keyboard that's adapted to the type: email brings up a keyboard with the @ sign number type brings up a number keyboard
• Give helpful versions of the date picker

Therefore, in mobile browsers, the new HTML5 types and elements make forms more accessible and usable for your visitors.

CURRENT APPROACHES

Until more visitors' browsers support these new features, and do so in a consistent way, developers will think carefully about how they use them.

POLYFILLS

A polyfill is a script that provides functionality you may expect a browser to support by default. For example, because older browsers do not support the new HTML5 elements, polyfills can be used to implement a similar experience / functionality in those older browsers. Typically this is achieved using JavaScript or a jQuery plugin.

Polyfills often come with CSS files that are used to style the functionality the script adds.

You can find a list of polyfills for various features here:
http://html5please.com

There is an example of how to use a polyfill on p594, where you see how to get the HTML5 placeholder attribute to show up in older browsers.

FEATURE DETECTION

Feature detection means checking whether a browser supports a feature or not. You can then decide what to do if a feature is, or is not, supported. On p415 you learned about a script called modernizr.js, which tests for browser features.

Commonly, if a feature is not supported, a polyfill script will be loaded to emulate that feature. To save loading the polyfill script into browsers that do not need it, Modernizr includes a conditional loader; it will only load a script if the test indicates that the script is needed.

Another popular conditional loader is Require.js (available from http://requirejs.org), but it is a bit more complex when you are first starting out because it offers many other features.

CONSISTENCY

Many designers and developers want to control the appearance of form controls and error messages to give a consistent experience across all browsers. (Consistency in error messages is considered important because different styles of error messages can confuse users.)

Therefore, the long example used at the end of this chapter will disable HTML5 validation and try to use JavaScript validation as its first choice. (HTML5 validation is only shown if the user does not have JavaScript enabled; it is used as a fallback in modern browsers.)

In that example, you also see jQuery UI used to ensure that the date picker is consistent across all devices, with as little code as possible.

PLACEHOLDER FALLBACK

The HTML5 placeholder attribute lets you put words in text inputs (to replace labels or to add hints about what to enter). When the input gains focus and the user starts typing, the text disappears. But it only works in modern browsers, so this script ensures that the user sees placeholder text in older browsers too. It is a basic example of a polyfill.

POLYFILL USING MODERNIZR & YEPNOPE

You met Modernizr in Chapter 9, here you can see it used with a conditional loader so that it only loads a fallback script if one is needed.

Modernizr lets you test whether or not a browser and device support certain features; this is known as feature detection. You can then take different courses of action depending on whether or not the features were supported. For example, if an older browser does not support a feature, you might decide to use a polyfill.

Modernizr is sometimes included in the <head> of an HTML page when it needs to perform checks before the page has loaded (for example, some HTML5 / CSS3 polyfills must be loaded before the page).

MODERNIZR ON ITS OWN

Each feature you test using Modernizr becomes a property of the Modernizr object. If the feature is supported, the property contains true; if not, it contains false. You then use the properties of the Modernizr object in a conditional statement as shown below. Here, if Modernizr's cssanimations property does not return true the code in the curly braces runs.

if (!Modernizr.cssanimations) {
  // CSS animations are not supported
  // Use jQuery animation instead
}

Rather than loading a polyfill script for everyone who visits your site (even if they do not need to use it), you can use something called a conditional loader, which will let you load different files depending on whether a condition returns true or false. Modernizr is commonly used with a conditional loader called YepNope.js, so polyfills are only loaded if needed.

Once you have included the YepNope script in your page, you can call the yepnope() function. It uses object literal syntax to indicate a condition to test, and then what files to load depending on whether the condition returned true or false.

MODERNIZR + YEPNOPE

YepNope is passed an object literal, which usually contains a minimum of three properties:

• test is the a condition being checked. Here Modernizr is used to check if cssanimations are supported.
• yep is the file to load if the condition returns true.
• nope is the file to load if the condition returns false (here it loads two files using array syntax).

yepnope({
  test: Modernizr.cssanimations,
  yep: ‘css/animations.css’,
  nope: [‘js/jquery.js’, ‘js/animate.js’]
});

FORM VALIDATION

The final section of this chapter uses one big script to discuss the topic of form validation. It helps users give you responses in the format you need. (The example also has some form enhancements, too.)

Validation is the process of checking whether a value meets certain rules (for example, that a password has a minimum number of characters). It lets you tell users if there is a problem with the values they entered so that they can correct the form before they resubmit it. This has three key advantages:

• You are more likely to get the information you need in a format you can use.
• It is faster to check values in the browser than it is to send data to the server to be checked.
• It saves resources on the server.

In this section you see how to check the values a user enters into a form. These checks happen when the form is submitted. To do this users could press submit or use the Enter on the keyboard, so the validation process will be triggered by the submit event (not the click event of a submit button).

We will look at validation using one long example. You can see the form below, and the HTML is shown on the right. It uses HTML5 form controls, but the validation is going to be done using JavaScript to make sure that the experience is consistent across all browsers (even if they do support HTML5).

VALIDATION OVERVIEW

This example has over 250 lines of code and will take 22 pages to explain. The script starts by looping through each element on the page performing two generic checks on every form control.

GENERIC CHECKS

First, the code loops through every element in the form and performs two types of generic checks. They are generic checks because they would work on any element, and would work with any form.

1. Does the element have the required attribute? If so, does it have a value?

2. Does the value match with the type attribute? E.g., Does an email input hold an email address?

CHECKING EACH ELEMENT

To work through each element in the form, the script makes use the form's elements collection (which holds a reference to each form control). The collection is stored in a variable called elements. In this example, the elements collection will hold the following form controls. The right-hand column tells you which elements are required to have a value:

Some developers proactively cache form elements in variables in case validation fails. This is a good idea, but to keep this (already very long) example simpler, the nodes for the form elements are not cached.

If you have not already done so, it would be helpful to download the code for this example from the website, javascriptbook.com, and have it ready when you are reading through the following pages.

Once the generic checks have been performed, the script then makes some checks that apply to individual elements on the form. Some of these checks apply only to this specific form.

CUSTOM VALIDATION TASKS

Next the code performs checks that correspond with specific elements in the form (not all elements):

• Do the passwords match?
• Is the bio in the textarea under 140 characters?
• If the user is less than 13 years old, is the parental consent checkbox selected?

These checks are specific to this form and only apply to selected elements in the form (not all of them).

TRACKING VALID ELEMENTS

To keep track of errors, an object called valid is created. As the code loops through each element performing the generic checks, a property is added to the valid object for each element:

• The property name is the value of its id attribute.
• The value is a Boolean. Whenever an error is found on an element, this value is set to false.

DEALING WITH ERRORS

If there are errors, the script needs to prevent the form being submitted and tell the user what they need to do in order to correct their answers.

As the script checks each element, if an error is found, two things happen:

• The corresponding property of the valid object is updated to indicate the content is not valid.
• A function called setErrorMessage() is called. This function uses jQuery's .data() method, which allows you to store data with the element. So the error message is stored in memory along with the form element that has the problem.

After each element has been checked, then error messages can be shown using showErrorMessage(). It retrieves the error message and puts it in a <span> element, which is added after the form control.

Each time the user tries to submit the form, if an error was not found on an element it is important to remove any error messages from that element. Consider the following scenario:
a) A user filled out a form with more than one error.
b) This triggered multiple error messages.
c) The user fixes one problem, so its corresponding message must be removed, while error message(s) for problems that have not been fixed must remain visible.

Therefore, when each of the elements is looped through, either an error message is set, or the error message is removed.

Above you can see a representation of the form and its elements collection. There was a problem with the email input, so the .data() method has stored a key/value pair with that element.

This is how the setErrorMessage() function will store the error messages to show to the user. If the error is fixed, then the error value is cleared (and the element with the error message removed).

SUBMITTING THE FORM

Before sending the form, the script checks whether there were any errors. If there were, the script stops the file from being submitted.

In order to check whether any errors were found, a variable called isFormValid is created and is given a value of true. The script then loops through each property of the valid object, and if there was an error (if any property of that object has a value of false), then there is an error in the form and the isFormValid variable is also set to false.

So, isFormValid is being used as a flag (you can think of it being like a master switch) if an error is found, it is turned off. At the end of the script, if isFormValid is false then an error must have been found and the form should not be submitted (using the preventDefault() method).

It is important to check and process all of the elements before deciding whether to submit the form so that you can show all of the relevant error messages in one go.

If every value has been checked, the user can be shown all of the things they have to amend before re-submitting the form.

If the form only showed the first error it came across, and stopped, the user would only see one error each time they submitted the form. This could soon become frustrating for the user if they were to keep trying to submit the form and see new errors.

CODE OVERVIEW

On the right is an outline of the validation code, split into four sections. On line 3, an anonymous function is called when the form is submitted. It orchestrates the validation, in turn calling other functions (not all of which are shown on the right-hand page, see further pages for more).

A: SET UP THE SCRIPT

REQUIRED FORM ELEMENTS

The HTML5 required attribute indicates a field must have a value. Our validateRequired() function will first check for the attribute. If present, it then checks whether or not it has a value.

validateRequired() is called for each element individually (see step 9, p605). Its one parameter is the element it is checking.

In turn, it calls upon three other named functions.
i) isRequired() checks for the required attribute.

ii) isEmpty() can check if the element has a value.
iii) setErrorMessage() sets error messages if there are problems.

A: DOES IT HAVE A REQUIRED ATTRIBUTE?

validateRequired() uses two functions to perform checks:
1: isRequired() checks whether the element has a required attribute.
2: isEmpty() checks whether the element has a value.

isRequired()

The isRequired() function takes an element as a parameter and checks if the required attribute is present on that element. It returns a Boolean.

There are two types of check: The first, in blue, is for browsers that support the HTML5 required attribute. The one in orange is for older browsers.

To check if the required attribute is present, the typeof operator is used. It checks what datatype the browser thinks the required attribute is.

MODERN BROWSERS

Modern browsers know the required property is a Boolean, so the first part of this check tells us if it is a modern browser. The second part checks if it is present on this element. If the attribute is present, it will evaluate to true. If not, it returns undefined, which is considered a falsy value.

isEmpty()

The isEmpty() function (below) takes an element as a parameter and checks to see if it has a value. As with isRequired(), two checks are used to handle both new and older browsers.

OLDER BROWSERS

Browsers that do not know HTML5 can still tell whether or not an HTML5 attribute is present on an element. In those browsers, if the required attribute is present, it gets treated as a string, so the condition would evaluate to true. If not, the type would be undefined, which is falsy.

ALL BROWSERS

The first check looks to see if the element does not have a value. If it has a value, the function should return false. If it is empty, it will return true.

WHAT IS VALIDATED

It is important to note that the required attribute only indicates that a value is required. It doesn't stipulate how long the value should be, nor does it perform any other kind of validation. Specific checks, such as these, would have to be added in the validateTypes() function or the script's custom validation section.

OLDER BROWSERS

If older browsers use a polyfill for placeholder text, the value would be the same as the placeholder, so it is considered empty if those values match.

CREATING ERROR MESSAGES

The validation code processes elements one by one; any error messages are stored using jQuery's .data() method.

HOW ERRORS ARE SET

Throughout the validation code, whenever an error is found, you will see calls to a function called setErrorMessage(), which takes two parameters:
i) el: the element that the error message is for
ii) message: the text the error message will display

For example, the following would add the message ‘Field is required’ to the element that is stored in the el variable:

setErrorMessage(el, ‘Field is required’);

HOW DATA IS STORED WITH NODES

Each error message is going to be stored with the element node that it relates to using the jQuery .data() method. When you have elements in a jQuery matched set, the .data() method allows you to store information in key/value pairs for each individual element.

The .data() method has two parameters:
i) The key, which is always going to be errorMessage
ii) The value, which is the text that the error message will display

setErrorMessage()

DISPLAYING ERROR MESSAGES

After each element has been checked, if one or more were not valid, showErrorMessage() will display the error messages on the page.

HOW ERRORS ARE DISPLAYED

If an error message needs to be shown, first a <span> element will be added to the page directly after the form field with the error.

Next, the message is added into the <span> element. To get the text for the error message, the same jQuery .data() method that set the message is used again. This time, it only takes one parameter: the key (which is always errorMessage).

This all happens within the function called showErrorMessage() which is shown below.

showErrorMessage()

VALIDATING DIFFERENT TYPES OF INPUT

HTML5's new types of input come with built-in validation. This example uses HTML5 inputs, but validates them with JavaScript to ensure that the experience is consistent across all browsers.

The validateTypes() function is going to perform the validation just like modern browsers do with HTML5 elements, but it will do it for all browsers. It needs to:

• Check what type of data the form element should hold
• Ensure the contents of the element matches that type

CREATING AN OBJECT TO VALIDATE DATA TYPES

The validateType object (outlined below) has three methods:

var validateType = {
  email: function(el) {
  // Check email address
  },
  number: function(el) {
  // Check it is a number
  },
  date: function(el) {
  // Check date format
  }
}

The code inside each method is virtually identical. You can see the format of the email() method below. Each method validates the data using something called a regular expression. The regular expression is the only thing that changes in each method to test the different data types.

Regular expressions allow you to check for patterns in strings, and here they are used with a method called test().

You can learn more about regular expressions and their syntax on the next two pages. For now, you just need to know that they are used to check the data contains a specific pattern of characters.

Storing these checks as methods of an object makes it easy to access each of the the different checks when it comes time to validate the different types of input in a form.

i) The regular expression is [^@]+@[^@]+ (it is between the / and / characters). It states a pattern of characters that are found in a typical email address.

ii) The test() method takes one parameter (a string), and checks whether the regular expression can be found within the string. It returns a Boolean.

iii) In this example, the test() method is passed the value of the element you want to check. Below you can see the method to test email addresses.

CUSTOM VALIDATION

The final part of the script performs three checks that apply to individual form elements; each check lives in a named function.

On the next pages, you will see these three functions. Each is called in the same manner as the validateBio() function shown below. (The full code that calls them is available from the website, along with the code for all examples from the book.)

Each of these functions will return a value of true or false.

CODE DEPENDENCIES & REUSE

In any project, avoid writing two sets of code that perform the same task. You can also try to reuse code across projects (for example, using utility scripts or jQuery plugins). If you do, note any dependencies in your code.

DEPENDENCIES

Sometimes one script will require another script to be included in the page in order to work. When you write a script that relies on another script, the other script is known as a dependency.

For example, if you are writing a script that uses jQuery, then your script depends upon jQuery being included in the page in order to work; otherwise, you would not be able to use its selectors or methods.

It is a good idea to note dependencies in a comment at the top of the script so that they are clear to others. The final custom function in this example depends on another script that checks the user's age.

CODE REUSE VS. DUPLICATION

When you have two sets of code that do the same job, it is referred to as code duplication. This is usually considered bad practice.

The opposite is code reuse where the same lines of code are used in more than one part of a script (functions are a good example of code reuse).

You may hear programmers refer to this as the DRY principle: don't repeat yourself. “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.” It was formulated by Andrew Hunt and Dave Thomas in a book called The Pragmatic Programmer (Addison-Wesley, 1999).

To encourage reuse, programmers sometimes create a set of smaller scripts (instead of one big script). Therefore, code reuse can lead to more code dependencies. You have already seen an example of this with the helper functions for event handling. You are about to see another example…

HIDE PARENTAL CONSENT

As you saw on the previous page, the subscription form uses two extra scripts to enhance the user experience. Here is the first; it does two things:

• Uses the jQuery UI date picker to show a consistent date picker across browsers
• Checks whether the parental consent checkbox should be shown when the user leaves the date input (it does this if they are under 13)

PASSWORD FEEDBACK

The second script designed to enhance the form provides feedback to the users as they leave either of the password inputs. It changes the value of the class attribute for the password inputs, offering feedback to show whether or not the password is long enough and whether or not the value of the password and its confirmation box match.

This demonstrates how scripts often group all of the functions and the event handlers together.