contents

W3C


Document Object Model (DOM) Requirements

W3C Working Draft 08 February, 2000


This version:
http://www.w3.org/TR/2000/WD-DOM-Requirements-20000208
Latest version:
http://www.w3.org/TR/DOM-Requirements
Previous versions:
http://www.w3.org/TR/1998/WD-DOM-19980416/requirements
http://www.w3.org/TR/WD-DOM/requirements-971009
Editors:
Jared Sorensen, Novell, Inc. (until January 1999)
Lauren Wood, SoftQuad Software Inc., chair
Philippe Le Hégaret, W3C, staff contact

Copyright ©2000 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

Abstract

This specification contains the requirements for the Document Object Model, a platform- and language-neutral interface that allows programs and scripts to dynamically access and update the content, structure and style of documents. The Document Object Model provides a standard set of objects for representing HTML and XML documents, a standard model of how these objects can be combined, and a standard interface for accessing and manipulating them. Vendors can support the DOM as an interface to their proprietary data structures and APIs, and content authors can write to the standard DOM interfaces rather than product-specific APIs, thus increasing interoperability on the Web.

Status of this document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.

This document is a Working Draft of the requirements of the Document Object Model. Comments on this document are invited and are to be sent to the public mailing list www-dom@w3.org. An archive is available at http://lists.w3.org/Archives/Public/www-dom/.

This is still a draft document and may be updated, replaced or obsoleted by other documents at any time. It is therefore inappropriate to use it as reference material or to cite it as other than "work in progress". This is work in progress and does not imply endorsement by, or the consensus of, either W3C or members of the DOM Working Group.

This document has been produced as part of the W3C DOM Activity. The authors of this document are the DOM WG members.

A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR.

Table of Contents

1. General requirements

1.1. Basic requirements

  1. References to XML and HTML documents generally denote the physical files that contain structural markup.
  2. Where possible, the Level of the DOM in which the requirements are met is noted.

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. Error Reporting

  1. Error reporting will be primarily via return values. Exceptions will be raised on unrecoverable conditions.
  2. The DOM will provide a document-wide reporting mechanism. [After Level 1]
  3. The DOM error state can be queried. [After Level 1]

2. DOM Level 1 Requirements

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

2.1.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.
  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. [After Level 1]
  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.

2.1.2. HTML Requirements

These are specific to HTML document.

  1. All elements that are defined in the HTML 4.0 specification are exposed. User agents may expose other elements using similar interfaces.
  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).

2.2. Document Manipulation

  1. There will be a way to add, remove and change elements and/or tags in the document structure.
  2. There will be a way to add, remove and change attributes 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.

2.3. Content Manipulation

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

3. DOM Level 2 Requirements

3.1. Event Model

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 user interface events, mutation events, and logical events.
  3. The event delivery mechanism will allow for overriding of default behavior.
  4. The event model will provide a mechanism by which events for specific elements may be received by an ancestor in the DOM hierarchy.
  5. Events may be synchronous.
  6. Events will be defined in a platform independent and language neutral way.
  7. There will be an interface for binding to events.

3.2. Stylesheet Object Model

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.

3.3. Range model

Linear view
allows querying and editing functionality based on a range of text rather than a subtree of Nodes.
Live
edits on the range modify the underlying tree
Low Level
no parser, no relationship to user agent, no convenience methods or range comparison methods (these would be part of the SmartRange interface)

The DOM Range API should support the following types of operations on ranges:

3.4. Traversal model

The DOM Traversal API should be able to see a filtered view without comments or entity references, and to have an iterator robust under mutation.

contents