Internet Explorer DHTML (Dynamic HTML: The Definitive Reference, 2nd Edition)

Dynamic HTML: The Definitive Reference, 2rd Ed.

2.3. Internet Explorer DHTML

The browser that inspired extensive dynamic content was Microsoft Internet Explorer 4. Two groundbreaking characteristics of that browser fired developers' imaginations:

Exposing practically every HTML element as a scriptable object
Automatically reflowing the page after content modification

In the absence of an industry standard for its document object model, Microsoft invented its own model, along with a vocabulary of objects, properties, methods, and object collections (arrays). While many of the concepts of the IE 4 model found their way into the HTML portion of the W3C DOM recommendation, the W3C crafted an entirely new architecture for its core model, along with its own vocabulary set.

With so many scripts relying on the IE 4 model and syntax, Microsoft faced the unenviable task of blending the W3C model into the IE 4 model. This began slowly in IE 5 (although IE 5 for the Macintosh embraced the W3C DOM more from the start) and gradually picked up the pace through Version 6. This means that for many object-scripting tasks, you have your choice of the Microsoft or W3C DOM approach in your code—an enormous syntactic palette from which to choose. As yet, there are no signs of Microsoft deprecating its own features. If you choose the W3C DOM route, however, you'll find that Microsoft has so far elected to bypass some modules (as described shortly), forcing you to use the Microsoft syntax for some vital services, such as events. On the flip side, if you start your DHTML authoring life exclusively in the world of IE for Windows, you will find some features not available in other browsers, including IE for the Mac.

2.3.1. Element Object References

The breadth of browsers you intend to support for your DHTML content exerts great influence over a key scripting task, namely how your script statements reference HTML element objects. All IE browsers starting with Version 4 (including those for the Mac) implement the document.all collection, which provides a gateway to any element for which you have assigned an identifier to the id attribute. Statements that refer to elements can reference the element ID as either a property reference or string, as in the following forms:

document.all.elementID
document.all("elementID")
document.all["elementID"]
document.all.item("elementID")

Even Opera 4 and later, when its Connection preference is set to identify itself to servers as IE, supports the first three formats. The string versions are helpful when you define generic functions that receive an ID string as an argument, allowing a single statement to reference any element.

IE also let you omit the document.all part of a reference so that you could reference an element simply by its ID. Although this practice makes for compact code, it also makes it very difficult to go back to the code to find statements that reference elements. Converting from the abbreviated style to the new W3C DOM-oriented referencing style will be a headache unless you are intimately familiar with the document's element structure and IDs.

If you prefer to bypass support for IE 4, you should use the W3C DOM element reference syntax because in time, it will predominate. In this case, the syntax consists of a core document object method whose sole parameter is a string identifier for the desired element:

document.getElementById("elementID")

It's unfortunate that a method that is likely to get a lot of use in scripts is so long and difficult to type (observe the case of each letter). But because this is the accepted standard format, your scripts will be more compatible with a wider range of browsers going forward than with the IE 4 version.

One other point about the W3C DOM specification: it continues to recognize the contribution of the first scriptable browser DOM, with its limited range of objects, such as forms and form controls. The "old" way of referring to these Level 0 objects, such as document.forms[n].controlName, is still valid syntax. Therefore, in the IE environment, several element objects give you three ways to reference them. In practice, however, you should use only the Level 0 syntax when scripts need to be backward-compatible with earlier browsers.

2.3.2. Cascading Style Sheets

Some CSS functionality was introduced in IE 3, but IE 4 is considered the first browser to make a serious attempt at supporting the CSS Level 1 standard. Even so, the support was far from bug-free. Microsoft claims full CSS1 support for IE 6/Windows. In the process, the company implemented fixes for some long-standing deviations from the W3C standard. While the Windows version went through a slow evolution to achieve this point, IE 5 for the Macintosh provides very good CSS1 support. CSS2 support, particularly complex selectors, is still a work-in-progress. The modularization of CSS (see Chapter 7) will allow future IE versions to opt out of supporting modules that don't apply to the browser, such as the aural style attributes, in which case the browser will simply ignore attributes from unsupported modules.

Script access to style sheet properties occurs via an element object's style property. This property contains a style object whose properties correspond to style sheet attributes. Element object properties provide scripted access to the element's attribute values, and the style property is no different. In other words, the style property reports only those values assigned to an inline style sheet rule. To read the actual style being applied to the element (from a style sheet defined in the head or imported from an external file), IE 5 and later provide a proprietary currentStyle property for all element objects.

