Behaviors in Internet Explorer 5

The "behavior", as Microsoft calls it, takes everything we've seen so far one step further. A behavior is a self-contained file which both attaches event handlers to particular target elements and includes the script for the event handler itself. To begin thinking about behaviors, let's consider a form button.

Your page has a form button and you want certain things to occur when it is clicked. We've already seen the traditional way of attaching an event handler to the form button, by grafting the script into the <INPUT> tag.

Using behaviors, there would be an external file which attached the onClick event handler to this button and contained the script of the event handler itself, for instance, calculating a subtotal.

An obvious question, then, is how we form the relationship between the button, created with the <INPUT> tag, and the external behavior file. How does the behavior file know to attach event handlers to this button? Microsoft has bridged this gap by relying on style sheets.

A Cascading Style Sheet, or CSS, is a method of attaching display styles to page elements. These styles which, like scripts, can be embedded within the HTML document or isolated in external files, are typically used to define the color, font, size, or position of a page element. You can apply a style sheet globally to an entire category of elements (e.g. all <P> tags), or you can define style classes which are only applied to elements whose tags use the CLASS attribute (e.g. <P CLASS="headline">). Furthermore, you can even apply a style to only a particular instance of an element, known as in-line styles, using the STYLE attribute (e.g. <P STYLE="color:red;">). Of course, this is not a tutorial on style sheets, although you are invited to read one.

Microsoft has therefore introduced a new CSS property, behavior, which references the external behavior file that attaches its event handlers to whichever elements the style affects. Since this can be slightly confusing, let's take a few incomplete examples. Suppose that you have created one external behavior file which attaches an onClick event and causes the page background color to change briefly to red and then back to white when this event is triggered. You now relate this behavior to one or more button elements using a style sheet.

Relate behavior to:
all form elements

<STYLE>
 INPUT 
  {behavior:url(colors.htc)}
</STYLE>

Relate behavior to:
form elements
of class "colorchange"

<STYLE>
 INPUT.colorchange 
  {behavior:url(colors.htc)}
</STYLE>

<INPUT
 TYPE="button"
 CLASS="colorchange"
 VALUE="Click me to see red!">

Relate behavior to:
a single button

<INPUT
 TYPE="button"
 STYLE="behavior:url(colors.htc)"
 VALUE="Click me to see red!">

In the first example, the style sheet is applied to all <INPUT> tags. Thus, all form elements will be related to the behavior colors.htc.

The second example limits this by creating a style class named "colorchange", which may only be applied to form elements. In the HTML we create the button with a class of "colorchange" -- any form element we create with this class will be related to the behavior colors.htc.

The third example employs an in-line style to assign this style sheet to only this particular button. Therefore, only this button will relate to the behavior colors.htc.

Although relating elements to external behaviors may still involve adding attributes to the element's HTML tag, these attributes are valid HTML, such as CLASS and STYLE. This is an improvement over attributes such as ONCLICK, which force you to include script code within the tag.

Now, then, we've been dancing around the issue of just what an external behavior looks like. In the examples above you can see that we've referred to the behavior as colors.htc. All behavior files end in the suffix .htc, which means "HTML Component". Perhaps not the best suffix Microsoft could have come up with, but they've been busy lately.

Perhaps the easiest way to understand the contents of an .htc behavior file is to look at one. Then we'll explain it all.

colors.htc

<PUBLIC:ATTACH EVENT="onclick" HANDLER="changeBG" />
 <SCRIPT LANGUAGE="JavaScript">
  var clearID=0;
  function changeBG()
   { if (clearID) { clearTimeout(clearID) }
    window.document.body.style.backgroundColor="red";
    clearID=setTimeout
    ("window.document.body.style.backgroundColor='black'",
	2000);
   }
 </SCRIPT>

Some of this example will seem somewhat familiar, as it shares quite a bit in common with traditional HTML markup. In fact, the .htc file is contained within XML markup, but it is not so important here that you understand XML so much that you can mimic the above template.

The first line of colors.htc attaches the function reference changeBG to the onClick event handler for the element to which this behavior relates (remember our example, this may be all form elements, all form elements of class "colorchange", or a single button, depending on the style sheet we used).

Syntactically speaking, do take note of the closing backslash within the <PUBLIC> tag; this is important and is simply an XML way of closing a tag without writing </PUBLIC>.

The rest of this .htc file should be easy to read -- it is simply a block of script, specified as JavaScript, which defines the function changeBG(). The script first initializes a local variable clearID. The function itself clears any existing timeout set from a previous execution of this function.

Next, the background color for the page is set to "red". Notice that we refer to the page background using a fully explicit reference: window.document.body.style.backgroundColor. If we did not specify the window object then the reference is assumed to stem from the object which triggered this event. In other words, merely stating:

style.backgroundColor="red";

would have caused the button's background to become red, not the page, since the button was the triggering element of this event handler. Lastly, a timeout is set to change the background color back to white.

The .htc file may attach any number of event handlers to the relating element; simply add more <PUBLIC:ATTACH> tags.

<PUBLIC:ATTACH EVENT="onclick"
HANDLER="changeBG" />
<PUBLIC:ATTACH EVENT="onclick" HANDLER="changeButton"
/>
..etc...

In the above scenario, the innermost handler will execute before the outermost; thus, changeButton will execute first followed by changeBG when an onClick occurs at the target element.

You can also add multiple event handlers for the element, in case you want to watch for both a Click and a MouseOver event, for instance.

<PUBLIC:ATTACH EVENT="onclick"
HANDLER="changeBG" />
<PUBLIC:ATTACH EVENT="onmouseover"
HANDLER="changeStatusMsg" />
..etc...

Although this has been a basic primer on behaviors, you can at least see how they contribute towards ever more modular and portable client-side scripts. Of course, there is a learning curve to this new technology which may make behaviors seem like additional work at first, but in the long-run, except for very simple web sites, it is best to keep scripts in script files, style sheets in style sheet files, and HTML in HTML files!

Behaviors, again, are proprietary and supported only by Microsoft Internet Explorer 5 -- although Microsoft has "proposed" the behavior property as a new CSS attribute, this does not mean anyone else will accept it. In this case, behaviors may die off, or be constrained to MSIE-based intranets. Nonetheless, behaviors nicely illustrate the direction that scripting support should evolve.

Additional Reading

• Embedding JavaScript in HTML
• Overview of Behaviors
• Creating HTC Files
• DHTML Behaviors

Ugly Grafted Event Handlers
Creating Portable and Modular Client-Side Scripts