Fundamentally, DHTML behaviors represent the marriage of cascading style sheet (CSS) formatting and HTML Components functionality. You can assign DHTML behaviors to any element found on an HTML page, offering incredible flexibility in content presentation.

DHTML behaviors are the result of an evolutionary process of Web design under Internet Explorer. Previously, if you wanted to add functionality to IE, you had to use ActiveX controls, which raised a number of troubling security and architecture issues. Microsoft developed the HTML Components standard (still awaiting World Wide Web Consortium adoption) as an XML replacement for ActiveX controls.

Think of HTML Components as encapsulated DHTML—you can implement them as reusable, self-contained files. HTML Components are usually coded using VBScript or JScript. More advanced behavior-driven applications can be scripted using Windows Script Components (WSC) or any ActiveX-enabled programming language.

The importance of HTML Components
The obvious advantage of using HTML Components is that your code becomes clean and modular. As with JavaScript source files (.js), you can access and reuse your HTML Components code across multiple Web pages. Under HTML Components, you can alter a component by modifying a single file rather than making in-line changes throughout your Web site. Components encourage the separation of content from functionality.

DHTML behaviors provide numerous advanced programming tools, including extended browser methods, properties, and scripting access across domains. Behavior functionality can be attached and detached dynamically from HTML elements using script. Moreover, Microsoft has made HTML Components an integral part of its .NET Web services strategy.

Limitations of HTML Components
The obvious limitation of this technology is the fact that it’s still proprietary, despite Microsoft’s attempts to make it a standardized format. HTML Components are supported in IE 5.0 and above. Netscape doesn’t support DHTML behaviors. Most browsers will ignore the CSS behavior attributes, but references to behavior events, methods, or properties will definitely cause scripting errors in non-IE software.

To successfully deploy DHTML behaviors on a Web site, a browser detection routine is required to ensure the user is running a compliant version of IE before launching the components. DHTML behaviors are thus best suited for heterogeneous computing environments such as intranets.

HTML Components rely on the Windows Scripting Host (WSH) because they are coded using JScript and VBScript. If the user has disabled WSH for security reasons, the components will not function. Moreover, HTML Components are subject to all security limitations internally imposed by IE.

DHTML behaviors won’t work if your Web server doesn’t parse all HTML elements on a Web page. You should use readyState variables such as oncontentready and ondocumentready to check for the availability of the component before trying to launch a behavior. Otherwise, your users may receive ugly scripting errors. More information on the readyState variable is available in this article on MSDN.

How HTML Components work
You can implement DHTML behaviors by creating a style sheet (i.e., .css) linked to an HTML Component (i.e., .htc) for a specific DHTML effect. If you’re accessing behaviors prebuilt into the IE browser, you don’t need an external .htc file. You simply need to add a couple of XML declarations in your code and define the behavior from within your style declaration.

Here’s an example of the generic structure of an HTML Component file:
<PUBLIC:COMPONENT>
<SCRIPT>
</SCRIPT>
</PUBLIC:COMPONENT>

Within the HTC syntax and framework, you can:

  • Make available behavior-specific properties, methods, and events.
  • Use any element from the DHTML Object Model.
  • Receive DHTML and HTC event notifications.

To get a better understanding of how they work, let’s examine two types of behaviors you can deploy using IE: the attached behavior and the element behavior.

IE’s default behaviors
Microsoft has added a variety of default behaviors in IE version 5.0 and above. These are referred to as default behaviors. You can view the entire listing of default behaviors on this MSDN reference page.

Figure A shows a dynamic toolbar that makes use of the default homePage behavior. You can easily customize this toolbar to use on your own site—just be sure to detect the correct version of IE before embedding it on the page.

Figure A

