A web application is usually divided into two distinct parts. The first is usually referred to as the back end or server side. It is powered by PHP, ASP.NET, Ruby, or any other server-side technology to validate, process, and format data. While there's always some level of complexity involved with an application, the server-side portion of a web application is typically more straightforward than the client portion — the second part — because it has to do something only when data is sent or requested by the user.
The client portion, or front end, is the interface used by the user to input and view information, as well as to interact with the application as a whole. The client portion is made up of HTML, CSS, and JavaScript. HTML and CSS are sufficient for providing a user interface for a web application, but JavaScript is what can make an interface dynamic and responsive.
The user interface of a web application is usually in a reactive state — it waits for the user to perform a particular action before it knows to do something. Look at Google's search page as an example. When you first visit the page, you see something similar to Figure 16-1.
You see nothing but a search form, but the moment you move your mouse pointer or type in the search field, the page reacts to your actions. Moving your mouse causes the tool bar at the top to fade into view, and typing text into the search field causes Google's autocomplete feature to activate, as shown in Figure 16-2.
These subtle features on Google's search page are a prime example of how JavaScript can enrich the user's experience. But how does JavaScript know when to execute certain code based on a user's actions?
The answer is events. An event is something that happens, usually outside the developer's control, and that is handled by code. For example, pressing a key while the cursor is in the search field on Google's search page causes an event called keypress to fire, or take place. The developers of Google's search page lack control over when you press a key, but they can write what is called an event handler to handle the keypress event. This event handler executes JavaScript code every time you press a key while typing in the search field. By reacting to your users' actions, you can enrich their experiences while they use your app — just as the developers of Google's search page enhance your experience.
Unfortunately, events are one area in client-side development in which there are very noticeable differences in the various browsers. On one hand you have the browsers that support and implement the standard DOM event model; these are Internet Explorer 9, Firefox, Chrome, Safari, and Opera. On the other hand are Internet Explorer 8 and below, which use their own proprietary event model. Thankfully, there are similarities between the two event models; their differences, and how to cope with them, will be discussed in later lessons.
Now, though, you'll be introduced to the many different kinds of events you can "listen" for in order to execute code when they happen. You'll apply this information in future lessons.
Note
The events covered in this introduction are part of the W3C DOM event standard, and most pertain to events attached to HTML elements.
The mouse is arguably the most important input device when it comes to the Web. Unless inputting information into a form, the average user doesn't use the keyboard all that much, and certainly doesn't use it to interact with a web page. No, pointing devices reign on the Web, and so the events associated with the mouse are the most commonly handled.
The mouse can generate a variety of events, but they all fall into two categories: movement-based and button-based.
On a web page, a user generates an event every time he or she moves the mouse. In some cases, moving the mouse pointer one pixel in either direction can generate three events (or more, depending on the browser ). These events are:
Movement is just part of the equation when it comes to mouse-based events; it's also very useful to know when the user clicks the mouse button. Usually, clicking a button on the mouse generates three events, and they occur in the following order:
mousedown: This event occurs when a mouse button is pressed over an element.mouseup: This event occurs when a mouse button is released over an element.click: This event occurs when the mouse button is clicked over an element. Aclickevent happens when both amousedownand amouseupoccur over the same location.
There is a fourth button event:
The second-most-important input device, for web applications, is the keyboard. It is what users use to supply data to web applications. There are three keyboard events, and they are similar in concept to the three primary events of the mouse button. Pressing a key generates the following three events in the provided order:
There is usually some confusion about keyboard events, as they may seem redundant. But there are subtle differences in the ways they are used, and it's important to know the difference between a character and a key. A key is a physical button on the keyboard, and a character is a value that results from a key's being pressed.
The keypress event is traditionally used to detect the character being typed. In fact, the keypress event fires only if an alphanumeric or symbol (such as a period or tilde) key was pressed and released. For example, you can handle the keypress event on a textbox and filter out alphabetical characters so that only numbers and symbols appear in the textbox.
The keypress event does not fire for keys such as Backspace, Shift, or Enter, but the keyup and keydown events do. These two events fire when any key is pressed and released. You can actually detect when the user presses the Backspace key and prevent the deletion of characters — not that you should do that, of course.
Not all events occur from a user's actions. Some occur when something happens from within the HTML document. The user didn't do anything, but something took place within the window or document, and you may want to execute some code when one of these events occurs.
For example, there are some events that fire in relation to the window. They are:
load: This element occurs when the window is finished loading the document and all other resources, such as JavaScript, style sheets, and images.unload: This element occurs when the document is unloaded from the window. For example, it fires on the current page when you navigate to another page.abort: This element occurs when the loading of the page is aborted, usually because the user has pressed the cancel button.error: This event occurs when a JavaScript error takes place.
The beautiful thing about events is that the object related to an event, like the window object, doesn't care if you, or anyone for that matter, write code to handle the event. All the object knows is that it needs to execute an event handler when the associated event occurs, and if one exists, it executes it.
There isn't anything to try for this lesson. Events are an integral part of client-side development, and it's important to understand the concepts involved. This lesson is primarily meant to be a primer on events. In the next lesson, you learn one of the many ways you can handle events — by using HTML attributes.
Note
There is no video to accompany this lesson.