home | O'Reilly's CD bookshelfs | FreeBSD | Linux | Cisco | Cisco Exam  

Dynamic HTML: The Definitive Reference, 2rd Ed.Dynamic HTML: The Definitive ReferenceSearch this book

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:


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:


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.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:

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

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).

Library Navigation Links

Copyright © 2003 O'Reilly & Associates. All rights reserved.