Let’s take a closer look at the source code that powers the toolbar. First, you declare that the XML namespace for the HTML document is called IE.
<html XMLNS:IE>
<head>
<title>Attached behavior Example – HomePage Toolbar</title>
<style>
@media all {IE\:homePage {Behavior:url(#default#homepage)}}
</style>

The @media all declaration (found in the CSS2 specs) means that the following declaration is applicable to all devices. As shown below, you next specify from within the IE namespace that homePage refers to the default homePage behavior.
<script language=”JScript”>
defaultHomePage=”http://www.techrepublic.com/”;
function goCurrent(){
objHomePage.navigateHomePage();
event.returnValue=false;
}

Next, you create a variable assigning Builder.com’s home page URL as a default home page. The function goCurrent() accesses the navigateHomePage() method available from within the homePage behavior. It essentially redirects the browser to the user’s current IE home page (even if it’s not Builder.com).
function setBuilder(){
if (objHomePage.isHomePage(defaultHomePage)){
alert(“Thanks for choosing Builder.com!”);
}else{
objHomePage.setHomePage(defaultHomePage);
}
event.returnValue=false;
}

The setBuilder() function contains the isHomePage() method from the homePage behavior, which allows us to check whether the user set Builder.com as the home page. If the user has set the home page to Builder.com, he or she will receive an alert box saying thanks for making that choice. If the user has not set his or her home page to Builder.com, the setHomePage method, also from the homePage behavior, is triggered and the user is prompted as to whether the current home page should be changed to Builder.com.

You should note an interesting quirk in regards to the isHomePage method: If you attempt to execute the function to check whether the user has selected Builder.com as his or her home page, and your code is not located on Builder.com’s server, the browser will return “false” even if the user has set Builder.com as the current home page. You can check for the existence of your own server domain name in the user’s home page preferences only by using the isHomePage method:
function goBuilder(){
location.href=defaultHomePage;
}

The goBuilder() function simply redirects the user’s browser to the default home page, which happens to be Builder.com.
</script>
</head>
<body>
<IE:homePage ID=”objHomePage” />

The above command creates an object called objHomePage, which is associated with the homePage behavior. This declaration allows us to access the behavior’s properties and methods within the JScript code, as shown in Listing A.

Finally, you embed the toolbar image (i.e., homepage-toolbar.gif) using a client-side image map. Each link triggers one of the functions defined in the head of your HTML document.

Customized behaviors
As of IE version 5.5, Microsoft gave developers the ability to code customized behaviors. In Microsoft’s own lingo, these custom behaviors are called element behaviors. You can read MSDN’s official documentation for element behaviors in this MSDN article.

Here’s an interesting fact: Element behaviors can override the browser’s built-in behaviors. For example, you can rewrite the link (or anchor “<a href>” element) to do some other action instead of jumping to a specific URL. To illustrate this concept, below is a custom behavior that creates a funky fade effect when you mouse over a link. Please note that the effect will work only in IE 5.5 and above.
<html>
<head>
<title>Element behavior Example – Link Fade</title>
</head>
<link rel=”stylesheet” type=”text/css” href=”element.css”>
<body>
<a href=”http://www.techrepublic.com/”>Click to go to Builder.com</a>
</body>
</html>

As you can see, it’s quite simple. The page contains a link to Builder.com and a link to a style sheet called element.css. Listing B shows the source of the element style sheet (element.css):

The above code tells the browser that there should be black text within all links, and links should not be underlined. We have linked a custom HTML component (i.e., element.htc) and the IE fade transition to the anchor element. Once the user hovers the pointer over the link, the style sheet defines the text color as white (which is the same color as your white background). For more information on visual filters and transitions, check out this MSDN article.

Listing C contains the source code for the custom component (element.htc). Here’s how it works. First, you declare the .htc file as a publicly accessible component. Then you attach two events to the component, onMouseOver and onMouseOut, and define two functions, mOver(), and mOut(). Both functions do essentially the same thing: They apply the fade transition defined in the style sheet to any link on the HTML page. So when you run your mouse over a link, the text fades from black (as defined in the a{} block in the style sheet) to white (as defined in the a:hover{} block), and vice versa.

HTML Components and .NET
Microsoft has integrated into Internet Explorer 5.0 the WebService behavior that allows client-side code to access methods contained in remote .NET Web services or other SOAP-enabled services. Abstraction makes the behavior simple to use because the developer doesn’t require any specific knowledge or expertise about the service. The WebService behavior can extract everything from SOAP arrays and data to XML formatted data. Most importantly, the behavior supports the next-generation .NET Web services infrastructure and tools. For more information on the WebService behavior, check out this MSDN article.

Just the tip of the iceberg
This article barely begins to address the potential of DHTML behaviors. There’s a host of very useful integrated behaviors (the ClientCaps behavior comes to mind) that I haven’t addressed, and the customization possibilities are endless. While DHTML behaviors are currently limited to IE, IE dominates the browser market. With this in mind, DHTML behaviors should be incorporated into any serious Web developer’s skill set.