Document Object Model Requirements

W3C Working Draft 2-September-97

This version:
Latest Version:
Previous Version:


Status of This Document

This draft is work under review by the W3C DOM Working Group, for use in an upcoming version of the Document Object Model specification. Please remember this is subject to change at any time, and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress".

A list of current W3C Working Drafts can be found at http://www.w3.org/TR.

Public discussion of the Document Object Model, including discussion of this draft, takes place on www-dom@w3.org. To subscribe send a message to www-dom-request@w3.org with the word "subscribe" in the subject line.

This document defines the high-level requirements for the Document Object Model (DOM). The requirements are categorized as follows:


  1. References to XML and HTML documents generally denote the physical files that contain structural markup.
  2. Some requirements are not implemented in DOM Level 1. Those requirements are identified in this document with the notation [After Level 1].

General Requirements

Listed below are the general requirements of the Document Object Model.

  1. The Object Model is language neutral and platform independent.
  2. There will be a core DOM that is applicable to HTML, CSS and XML documents.
  3. The Object Model can be used to construct and deconstruct the document.
  4. The Object Model will not preclude use by either agents external to the document content, or scripts embedded within the document.
  5. Consistent naming conventions must be used through all levels of the Object Model.
  6. A visual UI component will not be required for a conforming implementation of the Object Model.
  7. The specific HTML, CSS or XML document object models will be driven by the underlying constructs of those languages.
  8. It must be possible to read in a document and write out a structurally identical document to disk (both documents can be represented by the same raw structural model).
  9. The Object Model will not expose the user to problems with security, validity, or privacy.
  10. The Object Model will not preclude other mechanisms for manipulating documents.

Structure Navigation

This refers to the navigation around a document, such as finding the parent of a given element, or what children elements a given parent element contains.

General Requirements

  1. All document content, including elements and attributes, will be programmatically accessible and manipulable.
  2. Navigation from any element to any other element will be possible, except where such navigation would compromise security.
  3. There will be a way to uniquely and reproducibly enumerate the structure of static documents.
  4. There will be a way to query for elements and attributes, subject to security and privacy considerations.
  5. Basic low-level functions (get first, get next, etc.) will be provided, along with convenience functions that build upon them, but have a consistent access method.

HTML Requirements

These are specific to HTML documents.

  1. All elements known to the user agent are exposed.
  2. Unknown tags and attributes are exposed.
  3. Implied elements are exposed even if not explicitly defined in the document (e.g., HTML, HEAD, BODY)
  4. There will be guidelines for the inclusion of new elements and attributes in the object model

Document Manipulation

  1. There will be a way to add, remove and change elements and/or tags (if permitted by the Document Type Definition and not precluded by security or validity considerations) in the document structure.
  2. There will be a way to add, remove and change attributes (if permitted by the Document Type Definition and not precluded by security or validity considerations) in the document structure.
  3. Operations must restore consistency before they return.
  4. A valid static document acted upon by the DOM will deliver a consistent reproducible document structure.

Content Manipulation

  1. There will be a way to determine the containing element from any text part of the document (subject to security considerations).
  2. There will be a way to manipulate (add, change, delete) content.
  3. There will be a way to navigate content.

Event Model [After Level 1]

The event model must be rich enough to create completely interactive documents. This requires the ability to respond to any user action that may occur on the document. Therefore, many of these requirements only apply if a UI component is involved.

  1. All elements will be capable of generating events.
  2. There will be interaction events, update events, and change events.
  3. The event model will allow responses to user interactions.
  4. The event delivery mechanism will allow for overriding of default behavior.
  5. Events will bubble through the structural hierarchy of the document.
  6. Events are synchronous.
  7. Events will be defined in a platform independent and language neutral way.
  8. There will be an interface for binding to events.

Stylesheet Object Model [After Level 1]

Cascading Style Sheets (CSS) is one model for manipulating the style of the document. The Stylesheet Object Model exposes the ability to create, modify, and associate CSS style sheets with the document. The stylesheet model will be extensible to other stylesheet formats in the future.

  1. All style sheets will be represented in the object model.
  2. There will be a CSS stylesheet model. The CSS object model will be defined as part of a stylesheet embedding model, where the core part of the model may be applicable to other style languages.
  3. Selectors, rules and properties of individual style sheets can be added, removed and changed.
  4. All elements of a CSS style can be added, removed, and changed in the object model. This includes but is not limited to:
    1. linked style sheets
    2. imported style sheets
    3. alternative style sheets
    4. CSS pseudo-classes and CSS pseudo-elements
    5. contextual selectors
    6. inline styles
    7. All properties as defined in the CSS specification, including but not limited to font properties, colors, backgrounds, and box properties.

DTD Manipulation

  1. [After Level 1] There will be a way to determine the presence of a DTD.
  2. There will be a way to query declarations in the underlying DTD (if available).
  3. [After Level 1] There will be a way to add, remove, and change declarations in the underlying DTD (if available).
  4. [After Level 1] There will be a way to test conformance of all or part of the given document against a DTD (if available). (See Document Manipulation, item 3).

Error Reporting

  1. The DOM will provide a document-wide error logging and reporting mechanism.
  2. Error reporting will be primarily via exceptions.
  3. The DOM error state can be queried.

Security, Validity and Privacy

Security, validity, and privacy considerations are interrelated and entwined. DOM Level 1 will provide simple "sandbox" security; subsequent levels are expected to incorporate more sophisticated mechanisms.

  1. Each object must be responsible for maintaining its own internal consistency.
  2. It must be safe to have multiple threads operating on the same object.
  3. Object locking must be incorporated to ensure consistent results.
  4. It must be possible to prevent scripts on one page from accessing another page.
  5. Firewall boundaries must be respected.
  6. It must be possible to restrict access and navigation to specific elements.
  7. [After Level 1] An external security API will be provided.

Document Meta Information

These are requirements for what must be exposed about the document:

  1. There will be information about the document and its embedded objects such as source location, date created, and associated cookies.

UA Information

These are requirements for information about the user agent environment, if applicable

  1. There will be a way of obtaining relevant information about the display environment, including the UA brand information and version number, and, where appropriate, the HTTP header.
  2. [After Level 1] A way of determining support for a MIME type will be available.

Editors: Lauren Wood, Jared Sorensen
Chair of the W3C DOM WG: Lauren Wood
W3C staff contact: Arnaud Le Hors
$Date: 1997/08/09 17:44:05 $