Chapter 11: Event Handling

Browsers have the ability to invoke JavaScript in response to a user s actions within a Web page. For example, it s possible to specify JavaScript that is to be run whenever a user clicks a particular link or modifies a form field. The actions to which JavaScript can respond are called events . Events are the glue bringing together the user and the Web page; they enable pages to become interactive, responsive to what a user is doing. An event model defines the ways the events are processed and how they are associated with the various document and browser objects.

Like many other aspects of JavaScript, the event models of major browsers predictably evolved in separate, incompatible directions. Prior to the fourth versions of Internet Explorer and of Netscape s browser, only primitive support for events was available. The fourth generation of the major browsers added new events and functionality, greatly improving programmer control over many aspects of the event model. However, because of the divergent nature of these event models, the W3C once again entered the fray by including a standard event model in DOM2. This model extends the DOM to include events, marrying the two incompatible models to produce a powerful, robust environment for event handling. This chapter begins with the basic event model and how it fits into (X)HTML and JavaScript. The event models of 4. x -generation browsers are discussed, and finally the DOM2 event model is introduced.

Overview of Events and Event Handling

An event is some notable action occurring inside the browser to which a script can respond. An event occurs when the user clicks the mouse, submits a form, or even moves the mouse over an object in the page. An event handler is JavaScript code associated with a particular part of the document and a particular event. A handler is executed if and when the given event occurs at the part of the document to which it is associated. For example, an event handler associated with a button element could open a pop-up window when the button is clicked, or a handler associated with a form field could be used to verify the data the user entered whenever the value of the form field changes.

Most events are named in a descriptive manner. It should be easy to deduce what user action the events click , submit , and mouseover correspond to. Some events are less well-named, for example, blur , which indicates a field or object has lost focus , in other words is not active. Traditionally, the handler associated with a particular action is named with the event name prefixed by on. For example, a handler for the click event is called onclick .

Events are not limited to basic user actions associated with the document like click and mouseover . For example, most browsers support events such as resize and load , which are related to window activity such as resizing the window or loading a document from network or disk.

Browsers provide detailed information about the event occurring through an Event object that is made available to handlers. An Event object contains contextual information about the event, for example, the exact x and y screen coordinates where a click occurred and whether the SHIFT key was depressed at the time.

Events that are the result of user actions typically have a target , the (X)HTML element at which the event is occurring. For example, a click event s target would be the element such as << img >> or << p >> the user clicked on. Event handlers are therefore bound to particular elements. When the event a handler handles occurs on that element to which it is bound, the handler is executed.

Note  

Browser event models are actually more flexible than this; we ll see in later sections of this chapter how handlers can be invoked in response to actions occurring on targets contained by the element to which they re bound.

Handlers can be bound to elements in numerous ways, including

• Using traditional (X)HTML event handler attributes, for example, << form onsubmit= "myFunction();" >>

• Using script to set handlers to be related to an object, for example, document.getElementById( "myForm").onsubmit = myFunction;

• Using proprietary methods such as Internet Explorer s attachEvent() method

• Using DOM2 methods to set event listeners using a node s addEventListener() method

Each technique has its pros and cons, and will be discussed in the following sections.

Just as there are many ways to bind events to elements, there are several ways events are triggered:

• Implicitly by the browser in response to some user- or JavaScript-initiated action

• Explicitly by JavaScript using DOM1 methods, for example,

• document.forms[0].submit()

• Explicitly using proprietary methods such as Internet Explorer s fireEvent() method

• Explicitly by JavaScript using the DOM2 dispatchEvent() method

The Proliferation of Event Models

The fact that there are so many different ways to attach and trigger events is the unfortunate result of a proliferation of event models. Early browsers supported a basic model that was fairly consistent across different browsers. Version 4 of Netscape and Internet Explorer added new proprietary event models that were incompatible. The most recent arrival on the field is the DOM2 model, which standardizes the way events can be manipulated and will hopefully bring some consistency to the mad world that is JavaScript events. The unfortunately complex situation is summarized in Table 11-1.

Table 11-1: The Nightmare of Browser Event Model Compatibility

Browser	Basic Model?	Internet Explorer Model?	Netscape 4 Model?	DOM2 Model?
Netscape 2-3	Yes	No	No	No
Netscape 4	Yes	No	Yes	No
Mozilla-based browsers (e.g., Netscape 6+)	Yes	No	No	Yes
Internet Explorer 3	Yes	No	No	No
Internet Explorer 4-5. x	Yes	Yes	No	No
Internet Explorer 6	Yes	Yes	No	No