Document Object Model (DOM) Requirements
W3C Working Draft 08 February, 2000
- This version:
- Latest version:
- Previous versions:
- Jared Sorensen,
Novell, Inc. (until January 1999)
- Lauren Wood,
SoftQuad Software Inc., chair
- Philippe Le Hégaret,
W3C, staff contact
INRIA, Keio), All Rights Reserved. W3C
document use and
software licensing rules
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 email@example.com. An archive is available at
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.
1. General requirements
1.1. Basic requirements
References to XML and HTML documents generally denote the physical
files that contain structural markup.
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.
The Object Model is language neutral and platform independent.
There will be a core DOM that is applicable to HTML, CSS and XML
The Object Model can be used to construct and deconstruct the
The Object Model will not preclude use by either agents external
to the document content, or scripts embedded within the document.
Consistent naming conventions must be used through all levels of
the Object Model.
A visual UI component will not be required for a conforming
implementation of the Object Model.
The specific HTML, CSS or XML document object models will be driven
by the underlying constructs of those languages.
It must be possible to read in a document and write out a
structurally isomorphic document.
The Object Model will not expose the user to problems with
security, validity, or privacy.
The Object Model will not preclude other mechanisms for
1.2. Error Reporting
Error reporting will be primarily via return values. Exceptions
will be raised on unrecoverable conditions.
The DOM will provide a document-wide reporting mechanism.
[After Level 1]
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
2.1.1. General Requirements
All document content, including elements and attributes, will
be programmatically accessible and manipulable.
Navigation from any element to any other element will be
There will be a way to uniquely and reproducibly enumerate the
structure of static documents.
There will be a way to query for elements and
attributes. [After Level 1]
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.
All elements that are defined in the HTML 4.0 specification are
exposed. User agents may expose other elements using similar
Unknown tags and attributes are exposed.
Implied elements are exposed even if not explicitly defined in
the document (e.g., HTML, HEAD, BODY).
2.2. Document Manipulation
There will be a way to add, remove and change elements and/or
tags in the document structure.
There will be a way to add, remove and change attributes in the
Operations (or a combination of operations) must restore
consistency before they return.
A valid static document acted upon by the DOM will deliver a
consistent reproducible document structure.
2.3. Content Manipulation
There will be a way to determine the containing element from any
text part of the document.
There will be a way to manipulate (add, change, delete) content.
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.
All elements will be capable of generating events.
There will be user interface events, mutation events, and logical
The event delivery mechanism will allow for overriding of default
The event model will provide a mechanism by which events for
specific elements may be received by an ancestor in the DOM
Events may be synchronous.
Events will be defined in a platform independent and language
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.
All style sheets will be represented in the object model.
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.
Selectors, rules and properties of individual style sheets can be
added, removed and changed.
All elements of a CSS style can be added, removed, and changed in
the object model. This includes but is not limited to:
linked style sheets
imported style sheets
alternative style sheets
CSS pseudo-classes and CSS pseudo-elements
all properties as defined in the CSS specification, including
but not limited to font properties, colors, backgrounds, and
3.3. Range model
- Linear view
- allows querying and editing functionality based on a range of text
rather than a subtree of Nodes.
- 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
The DOM Range API should support the following types of operations on
- Creating a Range object
- Extracting text from a Range (with or without markup)
- Inserting, Deleting text inside the Range
- Inserting, Deleting document structure inside the Range
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