 |  |
| |
W3C Modularization
XHTML Modularization (XHTML Basic and 1.1)
CSS Modularization (CSS3)
DOM Modularization (DOM2 and DOM3)
What Is Conformance?
As more surfers and new browsers wend their way around the World Wide Web, the installed base of browsers becomes more and more fragmented—even when one browser brand appears to dominate the scene. Fragmentation occurs because users choose not to upgrade to the latest browser version and organizations prohibit individuals from upgrading beyond a corporate standard that may be one or two generations old. This makes the job of adopting new W3C standards difficult, for both web browser makers and page authors.
Regardless of the latest browser bells and whistles or the "preferred" way to apply certain content constructs, many thousands of web pages on the Net use techniques long gone from the standards documents. Web browser makers bear the burden of this "ancient" baggage, as their browsers (with rare exception) continue to be backward compatible with earlier technologies. Unfortunately, this continued support can lead casual page authors to believe that the old ways are just fine, so they have little incentive to use the latest techniques. Conversely, a tuned-in content author who blindly follows standards—essentially treating the standards as platforms—may be even more foolhardy, because browser makers haven't caught up with the standards or have implemented them oddly in the early development stages.
Demands from managers or clients that a web presentation be 100% standards-compliant and validated may derive from good intentions, but the browser world—particularly for public web sites—doesn't necessarily live under the same blue sky. DHTML programmers must frequently defend workarounds and compromises necessitated by less-than-perfect standards support even in the latest and most popular browsers.
Like it or not, adding Dynamic HTML to your content means that you should look to the browsers as they exist in the real world, warts and all, as your development platforms. DHTML authors have begged for industry standards, especially for the DOM, for years. And now that these standards are filling out and solidifying, we're only somewhat better off than before, primarily because the standards are not yet thoroughly and uniformly implemented in a critical mass of installed browsers. And, as indicated by the questions I raised at the end of Chapter 6, it's impossible to predict if or when that day will come.
As content creators, we must strike a balance between coding for "what is" and planning for "what we think will be." If you believe that the future is largely standards-based (an underlying theme of the previous chapters) and XML-oriented, it's not too soon to begin aligning your content, code, and even authoring process with W3C and ECMA standardization trends. The purpose of this chapter is to acquaint you with the not-too-distant look of the W3C standards on which your content is based. If nothing else, this exploration may help you understand how and why future browser versions implement the standards as they do. The fundamental threads of this discussion focus on modularization and could be called implementation "wiggle room."
The longer you have been involved with development platforms, the more likely it is that you've seen this scenario before: a platform becomes very popular, but for any number of valid reasons, it doesn't contain all the functionality that developer groups desire. Rather than risk alienating devoted fans by holding back progress or overloading the platform with tons of features of limited scope, the platform evolves into an extensible one that provides a sound foundation upon which developers can build their own special-purpose add-ons, yet still claim conformance with the foundation technology. Turning what had been a static system into an extensible one takes considerable effort, so that all sects are satisfied with both the foundation and the extensibility mechanism.
Extensibility (the "X" in so many of the web standards' names) is a primary driving force behind the modularization of popular W3C standards: HTML/XHTML, CSS, and DOM. But other factors are also behind this movement. While many standards expanded to meet advances in day-to-day technologies—the prevalence of graphical user interfaces (GUIs) is a good example—they grew to enormous proportions. At the same time, however, new web content delivery vehicles, such as new generation cellular telephones, shirt-pocket-sized computers, and audio-only content readers, couldn't possibly take advantage of all the big-screen GUI standards. To include support for DHTML scripting in a small-screen cell phone browser may very likely be a waste of limited ROM and RAM resources. The maker of an audio-only browser might want omit support for color style setting or extend the color style standards so that the colors could include additional meaning that is translated into spoken text or background sound when loaded into its client.
On the standards development side, modularization has the potential to make it easier to improve segments of a larger standard, without requiring a major upgrade of the entire standard. Even more likely, if an entirely new technology comes on the scene, a standard module based on that technology can be developed independently of the larger standard, and then embraced as a new module of an existing standard when the module is adopted as a formal recommendation.
The initial modularization of the XHTML, CSS, and DOM recommendations represent major transitions for these standards. The impact of this direction on your DHTML authoring will be minimal, at first, because the major browsers you support will implement everything and the kitchen sink to maintain compatibility with tons of existing content on the Web. But when you learn about what constitutes standards conformance in a modular world, you may reconsider some of your design assumptions going forward.
|  | |
| 6.8. Event Futures |  | 7.2. XHTML Modularization |
Copyright © 2003 O'Reilly & Associates. All rights reserved.