Abstract
This specification evolves HTML and its related APIs to ease the
authoring of Web-based applications. Additions include the context menus,
a direct-mode graphics canvas, inline popup windows, and server-sent
events. Heavy emphasis is placed on keeping the language backwards
compatible with existing legacy user agents and on keeping user agents
backwards compatible with existing legacy documents.
Status of this document
This is a work in progress! This document is changing
on a daily if not hourly basis in response to comments and as a general
part of its development process. Comments are very welcome, please send
them to whatwg@whatwg.org. Thank
you.
The current focus is in developing a first draft proposal.
Implementors should be aware that this specification is not stable.
Implementors who are not taking part in the discussions are likely
to find the specification changing out from under them in incompatible
ways. Vendors interested in implementing this specification
before it eventually reaches the call for implementations should join the
WHATWG mailing list and take part in the
discussions.
This specification is also being produced by the W3C HTML WG. The two specifications
are identical from the table of contents onwards.
Table of contents
1. Introduction
1.1 Background
This section is non-normative.
1.2 Scope
This section is non-normative.
1.3 Relationships to other
specifications
1.3.1 Relationship to HTML5
This section is non-normative.
1.3.2 Relationship to
ECMAScript
This section is non-normative.
All diagrams, examples, and notes in this specification are
non-normative, as are all sections explicitly marked non-normative.
Everything else in this specification is normative.
The key words "MUST", "MUST NOT", "REQUIRED",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the
normative parts of this document are to be interpreted as described in
RFC2119. For readability, these words do not appear in all uppercase
letters in this specification. [RFC2119]
Requirements phrased in the imperative as part of algorithms (such as
"strip any leading space characters" or "return false and abort these
steps") are to be interpreted with the meaning of the key word ("must",
"should", "may", etc) used in introducing the algorithm.
Some conformance requirements are phrased as requirements on attributes,
methods or objects. Such requirements are to be interpreted as
requirements on user agents.
Conformance requirements phrased as algorithms or specific steps may be
implemented in any manner, so long as the end result is equivalent. (In
particular, the algorithms defined in this specification are intended to
be easy to follow, and not intended to be performant.)
The only conformance class defined by this specification is user agents.
User agents may impose implementation-specific limits on otherwise
unconstrained inputs, e.g. to prevent denial of service attacks, to guard
against running out of memory, or to work around platform-specific
limitations.
1.4.1 Dependencies
This specification relies on several other underlying specifications.
- HTML5
-
Many fundamental concepts from HTML5 are used by this specification.
[HTML5]
- ECMAScript
-
This specification is intended to be used with JavaScript as the
scripting language. [JS]
- WebIDL
-
The IDL blocks in this specification use the semantics of the WebIDL
specification. [WebIDL]
1.5 Terminology
For simplicity, terms such as shown, displayed, and
visible might sometimes be used when referring to the way a
document is rendered to the user. These terms are not meant to imply a
visual medium; they must be considered to apply to other media in
equivalent ways.
The construction "a Foo object", where Foo is
actually an interface, is sometimes used instead of the more accurate "an
object implementing the interface Foo".
The term DOM is used to refer to the API set made available to scripts
in Web applications, and does not necessarily imply the existence of an
actual Document object or of any other Node
objects as defined in the DOM Core specifications. [DOM3CORE]
A DOM attribute is said to be getting when its value is being
retrieved (e.g. by author script), and is said to be setting when
a new value is assigned to it.
If a DOM object is said to be live, then that means
that any attributes returning that object must always return the same
object (not a new object each time), and the attributes and methods on
that object must operate on the actual underlying data, not a snapshot of
the data.
References
This section will be written in a future
draft.
Acknowledgements
Thanks to Maciej Stachowiak and Mike Smith for their useful and
substantial comments.
