 |  |
| |
As a further complication, there are the inevitable prerelease versions of browsers and standards. Browser prereleases are sometimes called "preview editions" or "beta" versions. While not officially released, these versions give you a chance to see what new functionality will be available for content display in the next-generation browsers. Authors who follow browser releases closely sometimes worry when certain aspects of their current pages fail to work properly in prerelease versions. The fear is that the new version of the browser is going to break a carefully crafted masterpiece that runs flawlessly in released versions of the browser.
Prerelease browsers are valuable resources for content developers. On the one hand, testing existing content on a preview release allows you to uncover bugs in the browser before the browser is released. Report those bugs! Wherever possible, provide a simple test case (or link to a test case) that proves the bug so that the browser engineers can see exactly what you mean and test their fixes against real code. On the other hand, testing may allow you to learn about the rare case in which a feature you rely on is removed or changed (usually to meet a standard definition). While browsers tend to be backward compatible with previous versions, many developers were caught unaware when Netscape 6, in its effort to adopt industry standards, completely dropped support for a couple of features implemented in the previous version (Netscape 4). Developers who tested preview versions of the browser would have learned of this important change early in the process, and planned for the new deployment ahead of time.
Avoid the urge, however, to modify your public HTML or scripting code to accommodate what may be a temporary bug in a prerelease version of a browser. Any page visitor who uses a prerelease browser does so at his own risk. If your pages are breaking on that browser, they're probably not the only ones on the Web that are breaking. A user of a prerelease browser must understand that using such a browser for mission-critical web work is as dangerous as entrusting one's life work to a beta version of a word processing program.
On the standards side, working groups usually publish prerelease (draft) versions of their standards. These documents are very important to the people who build browsers and authoring tools. The intent of publishing a working draft is not much different from making a prerelease browser version public. The goal is to get as many concerned netizens as possible looking over the material to find flaws or shortcomings before the standard is published.
Speaking of standards, it is important to recognize that the final releases of these documents from standards bodies are called not "standards" but "recommendations." You will also find details within a recommendation that are optional, thus allowing a browser maker to claim full compliance, even when not every feature is implemented.
No law or contract forces browser makers to implement the recommendations. Fortunately, from a marketing angle, it plays well to the web audience that a company's browser adheres to the "standards." Eventually—after enough release cycles of both standards and browsers allow everyone to catch up with each other—our lives as content creators should become easier.
In the meantime, the following sections provide a snapshot of the various standards, and their implementation in browsers, as they relate to the technologies that affect DHTML.
|  | |
| 1. The State of the Art |  | 1.3. HTML |
Copyright © 2003 O'Reilly & Associates. All rights reserved.