Introduction to XML Events
By Micah Dubinko2005-04-22
How Events Work
|
|
What exactly is an event? For purposes of this discussion, it's best not to think about it in the traditional sense of the word "event", but rather as a simple data structure that contains details about something that's changing. For example, on a mouseover event, the interesting information in the event object is the mouse pointer coordinates, which mouse buttons are depressed, whether modifier keys like "shift" are currently depressed, and so on. An individual event object is short-lived, and exists only long enough for immediate processing before it ceases to be.
Every event has a target, the XML or HTML element most closely associated with the event. An event handler is a piece of executable code or markup that responds to a particular event. Distinct from any handler, some events, such as clicking on a hyperlink, can cause activity called a default action. In Listing 1, the target of the unload event is the body element, and the event handler is the bit of script inside the onunload attribute.
Event flow
The easiest and most common technique is to attach event handlers right at the target, and once upon a time this technique was all that browsers supported. However, this often isn't practical. Listing 2 offers one example:
Listing 2. Demonstrating the need for event observers
<p>You want to capture all clicks on this paragraph,
even if the text has <em>special markup</em>.</p>
In Listing 2, suppose you have an event handler in place to handle click events targeted at the p element. If the user happens to click on the words "special markup", this will create an event targeted at the em element. Because the paragraph isn't the target, its click handler will not fire. Getting this to work involves placing an event observer on the p element that can respond to events targeted at itself or any of its children.
DOM Level 2 Events describes how an event handler can be connected in a way that solves the problem shown in Listing 2 -- though it may be more complex than necessary due to ancient browser history (earlier versions of Internet Explorer and Netscape had their own idiosyncrasies, and some of them were grandfathered in to the official DOM spec). An event takes an imaginary journey, known as propagation, through the tree structure of the document. Actually, it takes two journeys: The first, called capture, begins at the document root and proceeds to the target element. After a chance for ordinary target processing, a second journey, called bubbling, starts at the target element and ends up back at the document root. During each phase, any element along the path can be registered as an observer of the event, and can thus trigger an event handler. Events can even be stopped from further propagation, which prevents later observers from detecting that the event happened. Figure 1 illustrates propagation.
Figure 1. Event propagation
If you need to set up an event observer, should you use the capture or bubbling phase? Here are a few guidelines:
• If you're dealing with only a single observation point, which is usually the case, you can use either the capture or bubbling phase -- there's no real difference. The distinction only matters if a single event will be observed from multiple places in the document tree.
• Some events like focus do not participate in the bubbling phase, and thus can only be observed during the capture phase or directly at the target.
• When multiple observers are present, use the bubbling phase if you want closer observers to fire first. For example, suppose that in Figure 1 there were observers on both body and p. With capture, the observer on body would fire first, followed by the one on p. With bubbling, the observer on p would fire first, followed by the one on body.
• Keep in mind that the HTML 4.0-style attribute syntax, used for onunload in Listing 1, registers observers for the bubbling phase.
• Whether the bubbling or capture phase is used, the default action always happens after all event propagation is finished. Stopping the event propagation doesn't by itself prevent the default action. A separate API feature allows the default action to be cancelled, regardless of whatever else happens during propagation.
The DOM Events specification defines a way to attach event observers from script, as shown here in Listing 3.
Listing 3. Attaching event observers
var el = document.getElementById('observer_element_id');
el.addEventListener("mouseover", highlight_func, true);
el.addEventListener("mouseout", normal_func, true);In the call to addEventListener, the first parameter is the event name, the second parameter is a function reference that will get executed, and the third parameter is either true (indicating the capture phase) or false (for bubbling). The DOM Events specification defines a number of core events, as well as an API method to stop the propagation of an event, and cancel the default action associated with it.
It's worth noting that there are significant differences in various browser implementations of these APIs. In particular, Internet Explorer up to version 6 doesn't support addEventListener, but instead uses a similar function named attachEvent.
Events and accessibility
Any time you're thinking about events, it's worth figuring out which events you really need. For example, do you really care whether a button was clicked with a mouse? What if it was activated in some other way? A number of Web users don't have mice, or even graphical user interfaces for that matter. When possible, it's almost always better to use device-independent events -- for example, DOMActivate instead of click for buttons.
The W3C publishes a number of documents (see Resources) describing techniques for making Web content more accessible.
Tutorial Pages:
» Dynamic Documents with Less Script
» Two Kinds of Events
» How Events Work
» From Events to XML Events
» Conclusion
» Resources
First published by IBM DeveloperWorks
|
