Uh-oh, it looks like your Internet Explorer is out of date.

For a better shopping experience, please upgrade now.

IE5 Dynamic HTML Programmer's Reference

IE5 Dynamic HTML Programmer's Reference

by Alex Homer, Chris Ullman

Dynamic HTML enables web developers to create pages with mobile interactive effects, which they were unable to achieve using standard HTML. You basically take HTML, add scripting and you have Dynamic HTML. The technology was introduced by both major browser companies last year in IE4 and Communicator 4, when Wrox produced separate books on each browser


Dynamic HTML enables web developers to create pages with mobile interactive effects, which they were unable to achieve using standard HTML. You basically take HTML, add scripting and you have Dynamic HTML. The technology was introduced by both major browser companies last year in IE4 and Communicator 4, when Wrox produced separate books on each browser implementation. This is our update to the IE4 book, when we shall include all the great new features introduced for DHTML in IE5 and update the definitive reference sections at the back of the book.

Gives basic introduction to Dynamic HTML
Shows how it relates to existing technologies
Covers style sheets, the latest CSS2 version, which provide the basis for DHTML
Gives examples in both VBScript and JavaScript
Covers techniques for working with text, tables, windows, forms and filters
Extensive reference sections on Dynamic HTML. VBScript and JavaScript

This book is for developers who already use Dynamic HTML and want to see what changes have been implemented in IE5, or for developers who know HTML and scripting but have not yet started to use Dynamic HTML as they were waiting for implementations to stabilize.

Product Details

Publication date:
Edition description:
Product dimensions:
(w) x (h) x 0.05(d)

Related Subjects

Read an Excerpt

Chapter 3: The Dynamic HTML Browser Object Model

Now that we've explored the properties that are available in the Dynamic HTML implementation of style sheets, we can move on to look at the other major difference between traditional and Dynamic HTML. Since the advent of Netscape 2 (the first browser to provide a documented object model), it has been possible to use the scripting code in a page to access both the browser environment and the contents of the page itself. These early object models made access OK for controls, but access was still limited when it came to most other things in the page. So while you could access such things as HTML text boxes and list boxes, and Java applets or ActiveX controls, you couldn't get at the real contents of the document. The text, images, headings and other page contents remained temptingly out of reach.

This all changed with the introduction of DHTML. Almost anything that's visible in the page, plus many things that aren't, can be accessed through the extensions to the object model. This is the subject of this chapter. We'll take an overview of the whole structure, then investigate the most useful objects. We'll continue this process in the next chapter, by looking at the objects that are most useful for integrating our script into a web page.

In this chapter, we'll cover:

  • The browser object model in outline — how it compares to older browsers
  • A brief tour of the basic window objects
  • A look at some of the more useful objects and collections
We can't hope to give an in-depth explanation of the entire structure in this book, and there's no real need to do this anyway. Much of the structure is simple, andsome is only used in very special cases. You will, however, find definitions and listings of the items that make up the structure in Appendix A of this book.

Introducing the Browser Object Model

If you haven't used scripting code in a web page before, you may not have realized that the browser is built around a structured set of objects. It's these objects that provide an interface between the HTML that creates the page, and the internal workings of the browser itself. To make the whole thing easier to visualize and work with, the various objects are organized into a structure called the object model.

Why Do We Need An Object Model?

When we define a normal static web page with HTML, we don't need to know about the browser's object model or the structure of the browser itself. Even when we display several documents in different frames, we just give each frame a name, and then TARGET new pages to the appropriate one. For example, suppose we have defined a frameset which contains a frame named mainwindow, like this:
<FRAME NAME="mainwindow" SRC="http://www.wrox.com">
Then we can load a different page into it using the TARGET attribute of the <A> tag:
<A HREF="http://webdev.wrox.co.uk" TARGET="mainwindow">Web Developer's website</A>
So why do we need an object model?

The Object Model and Scripting

