1. Document Object Model Requirements

Editors

Jared Sorensen, Novell, Inc.
Lauren Wood, SoftQuad, Inc.

This document defines the high-level requirements for the Document Object Model (DOM). It is part of the Document Object Model Specification .


1.1. General Requirements

  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].

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 isomorphic document.
  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.

1.2. 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.

1.2.1. 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.

1.2.2. 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.


1.3. 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 (or a combination of operations) must restore consistency before they return.
  4. A valid static document acted upon by the DOM will deliver a consistent reproducible document structure.

1.4. 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.

1.5. 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. The event model will provide a mechanism by which events for specific elements may be received by an ancestor in the DOM hierarchy.
  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.

1.6. 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.

1.7. 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).

1.8. 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.

1.9. Security, Validity and Privacy [After Level 1]

Security, validity, and privacy considerations are interrelated and entwined. DOM will initially 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. An external security API will be provided.

1.10. Document Meta Information

These are requirements for information about the document.

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

1.11. 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.