Section A. Browser incompatibilities

A. Browser incompatibilities

As we saw in 1B, JavaScript standardization is a two-tiered construct, with the de facto Netscape 3 standard forming the lower tier, and the modern W3C specifications the upper one. This is also true in event handling, but there's one extra catch. There are two upper-tier specifications instead of one: W3C and Microsoft.

In contrast to the W3C DOM and XMLHttpRequest, which all browsers have honestly tried to implement, event handling is still plagued by deliberate incompatibilities that were introduced during the Browser Wars. Explorer sticks to the Microsoft way of doing things, while Mozilla follows the W3C specification faithfully. Safari and Opera support both systems. Although it's useful to see the combined W3C and Microsoft models as the advanced tier of event handling, you should be aware that there are differences between them, some of which are rather tricky.

You'll encounter most incompatibilities when you access the event object and its properties. For instance, W3C calls the target of the event target, while Microsoft calls it srcElement. If you need to identify the target of the event, you try both properties and use the one that contains a useful valueit's an inconvenience, but not a show-stopping problem.

Unfortunately, in addition to these easily solved problems, there still exist a few truly vicious incompatibilitiesescapees, perhaps, from a Browser Wars Era malign-life-form exhibit. The mouse properties, especially, are infested with them. Solving these incompatibilities is difficult, and occasionally even flat-out impossible. We'll discuss these problems later in this chapter.

The traditional event-handling model, which is part of the de facto Netscape 3 standard, is supported by all browsers, but lacks a few functionalities of the W3C and Microsoft models. It's still possible to use this model instead of the advanced ones, and most example scripts actually do so, because the traditional model causes fewer browser incompatibilities.

Resolve case by case

You should resolve browser incompatibilities on a case-by-case basis; don't use one sweeping object-detection script to decide which event model you're going to follow. Consider this case:

   if (W3C model) {    // execute W3C compatible scripts } else if (Microsoft model) {    // execute Microsoft compatible scripts      } 

The problem is that there is no adequate general detectno single object whose presence or absence conclusively proves that a browser supports or does not support a certain event model.

Besides, as I said earlier, browser incompatibilities mostly occur in the event object. Other areas of event handling are relatively problem-free, and don't usually require code branching. Therefore it's best to restrict your code branching to the scripts that really need it.

Overview

These are the most important topics in event handling and their browser compatibility:

Area	Description	Incompatibilities	Section
Events	The action that the user has to take to trigger the script.	Few	7B
Event handler registration	Defines which function is executed when the event takes place.	Some, especially between the W3C and Microsoft models	7C
Event bubbling and capturing	Determines which event handler fires first if an HTML element and its parent handle the same event.	Few	7D
Accessing the event object	The event object holds information about the event which your script may need.	Many, some of them unsolvable	7E
Targeting	Finding out which element you should do something with as a response to the event.	Few	7F