If you've used a scripting language like VBScript or JavaScript before, you'll know that the example above gives an extremely simplified view. In reality, all the frames in the browser window are stored by the browser as child objects of the main window. They are organized into a collection (a structure rather like an array — we'll come back to collections later). To refer to the main window in a scripting language, we can reference it using the keywords parent or top, depending on its position in the hierarchy. The parent keyword refers to the window immediately above the current window in the hierarchy, which may be the top window, while top always refers to the topmost window. If we were in one window in a frame, and wanted to refer to another window (named mainwindow) held in the same frameset, we would use the following code:

parent.frames ("mainwindow").location.href = "http://webdev.wrox.co.uk"
Don't worry about the code we've used here for the time being — we'll look at what all of these references mean later in the chapter.

Throughout this chapter we'll be using VBScript in our examples, unless we specifically mention otherwise. However, many of the properties and methods definitions in code are identical in JavaScript (remembering that JavaScript is case-sensitive, while VBScript is not).

You may well have met the 'page targeting' keywords _top and _self before. In the TARGET attribute of an <A> tag, _top is used to load a page into the main browser window, instead of into a frame within the window — effectively replacing the frameset. _self can be used to load a page into the current window and maintain the current frame layout, though this is rarely used. The top and self keywords in scripting languages have the same meaning as these.

The concept of things belonging to collections and having parents and children implies that there is an underlying object model structure. In this chapter, we'll start to explore the object model, and see how to use it in Dynamic HTML.

The Object Model in Overview

The browser object model is, in fact, simply an interface between the DHTML source code in the page, and the browser software routines that create the window and fill it with the elements defined in the page. Exactly how these routines fill the browser window (or render the page) is unimportant to us. Dynamic HTML simply defines what the results should be, not how the processes should be implemented.

We can think of the browser object model as being a part of the browser, while Dynamic HTML is (in theory at least) a universal browser-independent document definition language. This means that all browsers that host Dynamic HTML must provide the same core objects in their object model. Otherwise, it would be impossible to create pages that performed properly on different browsers.

So, we can think of the browser's object model as being a way of connecting our pages to the browser. The object model provides a range of objects, methods, properties and events that are present and active within the browser's software, and are exposed to the HTML and scripting code in the page. We can use these to communicate our wishes back to the browser, and hence to the viewer. The browser will carry out our commands, and update the page(s) it displays.

Objects, Methods, Properties and Events

So far we've talked about objects, methods, properties and events — and assumed that you're familiar with these terms. No doubt you've heard them used many times, but we'll recap briefly here before going on to look at the browser object model itself.


Modern software design is very much concerned with objects. Objects are self-contained parts of a program such as the browser, and each object carries out specific functions. The key is that each object will usually store its own data in its own format and will also contain the code routines (called methods — see the definition below) that are required to manipulate that data.

You can think of an object as being rather like a video recorder, in that we put the tapes in and set the timer, but all the work of recording and playing back goes on inside the black box. We just tell it to record or play back, and we don't need to know what's actually going on inside. The video recorder stores its data (our TV program) itself, in its own format (a video cassette), without us having to worry about how it's doing it.


Methods are an object's way of letting us do something with it. Our video recorder has methods built in that allow us to record or play back TV programs. The big advantage of having an object provide methods is that it takes away the worry of knowing what's going on inside the object. Rather than telling the video recorder the exact patterns of magnetism to lay down on the tape, and how to interpret the sound signal, we execute its Record method by pressing a couple of buttons.


If methods are our way of telling an object what to do, events can be thought of as the object's way of telling us that something happened. It's likely that our trusty video recorder will have something we could term an EndOfTape event. This occurs when the end of the tape is reached, and stops the motor to prevent it tearing the tape off the spool. Here, the event is being used internally to execute the Stop method of the TapeWindingMotor object inside the video recorder.

However, it's likely that the video recorder will also tell us that the end of the tape has been reached, by changing the display on the front or by rewinding and automatically ejecting the tape. This allows us to respond to the event, perhaps by putting the tape back in its library case — this is called event handling.


Properties should be no problem to grasp by now. We regularly used the term Chapter 2, when we were referring to the style properties of the elements in the page. All we really mean by a property is some setting, or stored value, that applies to an object. The object will usually expose a set of properties that affect the appearance or behavior of the object, and some that just provide information about it.

In our video recorder example there are read/write properties — these are properties that we can change in order to adjust the behavior or appearance of the video recorder. These might include the record speed setting and the time setting on the clock. The video recorder will also have some read-only properties — these might include the age, the price, and the working condition. As you can see, there are often read-only properties that we would like to be able to change, but can't — and DHTML is no exception.

The 0bject Model Diagram

Being able to describe the object model of the browser is a necessity if we are to understand how all the parts of the hierarchy fit together. The usual way to do this is to show a tree-style diagram, with the main objects at the top and the subsidiary ones below: this is what we've done here. The object model diagram is really an abstract representation of the available objects and how they are related to one another. In a real page scenario, we work with instances of these objects, whose relationship reflects the structure that is shown here.

The top-level object in the browser hierarchy is the window. This is the parent object for every other object in the structure.

You'll notice that some of the 'things' in the object hierarchy are objects, and some are collections. In general, collections have a plural name, i.e. anchors rather than anchor. The one that breaks the rule is the all collection — we can only assume that calling it the alls collection would have sounded a little odd.
The diagram shows how each of the objects is related — and there are quite a few of them altogether. If you've used VBScript or JavaScript in any depth before, you'll recognize many of them. To maintain backwards compatibility with pages designed for older browsers, the object model for DHTML is a superset of that found in prior versions of Internet Explorer. ...

Customer Reviews

Average Review:

Post to your social network


Most Helpful Customer Reviews

See all customer reviews