2.3.3. CSS Positioning and Layering

Although CSS-P was not strictly a part of the CSS specification until CSS2, IE 4 and later support style sheet attributes that place elements in their own layers above the body content. An inline style rule that pulls a graphic out of the rendering sequence of a page and positions it to a specific spot within a document looks as follows:

<img src="myFace.jpg" height="60" width="40" alt="Nancy's Mug"
style="position:absolute; left:200px; top:100px">

Positioning attributes include facilities for hiding and showing an element, as well as controlling the stacking order of the layers (with undesirable behavior when a layer contains some form controls). Script control of these attributes provides much of the dynamism in DHTML-enhanced pages.

2.3.4. Dynamic Content

Rendering engines in IE 4 and later respond quickly to changes in content, by reflowing the page after any such change. Regardless of your choice of element referencing syntax, the DOMs in IE provide properties and methods that allow adding, removing, or modifying content within an element or whole elements and their content. Starting with IE 5, you have your choice of using the IE 4 DOM or W3C DOM properties and methods for modifying elements and their content. If your audience is exclusively IE 5 or later, you can even mix and match your syntax (using document.all references to elements and W3C DOM properties to read or write the element's content). It's good practice, however, to use the DOM properties and methods that are consistent with the element referencing syntax you use. Netscape 6's support for the IE innerHTML convenience property can help smooth your transition to cross-browser support.

2.3.5. The Event Model

The IE event model, which works hand-in-hand with the object model, is the critical bridge between user action and scripted activity. Virtually every element object has event handlers that can be scripted to respond to user and system actions. For example, it is possible to associate different actions with user clicks over different headings (even if the text blocks don't look like links) by assigning a different script statement to each heading's onclick event handler. IE for Windows, especially starting with IE 5, defines a large number of new events that can trigger scripts (as described in Chapter 10). Many of these events are patterned after the kinds of events application programmers use for manipulating Windows-based data and user interface behaviors. As a result, many of these events are available only in Windows versions of IE.

Another part of the event model is an event object. This abstract and short-lived entity—accessed as a property of the window object, and thus available to any function processing the event—contains details about each event that occurs. Scripts operating in response to events can inspect properties of the event object to determine the element responding to the event, the event's location, keyboard key, and so on.

The last aspect of the event model you need to understand is event propagation. Since IE 4, an event, unless otherwise instructed by script, continues to "bubble up" through the HTML element containment hierarchy of the document. Consider the following simple HTML document:

<html>
<body>
<div>
<p>Some Text:</p>
<form>
<input type="button" value="Click me" onclick="alert('Hi!')">
</form>
</div>
</body>
</html>

When the user clicks on the button, the click event is first processed by the onclick event handler in the button's own tag. Then the click event propagates through the form, div, and body elements. If the tag for one of those elements were to have an onclick event handler defined in it, the click event would trigger that handler, too. Event bubbling can also be programmatically canceled at any level along the way.

While the W3C DOM Level 2 contains an Events module, Microsoft has not implemented it as of IE 6 for Windows or IE 5 for the Mac. As you will see in Chapter 6, cross-browser applications must be built to support both the proprietary Microsoft event model and the W3C DOM event model (and, if necessary, the Navigator 4 event model, which shares some important features with the W3C model).

2.3.6. Transitions and Filters

Building atop the syntactical conventions of CSS1, IE 4 and later for Windows includes a style attribute called filter (implemented as an ActiveX module). This attribute serves double duty. One set of attribute parameters supplies extra display characteristics for certain types of HTML content. For example, you can set a filter to render content with a drop shadow or with its content flipped horizontally. The other set of attributes lets you define visual transition effects for when an object is hidden or shown, much like the transition effects you set in presentation programs such as PowerPoint.

2.3.7. Downloadable Fonts

A document to be displayed in IE 4 and later for Windows can embed TrueType font families downloaded from the server. You download the font via CSS style attributes:

<style type="text/css">
@font-face {
    font-family:familyName; 
    font-style:normal; 
    font-weight:normal; 
    src:url("someFont.eot")}
</style>

With the basic font family downloaded into the browser, the family can be assigned to content via CSS styles or <font> tags.

Note that the downloadable font format differs between Internet Explorer and Navigator. Each browser requires that the font definition files be generated with a different tool. The tool for IE is called WEFT, which you can download and learn about at (http://www.microsoft.com/typography/).