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:
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.
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.
Create your page elements, whatever they may be (a table, a pop-up menu, whatever).
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.
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 <CENTER> and <DIV> will create blocks of related items, which you can then assign a style or class. For an example, see Listing B.
You can reference these when the time comes via several DOM functions, including: getElementsByClassName, getElementsByTagName, and getElementsByID (these functions are also great for doing client-side list sorting). You can, if you like, declare a table, to be filled with the elements you wish to group together (create this table in whatever way pleases your programmer’s soul).
But you don’t need to if you’re really shooting for simplicity.
All that’s left is to invoke the style change. The switch that controls this is often defined in your script (though it doesn’t have to be). You can create a style-change function if you like. Or you can tie the change to an event, something as innocuous as passing over an element with the cursor; i.e., set a matching tag between the screen items under your <DIV> element, as above, then trigger an event—onMouseOver, for example—and your hover pseudostyle will be applied.
And there are other ways. For example, if you choose to execute the style change via script, you can create a function—say, changeMyStyle( )—and change specific elements tagged for your change group to be the opposite of whatever they are.
The reason you would avoid scripting to begin with is so you don’t have to write element-specific code to do the job—tough to maintain, right? Well, with DOM, you can load everything that’s tagged up with those functions mentioned above (getElementsByTagName, etc.) and write a loop to handle all the elements generically, flipping them from your first style value to the alternative, without ever hard-coding an element.
At this point, you’re into the realm of your own creativity and ingenuity. Remember that the whole point of using DOM’s features for this kind of page surgery is to make life easier on the next person to handle the code, to bolster the efficiency of the document, and most of all, to simplify, simplify, simplify.
Scott Robinson is a 20-year IT veteran with extensive experience in business intelligence and systems integration. An enterprise architect with a background in social psychology, he frequently consults and lectures on analytics, business intelligence and social informatics, primarily in the health care and HR industries.