This chapter marks the first of nine tutorial chapters tailored to Web
authors who have at least basic grounding in HTML concepts.
In
particular, you should already be familiar with common HTML tags
and their attributes, as well as the fundamentals of Cascading Style
Sheets (CSS). In this chapter, you see several practical applications
of JavaScript and begin to see how a JavaScript-enabled browser
turns familiar HTML elements into objects that your scripts control.
This tutorial teaches concepts and terminology that apply to modern
browsers with special focus on standards-compatibility to equip you
to work with today’s and tomorrow’s browsers. You should study this
tutorial in conjunction with any of the following browsers: Internet
Explorer 5 or later (Windows or Macintosh), any Mozilla-based
browser, or Apple’s Safari.
Scripts Run the Show
If you have authored Web pages with HTML, you are familiar with
how HTML tags influence the way content is rendered on a page
when viewed in the browser. As the page loads, the browser recognizes
angle-bracketed tags as formatting instructions. Instructions
are read from the top of the document downward, and elements
defined in the HTML document appear onscreen in the same order in
which they appear in the document’s source code. As an author, you
do a little work one time and up front—adding the tags to text
content—and the browser does a lot more work every time a visitor
loads the page into a browser.
Assume for a moment that one of the elements on the page is a text
input field inside a form. The user is supposed to enter some text in
the text field and then click the Submit button to send that information
back to the Web server. If that information must be an Internet
e-mail address, how do you ensure the user includes the “@” symbol
in the address?
One way is to have a Common Gateway Interface (CGI) program on
the server inspect the submitted form data after the user clicks
the Submit button and the form information is transferred to the
server. If the user omits or forgets the “@” symbol, the CGI program
sends the page back to the browser—but this time with an instruction
to include the symbol in the address. Nothing is wrong with this
exchange, but it means a significant delay for the user to find out that the address does not
contain the crucial symbol. Moreover, the Web server has to expend some of its resources to
perform the validation and communicate back to the visitor. If the Web site is a busy one, the
server may try to perform hundreds of these validations at any given moment, probably slowing
the response time to the user even more.
Now imagine that the document containing that text input field has some intelligence built
into it that makes sure the text field entry contains the “@” symbol before ever submitting
one bit (literally!) of data to the server. That kind of intelligence would have to be embedded
in the document in some fashion—downloaded with the page’s content so it can stand ready
to jump into action when called upon. The browser must know how to run that embedded
program. Some user action must start the program, perhaps when the user clicks the Submit
button. If the program runs inside the browser and detects a lack of the “@” symbol, an alert
message should appear to bring the problem to the user’s attention. The same program also
should be capable of deciding if the actual submission can proceed or if it should wait until a
valid e-mail address is entered into the field
.
This kind of pre-submission data entry validation is but one of the practical ways JavaScript
adds intelligence to an HTML document. Looking at this example, you might recognize that a
script must know how to look into what is typed in a text field; a script must also know how
to let a submission continue or how to abort the submission. A browser capable of running
JavaScript programs conveniently treats elements such as the text field as objects. A
JavaScript script controls the action and behavior of objects—most of which you see on the
screen in the browser window.
JavaScript in Action
By adding lines of JavaScript code to your HTML documents, you control onscreen objects in
whatever way your applications require. To give you an idea of the scope of applications you
can create with JavaScript, I show you several applications on the CD-ROM (in the Listings
folders for Chapters 48 through 57). I strongly suggest you open the applications and play
with them in your browser as they are described in the next several pages. You can find links
to the application files for these chapters via the index.html file located in the Listings
folder on the CD-ROM.
Interactive user interfaces
HTML hyperlinks do a fine job, but they’re not necessarily the most engaging way to present
a table of contents for a large site or document. With a bit of JavaScript, you can create an
interactive, expandable table of contents listing that displays the hierarchy of a large body of
material (see Figure 4-1). Just like the text listings (or tree views) in operating system file management
windows, the expandable table of contents lets the user see as much or as little as
possible while displaying the big picture of the entire data collection.
Click a gray widget icon to expand the items underneath. An endpoint item has an orange and
black widget icon. Items in the outline can be links to other pages or descriptive information.
You also maintain the same kind of font control over each entry, as expected from HTML.
While such outlines have been created with the aid of server programs in the past, the
response time between clicks is terribly slow. By placing all of the smarts behind the outline
inside the page, it downloads once and runs quickly after each click.
A common application on the Web is having a server program present a page that visitors use
to access large databases on the server. Large data collections are best left on the server
where search engines and database technologies are the best fit. But if your page acts as a
front end to a small data collection lookup, you can consider embedding that data collection
in the document (out of view) and letting JavaScript act as the intermediary between user
and data.
I do just that in a Social Security prefix lookup system shown in Figure 4-2. I convert a printed
table of about 55 entries into a JavaScript list that occupies only a few hundred bytes. When
the visitor types the three-character prefix of his or her Social Security number into the field
and clicks the Search button, a script behind the scenes compares that number against the 55
or so ranges in the table. When the script finds a match, it displays the corresponding state of
registration in a second field.
If the application were stored on the server and the data stored in a server database, each
click of the Search button would mean a delay of many seconds as the server processed the
request, got the data from the database, and reformulated the page with the result for the
user. Built instead as a JavaScript application, once the page downloads the first time, scripts
perform all lookups instantaneously.
I’ve already used data entry form validation as an example of when JavaScript is a good fit.
In fact, the data entry field in the Social Security lookup page (see Figure 4-2) includes scripting
to check the validity of the entered number. Just as a server program for this task has to
verify that the entry is a three-digit number, so, too, must the JavaScript program verify the
entered value. If a mistake appears in the entry—perhaps a finger slips and hits a letter
key—the visitor is advised of the problem and directed to try another entry. The validation
script even preselects the text in the entry field for the visitor so that typing a new value
replaces the old one.
Interactive data
JavaScript opens opportunities for turning static information into interactive information.
Figure 4-3 shows a graphical calculator for determining the value of an electrical component
(called a resistor) whose only markings are colored bars.
bunched up against each other. Four slices display the colored bands, while the remaining
three slices contain the ends of the resistor and the spacer between groups of bands. As the
visitor selects a color from a pop-up list near the top, the associated image slice changes to
the selected color and the resistance value is calculated and displayed.
Again, once the page is loaded, response time is instantaneous. Conversely, a server-based
version of this calculator would take many seconds between color changes. Moreover,
JavaScript provides the power to preload all possible images into the browser cache while
the main page loads. Therefore, with only a slight extra delay to download all images with the
page, no further delay occurs when a visitor chooses a new color. Not only is the application
practical (for its intended audience), but it’s just plain fun to play with.
Multiple frames
While frames are the domain of HTML, they suddenly become more powerful with some
JavaScript behind them. The Decision Helper application shown in Figure 4-4 takes this
notion to the extreme.
The Decision Helper is a full-fledged application that includes four input screens and one
screen that displays the results of some fairly complex calculations based on the input
screens. Results are shown both in numbers and in a bar graph form, as displayed in
Figure 4-4.
one of the directional arrows in the top-left frame. Not only does the top-right frame change
to another document, but the instructions document in the bottom frame also shifts to the
anchor point that parallels the content of the input screen. Scripting behind the top-right
frame documents uses various techniques to preserve entry information as the user navigates
through the sequence of input pages. These are the same techniques you might use to
build an online product catalog and shopping cart—accumulating the customer’s selections
from various catalog pages and then bringing them together in the checkout order form.
Certainly you could fashion this application out of a CGI program on the server. But the high
level of interaction and calculation required would turn this now speedy application into a
glacially slow exchange of information between user and server.
Dynamic HTML
Starting with the version 4 browsers from both Netscape and Microsoft, you can modify more
and more content on the page with the help of client-side scripts. In Figure 4-5, for example,
scripts in the page control the dragging of map pieces in the puzzle. Highlighted colors
change as you click the state maps, instruction panels fly in from the edge of the screen, and
another item appears when you place all the states in their proper positions.
Applying scripts to modify HTML content or position on the fly is commonly called Dynamic
HTML (DHTML). JavaScript becomes the vital connection between the user and dynamically
respositionable elements on the screen. Not even a program on the server could help this
application because you need immediate programmatic control in the page to respond to
user mouse motion and instantaneous changes to screen elements.
When to use JavaScript
The preceding examples demonstrate a wide range of applications for JavaScript, but by no
means do they come close to exhausting JavaScript’s possibilities. When faced with a Web
application task, I look to client-side JavaScript for help with the following requirements:
✦ Data entry validation: If form fields need to be filled out for processing on the server, I
let client-side scripts prequalify the data entered by the user.
✦ Serverless CGIs: I use this term to describe processes that, were it not for JavaScript,
would be programmed as CGIs on the server, yielding slow performance because of the
interactivity required between the program and user. This includes tasks such as small
data collection lookup, modification of images, and generation of HTML in other frames
and windows based on user input.
✦ Dynamic HTML interactivity: It’s one thing to use DHTML’s capabilities to position elements
precisely on the page—you don’t need scripting for that. But if you intend to
make the content dance on the page, scripting makes that happen.
✦ CGI prototyping: Sometimes you may want a CGI program to be at the root of your
application because it reduces the potential incompatibilities among browser brands
and versions. It may be easier to create a prototype of the CGI in client-side JavaScript.
Use this opportunity to polish the user interface before implementing the application
as a CGI.
✦ Offloading a busy server: If you have a highly trafficked Web site, it may be beneficial
to convert frequently used CGI processes to client-side JavaScript scripts. Once a page
is downloaded, the server is free to serve other visitors. Not only does this lighten
server load, but users also experience quicker response to the application embedded
in the page.
✦ Adding life to otherwise dead pages: HTML by itself is pretty “flat.” Adding a blinking
chunk of text doesn’t help much; animated GIF images more often distract from, rather
than contribute to, the user experience at your site. But if you can dream up ways to
add some interactive zip to your page, it may engage the user and encourage a recommendation
to friends or repeat visits.
✦ Creating “Web pages that think”: If you let your imagination soar, you may develop
new, intriguing ways to make your pages appear “smart.” For example, in the application
Intelligent “Updated” Flags (Chapter 54 on the CD-ROM), you see how (without a
server CGI or database) an HTML page can “remember” when a visitor last came to the
page. Then any items that have been updated since the last visit—regardless of the
number of updates you’ve done to the page—are flagged for that visitor. That’s the
kind of subtle, thinking Web page that best displays JavaScript’s powers.
The Document Object Model
Before you can truly start scripting, you should have a good feel for the kinds of objects you
will be scripting. A scriptable browser does a lot of the work of creating software objects that
generally represent the visible objects you see in an HTML page in the browser window.
Obvious objects include form controls (text boxes and buttons) and images. However, there
may be other objects that aren’t so obvious by looking at a page but which make perfect
sense when you consider the HTML tags used to generate a page’s content—paragraph
objects or frames of a frameset, for example.
To help scripts control these objects—and to help authors see some method to the madness
of potentially dozens of objects on a page—the browser makers define a document object
model (DOM). A model is like a prototype or plan for the organization of objects on a page.
Evolution of browser DOMs has caused much confusion and consternation among scripters
due to a lack of compatibility across succeeding generations and brands of browsers.
Fortunately, the DOM world is stabilizing around a formal specification published by the
World Wide Web Consortium (W3C). Today’s modern browsers continue to support some of
the “old ways” of the earliest DOM because so much existing script code on the Web relies on
these traditions continuing to work (you’ll see some of these in Chapter 9). But with the vast
majority of browsers in use today supporting the basic W3C DOM syntax and terminology,
scripters should aim toward standards compatibility whenever possible.
HTML structure and the DOM
An important trend in HTML markup is applying markup solely to define the structure of a
document and the context of each piece of content in the document. The days of using HTML
tags solely to influence the appearance of a chunk of text are drawing to a close. It is no longer
acceptable to enclose a line of text in, say, an <h1> tag because you want the line to appear in
the text size and weight that browsers automatically apply to text tagged in that way. An <h1>
element has a special context within a document’s structure: a first-level heading. In today’s
HTML world, if you wish to display a standalone line of text with a particular style, the text
would likely be in a simple paragraph (<p>) tag; the precise look of that paragraph would be
the application of <b> and <i> tags to assign boldface and italic styles to a span of text.
Instead surround the text in a contextual tag (such as the <em> element to signify emphasis)
and define the CSS style you wish applied to any emphasized text in the document.
The result of applying strict structural design to your HTML tagging is a document that has a
well-defined hierarchy of elements based on their nesting within each other. For example, an
empty HTML document has the following minimum elements:
<html>
<head></head>
<body></body>
</html>
The html element contains two nested elements, head and body. The hierarchy of elements
can be charted like a corporate organizational chart, as shown in Figure 4-6. For the sake of
upcoming terminology lessons, however, it is more convenient to visualize the chart in Figure
4-6 as a family tree—except that, unlike most real family trees each point that spawns children
is a single-parent. In the empty HTML document, the html element is the parent of two
child elements: head and body. The html element is, in turn, a child of the document.
The DOM in a browser window
As its name implies, the formal Document Object Model focuses primarily on the HTML document
and the content nested inside it. From a practical standpoint, however, scripters often
need to control the environment that contains the document: the window. The window object
is the top of the hierarchy that browser scripts work with. The basic structure of the object
model in modern browsers (given an empty HTML document) is shown in Figure 4-7.
It’s not important to memorize the model. But to give you a sense of the relationships among
these top-level objects, the following describes their respective roles:
✦ window object: At the very top of the hierarchy is the window. This object represents
the content area of the browser window where HTML documents appear. In a multipleframe
environment, each frame is also a window (but don’t concern yourself with this
just yet). Because all document action takes place inside the window, the window is the
outermost element of the object hierarchy. Its physical borders contain the document.
✦ navigator object: This is the closest your scripts come to accessing the browser program,
primarily to read the brand and version of browser that holds the current document.
This object is read-only, protecting the browser from inappropriate access by
rogue scripts.
✦ screen object: Another read-only object lets scripts learn about the physical environment
in which the browser is running. For example, this object reveals the number of
pixels high and wide available in the monitor.
✦ history object: While the browser maintains internal details about the browser’s recent
history (such as the list available under the Back button), scripts have no access to the
details. At most this object assists a script in simulating a click of the Back or Forward
button.
✦ location object: This object is the primary avenue to loading a different page into the
current window or frame. URL information about the window is available under very
controlled circumstances so that scripts cannot track access to other Web sites.
✦ document object: Each HTML document that gets loaded into a window becomes a
document object. The document object contains the content that you are likely to
script. Except for the html, head, and body element objects that are found in every
HTML document, the precise makeup and structure of the element object hierarchy of
the document depends on the content you put into the document.
When a Document Loads
Programming languages, such as JavaScript, are convenient intermediaries between your
mental image of how a program works and the true inner workings of the computer. Inside
the machine, every word of a program code listing influences the storage and movement of
bits (the legendary 1s and 0s of the computer’s binary universe) from one RAM storage slot
to another. Languages and object models are inside the computer (or, in the case of
JavaScript and the DOM, inside the browser’s area of the computer) to make it easier for programmers
to visualize how a program works and what its results will be. The relationship
reminds me a lot of knowing how to drive an automobile from point A to point B without
knowing exactly how an internal combustion engine, steering linkages, and all that other
internal “stuff” works. By controlling high-level objects such as the ignition key, gearshift, gas
pedal, brake, and steering wheel, I can get the results I need.
Of course, programming is not exactly like driving a car with an automatic transmission. Even
scripting requires the equivalent of opening the hood and perhaps knowing how to check the
transmission fluid or change the oil. Therefore, now it’s time to open the hood and watch
what happens to a document’s object model as a page loads into the browser.
A simple document
Figure 4-8 shows the HTML and corresponding object model for a document that I’ll be
adding to in a moment. The figure shows only the document object portion—the window
object and its other top-level objects (including the document object) are always there, even
for an empty document. When this page loads, the browser maintains in its memory a map of
the objects generated by the HTML tags in the document. At this point, only three objects
exist, one for the outermost html element and its two nested elements.
<html>
<head></head>
<body></body>
</html>
Add a paragraph element
Now, I modify the HTML file to include an empty paragraph element and reload the document.
Figure 4-9 shows what happens to both the HTML (changes in boldface) and the object
map as constructed by the browser. Even though no content appears in the paragraph, the
<p> tags are enough to tell the browser to create that p element object. Also note that the p
element object is contained by the body element object in the hierarchy of objects in the current
map. In other words, the p element object is a child of the body element object. The
object hierarchy matches the HTML tag containment hierarchy.
<html>
<head></head>
<body>
<p></p>
</body>
</html>
Add paragraph text
I modify and reload the HTML file again, this time inserting the text of the paragraph between
the element’s start and end tags, as shown in Figure 4-10. A run of text extending between
tags is a special kind of object in the DOM, called a text node. A text node always has an element
acting as its container. Applying the official genealogy metaphor to this structure, the
text node is a child of its parent p element. We now have a branch of the document object
tree that runs several generations: document->html->body->p->text node.
<html>
<head></head>
<body>
<p>This is the one and
only paragraph.</p>
</body>
</html>
Make a new element
The last modification I make to the file is to wrap a portion of the paragraph text in an <em>
tag to signify emphasis for the enclosed text. This insertion has a large effect on the hierarchy
of the p element object, as shown in Figure 4-11. The p element goes from having a single (text
node) child to having three children: two text nodes with an element between them. In the
W3C DOM, a text node cannot have any children and therefore cannot contain an element
object. The bit of the text node now inside the em element is no longer a child of the p element,
but rather a child of the em element. That text node is now a grandchild of the p element
object.
Now that you see how objects are created in memory in response to HTML tags, the next step
is to figure out how scripts can communicate with these objects. After all, scripting is mostly
about controlling these objects.
html>
<head></head>
<body>
<p>This is the <em>one and
only </em> paragraph .</p>
</body>
</html>
Object References
After a document is loaded into the browser, all of its objects are safely stored in memory in
the containment hierarchy structure specified by the browser’s document object model. For
a script to control one of those objects, there must be a way to communicate with an object
and find out something about it such as, “Hey, Mr. Text Field, what did the user type?” To let
your scripts “talk to” an object, you need a way to refer to that object. That is precisely what
an object reference in a script does for the browser.
Object naming
The biggest aid in creating script references to objects is assigning a name to every scriptable
object in your HTML. In the W3C DOM (and current HTML specification), the way to assign a
name to an element is by way of the id attribute. This attribute is optional, but if you plan to
use scripts to access an element in the page, it is most convenient to assign a name to that
element’s id attribute directly in the HTML code. Here are some examples of id attributes
added to typical tags:
<p id=”firstParagraph” >
<img id=”logo” src=”images/logo.jpg” alt=”Corp Logo”>
<div class=”draggable” id=”puzzlePiece”>
The only rules about object IDs (also called identifiers) are that they
✦ May not contain spaces
✦ Should not contain punctuation except for the underscore character
✦ Must be inside quotes when assigned to the id attribute
✦ Must not start with a numeric character
✦ May not occur more than once in the same document
Think of assigning IDs as the same as sticking nametags on everyone attending a conference
meeting. To find a particular conference attendee whose name you know, you could wait at
the entrance and scan each nametag until you find the name you’re looking for; or you could
bump around the attendees at random in the hope that you’ll find a known name. But it
would be more efficient if you had a way to immediately target an attendee by name—like
broadcasting the name on the public address system to the whole crowd.
Referencing a particular object
The W3C DOM provides that kind of instant access to any named element in the document.
If you haven’t programmed before, the syntax for this access command may be intimidating
by its length—a hazard when a standard such as the W3C DOM is designed by programmers.
Like it or not, we’re stuck with this syntax. Here is the syntax you will use frequently in your
browser scripting:
window.document.getElementById(“elementID”)
You substitute the ID of the element you wish to reference for elementID. For example, if
you want to reference the paragraph element whose ID is firstParagraph, the reference
would be:
window.document.getElementById(“firstParagraph”)
Be careful! JavaScript is case-sensitive. Be sure you use uppercase for the three uppercase
letters in the command, and use a lowercase “d” at the end, and that you capitalize the
ID accurately as well.
The getElementById() command belongs to the document object, meaning that the
entire document’s collection of elements is subject to this instantaneous search for a matching
ID. The dot—a traditional period character—is the JavaScript way of indicating that the
item to the left of the dot (the document object here) has the item to the right of the dot
(getElementById() here) as a resource to call upon whenever needed. Each type of object
has a list of such resources, as you’ll see in a moment (and as summarized in Appendix A).
id versus name Attributes
Prior to the HTML 4.0 specification’s introduction of the id attribute, scripts could access a handful
of elements that also supported the name attribute. Elements supporting the name attribute
are predominantly related to forms, images, and frames. You will see how name attributes work
in forms in Chapter 9. In fact, most browsers still require the name attribute for forms and form
controls (text fields, buttons, and select lists) for their data to be submitted to a server. It is permissible
to assign the same identifier to both the id and name attributes of an element.
Node Terminology
W3C DOM terminology uses metaphors to assist programmers in visualizing the containment
hierarchy of a document and its content. One concept you should grasp early in your learning
is that of a node; the other concept is the family relationship among objects in a document.
About nodes
While the English dictionary contains numerous definitions of “node,” the one that comes
closest to its application in the W3C DOM is the one that implies a knob or bump on a tree
branch. Such nodules on a branch usually lead to one of two things: a leaf or another branch.
A leaf is a dead end in that no further branches emanate from the leaf; but the branch kind of
node leads to a new branch that can, itself, have further nodes, whether they be leaves or
more branches. When you define the structure of an HTML document, you also define a node
structure (also called a node tree) whose placement of branches and leaves depends entirely
on your HTML elements and text content.
In the W3C DOM, the fundamental building block is a simple, generic node. But inside an
HTML document, we work with special kinds of nodes that are tailored to HTML documents.
The two types of nodes that scripts touch most often are element nodes and text nodes.
These node types correspond exactly to HTML elements and the text that goes between an
element’s start and end tags. You’ve been working with element and text nodes in your HTML
authoring, and you didn’t even know it.
Look again at the simple document assembled earlier, along with its containment hierarchy
diagram in Figure 4-12. All of the boxes representing HTML elements (html, head, body, p,
and em) are element nodes; the three boxes containing actual text that appears in the rendered
document are text nodes. You saw in the transition from one long text node (Figure 4-10)
to the insertion of the em element (Figure 4-11) that the long text node divided into three
pieces. Two text node pieces stayed in the same position in the hierarchy relative to the containing
p element. The new em element bullied its way into the tree between the two text
nodes, and shifted the third text node one level away from the p element.
<html>
<head></head>
<body>
<p>This is the <em>one and
only </em> paragraph .</p>
</body>
</html>
Parents and children
Looking more closely at the p element and its content in Figure 4-12, you can see that element
has three child nodes. The first and last are of the text node type, while the middle one is an
element node. When an element contains multiple child nodes, the sequence of child nodes is
entirely dependent upon the HTML source code order. Thus, the first child node of the p element
is the text node containing the text “This is the “. In the case of the em element, a single
child text node is the sole descendant of the element.
Element node children are not always text nodes, nor do branches always end in text nodes.
In Figure 4-12, the html element has two child nodes, both of which are element nodes; the
body element has one child node, the p element. Even though the head element node appears
to be at the end of a branch, it is still an element node because it is capable of containing
other nodes (such as a title element). A tag in the HTML indicates an element node,
whether or not it has any child nodes. In contrast, a text node can never contain another
node—it’s one of those dead-end leaf type of nodes.
Notice that a child node is always contained by one element node. That container is the parent
node of its child or children. For example from the point of view of the em element node, it
has both one child (a text node) and one parent (the p element node). A fair amount of W3C
DOM terminology (which you’ll meet in Chapter 14) concerns itself with assisting scripts to
start at any point in a document hierarchy and obtain a reference to a related node if necessary.
For instance, if a Dynamic HTML script wants to modify the text inside the em element of
Figure 4-12, it would typically do so by starting with a reference to the em element via the
document.getElementById() command (assuming the em element has an ID assigned to it)
and then modifying the element’s child node.
In case you’re wondering, the document object at the top of the node tree is, itself, a node.
Its place in the tree is special and is called, simply, the document node. Each document contains
a single document node, and that node becomes the scripter’s gateway to the rest of
the document’s nodes. It’s no accident that the syntax for referencing an element node—
document.getElementById()—begins with a reference to the document object.
What Defines an Object?
When an HTML tag defines an object in the source code, the browser creates a slot for that
object in memory as the page loads. But an object is far more complex internally than, say,
a mere number stored in memory. The purpose of an object is to represent some “thing.” In
the browser and its Document Object Model, the most common objects are those that correspond
to elements, such as a text input form field, a table element, or the whole HTML document.
Outside of the pared-down world of the DOM, an object can also represent abstract
entities, such as a calendar program’s appointment entry or a layer of graphical shapes in a
drawing program. It is common for your browser scripts to work with both DOM objects and
abstract objects of your own design.
Every type of DOM object is unique in some way, even if two or more objects look identical to
you in the browser. Three very important facets of an object define what it is, what it looks
like, how it behaves, and how scripts control it. Those three facets are properties, methods,
and event handlers. They play such key roles in your future DOM scripting efforts that the
Object Quick Reference in Appendix A summarizes the properties, methods, and event handlers
for each object in the object models implemented in various browser generations.
Properties
Any physical object you hold in your hand has a collection of characteristics that defines it. A
coin, for example, has shape, diameter, thickness, color, weight, embossed images on each
side, and any number of other attributes that distinguish it from, say, a feather. Each of those
features is called a property. Each property has a value of some kind attached to it (even if the
value is empty or null). For example, the shape property of a coin might be “circle”—in this
case, a text value. In contrast, the denomination property is most likely a numeric value.
You may not have known it, but if you’ve written HTML for use in a scriptable browser, you
have set object properties without writing one iota of JavaScript. Tag attributes are the most
common way to set an HTML element object’s initial properties. For example, the following
HTML tag defines an input element object that assigns four property values:
<input type=”button” id=”clicker” name=”clicker” value=”Hit Me...”>
In JavaScript parlance, then, the type property holds the word “button,” the id and name
properties hold the same word, “clicker,” and the value property is the text that appears on
the button label, “Hit Me. . . .” In truth, a button input element has more properties than just
these, but you don’t have to set every property for every object. Most properties have
default values that are automatically assigned if nothing special is set in the HTML or later
from a script.
The contents of some properties can change after a document has loaded and the user interacts
with the page. Consider the following text input tag:
<input type=”text” id=”entry” name=”entry” value=”User Name?”>
The id and name properties of this object are the same word, “entry.” When the page loads,
the text of the value attribute setting is placed in the text field—the automatic behavior of
an HTML text field when the value attribute is specified. But if a user enters some other text
into the text field, the value property changes—not in the HTML, but in the memory copy of
the object model that the browser maintains. Therefore, if a script queries the text field about
the content of the value property, the browser yields the current setting of the property—
which isn’t necessarily the one specified by the HTML.
To gain access to an object’s property, you use the same kind of dot notation addressing
scheme you saw earlier for objects. A property is a resource belonging to its object, so the
reference to it consists of the reference to the object plus one more extension naming the
property. Therefore, for the button and text object tags just shown, references to various
properties are
document.getElementById(“clicker”).name
document.getElementById(“clicker”).value
document.getElementById(“entry”).value
You may wonder what happened to the window part of the reference. It turns out that there
can be only one document contained in a window, so references to objects inside the document
can omit the window portion and start the reference with document. You cannot omit
the document object, however, from the reference.
Internet Explorer References
Before the W3C DOM came into existence, Microsoft had created its own way of referencing element
objects by way of their id attributes. You will find many instances of this syntax in existing
code that has been written only for Internet Explorer 4 or later. The syntax uses a construction
called document.all. Although there are a few different ways to use this construction, the most
commonly applied way is to continue the dot notation to include the ID of the element. For
example, if a paragraph element’s ID is myParagraph, the IE-only reference syntax is:
document.all.myParagraph
You can also completely omit the lead-in parts of the reference, and simply refer to the ID of the
element:
myParagraph
Be aware, however, that none of these approaches is supported in the W3C DOM standard. Both
the IE-specific and W3C DOM reference syntax styles are implemented in IE5 or later. Going forward,
you should migrate existing code to the W3C DOM style to be compatible with more
browsers.
