Read an Excerpt
Chapter 3: The Dynamic HTML Browser Object ModelNow 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
Introducing the Browser Object ModelIf 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:
Then we can load a different page into it using the TARGET attribute of the <A> tag:
- <FRAME NAME="mainwindow" SRC="http://www.wrox.com">
<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
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.
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 OverviewThe 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.