Today, the W3C is organized in terms of several activity domains: HTML, which includes HTML markup and specifications; Cascading Style Sheets; and the Document Object Model fall within the W3C User Interface (UI) domain. Since Dynamic HTML interweaves all three of these topics, DHTML also falls within the UI domain at the W3C.
Because DHTML has come into the game rather later than either Microsoft or Netscape, the only meaningful work thats been published by the W3C on DHTML currently concerns the DOM. It already appears that the W3C seeks to implement a standard for a complete and thorough-going document object model. The DOMs included in vendor-specific browsers will have to comply with this specification to be W3C compliant. It also intends to make sure that this DOM specification covers not only HTML and CSS, but that it covers the needs of the emerging eXtensible Markup Language (XML) as well. Because XML represents a powerful, open-ended middle-point between HTML and SGML, this means that the W3Cs notion of a DOM must itself be extremely flexible and open-ended.
As of late 1997, the DOM specification is something that the W3C calls a working draft, which means that the specification is intended as a snapshot of current thinking, rather than a conclusive or definitive statement on the subject. Because this means the draft will undergo numerous revisions before it attains either Recommendation or Specification status (which is not expected to occur before mid-1998), its important to understand that whatever conclusion anyone might draw based on this document should be considered tentative, rather than authoritative. In other words, DHTML is still very much a moving target, as far as its standardization goes!
That said, we can still make
some general observations based on this working draft. Plenty of material
exists thats worth discussing, even though it may only indicate
the W3Cs tendencies where DHTML is concerned. To learn more about
the W3Cs work in this area, and read the working draft for yourself,
please visit this Web page:
The W3Cs working-draft DOM document begins with a set of requirements for a workable DOM, and then covers issues related to core document structure and navigation, followed by a discussion of structure and navigation specific to HTML and XML.
The requirements are of particular interest here, because they show the direction of the W3Cs thinking about document object models most directly. We paraphrase these requirements in list form to make them as short and palatable as possible; our apologies to the experts who worked so hard on the details that were about to so cheerfully ignore.
Heres our summation of the current requirements.
According to the W3C, a Document ObjectModel must have the following characteristics:
The rest of the working draft is broken into numerous subdocuments and sections, each of which addresses various topics. Instead of paraphrasing in great detail, we cover only those elements that pertain to dynamic HTML.
One key aspect of the W3C DOM is its ability to address and operate on any element in a document represented according to the model. This permits browsers and other programs (especially scripts and on-the-fly document generators) to access and change any element within a document, plus associated style information and even governing DTDs. The specification also covers a set of core primitives that are assumed to be available to get and alter document elements and attributes. Such primitives include operates like get and set, plus further elaborations like get first, get next, get where type=xx, and so on.
The W3C DOM also includes an event model designed to support user interaction, and even includes some abilities to respond to user input and selections while a document and its components are still being downloaded. This specification includes a series of messages and status codes that indicate what kinds of events are occurring, and provides a platform-neutral way to tell the browser what the user is up to at any given moment. Responses to user interactions are also covered, and include the ability to assign default actions, to override defaults, and to take conditional action based on a combination of document content and user input.
At the Document Type Definition (DTD) level, assignment or detection of a governing DTD will fall under the DOMs control. If an explicit DTD is referenced, it can also be incorporated into the DOM - where it can be navigated and manipulated in much the same way as the underlying document. The model even includes methods to request document validation according to a DTD, to make sure that documents are well-formed or complete, according to the markup language in use.
The DOM finally adds a consistent error-handling mechanism to Web environment and defines a set of messages to report and log errors as they occur. The DOM maintains an internal set of error-status information and is able to report on a documents error status at any time. This capacity of the DOM will greatly improve error handling, as compared to current HTML and CSS implementations, which have no consistent error reporting or handling capabilities beyond the numeric error codes associated with HTTP.
Finally, the DOM does its best to capture and deliver descriptive information about documents to the browser:
The DOM requires that documents supply metadata about themselves and states its assumptions about governing DTDs for HTML when no SGML preamble is supplied with a document. But metadata can also include things like a documents author information, creation and modification dates, and associated data packages such as cookies.
The DOM defines mechanisms to obtain information about a users browser and display environment, so that the Web page designer can query on this information and take local conditions into account.
DOM requests local checks to determine exactly which MIME types are supported, so it can decide what kinds of data the local browser can handle.
The primary thrust of the W3C specification for the DOM is to deliver a documents contents, structure, and properties for easy inspection and manipulation, and to support on-the-fly modification of such documents. Given the additional specification of an event model, and an ability to recognize and respond to events, the DOM facilitates a truly dynamic view of user interaction. We believe that the work of the W3C work will create a new vision of HTML documents, in which they readily transform themselves to fit their users desktops and also to respond to user input and events. These capabilities should make the Web much more of a two-way street in the future than it is today.
Extra 3 Main Page | Previous Section | Next Section
E-mail: HTML For Dummies
Webmaster: Natanya Pitts, LANWrights
Revised -- January 16, 1998