WebReference.com - Part 2 of Chapter 6 from Dynamic HTML: The Definitive Reference, 2nd Edition. From O'Reilly (5/8). | WebReference

WebReference.com - Part 2 of Chapter 6 from Dynamic HTML: The Definitive Reference, 2nd Edition. From O'Reilly (5/8).

To page 1To page 2To page 3To page 4current pageTo page 6To page 7To page 8
[previous] [next]

Dynamic HTML: The Definitive Reference, 2E. Chapter 6: Scripting Events

W3C Event Capture

Although event bubbling is the default mechanism in modern browsers, a propagating event in Netscape 6 or later starts its life by trickling down to the target. If you place an event listener for the event's type at a higher level, however, it will ignore the event as it trickles down unless event capture for that element and that event type is turned on.

To engage event capture, use the same addEventListener() method that the W3C event model prefers for event binding. The third parameter is a Boolean value that controls event capture. When you set the parameter to true, the element invokes the listener function during capture phase; after that function completes its task, the event continues its journey toward to the target element. Therefore, it is perfectly "legal" to add two separate event listeners to an element for the same event type. In capture phase, one listener function runs; in bubbling phase, another listener function runs.

Using the same three parameters, you can eliminate the event listener for the desired propagation phase with the removeEventListener() method. Thus, you could temporarily engage capture-phase processing and remove it without disturbing bubbling-phase event processing for the same element and event type.

At any point along W3C event propagation, you can prevent the event from going any further by invoking the event object's stopPropagation() method in a statement inside the listener function. Netscape 6 or later also wires the convenience cancelBubble property to work during capture phase as well.

The W3C root event object (and therefore event objects of all types) implements a handful of other properties that may be helpful while processing events within the two-way propagation model. Table 6-4 lists these properties, for which IE (through Version 6 on Windows) provides no analogues. A shared event listener function might use these (and other properties) to build code branches that execute when the desired combination of conditions exist (e.g., when the target's class name is "foo" and the event is being processed from a container of several elements of the same class).

Table 6-4 W3C event object propagation properties

bubblesBoolean true if event can bubble
currentTargetReference to the node whose event listener invoked the current listener function
eventPhaseInteger indicating in which phase the event listener is processing (1 is capture; 2 is at target; 3 is bubbling)

IE/Windows Event Capture

Microsoft's view of event capture is quite different from the W3C view. IE 5 and later event capture operates only with mouse events. In fact, when you invoke an element object's setCapture() method, you instruct the browser to direct all mouse events on the page to that element rather than to their targets. Events bubble up from the capturing element, unless canceled.

This event mechanism is intended primarily for temporary activation within a page. For example, the body element can contain an oncontextmenu event handler that waits for a Windows user to click the right (nondominant) mouse button. You can take this opportunity not only to block the display of the browser's own context menu (by setting event.returnValue to false), but also to display your own menu composed of DHTML positioned elements. While the custom menu is visible, you want all mouse events to head for the menu so that nothing else on the page is accessible via the mouse until either a choice is made from the menu or the right mouse button is clicked again. Either action hides the custom context menu and invokes releaseCapture() to allow mouse events to reach their normal targets again.

It's not uncommon for IE/Windows to implement proprietary DOM features that allow web applications to mimic operating-system-specific behaviors. In an intranet development environment targeting IE/Windows only, this tactic makes perfect sense. But such tight integration reduces the likelihood that these features will become part of an operating-system-agnostic W3C recommendation. It also makes it more difficult for Microsoft to implement some W3C recommendations that conflict with existing mechanisms.

To page 1To page 2To page 3To page 4current pageTo page 6To page 7To page 8
[previous] [next]

Created: September 9, 2002
Revised: September 9, 2002

URL: http://webreference.com/programming/javascript/dhtmlref/chap6/2/5.html