This section is non-normative.
The World Wide Web's markup language has always been HTML. HTML was primarily designed as a language for semantically describing scientific documents, although its general design and adaptations over the years has enabled it to be used to describe a number of other types of documents.
The main area that has not been adequately addressed by HTML is a vague subject referred to as Web Applications. This specification attempts to rectify this, while at the same time updating the HTML specifications to address issues raised in the past few years.
This section is non-normative.
This specification is limited to providing a semantic-level markup language and associated semantic-level scripting APIs for authoring accessible pages on the Web ranging from static documents to dynamic applications.
The scope of this specification does not include
concerns (although default rendering
rules for Web browsers are included at the end of this specification).
The scope of this specification does not include documenting
every HTML or DOM feature supported by Web browsers. Browsers
support many features that are considered to be very bad for
accessibility or that are otherwise inappropriate. For example, the
blink element is clearly presentational and authors
wishing to cause text to blink should instead use CSS.
The scope of this specification is not to describe an entire operating system. In particular, hardware configuration software, image manipulation tools, and applications that users would be expected to use with high-end workstations on a daily basis are out of scope. In terms of applications, this specification is targeted specifically at applications that would be expected to be used by users on an occasional basis, or regularly but from disparate locations, with low CPU requirements. For instance online purchasing systems, searching systems, games (especially multiplayer online games), public telephone books or address books, communications software (e-mail clients, instant messaging clients, discussion software), document editing software, etc.
For sophisticated cross-platform applications, there already exist several proprietary solutions (such as Mozilla's XUL, Adobe's Flash, or Microsoft's Silverlight). These solutions are evolving faster than any standards process could follow, and the requirements are evolving even faster. These systems are also significantly more complicated to specify, and are orders of magnitude more difficult to achieve interoperability with, than the solutions described in this document. Platform-specific solutions for such sophisticated applications (for example the MacOS X Core APIs) are even further ahead.
This section is non-normative.
This specification represents a new version of
HTML4 and XHTML1, along with a new version of the associated DOM2
HTML API. Migration from HTML4 or XHTML1 to the format and APIs
described in this specification should in most cases be
straightforward, as care has been taken to ensure that
backwards-compatibility is retained.
This specification will eventually supplant Web Forms 2.0 as well. [WF2]
This section is non-normative.
XHTML2 [XHTML2] defines a new HTML vocabulary with better features for hyperlinks, multimedia content, annotating document edits, rich metadata, declarative interactive forms, and describing the semantics of human literary works such as poems and scientific papers.
However, it lacks elements to express the semantics of many of the non-document types of content often seen on the Web. For instance, forum sites, auction sites, search engines, online shops, and the like, do not fit the document metaphor well, and are not covered by XHTML2.
This specification aims to extend HTML so that it is also suitable in these contexts.
XHTML2 and this specification use different namespaces and therefore can both be implemented in the same XML processor.
This section is non-normative.
This specification is independent of the various proprietary UI
languages that various vendors provide. As an open,
vender-neutral language, HTML provides for a
solution to the same problems without the risk of vendor
This section is non-normative.
This specification is divided into the following important sections:
There are also a couple of appendices, defining
shims for WYSIWYG editors , rendering rules for Web browsers, and
listing areas that are out of scope for this
This specification should be read like all other specifications. First, it should be read cover-to-cover, multiple times. Then, it should be read backwards at least once. Then it should be read by picking random sections from the contents list and following all the cross-references.
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",
"SHALL", "SHALL NOT", "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.
This specification describes the conformance criteria for user agents (relevant to implementors) and documents (relevant to authors and authoring tool implementors).
There is no implied relationship between document conformance requirements and implementation conformance requirements. User agents are not free to handle non-conformant documents as they please; the processing model described in this specification applies to implementations regardless of the conformity of the input documents.
User agents fall into several (overlapping) categories with different conformance requirements.
Web browsers that support XHTML must process elements and attributes from the HTML namespace found in XML documents as described in this specification, so that users can interact with them, unless the semantics of those elements have been overridden by other specifications.
A conforming XHTML processor would, upon finding
script element in an
XML document, execute the script contained in that element.
However, if the element is found within an XSLT transformation
sheet (assuming the UA also supports XSLT), then the processor
would instead treat the
element as an opaque element that forms part of the transform.
Web browsers that support HTML must process documents
text/html as described in this specification, so that
users can interact with them.
User agents that process HTML and XHTML documents purely to render non-interactive versions of them must comply to the same conformance criteria as Web browsers, except that they are exempt from requirements regarding user interaction.
Typical examples of non-interactive presentation user agents are printers (static UAs) and overhead displays (dynamic UAs). It is expected that most static non-interactive presentation user agents will also opt to lack scripting support .
A non-interactive but dynamic presentation UA would still execute scripts, allowing forms to be dynamically submitted, and so forth. However, since the concept of "focus" is irrelevant when the user cannot interact with the document, the UA would not need to support any of the focus-related DOM APIs.
Implementations that do not support scripting (or which have
their scripting features disabled
are exempt from supporting
the events and DOM interfaces mentioned in this specification. For
the parts of this specification that are defined in terms of an
events model or in terms of the DOM, such user agents must still
act as if events and the DOM were supported.
Scripting can form an integral part of an application. Web browsers that do not support scripting, or that have scripting disabled, might be unable to fully convey the author's intent.
Conformance checkers must verify that a document conforms to the
applicable conformance criteria described in this specification.
Conformance checkers are exempt from
detecting errors that require interpretation of the author's intent
(for example, while a document is non-conforming if the content of
blockquote element is not
a quote, conformance checkers do not have to check that
blockquote elements only
contain quoted material).
Conformance checkers must check that the input document conforms
and should also check that
the input document conforms when scripting is
(This is only a
"SHOULD" and not a "MUST" requirement because it has been proven to
be impossible. [HALTINGPROBLEM] )
The term "HTML5 validator" can be used to refer to a conformance checker that itself conforms to the applicable requirements of this specification.
XML DTDs cannot express all the conformance requirements of this specification. Therefore, a validating XML processor and a DTD cannot constitute a conformance checker. Also, since neither of the two authoring formats defined in this specification are applications of SGML, a validating SGML system cannot constitute a conformance checker either.
To put it another way, there are three types of conformance criteria:
A conformance checker must check for the first two. A simple DTD-based validator only checks for the first class of errors and is therefore not a conforming conformance checker according to this specification.
Applications and tools that process HTML and XHTML documents for reasons other than to either render the documents or check them for conformance should act in accordance to the semantics of the documents that they process.
A tool that generates document outlines but increases the nesting level for each paragraph and does not increase the nesting level for each section would not be conforming.
Authoring tools and markup generators must generate conforming documents. Conformance criteria that apply to authors also apply to authoring tools, where appropriate.
Authoring tools are exempt from the strict requirements of using elements only for their specified purpose, but only to the extent that authoring tools are not yet able to determine author intent.
For example, it is not conforming to use an
address element for arbitrary
contact information; that element can only be used for marking up
contact information for the author of the document or section.
However, since an authoring
is likely unable to determine the
difference, an authoring tool is exempt from that requirement.
In terms of conformance checking, an editor is therefore required to output documents that conform to the same extent that a conformance checker will verify.
When an authoring tool is used to edit a non-conforming
document, it may preserve the conformance errors in sections of the
document that were not edited during the editing session (i.e. an
editing tool is allowed to round-trip
content). However, an authoring tool must not claim that the output
is conformant if errors have been so preserved.
Authoring tools are expected to come in two broad varieties: tools that work from structure or semantic data, and tools that work on a What-You-See-Is-What-You-Get media-specific editing basis (WYSIWYG).
The former is the preferred mechanism for tools that author HTML, since the structure in the source information can be used to make informed choices regarding which HTML elements and attributes are most appropriate.
However, WYSIWYG tools are
and this specification makes
certain concessions to WYSIWYG editors .
All authoring tools, whether WYSIWYG or not, should make a best effort attempt at enabling users to create well-structured, semantically rich, media-independent content.
Some conformance requirements are phrased as requirements on
elements, attributes, methods or objects. Such requirements fall
categories; those describing content model
restrictions, and those describing implementation behaviour.
The former category of requirements are requirements on documents
and authoring tools. The second category are requirements on user
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.)
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.
For compatibility with existing content and prior specifications, this specification describes two authoring formats: one based on XML (referred to as XHTML5 ), and one using a custom format inspired by SGML (referred to as HTML5 ). Implementations may support only one of these two formats, although supporting both is encouraged.
Such XML documents may contain a
desired, but this is not required to conform to this
According to the XML specification, XML processors
are not guaranteed to process the external DTD subset referenced in
the DOCTYPE. This means, for example, that using
entities for characters in XHTML documents is unsafe
(except for <, >,
'). For interoperability,
authors are advised to avoid optional features of XML.
The language in this specification assumes that the user agent expands all entity references, and therefore does not include entity reference nodes in the DOM. If user agents do include entity reference nodes in the DOM, then user agents must handle them as if they were fully expanded when implementing this specification. For example, if a requirement talks about an element's child text nodes, then any text nodes that are children of an entity reference that is a child of that element would be used as well.
A lot of arrays/lists/ collection s in this spec assume zero-based indexes but use the term " index th" liberally. We should define those to be zero-based and be clearer about this.
other specified, if a DOM attribute that is a
floating point number type (
float ) is
assigned an Infinity or Not-a-Number value, a
NOT_SUPPORTED_ERR exception must be raised.
other specified, if a DOM attribute
that is a signed numeric type is assigned a negative value, a
NOT_SUPPORTED_ERR exception must be raised. Unless other
specified, if a method with
an argument that is a floating point number type (
float ) is passed an Infinity or Not-a-Number value, a
NOT_SUPPORTED_ERR exception must be
other specified, if a method is passed fewer
arguments than is defined for that method in its IDL definition, a
NOT_SUPPORTED_ERR exception must be
other specified, if a method is passed more
arguments than is defined for that method in its IDL definition,
the excess arguments must be ignored. Unless
other specified, if a method is expecting, as one of its arguments,
as defined by its IDL definition, an object implementing a
particular interface X , and the argument passed is an object whose
[[Class]] property is neither that interface X , nor the name of an
interface Y where this specification requires that all objects
implementing interface Y also implement interface X , nor the name
of an interface that inherits from the expected interface X , then
a TYPE_MISMATCH_ERR exception must be raised. Anything else?
Passing the wrong type of object, maybe? Implied conversions to
This specification relies on several other underlying specifications.
Implementations that support XHTML5 must support some version of
XML, as well as its corresponding namespaces specification, because
XHTML5 uses an XML
with namespaces. [XML] [XMLNAMES]
User agents must follow the rules given by XML Base to resolve relative URIs in HTML and XHTML fragments. That is the mechanism used in this specification for resolving relative URIs in DOM trees. [XMLBASE]
It is possible for
to be present even in HTML fragments, as such attributes can be
added dynamically using script.
Implementations must support some version of DOM Core and DOM Events, because this specification is defined in terms of the DOM, and some of the features are defined as extensions to the DOM Core interfaces. [DOM3CORE] [DOM3EVENTS]
Implementations that use ECMAScript to implement the APIs
defined in this specification must implement them in a manner
consistent with the ECMAScript Bindings
DOM Specifications specification, as this specification uses that
specification's terminology. [EBFD]
This specification does not require support of any particular network transport protocols, style sheet language, scripting language, or any of the DOM and WebAPI specifications beyond those described above. However, the language described by this specification is biased towards CSS as the styling language, ECMAScript as the scripting language, and HTTP as the network protocol, and several features assume that those languages and protocols are in use.
This specification might have certain additional requirements on character encodings, image formats, audio formats, and video formats in the respective sections.
Some elements are defined in terms of their DOM
textContent attribute. This is an
attribute defined on the
Node interface in DOM3 Core.
Should textContent be defined differently for dir="" and <bdo> ? Should we come up with an alternative to textContent that handles those and other things, like alt=""?
DOMTimeStamp is defined in DOM3
The term activation behavior is used as defined in the DOM3 Events specification. [DOM3EVENTS] At the time of writing, DOM3 Events hadn't yet been updated to define that phrase.
The rules for handling alternative style sheets are defined in the CSS object model specification. [CSSOM]
Certain features are defined in terms of CSS <color>
values. When the CSS value
specified in this context, the "computed value of the 'color'
property" for the purposes of determining the computed value of the
currentColor keyword is the computed value of
the 'color' property on the element in question. [CSS3COLOR]
If a canvas gradient's
addColorStop() method is called with the
currentColor keyword as the color, then the
computed value of the 'color' property on the
canvas element is the one that is used.
This specification refers to both HTML and XML attributes and DOM attributes, often in the same context. When it is not clear which is being referred to, they are referred to as content attributes for HTML and XML attributes, and DOM attributes for those from the DOM. Similarly, the term "properties" is used for both ECMAScript object properties and CSS properties. When these are ambiguous they are qualified as object properties and CSS properties respectively.
To ease migration from HTML to XHTML, UAs
conforming to this specification will place elements in HTML in the
http://www.w3.org/1999/xhtml namespace, at least for
the purposes of the DOM and CSS. The term " elements in the HTML namespace ", or " HTML elements " for short, when used in this
specification, thus refers to both HTML and XHTML elements.
Unless otherwise stated, all elements defined or mentioned in
this specification are in the
http://www.w3.org/1999/xhtml namespace, and all
attributes defined or mentioned in this specification have no
namespace (they are in the per-element partition).
The term HTML documents is sometimes used
in contrast with XML documents to
mean specifically documents that were parsed using an HTML parser (as opposed to using an XML parser or
created purely through the DOM).
Generally, when the specification states that a feature applies to HTML or XHTML, it also includes the other. When a feature specifically only applies to one of the two languages, it is called out by explicitly stating that it does not apply to the other format, as in "for HTML, ... (this does not apply to XHTML)".
This specification uses the term document to refer to any use of HTML, ranging from short static documents to long essays or reports with rich multimedia, as well as to fully-fledged interactive applications.
For readability, the term URI is used to refer to both ASCII URIs and Unicode IRIs, as those terms are defined by RFC 3986 and RFC 3987 respectively. On the rare occasions where IRIs are not allowed but ASCII URIs are, this is called out explicitly. [RFC3986] [RFC3987]
The term root element , when not
qualified to explicitly refer to the document's root element, means the furthest
ancestor element node of whatever node is being discussed, or the
node itself is there is none.
When the node
is a part of the document, then that is indeed the document's root
element. However, if the node is not currently
part of the document tree, the root element will be an orphaned
An element is said to have been inserted into a document when its root element changes and is now the document's root element .
The term tree order means a
pre-order, depth-first traversal of DOM nodes involved (through the
When it is stated that some element or attribute is ignored , or treated as some other value, or handled as if it was something else, this refers only to the processing of the node after it is in the DOM. A user agent must not mutate the DOM in such situations.
When an XML name, such as an attribute or element name, is
referred to in the form
localName , as in
svg:rect , it refers to a name with the local name
localName and the namespace given by the
prefix, as defined by the following table:
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.
Various DOM interfaces are defined in this specification using pseudo-IDL. This looks like OMG IDL but isn't. For
instance, method overloading is used, and types from the W3C DOM
specifications are used without qualification. Language-specific
bindings for these abstract interface definitions must be derived in the way consistent with W3C DOM
specifications. Some interface-specific binding information for
ECMAScript is included in this specification. The current situation
with IDL blocks is pitiful. IDL is totally inadequate to properly
represent what objects have to look like in JS; IDL can't say if a
member is enumerable, what the indexing behaviour is, what the
stringification behaviour is, what behaviour setting a member whose
type is a particular interface should be (e.g. setting of
document.location or element.className), what constructor an object
implementing an interface should claim to have, how overloads work,
etc. I think we should make the IDL blocks
non-normative, and/or replace them with something else that is
better for JS while still being clear on how it applies to other
languages. However, we do need to have something that says what
types the methods take as arguments, since we have to raise
exceptions if they are wrong.
The construction "a
Foo object", where
Foo is actually an interface, is sometimes used
instead of the more accurate "an object implementing the interface
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.
The terms fire and dispatch are used interchangeably in the context of events, as in the DOM Events specifications. [DOM3EVENTS]
The term text node refers to any
Text node, including
Node with node type
Some of the algorithms in this specification, for historical
reasons, require the user agent to pause
until some condition has been met. While a user agent is paused, it
must ensure that no scripts execute (e.g. no event handlers, no
timers, etc). User agents should remain responsive to user input
This section is non-normative.
This specification defines an abstract language for describing documents and applications, and some APIs for interacting with in-memory representations of resources that use this language.
The in-memory representation is known as "DOM5 HTML", or "the DOM" for short.
There are various concrete syntaxes that can be used to transmit resources that use this abstract language, two of which are defined in this specification.
The first such concrete syntax is "HTML5". This is the format
recommended for most authors. It is compatible with all legacy Web
browsers. If a document is transmitted with the MIME type
text/html , then it will be processed as an
"HTML5" document by Web browsers.
The second concrete syntax uses XML, and is known as "XHTML5".
When a document is transmitted with an XML MIME type, such as
application/xhtml+xml , then it is processed
by an XML processor by Web browsers, and treated as an "XHTML5"
document. Authors are reminded that the processing for XML and HTML
differs; in particular, even minor syntax errors will prevent an
XML document from being rendered fully, whereas they would be
ignored in the "HTML5" syntax.
The "DOM5 HTML", "HTML5", and "XHTML5" representations cannot
all represent the same content. For example, namespaces cannot be
represented using "HTML5", but they are supported in "DOM5 HTML"
and "XHTML5". Similarly, documents that use the
noscript feature can be represented using
"HTML5", but cannot be represented with "XHTML5" and "DOM5 HTML".
Comments that contain the string "
can be represented in "DOM5 HTML" but not in "HTML5" and "XHTML5".
And so forth.