Document Object Model Requirements
October 2, 1997
Document Object Model Requirements
Lauren Wood, Jared Sorensen
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 email@example.com. To subscribe send a message to firstname.lastname@example.org with the word "subscribe" in the subject line.
This document defines the high-level requirements for the Document Object Model (DOM). 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 Level 1].
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 documents.
- The Object Model can be used to construct and deconstruct the document.
- 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 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 documents.
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.
- 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.
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.
- 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 behavior.
- Events will bubble through the structural hierarchy of the document.
- Events are synchronous.
- Events will be defined in a platform independent and language neutral way.
- 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.
- 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
- [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 available).
- [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 mechanism.
- Error reporting will be primarily via exceptions.
- 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.
- Each object must be responsible for maintaining its own internal consistency.
- It must be safe to have multiple threads operating on the same object.
- Object locking must be incorporated to ensure consistent results.
- It must be possible to prevent scripts on one page from accessing another page.
- Firewall boundaries must be respected.
- It must be possible to restrict access and navigation to specific elements.
- [After Level 1] An external security API will be provided.
Document Meta Information
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, if applicable:
- 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.
About the Authors
- Lauren Wood
- Technical Product Manager
- SoftQuad, Inc.
- 108-10070 King George Hwy
- Surrey B.C. Canada V3T 2W4
Lauren Wood is Technical Product Manager at SoftQuad, Inc., one of the leading vendors of Internet, Intranet, and SGML document solutions. She plays a major role in the design of SoftQuad's authoring tools, as well as taking part in various technical committees, such as the W3C HTML Working Group, the CSS and Formatting Properties Working Group, and the XML Working Group. She chairs the W3C Document Object Model Working Group. Lauren holds a Ph.D. in theoretical nuclear physics from the University of Melbourne, Australia.
- Jared N. Sorensen
- Manager, Documentation Products Group
- Novell, Inc.
- 1555 N. Technology Way
- M/S ORM-Q354
- Orem, UT 84097
Jared N. Sorensen manages documentation engineering efforts at Novell, Inc. He is also the webmaster of the Novell Product Documentation Web site, one of the largest on the World Wide Web. Mr. Sorensen is Novell's representative on three working groups of the W3C: DOM, CSS, and HTML. An accomplished programmer, linguist, and technical writer, he has worked in management capacities for several software development companies and has been a popular speaker at publishing conferences around the world.