Well-Behaved DHTML: A Case Study

5 Steps to Writing Well-Behaved DHTML

Our goals for the production Dynamic Label script are not unlike the goals for most DHTML enhancements to Webpages. In fact, almost all scripts I write share these same goals.

Over time, I’ve discovered that there’s a simple process that can be followed for almost any DHTML effect to ensure that these goals are met:

1. Identify the underlying logical structure of the effect.
   
2. Create a full working example of the effect.
   
3. Identify all user agent requirements.
   
4. Write code to transform the logical structure when the agent requirements are met.
   
5. Thoroughly test each target platform.

Step 1: Identify The Underlying Logical Structure of the Effect

One of our primary goals is to avoid any reliance on JavaScript. A common, but ultimately flawed approach to this problem is to try to detect “supported” browsers on the server. If a browser is supported, it is sent the dynamic version of the code. Otherwise, it is sent a simpler version.

The problem is that it’s practically impossible to unambiguously detect browser type and version on the server. Even if you could, you wouldn’t be able to detect whether JavaScript was actually enabled for a particular user. Browsers simply don’t send the server enough information to reliably identify themselves, or their configuration.

The best way to avoid JavaScript reliance is to build DHTML effects on top of a simple, logical document structure that doesn’t require it. The effect will become enabled dynamically on the client, if it is supported. If not, the user will see the basic document.

The logical structure for our dynamic label works out nicely, thanks to the existence of the label HTML element.

The label element structurally links a form element to its textual label. In most visual browsers, the only tactile difference between using the label element and any other element (or no element at all) is that clicking the label focuses the form on the field with which that label is associated.

However, at this point we are interested in simply building the most logical underlying structure for our effect, so we will use the label element. Example B shows our work.

Clearly there’s nothing fancy here, and that’s precisely what we want. The code from this step is the lowest-common-denominator view of our effect. Ideally, this document should make sense whether it is viewed in the latest version of Mozilla, or on a cell phone. This is the document users will see if their browser doesn’t have the features our effect requires, or doesn’t have them enabled.

Step 2: Create A Full Working Example of the Effect in a Best-Case Environment

The next thing to do, once you’ve got the logical structure in place, is to modify it to create a full working example of the effect. Don’t worry about how the script will degrade at this point, just make it work with the assumption that every feature you require will be available and turned on.

Looking at our work from Step 1, it’s easy to see the high-level tasks we’ll have to accomplish for each dynamic label to display our effect:

1. Hide the regular HTML label element.
   
2. Attach JavaScript functions to the onfocus and onblur events of the associated field that show and hide the label at the right times.

The simplest way to complete the first task is with a CSS rule like so:

<style type=”text/css”>  
 label {  
   display:none;  
   }  
</style>

If you’re not familiar with CSS, you can get a quick primer here at SitePoint.com, or at the W3C.

The problem with a simple CSS rule like this is that it will turn off the display of every label on the page. We’ll have to modify the rule when we want to use it on a page that has label elements we want displayed in the regular way, without the effect. This wouldn’t be a very modular design at all.