Handling events with the DOM - Part III

In this field, numerous differences are denoted, according to which browser we’re using. W3C and Netscape determine the target of the event through the "target" property. Conversely, IE uses the "srcElement" property. Our cross-browser function for detecting the target of the event can be coded as follows:

function detectTarget(e){

    var targ;

    if (!e) var e=window.event;

    if (e.target){targ=e.target;}

    else if(e.srcElement){targ=e.srcElement;}

    if (targ.nodeType==3){targ=targ.parentNode;}

    alert(targ);

}

As you can see, we followed the same approach for object detection, assigning the property "target" for W3C/Nestcape and "srcElement" for IE.

The checking process for node Type is suited to Safari. If an event occurs on an element that contains text, the text node, instead of the element, is considered the target of the event. For this reason we check whether the target's nodeTypeis 3, a text node. If it’s a textnode, we move up in the document tree to its parent node, that is, the HTML element.

There are additional properties inherent to the target. One particularly useful one is "currentTarget." Suppose that we’ve defined one function that is triggered by two elements, where element 1 is a container of element 2, reacting to the same event. It is similar to this situation:

element1.onclick=functionA;

element2.onclick=functionA;

Using a browser with event bubble capabilities, if the user clicks on element 2, "functionA" will be executed twice, since the event will fire the function for element 2 and traverse the document to reach element1, triggering again "functionA." In this case, how we know what HTML element is handling the event?

The "target" and "srcElement" properties always reference the first element, since it’s the original source of the event. For addressing this issue, the W3C has implemented the "currentTarget" property. This contains a reference to the HTML element that is handling the event. Not surprisingly, IE doesn’t offer this property. However, based on the previous example, using the "this" keyword will reference the element handling the event, behaving similar to the "currentTarget" property.

But if we’re using the IE registration model, with the attachEvent():

element1.attachEvent('onclick',functionA);

element2.attachEvent('onclick',functionA);

 

The "this" keyword is not going to work to reference the HTML element handling the event. This is one of the most critical reasons why the IE registration model is not widely used.

Given the situation explained above, sometimes it is desirable to manipulate the event flow related to page elements. For doing this, the W3C event model present two methods: "preventDefault()" and "stopPropagation()", respectively. The first can be used to cancel the event, if it can be cancelled. This prevents the browser from performing any default action for the event, such as loading a URL when a hypertext link is clicked. Note that the event will continue propagating along the normal event flow. The second simply stops the event flow. This can be used on either the capture or bubble phase.

IE offers two properties (not methods) to achieve similar results. They are "returnValue" and "cancelBubble". The first property must be set to true to cancel any default action for the event, while the second should be set to true to prevent the event from bubbling.

Now, let’s take a look at the properties for determining which key has been pressed.