Document Object Model Requirements
September 2, 1997
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
Public discussion of the Document Object Model, including discussion of
this draft, takes place on email@example.com.
To subscribe send a message to
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:
- References to XML and HTML documents generally denote the physical
files that contain structural markup.
- Some requirements are not implemented in DOM Level 1. Those
requirements are identified in this document with the notation [After
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
- 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 identical document to disk (both documents can be
represented by the same raw structural model).
- The Object Model will not expose the user to problems with security,
validity, or privacy.
- The Object Model will not preclude other mechanisms for manipulating
This refers to the navigation around a document, such as finding the
parent of a given element, or what children elements a given parent
- All document content, including elements and attributes, will be
programmatically accessible and manipulable.
- Navigation from any element to any other element will be possible,
except where such navigation would compromise security.
- 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, subject to
security and privacy considerations.
- 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.
These are specific to HTML documents.
- All elements known to the user agent are exposed.
- Unknown tags and attributes are exposed.
- Implied elements are exposed even if not explicitly defined in the
document (e.g., HTML, HEAD, BODY)
- There will be guidelines for the inclusion of new elements and
attributes in the object model
- 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.
- 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.
- Operations must restore consistency before they return.
- A valid static document acted upon by the DOM will deliver a
consistent reproducible document structure.
- There will be a way to determine the containing element from any text
part of the document (subject to security considerations).
- There will be a way to manipulate (add, change, delete) content.
- There will be a way to navigate content.
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 interaction events, update events, and change events.
- The event model will allow responses to user interactions.
- The event delivery mechanism will allow for overriding of default
- Events will bubble through the structural hierarchy of the document.
- Events are synchronous.
- Events will be defined in a platform independent and language neutral
- There will be an interface for binding to events.
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
- contextual selectors
- inline styles
- All properties as defined in the CSS specification, including but
not limited to font properties, colors, backgrounds, and box
- [After Level 1] There will be a way to determine
the presence of a DTD.
- There will be a way to query declarations in the underlying DTD (if
- [After Level 1] There will be a way to add, remove,
and change declarations in the underlying DTD (if available).
- [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).
- The DOM will provide a document-wide error logging and reporting
- Error reporting will be primarily via exceptions.
- The DOM error state can be queried.
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
- Each object must be responsible for maintaining its own internal
- It must be safe to have multiple threads operating on the same
- Object locking must be incorporated to ensure consistent results.
- It must be possible to prevent scripts on one page from accessing
- Firewall boundaries must be respected.
- It must be possible to restrict access and navigation to specific
- [After Level 1] An external security API will be
These are requirements for what must be exposed about the document:
- There will be information about the document and its embedded objects
such as source location, date created, and associated cookies.
These are requirements for information about the user agent environment,
- 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.
- [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
1997/08/09 17:44:05 $