2 Common infrastructure — HTML 5.1

2 Common infrastructure — HTML 5.1
HTML 5.1
A vocabulary and associated APIs for HTML and XHTML
W3C Working Draft 17 December 2012
Common infrastructure
2.1
Terminology
This specification refers to both HTML and XML attributes and IDL
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
IDL
attributes
for those defined on IDL interfaces. Similarly, the
term "properties" is used for both JavaScript object properties and
CSS properties. When these are ambiguous they are qualified as
object properties
and
CSS
properties
respectively.
Generally, when the specification states that a feature applies
to
the HTML syntax
or
the XHTML syntax
, 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. The term is used to refer
both to
Document
objects and their descendant DOM
trees, and to serialized byte streams using the
HTML syntax
or
XHTML syntax
, depending on context.
In the context of the DOM structures, the terms
HTML document
and
XML
document
are used as defined in the DOM Core specification,
and refer specifically to two different modes that
Document
objects can find themselves in.
[DOMCORE]
(Such uses are always hyperlinked
to their definition.)
In the context of byte streams, the term HTML document refers to
resources labeled as
text/html
, and the term XML
document refers to resources labeled with an
XML MIME
type
The term
XHTML document
is used to refer to both
Document
s in the
XML
document
mode that contains element nodes in the
HTML
namespace
, and byte streams labeled with an
XML MIME
type
that contain elements from the
HTML
namespace
, depending on context.
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.
When an algorithm B says to return to another algorithm A, it
implies that A called B. Upon returning to A, the implementation
must continue from where it left off in calling B.
The term "transparent black" refers to the color with red, green,
blue, and alpha channels all set to zero.
2.1.1
Resources
The specification uses the term
supported
when referring to whether a user agent has an implementation capable
of decoding the semantics of an external resource. A format or type
is said to be
supported
if the implementation can process an
external resource of that format or type without critical aspects of
the resource being ignored. Whether a specific resource is
supported
can depend on what features of the resource's
format are in use.
For example, a PNG image would be considered to
be in a supported format if its pixel data could be decoded and
rendered, even if, unbeknownst to the implementation, the image also
contained animation data.
An MPEG-4 video file would not be considered to
be in a supported format if the compression format used was not
supported, even if the implementation could determine the dimensions
of the movie from the file's metadata.
What some specifications, in particular the HTTP and URI
specifications, refer to as a
representation
is referred to
in this specification as a
resource
[HTTP]
[RFC3986]
The term
MIME type
is used to refer to what is
sometimes called an
Internet media type
in protocol
literature. The term
media type
in this specification is used
to refer to the type of media intended for presentation, as used by
the CSS specifications.
[RFC2046]
[MQ]
A string is a
valid MIME type
if it matches the
media-type
rule defined in section 3.7 "Media Types"
of RFC 2616. In particular, a
valid MIME type
may
include MIME type parameters.
[HTTP]
A string is a
valid MIME type with no parameters
if it
matches the
media-type
rule defined in section
3.7 "Media Types" of RFC 2616, but does not contain any ";" (U+003B) characters. In other words, if it consists only of a
type and subtype, with no MIME Type parameters.
[HTTP]
The term
HTML MIME type
is used to refer to the
MIME type
text/html
A resource's
critical subresources
are those that the
resource needs to have available to be correctly processed. Which
resources are considered critical or not is defined by the
specification that defines the resource's format.
The term
data:
URL
refers to
URLs
that use the
data:
scheme.
[RFC2397]
2.1.2
XML
To ease migration from HTML to XHTML, UAs
conforming to this specification will place elements in HTML in the
namespace, at least for
the purposes of the DOM and CSS. The term "
HTML
elements
", when used in this specification, refers to any
element in that namespace, and thus refers to both HTML and XHTML
elements.
Except where otherwise stated, all elements defined or mentioned
in this specification are in the
HTML namespace
("
"), and all attributes
defined or mentioned in this specification have no namespace.
The term
element type
is used to refer to the set of
elements that have a given local name and namespace. For example,
button
elements are elements with the element type
button
, meaning they have the local name "
button
" and (implicitly as defined above) the
HTML namespace
Attribute names are said to be
XML-compatible
if they
match the
Name
production defined in XML, they contain no
":" (U+003A) characters, and their first three characters are
not an
ASCII case-insensitive
match for the string
xml
".
[XML]
The term
XML MIME type
is used to refer to the
MIME types
text/xml
application/xml
, and any
MIME
type
whose subtype ends with the four characters "
+xml
".
[RFC3023]
2.1.3
DOM trees
The
root element of a
Document
object
is
that
Document
's first element child, if any. If it does
not have one then the
Document
has no root element.
The term
root element
, when not referring to a
Document
object's root element, means the furthest
ancestor element node of whatever node is being discussed, or the
node itself if it has no ancestors. When the node is a part of the
document, then the node's
root element
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 node.
When an element's
root element
is the
root
element of a
Document
object
, it is said to be
in a
Document
. An element is said to have
been
inserted into a
document
when its
root element
changes and is now
the document's
root element
. Analogously, an element is
said to have been
removed from a document
when its
root
element
changes from being the document's
root
element
to being another element.
A node's
home subtree
is the subtree rooted at that
node's
root element
. When a node is
in a
Document
, its
home subtree
is that
Document
's tree.
The
Document
of a
Node
(such as an
element) is the
Document
that the
Node
's
ownerDocument
IDL
attribute returns. When a
Node
is
in a
Document
then that
Document
is
always the
Node
's
Document
, and the
Node
's
ownerDocument
IDL attribute
thus always returns that
Document
The
Document
of a content attribute is the
Document
of the attribute's element.
The term
tree order
means a pre-order, depth-first
traversal of DOM nodes involved (through the
parentNode
childNodes
relationship).
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.
user agent must not mutate the DOM in such situations.
A content attribute is said to
change
value
only if its new value is different than its previous value; setting
an attribute to a value it already has does not change it.
The term
empty
, when used of an attribute
value,
Text
node, or string, means that the length of
the text is zero (i.e. not even containing spaces or control
characters).
2.1.4
Scripting
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
".
An IDL 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 the
attributes and methods on that object
must
operate on the actual underlying data, not a snapshot of the
data.
In the contexts of events, the terms
fire
and
dispatch
are used as defined in the
DOM Core specification:
firing
an event means to create and
dispatch
it, and
dispatching
an event means to follow the steps that propagate
the event through the tree. The term
trusted event
is
used to refer to events whose
isTrusted
attribute is
initialized to true.
[DOMCORE]
2.1.5
Plugins
The term
plugin
refers to a user-agent defined set of
content handlers used by the user agent that can take part in the
user agent's rendering of a
Document
object, but that
neither act as
child browsing
contexts
of the
Document
nor introduce any
Node
objects to the
Document
's DOM.
Typically such content handlers are provided by third parties,
though a user agent can also designate built-in content handlers as
plugins.
A user agent must not consider the types
text/plain
and
application/octet-stream
as having a registered
plugin
One example of a plugin would be a PDF viewer
that is instantiated in a
browsing context
when the
user navigates to a PDF file. This would count as a plugin
regardless of whether the party that implemented the PDF viewer
component was the same as that which implemented the user agent
itself. However, a PDF viewer application that launches separate
from the user agent (as opposed to using the same interface) is not
a plugin by this definition.
This specification does not define a mechanism for
interacting with plugins, as it is expected to be user-agent- and
platform-specific. Some UAs might opt to support a plugin mechanism
such as the Netscape Plugin API; others might use remote content
converters or have built-in support for certain types. Indeed, this
specification doesn't require user agents to support plugins at all.
[NPAPI]
A plugin can be
secured
if it honors the semantics of the
sandbox
attribute.
For example, a secured plugin would prevent its
contents from creating pop-up windows when the plugin is
instantiated inside a sandboxed
iframe
Browsers should take extreme care when
interacting with external content intended for
plugins
. When third-party software is run with
the same privileges as the user agent itself, vulnerabilities in the
third-party software become as dangerous as those in the user
agent.
2.1.6
Character encodings
The
preferred MIME name
of a character encoding is the
name or alias labeled as "preferred MIME name" in the IANA
Character Sets
registry, if there is one, or the
encoding's name, if none of the aliases are so labeled.
[IANACHARSET]
An
ASCII-compatible character encoding
is a
single-byte or variable-length encoding in which the bytes 0x09,
0x0A, 0x0C, 0x0D, 0x20 - 0x22, 0x26, 0x27, 0x2C - 0x3F, 0x41 - 0x5A,
and 0x61 - 0x7A
, ignoring bytes that
are the second and later bytes of multibyte sequences, all
correspond to single-byte sequences that map to the same Unicode
characters as those bytes in ANSI_X3.4-1968 (US-ASCII).
[RFC1345]
This includes such encodings as Shift_JIS,
HZ-GB-2312, and variants of ISO-2022, even though it is possible in
these encodings for bytes like 0x70 to be part of longer sequences
that are unrelated to their interpretation as ASCII. It excludes
such encodings as UTF-7, UTF-16, GSM03.38, and EBCDIC variants.
The term
a UTF-16 encoding
refers to any variant of
UTF-16: self-describing UTF-16 with a BOM, ambiguous UTF-16 without
a BOM, raw UTF-16LE, and raw UTF-16BE.
[RFC2781]
The term
code unit
is used as defined in the Web IDL
specification: a 16 bit unsigned integer, the smallest atomic
component of a
DOMString
. (This is a narrower
definition than the one used in Unicode.)
[WEBIDL]
The term
Unicode code point
means a
Unicode scalar value
where possible, and an isolated
surrogate code point when not. When a conformance requirement is
defined in terms of characters or Unicode code points, a pair of
code units
consisting of a high
surrogate followed by a low surrogate must be treated as the single
code point represented by the surrogate pair, but isolated
surrogates must each be treated as the single code point with the
value of the surrogate.
[UNICODE]
In this specification, the term
character
, when not
qualified as
Unicode
character, is synonymous with the term
Unicode code point
The term
Unicode character
is used to mean a
Unicode scalar value
(i.e. any Unicode code point that
is not a surrogate code point).
[UNICODE]
The
code-unit length
of a string is the number of
code units
in that string.
This complexity results from the historical decision
to define the DOM API in terms of 16 bit (UTF-16)
code units
, rather than in terms of
Unicode characters
2.2
Conformance requirements
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",
"MAY", and "OPTIONAL" in the normative parts of
this document are to be interpreted as described in RFC2119. The key word "OPTIONALLY" in the
normative parts of this document is to be interpreted with the same normative meaning as "MAY" and
"OPTIONAL". 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.
For example, were the spec to say:
To eat a kiwi, the user must:
1. Peel the kiwi.
2. Eat the kiwi flesh.
...it would be equivalent to the following:
To eat a kiwi:
1. The user must peel the kiwi.
2. The user must eat the kiwi flesh.
Here the key word is "must".
The former (imperative) style is generally preferred in this
specification for stylistic reasons.
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.)
2.2.1
Conformance classes
This specification describes the conformance criteria for
user agents (relevant to implementors) and
documents
(relevant to authors and authoring tool
implementors)
Conforming HTML5 documents
are those that comply with all
the conformance criteria for documents. For readability, some of
these conformance requirements are phrased as conformance
requirements on authors; such requirements are implicitly
requirements on documents: by definition, all documents are assumed
to have had an author. (In some cases, that author may itself be a
user agent — such user agents are subject to additional rules,
as explained below.)
For example, if a requirement states that
"authors must not use the
foobar
element", it
would imply that documents are not allowed to contain elements named
foobar
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 and other interactive user agents
Web browsers that support
the XHTML syntax
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 an XHTML
script
element in an XML document,
execute the script contained in that element. However, if the
element is found within a transformation expressed in XSLT
(assuming the user agent also supports XSLT), then the processor
would instead treat the
script
element as an opaque
element that forms part of the transform.
Web browsers that support
the HTML syntax
must
process documents labeled with an
HTML MIME type
as
described in this specification, so that users can interact with
them.
User agents that support scripting must also be conforming
implementations of the IDL fragments in this specification, as
described in the Web IDL specification.
[WEBIDL]
Unless explicitly stated, specifications that
override the semantics of HTML elements do not override the
requirements on DOM objects representing those elements. For
example, the
script
element in the example above
would still implement the
HTMLScriptElement
interface.
Non-interactive presentation user agents
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.
Visual user agents that support the suggested default rendering
User agents, whether interactive or not, may be designated
(possibly as a user option) as supporting the suggested default
rendering defined by this specification.
This is not required. In particular, even user agents that do
implement the suggested default rendering are encouraged to offer
settings that override this default to improve the experience for
the user, e.g. changing the color contrast, using different focus
styles, or otherwise making the experience more accessible and
usable to the user.
User agents that are designated as supporting the suggested
default rendering must, while so designated, implement the rules
in
the rendering section
that that
section defines as the behavior that user agents are
expected
to implement.
User agents with no scripting support
Implementations that do not support scripting (or which have
their scripting features disabled entirely) 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
Conformance checkers must verify that a document conforms to
the applicable conformance criteria described in this
specification. Automated 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 a
blockquote
element is not a quote,
conformance checkers running without the input of human judgement
do not have to check that
blockquote
elements only
contain quoted material).
Conformance checkers must check that the input document
conforms when parsed without a
browsing context
(meaning that no scripts are run, and that the parser's
scripting flag
is disabled), and should also check
that the input document conforms when parsed with a
browsing
context
in which scripts execute, and that the scripts
never cause non-conforming states to occur other than transiently
during script execution itself. (This is only a "SHOULD" and not a
"MUST" requirement because it has been proven to be impossible.
[COMPUTABLE]
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:
Criteria that can be expressed in a DTD.
Criteria that cannot be expressed by a DTD, but can still be
checked by a machine.
Criteria that can only be checked by a human.
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.
Data mining tools
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 with 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
Authoring tools and markup generators must generate
conforming
HTML5
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. However, authoring tools must not automatically misuse
elements or encourage their users to do so.
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 tool is likely unable to determine the difference, an
authoring tool is exempt from that requirement. This does not
mean, though, that authoring tools can use
address
elements for any block of italics text (for instance); it just
means that the authoring tool doesn't have to verify that when the
user uses a tool for inserting contact information for a section,
that the user really is doing that and not inserting something
else instead.
In terms of conformance checking, an editor has 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 erroneous
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 legitimate. WYSIWYG tools should use
elements they know are appropriate, and should not use elements
that they do not know to be appropriate. This might in certain
extreme cases mean limiting the use of flow elements to just a few
elements, like
div
and
span
and making liberal use of the
style
attribute.
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.
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
the XHTML syntax
), and one using a
custom format
inspired by SGML (referred to as
the HTML syntax
). Implementations must support at least
one of these two formats, although supporting both is
encouraged.
Some conformance requirements are phrased as requirements on
elements, attributes, methods or objects. Such requirements fall
into two categories: those describing content model restrictions,
and those describing implementation behavior. Those in the former
category are requirements on documents and authoring tools. Those in
the second category are requirements on user agents. Similarly, some
conformance requirements are phrased as requirements on authors;
such requirements are to be interpreted as conformance requirements
on the documents that authors produce. (In other words, this
specification does not distinguish between conformance criteria on
authors and conformance criteria on documents.)
2.2.2
Dependencies
This specification relies on several other underlying
specifications.
XML
Implementations that support
the XHTML syntax
must
support some version of XML, as well as its corresponding
namespaces specification, because that syntax uses an XML
serialization with namespaces.
[XML]
[XMLNS]
URIs, IRIs, IDNA
Implementations must support the semantics of
URLs
defined in the URI and IRI specifications,
as well as the semantics of IDNA domain names defined in the
Internationalizing Domain Names in Applications
(IDNA)
specification.
[RFC3986]
[RFC3987]
[RFC3490]
The following terms are defined in the Cookie specification:
[COOKIES]
cookie-string
receives a set-cookie-string
CORS
The following terms are defined in the CORS specification:
[CORS]
cross-origin request
cross-origin request status
custom request headers
simple cross-origin request
redirect steps
credential flag
resource sharing check
Web IDL
The IDL fragments in this specification must be interpreted as
required for conforming IDL fragments, as described in the Web IDL
specification.
[WEBIDL]
The terms
expose
supported property
indices
determine the value of an indexed
property
support named properties
supported property names
determine the value of a
named property
platform array objects
, and
read only
(when applied to
arrays) are used as defined in the Web IDL specification. The
algorithm to
convert a DOMString to a sequence of Unicode
characters
is similarly that defined in the Web IDL
specification.
When this specification requires a user agent to
create a
Date
object
representing a particular time
(which could be the special value Not-a-Number), the milliseconds
component of that time, if any, must be truncated to an integer
and the time value of the newly created
Date
object
must represent the time after that truncation.
For instance, given the time 23045 millionths
of a second after 01:00 UTC on January 1st 2000, i.e. the time
2000-01-01T00:00:00.023045Z, then the
Date
object
created representing that time would represent the same time as
that created representing the time 2000-01-01T00:00:00.023Z, 45
millionths earlier. If the given time is NaN, then the result is a
Date
object that represents a time value NaN
(indicating that the object does not represent a specific instant
of time).
JavaScript
Some parts of the language described by this specification only
support JavaScript as the underlying scripting language.
[ECMA262]
The term "JavaScript" is used to refer to ECMA262,
rather than the official term ECMAScript, since the term
JavaScript is more widely known. Similarly, the
MIME
type
used to refer to JavaScript in this specification is
text/javascript
, since that is the most
commonly used type,
despite it
being an officially obsoleted type
according to RFC
4329.
[RFC4329]
The term
JavaScript global environment
refers to the
global environment
concept defined in the
ECMAScript specification.
DOM
The Document Object Model (DOM) is a representation — a
model — of a document and its content. The DOM is not just
an API; the conformance criteria of HTML implementations are
defined, in this specification, in terms of operations on the DOM.
[DOMCORE]
Implementations must support DOM Core and the events defined in
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.
[DOMCORE]
[DOMEVENTS]
In particular, the following features are defined in the DOM
Core specification:
[DOMCORE]
Attr
interface
Comment
interface
DOMImplementation
interface
Document
interface
DocumentFragment
interface
DocumentType
interface
DOMException
interface
Element
interface
Node
interface
NodeList
interface
ProcessingInstruction
interface
Text
interface
HTMLCollection
interface, and the terms
collections
and
represented by the collection
DOMTokenList
interface
DOMSettableTokenList
interface
createDocument()
method
createHTMLDocument()
method
createElement()
method
createElementNS()
method
getElementById()
method
insertBefore()
method
ownerDocument
attribute
childNodes
attribute
localName
attribute
parentNode
attribute
namespaceURI
attribute
tagName
attribute
id
attribute
textContent
attribute
The
insert
append
, and
replace
algorithms for nodes
Event
interface
EventTarget
interface
EventInit
dictionary type
target
attribute
isTrusted
attribute
The
type
of an event
The concept of an
event listener
and the
event listeners
associated with an
EventTarget
The
encoding
(herein the
character encoding
) and
content type
of a
Document
The distinction between
XML documents
and
HTML documents
The terms
quirks mode
limited-quirks mode
, and
no-quirks mode
The algorithm to
clone
Node
, and the concept of
cloning steps
used by that algorithm
The concept of
base URL change steps
and the definition of what happens when an element is
affected by a base URL change
The concept of an element's
unique identifier (ID)
The concept of a DOM
range
, and the terms
start
end
, and
boundary point
as applied to ranges.
MutationObserver
interface
The
MutationObserver
scripting environment
concept
The
invoke
MutationObserver
objects
algorithm
The term
throw
in this specification is used as
defined in the DOM Core specification. The following
DOMException
types are defined in the DOM Core
specification:
[DOMCORE]
IndexSizeError
HierarchyRequestError
WrongDocumentError
InvalidCharacterError
NoModificationAllowedError
NotFoundError
NotSupportedError
InvalidStateError
SyntaxError
InvalidModificationError
NamespaceError
InvalidAccessError
TypeMismatchError
SecurityError
NetworkError
AbortError
URLMismatchError
QuotaExceededError
TimeoutError
InvalidNodeTypeError
DataCloneError
For example, to
throw a
TimeoutError
exception
, a user agent would
construct a
DOMException
object whose type was the
string "
TimeoutError
" (and whose code was
the number 23, for legacy reasons) and actually throw that object
as an exception.
The
URL
associated
with a
Document
, as defined in the DOM Core
specification, is referred to in this specification as
the
document's address
The following features are defined in the DOM Events
specification:
[DOMEVENTS]
MouseEvent
interface
The
MouseEvent
interface's
screenX
attribute
The
MouseEvent
interface's
screenY
attribute
The
MouseEvent
interface's
clientX
attribute
The
MouseEvent
interface's
clientY
attribute
The
MouseEvent
interface's
ctrlKey
attribute
The
MouseEvent
interface's
shiftKey
attribute
The
MouseEvent
interface's
altKey
attribute
The
MouseEvent
interface's
metaKey
attribute
The
MouseEvent
interface's
button
attribute
The
MouseEvent
interface's
buttons
attribute
The
MouseEvent
interface's
relatedTarget
attribute
The
UIEvent
interface's
view
attribute
The
UIEvent
interface's
detail
attribute
click
event
This specification sometimes uses the term
name
to refer to the event's
type
; as in, "an event named
click
" or "if the event name is
keypress
". The terms "name" and "type" for events
are synonymous.
The following features are defined in the DOM Parsing and
Serialization specification:
[DOMPARSING]
innerHTML
outerHTML
insertAdjacentHTML
User agents are also encouraged to implement the
features described in the
HTML Editing APIs
and
UndoManager
and DOM Transaction
specifications.
[EDITING]
[UNDO]
Typed Arrays
The
ArrayBuffer
interface and underlying concepts from the Typed Array
Specification are used for several features in this specification.
The
Uint8ClampedArray
interface type is specifically
used in the definition of the
canvas
element's 2D
API.
[TYPEDARRAY]
File API
This specification uses the following interfaces defined in the
File API specification:
[FILEAPI]
Blob
File
FileList
It also uses the following interface defined in the File System
API specification:
[FILESYSTEMAPI]
FileCallback
XMLHttpRequest
This specification references the XMLHttpRequest specification
to define how the two specifications interact. The terms
document response entity body
XMLHttpRequest
base URL
XMLHttpRequest
origin
, and
XMLHttpRequest
referrer source
are defined
in that specification.
[XHR]
Media Queries
Implementations must support the Media Queries language.
[MQ]
CSS modules
While support for CSS as a whole is not required of
implementations of this specification (though it is encouraged, at
least for Web browsers), some features are defined in terms of
specific CSS requirements.
In particular, some features require that a string be
parsed as a CSS value
. When parsing a CSS
value, user agents are required by the CSS specifications to apply
some error handling rules. These apply to this specification also.
[CSSCOLOR]
[CSS]
For example, user agents are required to close
all open constructs upon finding the end of a style sheet
unexpectedly. Thus, when parsing the string "
rgb(0,0,0
" (with a missing close-parenthesis) for
a color value, the close parenthesis is implied by this error
handling rule, and a value is obtained (the color 'black').
However, the similar construct "
rgb(0,0,
(with both a missing parenthesis and a missing "blue" value)
cannot be parsed, as closing the open construct does not result
in a viable value.
The term
provides a paint source
is used
as defined in the
CSS Image Values and Replaced
Content
specification to define the interaction of certain
HTML elements with the CSS 'element()' function.
[CSSIMAGES]
Support for the CSS Object Model is required for
implementations that support scripting. The following features and
terms are defined in the CSSOM specifications:
[CSSOM]
[CSSOMVIEW]
Screen
LinkStyle
CSSStyleDeclaration
StyleSheet
sheet
disabled
Alternative style sheet sets
and the
preferred style sheet set
Serializing a CSS value
Scroll an element into view
Parts of the Fullscreen specification, in particular the
top layer
concept, are used to define the rendering of
the
dialog
element.
[FULLSCREEN]
The term
CSS styling attribute
is defined in the
CSS Style Attributes
specification.
[CSSATTR]
SVG
The following interface is defined in the SVG specification:
[SVG]
SVGMatrix
WebVTT
Implementations may support
WebVTT
as a text track
format for subtitles, captions, chapter titles, metadata, etc, for
media resources.
[WEBVTT]
The following terms, used in this specification, are defined in
the WebVTT specification:
WebVTT file
WebVTT file using cue text
WebVTT file using chapter title text
WebVTT file using only nested cues
WebVTT parser
WebVTT cue settings
and how to
parse the WebVTT settings
The
rules for updating the display of WebVTT text tracks
The
WebVTT cue text DOM construction rules
The
WebVTT cue text rendering rules
The
WebVTT cue text parsing rules
The WebSocket protocol
The following terms are defined in the WebSocket protocol
specification:
[WSP]
establish a WebSocket connection
the WebSocket connection is established
validate the server's response
extensions in use
subprotocol in use
headers to send appropriate cookies
cookies set during the server's opening handshake
a WebSocket message has been received
fail the WebSocket connection
close the WebSocket connection
start the WebSocket closing handshake
the WebSocket closing handshake is started
the WebSocket connection is closed
(possibly
cleanly
the WebSocket connection close code
the WebSocket connection close reason
ARIA
The terms
strong native semantics
is used as defined
in the ARIA specification. The term
default implicit ARIA
semantics
has the same meaning as the term
implicit
WAI-ARIA semantics
as used in the ARIA specification.
[ARIA]
The
role
and
aria-*
attributes are defined in the ARIA
specification.
[ARIA]
This specification does not
require
support of any
particular network protocol, style sheet language, scripting
language, or any of the DOM specifications beyond those required in
the list above. However, the language described by this
specification is biased towards CSS as the styling language,
JavaScript as the scripting language, and HTTP as the network
protocol, and several features assume that those languages and
protocols are in use.
A user agent that implements the HTTP protocol must implement the Web Origin Concept
specification and the HTTP State Management Mechanism specification (Cookies) as well.
[HTTP]
[ORIGIN]
[COOKIES]
This specification might have certain additional
requirements on character encodings, image formats, audio formats,
and video formats in the respective sections.
2.2.3
Extensibility
HTML has a wide number of extensibility mechanisms that can be
used for adding semantics in a safe manner:
Authors can use the
class
attribute to extend elements, effectively creating their own
elements, while using the most applicable existing "real" HTML
element, so that browsers and other tools that don't know of the
extension can still support it somewhat well. This is the tack used
by microformats, for example.
Authors can include data for inline client-side scripts or
server-side site-wide scripts to process using the
data-*=""
attributes. These are
guaranteed to never be touched by browsers, and allow scripts to
include data on HTML elements that scripts can then look for and
process.
Authors can use the
content="">
mechanism to include page-wide metadata by
registering
extensions to the
predefined set of metadata names
Authors can use the
rel=""
mechanism to annotate
links with specific meanings by registering
extensions to the predefined set of
link types
. This is also used by microformats. Additionally,
absolute URLs that do not contain any non-ASCII characters, nor
characters in the range U+0041 (LATIN CAPITAL LETTER A) through
U+005A (LATIN CAPITAL LETTER Z) (inclusive), may be used as link
types.
Authors can embed raw data using the