12.0 Introduction

The dynamic part of Dynamic HTML is not restricted to elements flying around the page, hierarchical menus popping up from the ether, and users dragging stuff around the page. An element that doesn't move one pixel during its lifetime can still be dynamic because a change to one or more properties can alter the appearance of the element's content. Such changes can be automatic or in response to user action.

12.0.1 Referencing Element Objects

If you intend to modify a characteristic of an element on the page, your script must be able to "talk" to the element. In the early days of client-side scripting, the browser exposed only a handful of elements as objects accessible to scripts. Those elements were generally the more interactive elements, such as form controls (buttons, text boxes, and the like). Syntax used to reference these elements followed a hierarchy of exposed elements, starting with the window object and then gradually narrowing the focus to the specific element. The window object is assumed for the current window, so references typically start with the document object. For example, if you assign a identifier to the name attribute of an a, form, or input element, references can employ those names:

document.linkName
document.formName
document.formName.controlName

When a document contains more than one type of exposed element, the group of elements of the same type can be referenced through an array (collection) of those items. Array index values can be either a zero-based integer (numbered in source code order) or the name attribute string:

document.links[i]
document.forms["formName"]
document.forms[2].elements["controlName"]

These old-fashioned element reference styles continue to be supported in scriptable browsers to maintain backward-compatibility with a gigantic universe of existing code that employs these referencing techniques.

Microsoft Internet Explorer 4 was the first scriptable browser to expose all HTML elements as scriptable objects in its document object model. Scripts could reference any element that had a name or, preferably, an id attribute value. The most common mechanism to address an element was by way of the document.all collection—an array of all elements in the document, regardless of element nesting or position in the document. Microsoft provided a variety of syntaxes to reference elements via this collection:

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

The latter two versions were particularly helpful in processing a generic function that received a string of the ID of an element to operate on. Moreover, the IE object model let you omit the collection entirely and reference an element simply by its ID:

elementID

The effort to standardize document object models to encompass both HTML and XML documents took the form of the Document Object Model (DOM) recommendation from the World Wide Web Consortium (W3C). The W3C DOM working group elected to devise its own model and syntax for referencing elements as objects. The document object was still part of the equation, but a new method of the document object allowed a string of an element's ID to signify the specific element to reference:

document.getElementById("elementID")

This standards-based syntax is supported in IE 5 or later and in Netscape 6 or later. Thus, it is supported by the vast majority of scriptable browsers in use today. Exceptions are organizations where Navigator 4 is still the internal standard, small pockets of IE 4 users, and smaller groups of users of even older browsers.

To write code that employs features such as dynamic styles, you can equalize the disparity between document.getElementById( ) and document.all, while preventing lesser-equipped browsers from stumbling on code they won't know how to handle. The following function skeleton demonstrates how to process a string parameter containing the string of an element's ID:

function myFunction(elemID) {
    var elem = (document.getElementById) ? document.getElementById("elemID") : 
               ((document.all) ? document.all("elemID") : null);
    if (elem) {
        // process element here
    }
}

This technique gives priority to the W3C DOM syntax even when, as is the case in IE 5 or later, a browser supports multiple syntaxes. But notice, how older browsers skip over the main processing of the function because they won't be able to address arbitrary elements.

You don't have to jump through these hoops if a function is working only with elements that have been exposed as objects since the old days. Scripts for forms and form controls can utilize the original syntax, even if you use newer syntax in other portions of your scripts. Image elements, too, can be scripted on all but the first generations of browsers, with easy blockage of the early ones (see Recipe 12.1).

Recipes throughout this cookbook demonstrate the W3C DOM syntax except in the following cases:

• The recipe explicitly shows how to write code intended to work with multiple object models.

• Referenced elements are backward-compatible to browsers prior to IE 4 and NN 6.

If you wish to employ a W3C DOM-flavored recipe in an application intended for an audience that uses more varied browsers, utilize the cross-DOM object detection shown earlier in myFunction( ) in a wrapper around the core recipe code.

12.0.2 Referencing Elements from Events

If a function is defined as an event handler, the function very likely needs to devise a reference to the HTML element that was the target of the event. Internet Explorer and the W3C DOM have different event models and syntax, but they operate enough in parallel that you can equalize them to obtain a reference to the target element for further processing, as shown in the following function:

function myEventFunction(evt) {
    evt = (evt) ? evt : ((window.event) ? window.event : null);
    if (evt) {
        var elem = (evt.target) ? evt.target : 
                   ((evt.srcElement) ? evt.srcElement : null);
        if (elem) {
            // process element here
        }
    }
}

See Chapter 9 for more details on processing events across incompatible event models.

12.0.3 Getting to an Element's Style

One constant you can count on (so far, anyway) is that if a browser supports referencing individual HTML elements of all types, every element has a style property. The property is a reference to an object whose own properties are Cascading Style Sheet property names (occasionally contorted slightly to be in JavaScript-friendly format). A script reference to one of the style property values of an element follows the syntax:

elementReference.style.stylePropertyName

For example, using W3C DOM element referencing syntax for an element, the following statement assigns a new value to the color style sheet property for the element:

document.getElementById("mainHeading").style.color = "#ffff00";

The IE-only version is identical except for the element reference syntax:

document.all.mainHeading.style.color = "#ffff00";

When the CSS property name contains a hyphen, the DOM equivalent strips the hyphen and capitalizes the first character after each hyphen. This makes the reference compatible with the requirements of the JavaScript language (and others). Therefore, the following statement assigns a new value to the CSS font-size property of an element:

document.getElementById("link12").style.fontSize = "20px";

Changing an element's style sheet value is comparatively easy (there are multiple ways to do this, as shown in Recipe 11.7 and Recipe 11.8). But reading the current value applied to a particular property isn't always that easy, especially if the initial value is set via a style sheet definition outside of the element's style attribute. See Recipe 11.13 for more details.