#1: Know your browsers
Browser incompatibility is an age-old conflict that has haunted Web developers. However, in many respects, it's becoming less of a concern, as both the browsers and markup languages grow in sophistication. Still, some architectural conflicts do persist, especially if you must be mindful of accessibility concerns with your pages.
For example, not all features of Netscape Navigator and Internet Explorer that work on Windows will work on Mac and UNIX systems. And not all HTML 4.0 code that will run on Internet Explorer 4.0 will run on Navigator 4.0. (Navigator 4.0 did not embrace all the HTML 4.0 pop-up text features.) In addition, <BUTTON> tags are Navigator-unfriendly, and so on. The list is long, even today. So in addition to browser sniffer technologies, you now must be able to use HTML, XHTML, and CSS validators.
#2: Write code that allows for graceful degradation
Cross-platform errors pose a large threat to robust code, but backward compatibility is worse. Despite the best efforts of the software giants, versions preceding the 4.0 releases of both Internet Explorer and Netscape Navigator are still in use everywhere, and your code should run on them—even with your DHTML bells and whistles.
The concept of graceful degradation is applied most commonly in engineering, where it refers to the planned-for gradual failure of a device rather than catastrophic failure. The point is to design a mechanism so that substantial function will be preserved even when environmental circumstances compromise performance. The term is also well applied in software, where a prudent developer anticipates imperfect runtime conditions and codes an application in such a way that partial function is preserved in the face of errors.
This is particularly important when coding Web applications. Consider that any Web page available to the Internet community is asked to run on any number of versions of any number of browsers. By definition, no HTML code will run on every browser; errors are inevitable. Java runs into problems on browsers older than Version 3. Object model features are shaky across otherwise concurrent browser versions. Some Navigator versions will handle ActiveX correctly only with plug-ins. Cascading Style Sheet support is also inconsistent across otherwise concurrent browsers, and so on. Again, the list is long.
A capable designer should not only build robust error-handling into every Web application, taking into account as many environmental variations and potential incompatibilities as possible, but should also code the application to preserve function as much as possible when errors occur.
#3: Externalize code whenever possible
Redundant code is one of the greatest obstacles to writing an easily maintained system. The creation of functions or subroutines is the common programmer’s response, and DHTML allows variations on this theme.
The use of scripts and functions permits the dynamic Web page programmer to bundle common code into easily maintained batches. Of course, this offers the side benefits of easy readability and functional clarity for programmers who will maintain the code later, but this bundling of code serves a greater purpose: Where traditional HTML permits single functions to be assigned to single objects, the dynamic application of embedded scripting and functions enables a particular piece of code to be accessible for many events across many objects.
#4: Make methods, classes, and inheritance work for you
The Dynamic HTML Object Model is a boon to Web designers and permits an object-oriented approach to event-handling that employs all the key features of OOP: the use of classes, methods, and inheritance.
The Dynamic HTML Object Model makes it possible to assign attributes to objects and to set up contingent responses to click events with complete continuity, while leaving clean, easily maintained code in your path. Most versions of most browsers support these object-oriented features, making them easy to implement across platforms and versions.
DHTML’s power tools
Regardless of the power DHTML offers, redundancy, incompatibility between browsers and older versions, poorly placed code, and hard-to-maintain code creep in all too easily. You could be left with a page that is beautiful to behold and frighteningly powerful, given the right version of the right browser—but one that isn’t particularly fault-tolerant and that thousands of users can’t do anything with. The principles described above can help you craft powerful and durable code.
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.