Well-Behaved DHTML: A Case Study

Step 5: Thoroughly Test on All Target Platforms

The importance of careful testing for DHTML effects cannot be understated. The simple fact is that if you’re going to write DHTML, you need to be able to test it personally on the majority of the platforms on which it is intended to run.

For example, a simple Google search will find that Windows IE 5+, Gecko, and Safari all seem to implement the features we need.

However, if you were to run Example E on Safari 1.0, you’d notice a big problem: the effect runs only once! The first time you click in the textbox, the label disappears correctly. But upon blur, nothing happens. The textbox stays blank, and you can never get the label back again.

It turns out that Safari has a bug -- it doesn’t fire onblur for a textbox until the next textbox is focused. In our case, this means that if the user simply tabs or clicks away from the textbox without focusing another textbox, our label will not reappear.

Safari’s problem with onblur is an example of an implementation bug that cannot be tested for through simple feature detection. We will need to update our feature test function to test for the Safari Web browser specifically. The following change will do the trick:

function supportsDynamicLabels() {    
 return      
   document.getElementById &&      
   (window.attachEvent || window.addEventListener) &&      
   null == navigator.appVersion.match(/Safari\/\d+$/);    
}    


The added line uses a Regular Expression to test the appVersion property of the navigator object and return true when the current browser is not Safari.

When testing for a specific browser, it’s often better to test for a specific proprietary property in that browser’s object model. For instance, IE has the window.clientInformation property, which can be used to distinguish it unambiguously from other browsers.

Safari does not seem to support any proprietary properties, however. We must therefore resort to testing the appVersion property of that navigator object. You could also test the userAgent property, but this is less reliable as it can be modified by the users of some browsers.

Example F shows our final work. We’ve successfully transformed our first, badly-behaved dynamic label script into something much better. Our final code is completely modular, doesn’t rely on JavaScript, works well with other scripts, and doesn’t couple to any other components.

During testing, we discovered that Safari has an obscure bug in its handling of focus and blur events on textboxes, which makes it unable to support our effect. We look forward to a release of Safari that fixes this bug, at which time we can easily update our feature test function to test for only the buggy versions.

Most importantly, the five-step process we used to get to this point can easily be applied to any other DHTML effect for a modern Website.

DHTML can be used to supplement the UI of many Web pages, and it can be done so that its support is not required. This style of DHTML coding should not be viewed in the same light as the badly-behaved scripts of the past, but should be considered another worthy tool in the professional Web developer’s arsenal.