Back in the grand old days of linear programming, one of my IT mentors told me something I've never forgotten: "The easiest code in the world to write is bad code." It was true then; it is even truer in our nonlinear, object-ridden age, when programs are so multifunctional and cross-platformed. We just don't think about it as much because object-oriented programming is, in general, so robust and forgiving of error. It's possible, even easy, to write embarrassingly bad code that runs just fine. But this is no excuse for sloppy work. (Wait till someone tries to upgrade that sloppy app that "runs just fine.") And the rapid acceleration of Web growth heralds an end to the forgiveness of object code. Web pages themselves must, in these dynamic times, be ridiculously cross-platformed. And therein lies danger for the DHTML programmer. DHTML coding commandments
You need to avoid a couple of pitfalls when writing for Web applications. First, HTML code, and DHTML code in particular, must function consistently on multiple Web browsers and on multiple versions of those browsers. Second, where compatibility is not possible, a properly written Web app shouldn't crash but should fail gradually, preserving as much function as possible. We're going to look at some coding guidelines to help you meet these goals. Before we get underway, however, a note of caution: Applying these coding principles can't help but enhance your Web apps, but it's not so easy to actually apply them. They build on one another, so attention to detail is essential, over and above committing to the general principles to begin with. And since the "dynamic" in DHTML covers a number of Web technologies -- scripting, style sheets, and the DOM, to name the big ones -- they must be applied case by case. The art of browser-sniffing
An essential first step in writing robust DHTML is building browser detection into your code and writing conditional variations on your critical functions so that your pages will have full functionality across a broad spectrum of browsers. It's true that this is a lot easier since more current Web development packages anticipate newer versions of the most prominent browsers. But it's better in the long run if you anticipate a broad audience for your pages, going a little more native and using browser-detection techniques from the earlier days. Your apps are then more certain to work correctly on older systems. It's tempting to approach a DHTML project with nothing more than the latest Internet Explorer and Netscape Navigator in mind. But the browser world is much broader than this. At last count, more than 200 browsers were in broad deployment, including lesser-used browsers that don't support graphics (Lynx, for example) and browsers that run on operating systems other than Windows and Mac. Hundreds of thousands of copies of earlier releases of Internet Explorer and Netscape Navigator are also still in service, and these may not support all the features that you intend to use in your application.