Despite the logic behind the modularization of these key DHTML-related standards, content authors must be vigilant about how web software makers portray their products' conformance with the standards. You should also be aware of the wiggle room that the standards themselves occasionally build into their specification documents.
There can be quite a bit of distance between a browser's claim to support a particular W3C standard and the details surrounding that support. For example, a product's shorthand marketing description may indicate support for the W3C DOM standard, when, in truth, not every module is implemented or implemented in full. Only a thorough study of the developer documentation for the product (and sometimes not even that) can reveal more specifically which elements, attributes, objects, properties, and methods are implemented. The more modules that are defined for a standard, the less likely it is that a web product will truly support every module. You might even wonder if the software makers who participated in the W3C working groups eagerly promoted modularization so they could pick and choose which modules to support, while still claiming standards compliance. That way they could claim support for the modules they wanted to adopt (or had already adopted), while ignoring others, either due to technical challenges or conflicts with their home-grown version of the standard.
If you plan to mold your development around the published recommendations, you really need to study the fine print in the standards documents. As some of the standards grow in size, the modifiers "may" and "optional" become more common. If a feature is listed as optional, a software maker can still claim conformance, even though you won't find that feature implemented. Standards increasingly focus on common denominator functionality, which means that esoterica is more likely to be listed as optional.
In the end, successful DHTML development still requires a strong working knowledge of standards-based and proprietary features supported by your target browsers. At the same time, however, you have little to lose by holding your deployments close to the core modules for all standards. These tend to provide the features that let your DHTML add value to otherwise static content in a way that seems natural, so that the user isn't even aware of the scripts and gizmos operating on the other size of the computer monitor glass.
Copyright © 2003 O'Reilly & Associates. All rights reserved.