Introduction

This article refers to Microsoft® Internet Explorer 5.5 and Internet Tools for Microsoft Windows®, which are available for download at http://www.microsoft.com/windows/ie/default.htm.

With Internet Explorer 5.5, users of the browser will benefit from enhancements such as improved navigation performance and support for print preview. In this article, though, I'd like to talk about what's new for DHTML content authors and developers—and how the features of Internet Explorer version 5.5 make it an exciting platform to target for development of any application user interface (UI). Areas that have received particular focus in this release include enhancements to the behavior component model, improved editing features, and support for vertical text layout, as well as some compelling visual effects—all of which I'll highlight here, with links to more detailed discussions of the features.

To make the best use of this article, it's helpful to understand previous DHTML support available in Internet Explorer. You can find full reference documentation, including samples, in the MSDN Online Web Workshop.

Before describing the details of these exciting new features, I'd like to address an issue that has attracted some attention: standards support in Internet Explorer 5.5. This release of Internet Explorer improves support for standards such as CSS1, with features such as borders, margin, and padding on inline elements, and first-letter and first-line pseudo-elements. Internet Explorer also continues to support all the standards supported in previous releases, including leading support for technologies such as XML.

In each release of the product, we improve our support for standards while providing the sets of features that customers require for building real-world solutions. As we move forward with future releases of Internet Explorer, we will again evaluate which standards will be supported to offer developers a great platform for development.

For specific information about standards support for particular components or functionality, check out the new standards documentation in the MSDN Online Web Workshop DHTML reference pages. For more information about our policy regarding standards support, please take a look at the February "DHTML Dude" column.

Component Model

The work on the behavior component model has focused on enabling developers to add their own custom elements for others to use in their DHTML documents. The term component model refers to a number of individual features that, when put together, allow developers to build their own DHTML elements to extend and enhance functionality. These extended or enhanced elements can then be reused in DHTML content by other developers. For example, a developer can create a tree-type list control that is as rich and robust as built-in HTML elements like INPUT, TEXTAREA, and SELECT. Built around the DHTML behavior support introduced in Internet Explorer 5, the enhanced Behavior Component Model allows the programmer to encapsulate and reuse code without encountering potential name conflicts and unforeseen style inheritance. A number of factors go into making a full and robust model for building reusable components. In this section, we'll discuss how these features play a key part in helping you to build up rich components with DHTML and make use of these components in DHTML documents.

Element Behaviors

Element behaviors are a new type of DHTML behavior introduced in Internet Explorer 5.5. Element behaviors build on the existing behavior support in Internet Explorer 5 to provide a different method of binding to an element. Like the DHTML behaviors introduced in version 5.0, element behaviors can be implemented in script or in native binary code. For clarity, we now refer to behaviors supported in Internet Explorer 5 as attached behaviors, as they are attached to any element either through CSS declaration of the behavior property or procedurally through addBehavior and removeBehavior methods. Element behaviors, by contrast, bind to the element such that they can never be detached, and they are considered to be an intrinsic part of the element being defined.

Unlike attached behaviors, only one element behavior is allowed per element—and only custom elements (those elements that have explicit namespaces) can have an element behavior. You can think of an element behavior as implementing a custom element to which you can program as though it were a standard HTML element.

Remember that attached behaviors remain appropriate for many uses, so you probably don't want to eliminate them from your DHTML repertoire. Element behaviors are not better than attached behaviors, nor do element behaviors supersede attached behaviors. They simply offer advantages to developers who want to write their own custom elements. You can still attach attached behaviors to a custom element that is implemented as an element behavior.

So what does all this talk about robust custom elements mean? Consider developing a custom element, <MYSTUFF:TREE>, for a DHTML document that provides a rich tree-control user interface. You might want to reuse the <MYSTUFF:TREE> element in your documents in the same way you would use standard HTML elements (such as DIV, SPAN, INPUT, SELECT, and so forth). However, the traditional attached behavior mechanism for elements does not allow you to reuse this tree control, because it employs a secondary attachment mechanism that takes place after the custom element has been created.

For example, if the element were to be created in script using the createElement method, and a behavior were attached using CSS, any script following createElement and referring to a method supplied by the behavior would probably fail, because the behavior would not have been attached at that moment. Element behaviors allow immediate behavior instantiation when the element is created, and when the methods provided by the behavior are reliably present. Furthermore, the element behavior can be used without fear of a change in the CSS declaration that would result in the behavior being removed unexpectedly. You can achieve this binding of the element behavior to the custom element by declaring the behavior with a processing instruction rather than using CSS. For the full details of how to use and write your own element behaviors, take a look at the element behaviors article.

THE ABOVE MATERIAL IS COPYRIGHTED AND SHOULD NOT BE REPRODUCED OR DISTRIBUTED OUTSIDE OF MICROSOFT.