The face of the Web is increasingly dynamic, and the use of Cascading Style Sheets (CSS) to implement style value changes efficiently and consistently is a standard. CSS gives you a make-it-so mechanism for across-the-board style update. All you need to do is alter the style values from what you have to what you want. And there are, of course, many ways to do this. But before you write a complex conditional script to do the job (as much fun as that might be), or go to work on an applet (even more fun), remember that CSS is not the only magic wand in the DHTML treasure chest. The Document Object Model (DOM) is right at your elbow, waiting to go to work. And it is simpler, cleaner, and more efficient than writing a script or an applet.

What you can do
If you aren’t already familiar with DOM, it is a collection of hierarchical, scriptable objects that can make your life much easier when writing dynamic browser apps. Hierarchical objects that are already available to you in browser memory offer programming shortcuts that simplify code and maintenance, and increase the efficiency of the app. There are multiple levels of DOM, and the standards are still settling, but the method put forth below should serve you well with the most current browsers.

How can DOM enable your style changes? In a nutshell, you can group together the elements you will want changed with a tag name. You can then apply changes to properties of those elements as a group, like flipping a switch. It’s that simple.

Why you want to do it
What do you gain by going this route, rather than writing the style-change function into the app as scripted code, or an applet? Well, simplicity is achieved, for one thing. Rather than specifying the particular elements that are relevant to the change by explicitly referencing them in code, you’re going at it from the other direction, by simply applying a tag to any element you care about. Maintenance and modification are easy; when new elements are added to the document, just tag them as you did the others.

Your efficiency gain is obvious: Not bothering with code means no code to be executed. What does happen is that objects that are in memory anyway receive updated values (which are right there in memory, too, waiting to be plugged in).

How it can be done
Step by step, here’s how you can harness your style changes. It’s a bit of a dance, but not too hard to follow:

Step 1
Style is usually initialized via script. If you need to grab it once it’s set—or changed—you can do so easily by accessing the style attribute, or currentStyle if your browser is IE5 or better. DOM can give it to you, too (DOM Level 2, that is), via getComputedStyle.

Step 2
Set up your alternate CSS (there can, of course, be multiple alternate style sets). Listing A is an example of an initial style.

In Listing A I’ve created a pseudoclass in screenElementStyle:hover, just to accommodate the explanations below. Any defined styles may be used with this technique, however.

Step 3
Create your page elements, whatever they may be (a table, a pop-up menu, whatever).

Step 4
Select and implement some mechanism for switching styles. Often, this will be a screen event that demonstrates a progression from one event to another, such as when the cursor passes over some element (as a means of highlighting it, such as the items in a pop-up menu), or when an element is clicked on, generating a table or expanded view, etc. You’ll tie the style change function to this mechanism.

Step 5
Now, tie the elements whose style you want to change together via DOM. Here’s how you do it. You have a choice of methods for tagging the elements you will want to include in the style shift. Remember that HTML elements like