One aspect of the “dynamic” in Dynamic HTML is the presentation of alternative page content to a particular user, for whatever reason. This “personalization” is best applied in real time, must function efficiently no matter how many users are pinging away on your application server, and is becoming increasingly popular. The underlying code, on those sites you’ve seen that can do these tricks, is aided by the component technologies of DHTML. JavaScript no doubt leaps to mind.

But you do yourself, your code, and your successor developers a disservice by discounting DOM as a choice for real-time page content manipulation. DOM is the middle child, not as refined and popular as JavaScript, not as cute and adorable as CSS—but it has all the value of its siblings (and often more) when it comes to efficiency and continuity in content manipulation.

What you can do
The big plus with DOM is the manner in which its constituent objects are interrelated, forming an object tree. You can use the DOM tree to replace content dynamically. The DOM tree is a hierarchy of scriptable objects, residing in browser memory, with built-in parent-child relationships. You can assign these relationships to page elements and exploit these built-in features to manipulate content. The point is: You don’t have to build it; it’s already sitting there, waiting to go to work.

Why you should do it
Normally, if you wish to present data in different ways, you need to parse HTML code conditionally on the server side. With dynamic DOM-tree content manipulation, you can transfer this process to the client side, while simplifying the code. You’re basically writing one chunk of code that will be capable of creating multiple page content options, without conditional parsing. That’s a winner from all sides.

Simplification, with its maintenance, is no small excuse to proceed. Code minimization, with its implicit efficiency, is also a great reason. But you’ll also benefit from this technique in that it will encourage you to organize your document well. You’ll find yourself assigning logical relationships to your page elements that might not have occurred to you otherwise, and you’ll wind up with a cleaner, more reasonable document.

How it can be done
The job is to add a script to an application that will generate content dynamically; that is, alter the appearance of information being presented to the user, and do it in real time, using DOM rather than a hard-coded, element-by-element function, and do it on the client side, not the server side.

Here’s the direction you might go.

  1. Put the document data that you wish to be available for dynamic manipulation on the client side; create temporary arrays via your script, and load them with whatever data you want to present to the user. If your server-side facilities permit, you can have a small database waiting to load these for you; otherwise you can always load them as shown in Listing A.
  2. Tie your stylesheet file to the JavaScript file that displays these arrays by including an import of the file; you can do this in your <style> element with either a <LINK REL … SRC=”styles.css filename)”> tag or the @import “styles.css filename” method.
  3. Set up the portion of your document that will display content dynamically using the DIV element (DIV physically isolates elements into a group, and allows you to assign a class or style to everything it contains). Create display elements (i.e., <p id=”ScreenItemGoesHere” class=”itemName”>) in your dynamic content space, to be loaded from your temporary arrays.
  4. Now you write a script to create the display in which the content will be dynamically generated. In writing this script, you’ll make use of the DOM tree to access page elements. DOM has several built-in methods that your script can use: createElement and createTextNode are your big guns.
    Create a function in the script for loading your array elements into your dynamic content space. You’ll do this by generating DOM nodes as shown in Listing B.
  5. What you’ve done here is created a new TextNode object from your content possibilities. What goes in when depends upon your application logic. Use this function in a loop, according to whatever script logic suits your application, using append.Child to insert the new object into the page by relating it to its siblings (for more detail on nodes, parent/child, siblings, see the DOM specifications).
  6. Once you’ve created these nodes and loaded them, you need to create a display function. This should execute your loadElement function to create TextNodes and append them, as described above, to the desired physical element in the page. You may, and probably should, use this function to insert manual text decorations into the dynamic page area, such as headings, messages, and other non-dynamic text that must live alongside your array content.
  7. Set up some method to call the load and display functions in your script. This can be whatever you want it to be, and can be passive or active from the user’s viewpoint, depending on the needs of your app.

Make it dynamic
Depending on how you’ve written your display function, the index values fed to the function will determine which array items are made into elements, and DOM allows you to abstract both the creation and loading of elements into physical spaces, vastly simplifying your code and generalizing the components of your app.

How is this different from just doing it all in the script? What you’ve done above is basically create an abstract content generator, then filled up the physical page elements with content that is variable, and tied it to a user-generated event. No page elements need ever be hard-coded.

And why does it work the way it does? The parent-child relationship in DOM is, basically, an inheritance path that handles the passing of style properties, and it’s built in. An element nested within another element is a child (its container is the parent), and elements nested together are siblings. Style value inheritance follows this path, and class/style assignments can be made this way, which gives you a means of grouping items for one-pass style change. “Nodes” in this context are the components of an element.

More control
The recipe above is given loosely because there are countless ways to tackle this technique. It’s time for some serious creativity, not only in execution, but in application. Bottom-lining it, as a designer you can have far more control over your page design and can impart far more flexibility on your Web app documents if you use DOM’s hidden toolbox. You don’t need to rely on (or be constrained by) server-side designers for your client-side content. Go where you want to go.