Event accessing

I prepared a little example of the various event registration models, event properties and event orders. Thus you can get a quick overview of the possibilities and restrictions of event handling.

On this page I explain how to access an event object.

Now that we have registered an event handling function, we want to know more about the event itself. We’d like to know the mouse position at the moment the event took place, we want to detect any key the user has pressed. All this is possible, though this area of event handling contains the most serious browser incompatibilities. (For a quick overview, see the Event compatibility tables.)

To read out properties of the event we have to access the event first.

Browser incompatibilities

At the height of the Browser Wars, Netscape invented an accessing model (later copied by W3C) and a lot of event properties, while Microsoft also invented an accessing model and a lot of event properties. Of course these two models are completely incompatible. But, as was said on the Introduction page, code branching like

if (W3C/Netscape)
{
	use W3C/Netscape model for access and property names
}
else if (Explorer)
{
	use Microsoft model for access and property names
}

is not the correct solution to these compatibility problems since it may leave out minor browsers who can handle most scripts, if your detection code allows them. Although Opera and iCab have taken the sensible precaution of supporting both the Netscape and the Explorer event accessing models, Konqueror, as always, only supports the W3C way. In addition, support of an event accessing model need not necessarily mean that the browser also supports all the event properties of that model.

Therefore we have to check event access and individual properties separately. Let’s start with accessing the event, the event properties are discussed on a separate page. Accessing an event is quite simple.

W3C/Netscape

In the W3C/Netscape event accessing model the event is passed to the event handling function as an argument. So if you define an event handler

element.onclick = doSomething;

the function doSomething() receives the event itself as an argument. Traditionally it is stored in the variable e — though you can use any name you like:

function doSomething(e)
{
	// e gives access to the event
}

This is all fully automatic, no extra code required. In anonymous functions you can do

element.onclick = function (e) {alert('Event type is ' + e.type)}

Microsoft

In the Microsoft event accessing model there is a special property window.event that contains the last event that took place.

element.onclick = doSomething;

function doSomething()
{
	// window.event gives access to the event
}

or

element.onclick = function () {alert('Event type is ' + window.event.type)}

Event and event

Note that there also exists an ancient Netscape property window.Event. Explorer doesn’t understand it while Netscape 4 could misinterpret it. Therefore be very sure to always write event with a lower case “e”.

Cross-browser event accessing

Fortunately it is very easy to write a proper cross-browser script:

element.onclick = doSomething;

function doSomething(e)
{
	if (!e) var e = window.event;
	// e gives access to the event in all browsers
}

If the variable e does not exist (if it isn’t sent to the function), make it a reference to window.event . Now e refers to the event in all browsers.

Combination with inline event handlers

In the inline registration model you have to pass the event to the function:

<pre onclick="doSomething(event)">

function doSomething(e)
{
	alert(e.type);
}

(window.)event is the correct property in the Microsoft model anyway, while the other browsers also recognize it in this special case.

Continue

If you wish to go through all event pages in order, you should now continue with the Event properties page.

Home