Abstract

This specification defines the 5th major revision of the core language of the World Wide Web:
the Hypertext Markup Language (HTML). In this version, new features are introduced to help Web
application authors, new elements are introduced based on research into prevailing authoring
practices, and special attention has been given to defining clear conformance criteria for user
agents in an effort to improve interoperability.

Status of This document

This section describes the status of this document at the time of its publication.
Other documents may supersede this document. A list of current W3C publications and the
latest revision of this technical report can be found in the W3C
technical reports index at http://www.w3.org/TR/.

If you wish to make comments regarding this document in a manner
that is tracked by the W3C, please submit them via using our
public bug database. If you cannot do this then you can also e-mail feedback to public-html-comments@w3.org
(subscribe,
archives),
and arrangements will be made to transpose the comments to our
public bug database. All feedback is welcome.

Work on extending this specification typically proceeds through
extension specifications
which should be consulted to see what new features are being reviewed.

The bulk of the text of this specification is also
available in the WHATWG HTML Living Standard, under a license that permits reuse of the
specification text.

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
Candidate Recommendation stage should join the aforementioned
mailing lists and take part in the discussions.

This is a work in
progress! For the latest updates from the HTML WG, possibly
including important bug fixes, please look at the editor's draft instead.

Publication as a Candidate Recommendation does not imply endorsement by the W3C Membership.
This is a draft document and may be updated, replaced or obsoleted by other documents at
any time. It is inappropriate to cite this document as other than work in progress.

The W3C HTML Working
Group is the W3C working group responsible for this
specification's progress.
This specification is the 29 April 2014 Candidate Recommendation.
This specification is intended to become a W3C Recommendation.

Work on this specification is also done at the WHATWG. The W3C HTML working group actively pursues convergence of the
HTML specification with the WHATWG living standard, within the bounds of the W3C HTML working
group charter. There are various ways to follow this work at the WHATWG:

This document was published by the HTML Working Group as an updated revision to the Candidate
Recommendation
(http://www.w3.org/TR/2013/CR-html5-20130806/).
This document is intended to become a W3C Recommendation. W3C publishes a Candidate
Recommendation to indicate that the document is believed to be stable and to encourage
implementation by the developer community. This Candidate Recommendation is expected to advance
to Proposed Recommendation no earlier than 01 September 2014. All feedback is welcome.

1 Introduction

1.1 Background

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 have 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.

1.2 Audience

This section is non-normative.

This specification is intended for authors of documents and scripts that use the features
defined in this specification, implementors of tools that operate on pages that
use the features defined in this specification, and individuals wishing to establish the
correctness of documents or implementations with respect to the requirements of this
specification.

This document is probably not suited to readers who do not already have at least a passing
familiarity with Web technologies, as in places it sacrifices clarity for precision, and brevity
for completeness. More approachable tutorials and authoring guides can provide a gentler
introduction to the topic.

In particular, familiarity with the basics of DOM is necessary for a complete understanding of
some of the more technical parts of this specification. An understanding of Web IDL, HTTP, XML,
Unicode, character encodings, JavaScript, and CSS will also be helpful in places but is not
essential.

1.3 Scope

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 providing mechanisms for media-specific
customization of presentation (although default rendering rules for Web browsers are included at
the end of this specification, and several mechanisms for hooking into CSS are provided as part of
the language).

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. Examples of such applications include 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.

1.4 History

This section is non-normative.

For its first five years (1990-1995), HTML went through a number of revisions and experienced a
number of extensions, primarily hosted first at CERN, and then at the IETF.

With the creation of the W3C, HTML's development changed venue again. A first abortive attempt
at extending HTML in 1995 known as HTML 3.0 then made way to a more pragmatic approach known as
HTML 3.2, which was completed in 1997. HTML4 quickly followed later that same year.

The following year, the W3C membership decided to stop evolving HTML and instead begin work on
an XML-based equivalent, called XHTML. This
effort started with a reformulation of HTML4 in XML, known as XHTML 1.0, which added no new
features except the new serialization, and which was completed in 2000. After XHTML 1.0, the W3C's
focus turned to making it easier for other working groups to extend XHTML, under the banner of
XHTML Modularization. In parallel with this, the W3C also worked on a new language that was not
compatible with the earlier HTML and XHTML languages, calling it XHTML2.

Around the time that HTML's evolution was stopped in 1998, parts of the API for HTML developed
by browser vendors were specified and published under the name DOM Level 1 (in 1998) and DOM Level
2 Core and DOM Level 2 HTML (starting in 2000 and culminating in 2003). These efforts then petered
out, with some DOM Level 3 specifications published in 2004 but the working group being closed
before all the Level 3 drafts were completed.

In 2003, the publication of XForms, a technology which was positioned as the next generation of
Web forms, sparked a renewed interest in evolving HTML itself, rather than finding replacements
for it. This interest was borne from the realization that XML's deployment as a Web technology was
limited to entirely new technologies (like RSS and later Atom), rather than as a replacement for
existing deployed technologies (like HTML).

A proof of concept to show that it was possible to extend HTML4's forms to provide many of the
features that XForms 1.0 introduced, without requiring browsers to implement rendering engines
that were incompatible with existing HTML Web pages, was the first result of this renewed
interest. At this early stage, while the draft was already publicly available, and input was
already being solicited from all sources, the specification was only under Opera Software's
copyright.

The idea that HTML's evolution should be reopened was tested at a W3C workshop in 2004, where
some of the principles that underlie the HTML5 work (described below), as well as the
aforementioned early draft proposal covering just forms-related features, were presented to the
W3C jointly by Mozilla and Opera. The proposal was rejected on the grounds that the proposal
conflicted with the previously chosen direction for the Web's evolution; the W3C staff and
membership voted to continue developing XML-based replacements instead.

Shortly thereafter, Apple, Mozilla, and Opera jointly announced their intent to continue
working on the effort under the umbrella of a new venue called the WHATWG. A public mailing list
was created, and the draft was moved to the WHATWG site. The copyright was subsequently amended to
be jointly owned by all three vendors, and to allow reuse of the specification.

The WHATWG was based on several core principles, in particular that technologies need to be
backwards compatible, that specifications and implementations need to match even if this means
changing the specification rather than the implementations, and that specifications need to be
detailed enough that implementations can achieve complete interoperability without
reverse-engineering each other.

The latter requirement in particular required that the scope of the HTML5 specification include
what had previously been specified in three separate documents: HTML4, XHTML1, and DOM2 HTML. It
also meant including significantly more detail than had previously been considered the norm.

In 2006, the W3C indicated an interest to participate in the development of HTML5 after all,
and in 2007 formed a working group chartered to work with the WHATWG on the development of the
HTML5 specification. Apple, Mozilla, and Opera allowed the W3C to publish the specification under
the W3C copyright, while keeping a version with the less restrictive license on the WHATWG
site.

For a number of years, both groups then worked together under the same editor: Ian Hickson.
In 2011, the groups came to the conclusion that they had different goals: the W3C wanted to
draw a line in the sand for features for a HTML5 Recommendation, while the WHATWG wanted to
continue working on a Living Standard for HTML, continuously maintaining the specification
and adding new features. In mid 2012, a new editing team was introduced at the W3C to take
care of creating a HTML5 Recommendation and prepare a Working Draft for the next HTML
version.

Since then, the W3C HTML WG has been cherry picking patches from the WHATWG that resolved
bugs registered on the W3C HTML specification or more accurately represented implemented
reality in UAs. At time of publication of this document, patches from the
WHATWG HTML specification
have been merged until revision 8152 inclusive. The W3C
HTML editors have also added patches that resulted from discussions and decisions made by
the W3C HTML WG as well a bug fixes from bugs not shared by the WHATWG.

A separate document is published to document the differences between the HTML specified
in this document and the language described in the HTML4 specification. [HTMLDIFF]

1.5 Design notes

This section is non-normative.

It must be admitted that many aspects of HTML appear at first glance to be nonsensical and
inconsistent.

HTML, its supporting DOM APIs, as well as many of its supporting technologies, have been
developed over a period of several decades by a wide array of people with different priorities
who, in many cases, did not know of each other's existence.

Features have thus arisen from many sources, and have not always been designed in especially
consistent ways. Furthermore, because of the unique characteristics of the Web, implementation
bugs have often become de-facto, and now de-jure, standards, as content is often unintentionally
written in ways that rely on them before they can be fixed.

Despite all this, efforts have been made to adhere to certain design goals. These are described
in the next few subsections.

1.5.1 Serializability of script execution

This section is non-normative.

To avoid exposing Web authors to the complexities of multithreading, the HTML and DOM APIs are
designed such that no script can ever detect the simultaneous execution of other scripts. Even
with workers, the intent is that the behavior of implementations can
be thought of as completely serializing the execution of all scripts in all browsing contexts.

1.5.2 Compliance with other specifications

This section is non-normative.

This specification interacts with and relies on a wide variety of other specifications. In
certain circumstances, unfortunately, conflicting needs have led to this specification violating
the requirements of these other specifications. Whenever this has occurred, the transgressions
have each been noted as a "willful violation", and the reason for the violation has
been noted.

1.5.3 Extensibility

This section is non-normative.

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 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 <script type="">
mechanism with a custom type, for further handling by inline or server-side scripts.

Authors can create plugins and invoke them using the
embed element. This is how Flash works.

Authors can extend APIs using the JavaScript prototyping mechanism. This is widely used by
script libraries, for instance.

1.6 HTML vs XHTML

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 "DOM 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 the HTML syntax. This is the format suggested for most
authors. It is compatible with most legacy Web browsers. If a document is transmitted with the
text/htmlMIME type, then it will be processed as an HTML document by
Web browsers. This specification defines version 5.0 of the HTML syntax, known as "HTML 5".

The second concrete syntax is the XHTML syntax, which is an application of XML. When a document
is transmitted with an XML MIME type, such as application/xhtml+xml,
then it is treated as an XML document by Web browsers, to be parsed by an XML processor. Authors
are reminded that the processing for XML and HTML differs; in particular, even minor syntax errors
will prevent a document labeled as XML from being rendered fully, whereas they would be ignored in
the HTML syntax. This specification defines version 5.0 of the XHTML syntax, known as
"XHTML 5".

The DOM, the HTML syntax, and the XHTML syntax cannot all represent the same content. For
example, namespaces cannot be represented using the HTML syntax, but they are supported in the DOM
and in the XHTML syntax. Similarly, documents that use the noscript feature can be
represented using the HTML syntax, but cannot be represented with the DOM or in the XHTML syntax.
Comments that contain the string "-->" can only be represented in the
DOM, not in the HTML and XHTML syntaxes.

Documents are built from elements. These elements form a tree using the DOM. This section
defines the features of this DOM, as well as introducing the features common to all elements, and
the concepts used in defining elements.

Each element has a predefined meaning, which is explained in this section. Rules for authors
on how to use the element, along with user agent requirements for how to
handle each element, are also given. This includes large signature features of HTML such
as video playback and subtitles, form controls and form submission, and a 2D graphics API known
as the HTML canvas.

HTML documents do not exist in a vacuum — this section defines many of the features
that affect environments that deal with multiple pages, such as Web browsers and offline
caching of Web applications.

All of these features would be for naught if they couldn't be represented in a serialized
form and sent to other people, and so these sections define the syntaxes of HTML and XHTML, along with rules for how to parse content using those syntaxes.

1.7.1 How to read this specification

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.

As described in the conformance requirements section below, this specification describes
conformance criteria for a variety of conformance classes. In particular, there are conformance
requirements that apply to producers, for example authors and the documents they create,
and there are conformance requirements that apply to consumers, for example Web browsers.
They can be distinguished by what they are requiring: a requirement on a producer states what is
allowed, while a requirement on a consumer states how software is to act.

For example, "the foo attribute's value must be a valid
integer" is a requirement on producers, as it lays out the allowed values; in contrast,
the requirement "the foo attribute's value must be parsed using the
rules for parsing integers" is a requirement on consumers, as it describes how to
process the content.

Requirements on producers have no bearing whatsoever on consumers.

Continuing the above example, a requirement stating that a particular attribute's value is
constrained to being a valid integer emphatically does not imply anything
about the requirements on consumers. It might be that the consumers are in fact required to treat
the attribute as an opaque string, completely unaffected by whether the value conforms to the
requirements or not. It might be (as in the previous example) that the consumers are required to
parse the value using specific rules that define how invalid (non-numeric in this case) values
are to be processed.

1.7.2 Typographic conventions

This is a definition, requirement, or explanation.

This is a note.

This is an example.

This is an open issue.

This is a warning.

interface Example {
// this is an IDL definition
};

variable = object . method( [ optionalArgument ] )

This is a note to authors describing the usage of an interface.

/* this is a CSS fragment */

The defining instance of a term is marked up like this. Uses of that
term are marked up like this or like this.

The defining instance of an element, attribute, or API is marked up like this. References to that element, attribute, or API are marked
up like this.

In some cases, requirements are given in the form of lists with conditions and corresponding
requirements. In such cases, the requirements that apply to a condition are always the first set
of requirements that follow the condition, even in the case of there being multiple sets of
conditions for those requirements. Such cases are presented as follows:

This is a condition

This is another condition

This is the requirement that applies to the conditions above.

This is a third condition

This is the requirement that applies to the third condition.

1.8 Privacy concerns

This section is non-normative.

Some features of HTML trade user convenience for a measure of user privacy.

In general, due to the Internet's architecture, a user can be distinguished from another by the
user's IP address. IP addresses do not perfectly match to a user; as a user moves from device to
device, or from network to network, their IP address will change; similarly, NAT routing, proxy
servers, and shared computers enable packets that appear to all come from a single IP address to
actually map to multiple users. Technologies such as onion routing can be used to further
anonymize requests so that requests from a single user at one node on the Internet appear to come
from many disparate parts of the network.

However, the IP address used for a user's requests is not the only mechanism by which a user's
requests could be related to each other. Cookies, for example, are designed specifically to enable
this, and are the basis of most of the Web's session features that enable you to log into a site
with which you have an account.

There are other mechanisms that are more subtle. Certain characteristics of a user's system can
be used to distinguish groups of users from each other; by collecting enough such information, an
individual user's browser's "digital fingerprint" can be computed, which can be as good, if not
better, as an IP address in ascertaining which requests are from the same user.

Grouping requests in this manner, especially across multiple sites, can be used for both benign
(and even arguably positive) purposes, as well as for malevolent purposes. An example of a
reasonably benign purpose would be determining whether a particular person seems to prefer sites
with dog illustrations as opposed to sites with cat illustrations (based on how often they visit
the sites in question) and then automatically using the preferred illustrations on subsequent
visits to participating sites. Malevolent purposes, however, could include governments combining
information such as the person's home address (determined from the addresses they use when getting
driving directions on one site) with their apparent political affiliations (determined by
examining the forum sites that they participate in) to determine whether the person should be
prevented from voting in an election.

Since the malevolent purposes can be remarkably evil, user agent implementors are encouraged to
consider how to provide their users with tools to minimize leaking information that could be used
to fingerprint a user.

Unfortunately, as the first paragraph in this section implies, sometimes there is great benefit
to be derived from exposing the very information that can also be used for fingerprinting
purposes, so it's not as easy as simply blocking all possible leaks. For instance, the ability to
log into a site to post under a specific identity requires that the user's requests be
identifiable as all being from the same user, more or less by definition. More subtly, though,
information such as how wide text is, which is necessary for many effects that involve drawing
text onto a canvas (e.g. any effect that involves drawing a border around the text) also leaks
information that can be used to group a user's requests. (In this case, by potentially exposing,
via a brute force search, which fonts a user has installed, information which can vary
considerably from user to user.)

Features in this specification which can be used to
fingerprint the user are marked as this paragraph is.

Other features in the platform can be used for the same purpose, though, including, though not
limited to:

HTML documents consist of a tree of elements and text. Each element is denoted in the source by
a start tag, such as "<body>", and
an end tag, such as "</body>".
(Certain start tags and end tags can in certain cases be omitted and are implied by other tags.)

Tags have to be nested such that elements are all completely within each other, without
overlapping:

<p>This is <em>very <strong>wrong</em>!</strong></p>

<p>This <em>is <strong>correct</strong>.</em></p>

This specification defines a set of elements that can be used in HTML, along with rules about
the ways in which the elements can be nested.

Elements can have attributes, which control how the elements work. In the example below, there
is a hyperlink, formed using the a element and its href attribute:

<a href="demo.html">simple</a>

Attributes are placed inside the start tag, and consist
of a name and a value, separated by an "=" character.
The attribute value can remain unquoted if it doesn't contain space characters or any of "'`=< or
>. Otherwise, it has to be quoted using either single or double quotes.
The value, along with the "=" character, can be omitted altogether if the
value is the empty string.

The root element of this tree is the html element, which is the
element always found at the root of HTML documents. It contains two elements, head
and body, as well as a Text node between them.

There are many more Text nodes in the DOM tree than one would initially expect,
because the source contains a number of spaces (represented here by "␣") and line breaks
("⏎") that all end up as Text nodes in the DOM. However, for historical
reasons not all of the spaces and line breaks in the original markup appear in the DOM. In
particular, all the whitespace before head start tag ends up being dropped silently,
and all the whitespace after the body end tag ends up placed at the end of the
body.

The head element contains a title element, which itself contains a
Text node with the text "Sample page". Similarly, the body element
contains an h1 element, a p element, and a comment.

This DOM tree can be manipulated from scripts in the page. Scripts (typically in JavaScript)
are small programs that can be embedded using the script element or using event
handler content attributes. For example, here is a form with a script that sets the value
of the form's output element to say "Hello World":

Each element in the DOM tree is represented by an object, and these objects have APIs so that
they can be manipulated. For instance, a link (e.g. the a element in the tree above)
can have its "href" attribute changed in several
ways:

var a = document.links[0]; // obtain the first link in the document
a.href = 'sample.html'; // change the destination URL of the link
a.protocol = 'https'; // change just the scheme part of the URL
a.setAttribute('href', 'http://example.com/'); // change the content attribute directly

Since DOM trees are used as the way to represent HTML documents when they are processed and
presented by implementations (especially interactive implementations like Web browsers), this
specification is mostly phrased in terms of DOM trees, instead of the markup described above.

HTML documents represent a media-independent description of interactive content. HTML documents
might be rendered to a screen, or through a speech synthesizer, or on a braille display. To
influence exactly how such rendering takes place, authors can use a styling language such as
CSS.

In the following example, the page has been made yellow-on-blue using CSS.

For more details on how to use HTML, authors are encouraged to consult tutorials and guides.
Some of the examples included in this specification might also be of use, but the novice author is
cautioned that this specification, by necessity, defines the language with a level of detail that
might be difficult to understand at first.

1.9.1 Writing secure applications with HTML

This section is non-normative.

When HTML is used to create interactive sites, care needs to be taken to avoid introducing
vulnerabilities through which attackers can compromise the integrity of the site itself or of the
site's users.

A comprehensive study of this matter is beyond the scope of this document, and authors are
strongly encouraged to study the matter in more detail. However, this section attempts to provide
a quick introduction to some common pitfalls in HTML application development.

The security model of the Web is based on the concept of "origins", and correspondingly many of
the potential attacks on the Web involve cross-origin actions. [ORIGIN]

Not validating user input

Cross-site scripting (XSS)

SQL injection

When accepting untrusted input, e.g. user-generated content such as text comments, values in
URL parameters, messages from third-party sites, etc, it is imperative that the data be
validated before use, and properly escaped when displayed. Failing to do this can allow a
hostile user to perform a variety of attacks, ranging from the potentially benign, such as
providing bogus user information like a negative age, to the serious, such as running scripts
every time a user looks at a page that includes the information, potentially propagating the
attack in the process, to the catastrophic, such as deleting all data in the server.

When writing filters to validate user input, it is imperative that filters always be
whitelist-based, allowing known-safe constructs and disallowing all other input. Blacklist-based
filters that disallow known-bad inputs and allow everything else are not secure, as not
everything that is bad is yet known (for example, because it might be invented in the
future).

For example, suppose a page looked at its URL's query string to determine what to display,
and the site then redirected the user to that page to display a message, as in:

If the attacker then convinced a victim user to visit this page, a script of the attacker's
choosing would run on the page. Such a script could do any number of hostile actions, limited
only by what the site offers: if the site is an e-commerce shop, for instance, such a script
could cause the user to unknowingly make arbitrarily many unwanted purchases.

This is called a cross-site scripting attack.

There are many constructs that can be used to try to trick a site into executing code. Here
are some that authors are encouraged to consider when writing whitelist filters:

When allowing harmless-seeming elements like img, it is important to whitelist
any provided attributes as well. If one allowed all attributes then an attacker could, for
instance, use the onload attribute to run arbitrary
script.

When allowing URLs to be provided (e.g. for links), the scheme of each URL also needs to be
explicitly whitelisted, as there are many schemes that can be abused. The most prominent
example is "javascript:", but user agents can
implement (and indeed, have historically implemented) others.

Allowing a base element to be inserted means any script elements
in the page with relative links can be hijacked, and similarly that any form submissions can
get redirected to a hostile site.

Cross-site request forgery (CSRF)

If a site allows a user to make form submissions with user-specific side-effects, for example
posting messages on a forum under the user's name, making purchases, or applying for a passport,
it is important to verify that the request was made by the user intentionally, rather than by
another site tricking the user into making the request unknowingly.

This problem exists because HTML forms can be submitted to other origins.

Sites can prevent such attacks by populating forms with user-specific hidden tokens, or by
checking Origin headers on all requests.

Clickjacking

A page that provides users with an interface to perform actions that the user might not wish
to perform needs to be designed so as to avoid the possibility that users can be tricked into
activating the interface.

One way that a user could be so tricked is if a hostile site places the victim site in a
small iframe and then convinces the user to click, for instance by having the user
play a reaction game. Once the user is playing the game, the hostile site can quickly position
the iframe under the mouse cursor just as the user is about to click, thus tricking the user
into clicking the victim site's interface.

To avoid this, sites that do not expect to be used in frames are encouraged to only enable
their interface if they detect that they are not in a frame (e.g. by comparing the window object to the value of the top
attribute).

1.9.2 Common pitfalls to avoid when using the scripting APIs

This section is non-normative.

Scripts in HTML have "run-to-completion" semantics, meaning that the browser will generally run
the script uninterrupted before doing anything else, such as firing further events or continuing
to parse the document.

On the other hand, parsing of HTML files happens asynchronously and incrementally, meaning that
the parser can pause at any point to let scripts run. This is generally a good thing, but it does
mean that authors need to be careful to avoid hooking event handlers after the events could have
possibly fired.

There are two techniques for doing this reliably: use event handler content
attributes, or create the element and add the event handlers in the same script. The latter
is safe because, as mentioned earlier, scripts are run to completion before further events can
fire.

One way this could manifest itself is with img elements and the load event. The event could fire as soon as the element has been
parsed, especially if the image has already been cached (which is common).

Here, the author uses the onload handler on an
img element to catch the load event:

<img src="games.png" alt="Games" onload="gamesLogoHasLoaded(event)">

If the element is being added by script, then so long as the event handlers are added in the
same script, the event will still not be missed:

However, if the author first created the img element and then in a separate
script added the event listeners, there's a chance that the load
event would be fired in between, leading it to be missed:

<!-- Do not use this style, it has a race condition! -->
<img id="games" src="games.png" alt="Games">
<!-- the 'load' event might fire here while the parser is taking a
break, in which case you will not see it! -->
<script>
var img = document.getElementById('games');
img.onload = gamesLogoHasLoaded; // might never fire!
</script>

1.9.3 How to catch mistakes when writing HTML: validators and conformance checkers

This section is non-normative.

Authors are encouraged to make use of conformance checkers (also known as validators) to
catch common mistakes. The W3C provides a number of online validation services, including the Nu Markup Validation Service.

1.10 Conformance requirements for authors

This section is non-normative.

Unlike previous versions of the HTML specification, this specification defines in some detail
the required processing for invalid documents as well as valid documents.

However, even though the processing of invalid content is in most cases well-defined,
conformance requirements for documents are still important: in practice, interoperability (the
situation in which all implementations process particular content in a reliable and identical or
equivalent way) is not the only goal of document conformance requirements. This section details
some of the more common reasons for still distinguishing between a conforming document and one
with errors.

1.10.1 Presentational markup

This section is non-normative.

The majority of presentational features from previous versions of HTML are no longer allowed.
Presentational markup in general has been found to have a number of problems:

The use of presentational elements leads to poorer accessibility

While it is possible to use presentational markup in a way that provides users of assistive
technologies (ATs) with an acceptable experience (e.g. using ARIA), doing so is significantly
more difficult than doing so when using semantically-appropriate markup. Furthermore, even using
such techniques doesn't help make pages accessible for non-AT non-graphical users, such as users
of text-mode browsers.

Using media-independent markup, on the other hand, provides an easy way for documents to be
authored in such a way that they work for more users (e.g. text browsers).

Higher cost of maintenance

It is significantly easier to maintain a site written in such a way that the markup is
style-independent. For example, changing the color of a site that uses
<font color=""> throughout requires changes across the entire site, whereas
a similar change to a site based on CSS can be done by changing a single file.

Larger document sizes

Presentational markup tends to be much more redundant, and thus results in larger document
sizes.

For those reasons, presentational markup has been removed from HTML in this version. This
change should not come as a surprise; HTML4 deprecated presentational markup many years ago and
provided a mode (HTML4 Transitional) to help authors move away from presentational markup; later,
XHTML 1.1 went further and obsoleted those features altogether.

The only remaining presentational markup features in HTML are the style attribute and the style element. Use of the style attribute is somewhat discouraged in production environments, but
it can be useful for rapid prototyping (where its rules can be directly moved into a separate
style sheet later) and for providing specific styles in unusual cases where a separate style sheet
would be inconvenient. Similarly, the style element can be useful in syndication or
for page-specific styles, but in general an external style sheet is likely to be more convenient
when the styles apply to multiple pages.

It is also worth noting that some elements that were previously presentational have been
redefined in this specification to be media-independent: b, i,
hr, s, small, and u.

1.10.2 Syntax errors

This section is non-normative.

The syntax of HTML is constrained to avoid a wide variety of problems.

Unintuitive error-handling behavior

Certain invalid syntax constructs, when parsed, result in DOM trees that are highly
unintuitive.

For example, the following markup fragment results in a DOM with an hr element
that is an earlier sibling of the corresponding table element:

<table><hr>...

Errors with optional error recovery

To allow user agents to be used in controlled environments without having to implement the
more bizarre and convoluted error handling rules, user agents are permitted to fail whenever
encountering a parse error.

Errors where the error-handling behavior is not compatible with streaming user agents

Some error-handling behavior, such as the behavior for the <table><hr>... example mentioned above, are incompatible with streaming
user agents (user agents that process HTML files in one pass, without storing state). To avoid
interoperability problems with such user agents, any syntax resulting in such behavior is
considered invalid.

Errors that can result in infoset coercion

When a user agent based on XML is connected to an HTML parser, it is possible that certain
invariants that XML enforces, such as comments never containing two consecutive hyphens, will be
violated by an HTML file. Handling this can require that the parser coerce the HTML DOM into an
XML-compatible infoset. Most syntax constructs that require such handling are considered
invalid.

Errors that result in disproportionally poor performance

Certain syntax constructs can result in disproportionally poor performance. To discourage the
use of such constructs, they are typically made non-conforming.

For example, the following markup results in poor performance, since all the unclosed
i elements have to be reconstructed in each paragraph, resulting in progressively
more elements in each paragraph:

There are syntax constructs that, for historical reasons, are relatively fragile. To help
reduce the number of users who accidentally run into such problems, they are made
non-conforming.

For example, the parsing of certain named character references in attributes happens even
with the closing semicolon being omitted. It is safe to include an ampersand followed by
letters that do not form a named character reference, but if the letters are changed to a
string that does form a named character reference, they will be interpreted as that
character instead.

Certain syntax constructs are known to cause especially subtle or serious problems in legacy
user agents, and are therefore marked as non-conforming to help authors avoid them.

For example, this is why the "`" (U+0060) character is not allowed in unquoted
attributes. In certain legacy user agents, it is sometimes treated as a
quote character.

Another example of this is the DOCTYPE, which is required to trigger no-quirks
mode, because the behavior of legacy user agents in quirks mode is often
largely undocumented.

Errors that risk exposing authors to security attacks

Certain restrictions exist purely to avoid known security problems.

For example, the restriction on using UTF-7 exists purely to avoid authors falling prey to a
known cross-site-scripting attack using UTF-7. [UTF7]

Cases where the author's intent is unclear

Markup where the author's intent is very unclear is often made non-conforming. Correcting
these errors early makes later maintenance easier.

For example, it is unclear whether the author intended the following to be an
h1 heading or an h2 heading:

<h1>Contact details</h2>

Cases that are likely to be typos

When a user makes a simple typo, it is helpful if the error can be caught early, as this can
save the author a lot of debugging time. This specification therefore usually considers it an
error to use element names, attribute names, and so forth, that do not match the names defined
in this specification.

For example, if the author typed <capton> instead of
<caption>, this would be flagged as an error and the author could correct the
typo immediately.

Errors that could interfere with new syntax in the future

In order to allow the language syntax to be extended in the future, certain otherwise
harmless features are disallowed.

For example, "attributes" in end tags are ignored currently, but they are invalid, in case a
future change to the language makes use of that syntax feature without conflicting with
already-deployed (and valid!) content.

Some authors find it helpful to be in the practice of always quoting all attributes and always
including all optional tags, preferring the consistency derived from such custom over the minor
benefits of terseness afforded by making use of the flexibility of the HTML syntax. To aid such
authors, conformance checkers can provide modes of operation wherein such conventions are
enforced.

1.10.3 Restrictions on content models and on attribute values

This section is non-normative.

Beyond the syntax of the language, this specification also places restrictions on how elements
and attributes can be specified. These restrictions are present for similar reasons:

Errors involving content with dubious semantics

To avoid misuse of elements with defined meanings, content models are defined that restrict
how elements can be nested when such nestings would be of dubious value.

For example, this specification disallows nesting a section
element inside a kbd element, since it is highly unlikely for an author to indicate
that an entire section should be keyed in.

Errors that involve a conflict in expressed semantics

Similarly, to draw the author's attention to mistakes in the use of elements, clear
contradictions in the semantics expressed are also considered conformance errors.

In the fragments below, for example, the semantics are nonsensical: a separator cannot
simultaneously be a cell, nor can a radio button be a progress bar.

<hr role="cell">

<input type=radio role=progressbar>

Another example is the restrictions on the content models of the
ul element, which only allows li element children. Lists by definition
consist just of zero or more list items, so if a ul element contains something
other than an li element, it's not clear what was meant.

Cases where the default styles are likely to lead to confusion

Certain elements have default styles or behaviors that make certain combinations likely to
lead to confusion. Where these have equivalent alternatives without this problem, the confusing
combinations are disallowed.

For example, div elements are rendered as block boxes, and
span elements as inline boxes. Putting a block box in an inline box is
unnecessarily confusing; since either nesting just div elements, or nesting just
span elements, or nesting span elements inside div
elements all serve the same purpose as nesting a div element in a span
element, but only the latter involves a block box in an inline box, the latter combination is
disallowed.

Another example would be the way interactive content cannot be
nested. For example, a button element cannot contain a textarea
element. This is because the default behavior of such nesting interactive elements would be
highly confusing to users. Instead of nesting these elements, they can be placed side by
side.

Errors that indicate a likely misunderstanding of the specification

Sometimes, something is disallowed because allowing it would likely cause author
confusion.

For example, setting the disabled
attribute to the value "false" is disallowed, because despite the
appearance of meaning that the element is enabled, it in fact means that the element is
disabled (what matters for implementations is the presence of the attribute, not its
value).

Errors involving limits that have been imposed merely to simplify the language

Some conformance errors simplify the language that authors need to learn.

For example, the area element's shape attribute, despite accepting both circ and circle values in practice as synonyms, disallows
the use of the circ value, so as to simplify
tutorials and other learning aids. There would be no benefit to allowing both, but it would
cause extra confusion when teaching the language.

Errors that involve peculiarities of the parser

Certain elements are parsed in somewhat eccentric ways (typically for historical reasons),
and their content model restrictions are intended to avoid exposing the author to these
issues.

For example, a form element isn't allowed inside phrasing content,
because when parsed as HTML, a form element's start tag will imply a
p element's end tag. Thus, the following markup results in two paragraphs, not one:

<p>Welcome. <form><label>Name:</label> <input></form>

It is parsed exactly like the following:

<p>Welcome. </p><form><label>Name:</label> <input></form>

Errors that would likely result in scripts failing in hard-to-debug ways

Some errors are intended to help prevent script problems that would be hard to debug.

This is why, for instance, it is non-conforming to have two id attributes with the same value. Duplicate IDs lead to the wrong
element being selected, with sometimes disastrous effects whose cause is hard to determine.

Errors that waste authoring time

Some constructs are disallowed because historically they have been the cause of a lot of
wasted authoring time, and by encouraging authors to avoid making them, authors can save time in
future efforts.

For example, a script element's src attribute causes the element's contents to be ignored.
However, this isn't obvious, especially if the element's contents appear to be executable script
— which can lead to authors spending a lot of time trying to debug the inline script
without realizing that it is not executing. To reduce this problem, this specification makes it
non-conforming to have executable script in a script element when the src attribute is present. This means that authors who are
validating their documents are less likely to waste time with this kind of mistake.

Errors that involve areas that affect authors migrating to and from XHTML

Some authors like to write files that can be interpreted as both XML and HTML with similar
results. Though this practice is discouraged in general due to the myriad of subtle
complications involved (especially when involving scripting, styling, or any kind of automated
serialization), this specification has a few restrictions intended to at least somewhat mitigate
the difficulties. This makes it easier for authors to use this as a transitionary step when
migrating between HTML and XHTML.

For example, there are somewhat complicated rules surrounding the lang and xml:lang attributes
intended to keep the two synchronized.

Another example would be the restrictions on the values of xmlns attributes in the HTML serialization, which are intended to ensure that
elements in conforming documents end up in the same namespaces whether processed as HTML or
XML.

Errors that involve areas reserved for future expansion

As with the restrictions on the syntax intended to allow for new syntax in future revisions
of the language, some restrictions on the content models of elements and values of attributes
are intended to allow for future expansion of the HTML vocabulary.

For example, limiting the values of the target attribute that start with an "_" (U+005F) character to only specific predefined values allows new predefined values to be introduced
at a future time without conflicting with author-defined values.

Errors that indicate a mis-use of other specifications

Certain restrictions are intended to support the restrictions made by other
specifications.

For example, requiring that attributes that take media queries use only
valid media queries reinforces the importance of following the conformance rules of
that specification.

1.11 Suggested reading

This section is non-normative.

The following documents might be of interest to readers of this specification.

This Architectural Specification provides authors of specifications, software
developers, and content developers with a common reference for interoperable text manipulation on
the World Wide Web, building on the Universal Character Set, defined jointly by the Unicode
Standard and ISO/IEC 10646. Topics addressed include use of the terms 'character', 'encoding' and
'string', a reference processing model, choice and identification of character encodings,
character escaping, and string indexing.

Because Unicode contains such a large number of characters and incorporates
the varied writing systems of the world, incorrect usage can expose programs or systems to
possible security attacks. This is especially important as more and more products are
internationalized. This document describes some of the security considerations that programmers,
system analysts, standards developers, and users should take into account, and provides specific
recommendations to reduce the risk of problems.

Web Content Accessibility Guidelines (WCAG) 2.0 covers a wide range of
recommendations for making Web content more accessible. Following these guidelines will make
content accessible to a wider range of people with disabilities, including blindness and low
vision, deafness and hearing loss, learning disabilities, cognitive limitations, limited
movement, speech disabilities, photosensitivity and combinations of these. Following these
guidelines will also often make your Web content more usable to users in
general.

This specification provides guidelines for designing Web content
authoring tools that are more accessible for people with disabilities. An authoring tool that
conforms to these guidelines will promote accessibility by providing an accessible user interface
to authors with disabilities as well as by enabling, supporting, and promoting the production of
accessible Web content by all authors.

This document provides guidelines for designing user agents that
lower barriers to Web accessibility for people with disabilities. User agents include browsers
and other types of software that retrieve and render Web content. A user agent that conforms to
these guidelines will promote accessibility through its own user interface and through other
internal facilities, including its ability to communicate with other technologies (especially
assistive technologies). Furthermore, all users, not just users with disabilities, should find
conforming user agents to be more usable.

A document that uses polyglot markup is a document
that is a stream of bytes that parses into identical document trees
(with the exception of the xmlns attribute on the root element)
when processed as HTML and when processed as XML. Polyglot markup
that meets a well defined set of constraints is interpreted as
compatible, regardless of whether they are processed as HTML or as
XHTML, per the HTML5 specification. Polyglot markup uses a specific
DOCTYPE, namespace declarations, and a specific case —
normally lower case but occasionally camel case — for element
and attribute names. Polyglot markup uses lower case for certain
attribute values. Further constraints include those on empty
elements, named entity references, and the use of scripts and
style.

This is draft documentation mapping HTML
elements and attributes to accessibility API Roles, States and
Properties on a variety of platforms. It provides recommendations
on deriving the accessible names and descriptions for HTML
elements. It also provides accessible feature implementation
examples.

2 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
specification, and refer specifically to two different modes that Document objects
can find themselves in. [DOM] (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.

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 specification, refer to as a
representation is referred to in this specification as a resource. [HTTP]

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]

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 http://www.w3.org/1999/xhtml 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 ("http://www.w3.org/1999/xhtml"), 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
typestext/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.

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. A 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 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. [DOM]

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.

Since different users having differents sets of plugins provides a
fingerprinting vector that increases the chances of users being uniquely identified, user agents
are encouraged to support the exact same set of plugins for each
user.

2.1.6 Character encodings

A character encoding, or just encoding where that is not
ambiguous, is a defined way to convert between byte streams and Unicode strings, as defined in the
Encoding standard. An encoding has an encoding name and one or more
encoding labels, referred to as the encoding's name and
labels in the Encoding specification. [ENCODING]

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 Windows-1252. [ENCODING]

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 UTF-16 variants, as well as
obsolete legacy encodings such as UTF-7, GSM03.38, and EBCDIC variants.

The term a UTF-16 encoding refers to any variant of UTF-16: UTF-16LE or UTF-16BE,
regardless of the presence or absence of a BOM. [ENCODING]

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, and is not the same as a code point.) [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 an orange, the user must:
1. Peel the orange.
2. Separate each slice of the orange.
3. Eat the orange slices.

...it would be equivalent to the following:

To eat an orange:
1. The user must peel the orange.
2. The user must separate each slice of the orange.
3. The user must eat the orange slices.

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 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.

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 "HTML 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 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, b, i, 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.

Unicode and Encoding

The Unicode character set is used to represent textual data, and the Encoding standard
defines requirements around character encodings. [UNICODE]

This specification introduces terminology
based on the terms defined in those specifications, as described earlier.

The following terms are used as defined in the Encoding specification: [ENCODING]

Getting an encoding

The encoder and decoder algorithms for various encodings, including
the UTF-8 encoder and UTF-8 decoder

The generic decode algorithm which takes a byte stream and an encoding and
returns a character stream

The UTF-8 decode algorithm which takes a byte stream and returns a character
stream, additionally stripping one leading UTF-8 Byte Order Mark (BOM), if any

The UTF-8 decoder is distinct from the UTF-8 decode
algorithm. The latter first strips a Byte Order Mark (BOM), if any, and then invokes the
former.

For readability, character encodings are sometimes referenced in this specification with a
case that differs from the canonical case given in the encoding standard. (For example,
"UTF-16LE" instead of "utf-16le".)

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]

The IDL blocks in this specification are conforming IDL fragments as defined by the WebIDL
specification. [WEBIDL]

The terms 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 resulting truncated time.

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.

The ECMAScript SyntaxError exception is also
defined in the ECMAScript specification. [ECMA262]

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. [DOM]

Implementations must support DOM 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 interfaces. [DOM][DOMEVENTS]

In particular, the following features are defined in the DOM specification: [DOM]

The concept of a regular event parent and a cross-boundary event parent

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 a 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 MutationObserverscripting environment concept

The invoke MutationObserver objects algorithm

Promise interface

The resolver concept

The fulfill and reject algorithms

The term throw in this specification is used as defined in the DOM specification.
The following DOMException types are defined in the DOM specification: [DOM]

IndexSizeError

HierarchyRequestError

WrongDocumentError

InvalidCharacterError

NoModificationAllowedError

NotFoundError

NotSupportedError

InvalidStateError

SyntaxError

InvalidModificationError

NamespaceError

InvalidAccessError

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 following features are defined in the DOM Events specification: [DOMEVENTS]

MouseEvent interface

MouseEventInit dictionary type

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

User agents are also encouraged to implement the
features described in the HTML Editing APIs and
UndoManager and DOM Transaction
specifications.
[EDITING][UNDO]

The following parts of the Fullscreen specification are referenced from this specification
to define how the Fullscreen API interacts with the sandboxing features in HTML: [FULLSCREEN]

The top layer concept

requestFullscreen()

The fullscreen enabled flag

The fully exit fullscreen algorithm

Typed Arrays

The ArrayBuffer and ArrayBufferView interfaces 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 features defined in the File API specification: [FILEAPI]

Blob

File

FileList

Blob.close()

Blob.type

The concept of read errors

XMLHttpRequest

This specification references the XMLHttpRequest specification in some non-normative notes
and examples. The following features and terms are defined in the XMLHttpRequest specification:
[XHR]

XMLHttpRequest

Progress Events

This specification references the Progress Events specification to describe how the two
specifications interact and to use its ProgressEvent features. The following
features and terms are defined in the Progress Events specification: [PROGRESS-EVENTS]

ProgressEvent

Fire a progress event named e

Server-Sent Events

This specification references EventSource which is specified
in the Server-Sent Events specification [EVENTSOURCE]

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 <color>
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 CSS element reference identifier is used as defined in the CSS
Image Values and Replaced Content specification to define the API that declares
identifiers for use with the CSS 'element()' function. [CSSIMAGES]

Similarly, 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]

The term default object size is also defined in the CSS Image Values and
Replaced Content specification. [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]

The following interface is defined in the WebGL specification: [WEBGL]

WebGLRenderingContext

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

The rules for updating the display of WebVTT text tracks

The rules for interpreting WebVTT cue text

The WebVTT text track cue writing direction

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

Vendor-specific proprietary user agent extensions to this specification are strongly
discouraged. Documents must not use such extensions, as doing so reduces interoperability and
fragments the user base, allowing only users of specific user agents to access the content in
question.

If such extensions are nonetheless needed, e.g. for experimental purposes, then vendors are
strongly urged to use one of the following extension mechanisms:

For markup-level features that can be limited to the XML serialization and need not be
supported in the HTML serialization, vendors should use the namespace mechanism to define custom
namespaces in which the non-standard elements and attributes are supported.

For markup-level features that are intended for use with the HTML syntax,
extensions should be limited to new attributes of the form "x-vendor-feature", where vendor is a
short string that identifies the vendor responsible for the extension, and feature is the name of the feature. New element names should not be created.
Using attributes for such extensions exclusively allows extensions from multiple vendors to
co-exist on the same element, which would not be possible with elements. Using the "x-vendor-feature" form allows extensions
to be made without risk of conflicting with future additions to the specification.

For instance, a browser named "FerretBrowser" could use "ferret" as a vendor prefix, while a
browser named "Mellblom Browser" could use "mb". If both of these browsers invented extensions
that turned elements into scratch-and-sniff areas, an author experimenting with these features
could write:

Attribute names beginning with the two characters "x-" are reserved for
user agent use and are guaranteed to never be formally added to the HTML language. For
flexibility, attributes names containing underscores (the U+005F LOW LINE character) are also
reserved for experimental purposes and are guaranteed to never be formally added to the HTML
language.

Pages that use such attributes are by definition non-conforming.

For DOM extensions, e.g. new methods and IDL attributes, the new members should be prefixed by
vendor-specific strings to prevent clashes with future versions of this specification.

For events, experimental event types should be prefixed with vendor-specific strings.

For example, if a user agent called "Pleasold" were to add an event to indicate when
the user is going up in an elevator, it could use the prefix "pleasold" and
thus name the event "pleasoldgoingup", possibly with an event handler
attribute named "onpleasoldgoingup".

All extensions must be defined so that the use of extensions neither contradicts nor causes the
non-conformance of functionality defined in the specification.

For example, while strongly discouraged from doing so, an implementation "Foo Browser" could
add a new IDL attribute "fooTypeTime" to a control's DOM interface that
returned the time it took the user to select the current value of a control (say). On the other
hand, defining a new control that appears in a form's elements array would be in violation of the above requirement,
as it would violate the definition of elements given in
this specification.

When adding new reflecting IDL attributes corresponding to content
attributes of the form "x-vendor-feature", the IDL attribute should be named "vendorFeature" (i.e. the "x" is
dropped from the IDL attribute's name).

When vendor-neutral extensions to this specification are needed, either this specification can
be updated accordingly, or an extension specification can be written that overrides the
requirements in this specification. When someone applying this specification to their activities
decides that they will recognize the requirements of such an extension specification, it becomes an
applicable
specification.

The conformance terminology for documents depends on the nature
of the changes introduced by such applicable specifications, and on
the content and intended interpretation of the document. Applicable
specifications MAY define new document content (e.g. a foobar
element), MAY prohibit certain otherwise conforming content (e.g.
prohibit use of <table>s), or MAY change the semantics, DOM
mappings, or other processing rules for content defined in this
specification. Whether a document is or is not a conforming HTML5 document does not
depend on the use of applicable specifications: if the syntax and
semantics of a given conforming
HTML5 document is unchanged by the use of applicable
specification(s), then that document remains a conforming HTML5 document. If the
semantics or processing of a given (otherwise conforming) document
is changed by use of applicable specification(s), then it is not a
conforming HTML5 document. For
such cases, the applicable specifications SHOULD define conformance
terminology.

As a suggested but not required convention, such
specifications might define conformance terminology such as:
"Conforming HTML5+XXX document", where XXX is a short
name for the applicable specification. (Example: "Conforming
HTML5+AutomotiveExtensions document").

a consequence of the rule given above is that
certain syntactically correct HTML5 documents may not be conforming HTML5 documents in the
presence of applicable specifications. (Example: the applicable
specification defines <table> to be a piece of furniture —
a document written to that specification and containing a <table>
element is NOT a conforming HTML5
document, even if the element happens to be syntactically
correct HTML5.)

User agents must treat elements and attributes that they do not understand as semantically
neutral; leaving them in the DOM (for DOM processors), and styling them according to CSS (for CSS
processors), but not inferring any meaning from them.

When support for a feature is disabled (e.g. as an emergency measure to mitigate a security
problem, or to aid in development, or for performance reasons), user agents must act as if they
had no support for the feature whatsoever, and as if the feature was not mentioned in this
specification. For example, if a particular feature is accessed via an attribute in a Web IDL
interface, the attribute itself would be omitted from the objects that implement that interface
— leaving the attribute on the object but making it return null or throw an exception is
insufficient.

2.2.4 Interactions with XPath and XSLT

Implementations of XPath 1.0 that operate on HTML
documents parsed or created in the manners described in this specification (e.g. as part of
the document.evaluate() API) must act as if the following edit was applied
to the XPath 1.0 specification.

First, remove this paragraph:

A QName in the node test is expanded
into an expanded-name
using the namespace declarations from the expression context. This is the same way expansion is
done for element type names in start and end-tags except that the default namespace declared with
xmlns is not used: if the QName does not have a prefix, then the
namespace URI is null (this is the same way attribute names are expanded). It is an error if the
QName has a prefix for which there is
no namespace declaration in the expression context.

Then, insert in its place the following:

A QName in the node test is expanded into an expanded-name using the namespace declarations
from the expression context. If the QName has a prefix, then there must be a namespace declaration for this prefix in
the expression context, and the corresponding namespace URI is the one that is
associated with this prefix. It is an error if the QName has a prefix for which there is no
namespace declaration in the expression context.

If the QName has no prefix and the principal node type of the axis is element, then the
default element namespace is used. Otherwise if the QName has no prefix, the namespace URI is
null. The default element namespace is a member of the context for the XPath expression. The
value of the default element namespace when executing an XPath expression through the DOM3 XPath
API is determined in the following way:

If the context node is from an HTML DOM, the default element namespace is
"http://www.w3.org/1999/xhtml".

Otherwise, the default element namespace URI is null.

This is equivalent to adding the default element namespace feature of XPath 2.0
to XPath 1.0, and using the HTML namespace as the default element namespace for HTML documents.
It is motivated by the desire to have implementations be compatible with legacy HTML content
while still supporting the changes that this specification introduces to HTML regarding the
namespace used for HTML elements, and by the desire to use XPath 1.0 rather than XPath 2.0.

This change is a willful violation of the XPath 1.0 specification,
motivated by desire to have implementations be compatible with legacy content while still
supporting the changes that this specification introduces to HTML regarding which namespace is
used for HTML elements. [XPATH10]

XSLT 1.0 processors outputting to a DOM when the output
method is "html" (either explicitly or via the defaulting rule in XSLT 1.0) are affected as
follows:

If the transformation program outputs an element in no namespace, the processor must, prior to
constructing the corresponding DOM element node, change the namespace of the element to the
HTML namespace, ASCII-lowercase the
element's local name, and ASCII-lowercase the
names of any non-namespaced attributes on the element.

This requirement is a willful violation of the XSLT 1.0
specification, required because this specification changes the namespaces and case-sensitivity
rules of HTML in a manner that would otherwise be incompatible with DOM-based XSLT
transformations. (Processors that serialize the output are unaffected.) [XSLT10]

This specification does not specify precisely how XSLT processing interacts with the HTML
parser infrastructure (for example, whether an XSLT processor acts as if it puts any
elements into a stack of open elements). However, XSLT processors must stop
parsing if they successfully complete, and must set the current document
readiness first to "interactive" and then to "complete" if they are aborted.

This specification does not specify how XSLT interacts with the navigation algorithm, how it fits in with the event loop, nor
how error pages are to be handled (e.g. whether XSLT errors are to replace an incremental XSLT
output, or are rendered inline, etc).

2.3 Case-sensitivity and string comparison

Comparing two strings in a case-sensitive manner means comparing them exactly, code
point for code point.

Comparing two strings in an ASCII case-insensitive manner means comparing them
exactly, code point for code point, except that the characters in the range U+0041 to U+005A (i.e.
LATIN CAPITAL LETTER A to LATIN CAPITAL LETTER Z) and the corresponding characters in the range
U+0061 to U+007A (i.e. LATIN SMALL LETTER A to LATIN SMALL LETTER Z) are considered to also
match.

Comparing two strings in a compatibility caseless manner means using the Unicode
compatibility caseless match operation to compare the two strings, with no language-specific tailoirings. [UNICODE]

Except where otherwise stated, string comparisons must be performed in a
case-sensitive manner.

Converting a string to ASCII uppercase means
replacing all characters in the range U+0061 to U+007A (i.e. LATIN SMALL LETTER A to LATIN SMALL
LETTER Z) with the corresponding characters in the range U+0041 to U+005A (i.e. LATIN CAPITAL
LETTER A to LATIN CAPITAL LETTER Z).

Converting a string to ASCII lowercase means
replacing all characters in the range U+0041 to U+005A (i.e. LATIN CAPITAL LETTER A to LATIN
CAPITAL LETTER Z) with the corresponding characters in the range U+0061 to U+007A (i.e. LATIN
SMALL LETTER A to LATIN SMALL LETTER Z).

A string pattern is a prefix match for a string s when pattern is not longer than s and
truncating s to pattern's length leaves the two strings as
matches of each other.

2.4 Common microsyntaxes

There are various places in HTML that accept particular data types, such as dates or numbers.
This section describes what the conformance criteria for content in those formats is, and how to
parse them.

Implementors are strongly urged to carefully examine any third-party libraries
they might consider using to implement the parsing of syntaxes described below. For example, date
libraries are likely to implement error handling behavior that differs from what is required in
this specification, since error-handling behavior is often not defined in specifications that
describe date syntaxes similar to those used in this specification, and thus implementations tend
to vary greatly in how they handle errors.

2.4.1 Common parser idioms

The space characters, for the purposes of this
specification, are U+0020 SPACE, "tab" (U+0009), "LF" (U+000A), "FF" (U+000C), and "CR" (U+000D).

The White_Space characters are those that have the Unicode
property "White_Space" in the Unicode PropList.txt data file. [UNICODE]

This should not be confused with the "White_Space" value (abbreviated "WS") of the
"Bidi_Class" property in the Unicode.txt data file.

The control characters are those whose Unicode "General_Category" property has the
value "Cc" in the Unicode UnicodeData.txt data file. [UNICODE]

The ASCII hex digits are the characters in the ranges ASCII digits, U+0041 LATIN CAPITAL LETTER A to U+0046 LATIN CAPITAL LETTER F, and U+0061
LATIN SMALL LETTER A to U+0066 LATIN SMALL LETTER F.

The uppercase ASCII hex digits are the characters in the ranges ASCII digits and U+0041 LATIN CAPITAL LETTER A to U+0046 LATIN CAPITAL LETTER F only.

The lowercase ASCII hex digits are the characters in the ranges ASCII digits and U+0061 LATIN SMALL LETTER A to U+0066 LATIN SMALL LETTER F
only.

Some of the micro-parsers described below follow the pattern of having an input variable that holds the string being parsed, and having a position variable pointing at the next character to parse in input.

For parsers based on this pattern, a step that requires the user agent to collect a
sequence of characters means that the following algorithm must be run, with characters being the set of characters that can be collected:

Let input and position be the same variables as
those of the same name in the algorithm that invoked these steps.

Let result be the empty string.

While position doesn't point past the end of input
and the character at position is one of the characters,
append that character to the end of result and advance position to the next character in input.

2.4.3 Keywords and enumerated attributes

Some attributes are defined as taking one of a finite set of keywords. Such attributes are
called enumerated attributes. The keywords are each
defined to map to a particular state (several keywords might map to the same state, in
which case some of the keywords are synonyms of each other; additionally, some of the keywords can
be said to be non-conforming, and are only in the specification for historical reasons). In
addition, two default states can be given. The first is the invalid value default, the
second is the missing value default.

If an enumerated attribute is specified, the attribute's value must be an ASCII
case-insensitive match for one of the given keywords that are not said to be
non-conforming, with no leading or trailing whitespace.

When the attribute is specified, if its value is an ASCII case-insensitive match
for one of the given keywords then that keyword's state is the state that the attribute
represents. If the attribute value matches none of the given keywords, but the attribute has an
invalid value default, then the attribute represents that state. Otherwise, if the
attribute value matches none of the keywords but there is a missing value default state
defined, then that is the state represented by the attribute. Otherwise, there is no
default, and invalid values mean that there is no state represented.

When the attribute is not specified, if there is a missing value default state
defined, then that is the state represented by the (missing) attribute. Otherwise, the absence of
the attribute means that there is no state represented.

The empty string can be a valid keyword.

2.4.4 Numbers

2.4.4.1 Signed integers

A string is a valid integer if it consists of one or more ASCII digits,
optionally prefixed with a "-" (U+002D) character.

A valid integer without a "-" (U+002D) prefix represents the number
that is represented in base ten by that string of digits. A valid integerwith a "-" (U+002D) prefix represents the number represented in base ten by
the string of digits that follows the U+002D HYPHEN-MINUS, subtracted from zero.

The rules for parsing integers are as given in the following algorithm. When
invoked, the steps must be followed in the order given, aborting at the first step that returns a
value. This algorithm will return either an integer or an error.

Let input be the string being parsed.

Let position be a pointer into input, initially
pointing at the start of the string.

2.4.4.2 Non-negative integers

The rules for parsing non-negative integers are as given in the following algorithm.
When invoked, the steps must be followed in the order given, aborting at the first step that
returns a value. This algorithm will return either zero, a positive integer, or an error.

A valid floating-point number represents the number obtained by multiplying the
significand by ten raised to the power of the exponent, where the significand is the first number,
interpreted as base ten (including the decimal point and the number after the decimal point, if
any, and interpreting the significand as a negative number if the whole string starts with a
"-" (U+002D) character and the number is not zero), and where the exponent is the
number after the E, if any (interpreted as a negative number if there is a "-" (U+002D) character between the E and the number and the number is not zero, or else ignoring a "+" (U+002B) character between the E and the number if there is one). If there is no E, then the
exponent is treated as zero.

The best
representation of the number n as a floating-point number is the string
obtained from applying the JavaScript operator ToString to n. The JavaScript
operator ToString is not uniquely determined. When there are multiple possible strings that could
be obtained from the JavaScript operator ToString for a particular value, the user agent must
always return the same string for that value (though it may differ from the value used by other
user agents).

The rules for parsing floating-point number values are as given in the following
algorithm. This algorithm must be aborted at the first step that returns something. This algorithm
will return either a number or an error.

Let input be the string being parsed.

Let position be a pointer into input, initially
pointing at the start of the string.

If the character indicated by position is a U+002D HYPHEN-MINUS character
(-):

Change value and divisor to −1.

Advance position to the next character.

If position is past the end of input, return an
error.

Otherwise, if the character indicated by position (the first character)
is a "+" (U+002B) character:

Advance position to the next character. (The "+"
is ignored, but it is not conforming.)

If position is past the end of input, return an
error.

If the character indicated by position is a "." (U+002E), and
that is not the last character in input, and the character after the
character indicated by position is an ASCII
digit, then set value to zero and jump to the step labeled
fraction.

If the character indicated by position is not an ASCII digit, then return an error.

Conversion: Let S be the set of finite IEEE 754
double-precision floating-point values except −0, but with two special values added: 21024 and −21024.

Let rounded-value be the number in S that is
closest to value, selecting the number with an even significand if there are
two equally close values. (The two special values 21024 and −21024 are considered to have even significands for this purpose.)

If rounded-value is 21024 or −21024, return an error.

Return rounded-value.

2.4.4.4 Percentages and lengths

The rules for parsing dimension values are as given in the following algorithm. When
invoked, the steps must be followed in the order given, aborting at the first step that returns a
value. This algorithm will return either a number greater than or equal to 1.0, or an error; if a
number is returned, then it is further categorized as either a percentage or a length.

Let input be the string being parsed.

Let position be a pointer into input, initially
pointing at the start of the string.

If the character indicated by position is a U+002E FULL STOP character
(.):

Advance position to the next character.

If position is past the end of input, or if the
character indicated by position is not an ASCII
digit, then return value as a length.

Let divisor have the value 1.

Fraction loop: Multiply divisor by ten.

Add the value of the character indicated by position, interpreted as a
base-ten digit (0..9) and divided by divisor, to value.

Advance position to the next character.

If position is past the end of input, then
return value as a length.

If the character indicated by position is an ASCII digit, return to the step labeled fraction loop in these
substeps.

If position is past the end of input, return value as a length.

If the character indicated by position is a "%" (U+0025) character, return value as a percentage.

Return value as a length.

2.4.4.5 Lists of integers

A valid list of integers is a number of valid
integers separated by U+002C COMMA characters, with no other characters (e.g. no space characters). In addition, there might be restrictions on the
number of integers that can be given, or on the range of values allowed.

The rules for parsing a list of integers are as follows:

Let input be the string being parsed.

Let position be a pointer into input, initially
pointing at the start of the string.

Let numbers be an initially empty list of integers. This list will be
the result of this algorithm.

If there is a character in the string input at position position, and it is either a U+0020 SPACE, U+002C COMMA, or U+003B SEMICOLON
character, then advance position to the next character in input, or to beyond the end of the string if there are no more
characters.

If position points to beyond the end of input,
return numbers and abort.

If the character in the string input at position position is a U+0020 SPACE, U+002C COMMA, or U+003B SEMICOLON character, then
return to step 4.

Let negated be false.

Let value be
0.

Let started be false. This variable is set to true when the parser
sees a number or a "-" (U+002D) character.

Let got number be false. This variable is set to true when the parser
sees a number.

Let finished be false. This variable is set to true to switch parser
into a mode where it ignores characters until the next separator.

Let bogus be false.

Parser: If the character in the string input at position position is:

A U+002D HYPHEN-MINUS character

Follow these substeps:

If got number is true, let finished be true.

If finished is true, skip to the next step in the overall set of
steps.

If started is true, let negated be false.

Otherwise, if started is false and if bogus is
false, let negated be true.

If the character at position is a "%" (U+0025) character,
then set unit to percentage.

Otherwise, if the character at position is a U+002A ASTERISK character
(*), then set unit to relative.

Add an entry to result consisting of the number given by value and the unit given by unit.

Return the list result.

2.4.5 Dates and times

In the algorithms below, the number of days in month month of year
year is: 31 if month is 1, 3, 5, 7, 8,
10, or 12; 30 if month is 4, 6, 9, or 11; 29 if month is 2 and year is a number divisible by 400, or if year is a number divisible by 4 but not by 100; and 28 otherwise. This
takes into account leap years in the Gregorian calendar. [GREGORIAN]

When ASCII digits are used in the date and time syntaxes defined in this section,
they express numbers in base ten.

While the formats described here are intended to be subsets of the corresponding
ISO8601 formats, this specification defines parsing rules in much more detail than ISO8601.
Implementors are therefore encouraged to carefully examine any date parsing libraries before using
them to implement the parsing rules described below; ISO8601 libraries might not parse dates and
times in exactly the same manner. [ISO8601]

Where this specification refers to the proleptic Gregorian calendar, it means the
modern Gregorian calendar, extrapolated backwards to year 1. A date in the proleptic
Gregorian calendar, sometimes explicitly referred to as a proleptic-Gregorian
date, is one that is described using that calendar even if that calendar was not in use at
the time (or place) in question. [GREGORIAN]

The rules to parse a month string are as follows. This will return either a year and
month, or nothing. If at any point the algorithm says that it "fails", this means that it is
aborted at that point and returns nothing.

Let input be the string being parsed.

Let position be a pointer into input, initially
pointing at the start of the string.

The rules to parse a month component, given an input string and
a position, are as follows. This will return either a year and a month, or
nothing. If at any point the algorithm says that it "fails", this means that it is aborted at that
point and returns nothing.

Collect a sequence of characters that are ASCII digits. If the
collected sequence is not at least four characters long, then fail. Otherwise, interpret the
resulting sequence as a base-ten integer. Let that number be the year.

If year is not a number greater than zero, then fail.

If position is beyond the end of input or if the
character at position is not a U+002D HYPHEN-MINUS character, then fail.
Otherwise, move position forwards one character.

Collect a sequence of characters that are ASCII digits. If the
collected sequence is not exactly two characters long, then fail. Otherwise, interpret the
resulting sequence as a base-ten integer. Let that number be the month.

The rules to parse a date string are as follows. This will return either a date, or
nothing. If at any point the algorithm says that it "fails", this means that it is aborted at that
point and returns nothing.

Let input be the string being parsed.

Let position be a pointer into input, initially
pointing at the start of the string.

The rules to parse a date component, given an input string and a
position, are as follows. This will return either a year, a month, and a day,
or nothing. If at any point the algorithm says that it "fails", this means that it is aborted at
that point and returns nothing.

If position is beyond the end of input or if the
character at position is not a U+002D HYPHEN-MINUS character, then fail.
Otherwise, move position forwards one character.

Collect a sequence of characters that are ASCII digits. If the
collected sequence is not exactly two characters long, then fail. Otherwise, interpret the
resulting sequence as a base-ten integer. Let that number be the day.

If day is not a number in the range 1 ≤ day ≤ maxday, then fail.

Return year, month, and day.

2.4.5.3 Yearless dates

A yearless date consists of a Gregorian month and a
day within that month, but with no associated year. [GREGORIAN]

A string is a valid yearless date string representing a month month and a day day if it consists of the following components
in the given order:

Two ASCII digits, representing day, in the range
1 ≤ day ≤ maxday where maxday is the number of
days in the month month and any arbitrary leap year (e.g. 4 or
2000)

In other words, if the month is "02",
meaning February, then the day can be 29, as if the year was a leap year.

The rules to parse a yearless date string are as follows. This will return either a
month and a day, or nothing. If at any point the algorithm says that it "fails", this means that
it is aborted at that point and returns nothing.

Let input be the string being parsed.

Let position be a pointer into input, initially
pointing at the start of the string.

The rules to parse a yearless date component, given an input
string and a position, are as follows. This will return either a month and a
day, or nothing. If at any point the algorithm says that it "fails", this means that it is aborted
at that point and returns nothing.

Collect a sequence of characters that are ASCII digits. If the
collected sequence is not exactly two characters long, then fail. Otherwise, interpret the
resulting sequence as a base-ten integer. Let that number be the month.

If month is not a number in the range 1 ≤ month ≤ 12, then fail.

Let maxday be the number of days in month month of any arbitrary leap year (e.g. 4
or 2000).

If position is beyond the end of input or if the
character at position is not a U+002D HYPHEN-MINUS character, then fail.
Otherwise, move position forwards one character.

Collect a sequence of characters that are ASCII digits. If the
collected sequence is not exactly two characters long, then fail. Otherwise, interpret the
resulting sequence as a base-ten integer. Let that number be the day.

If day is not a number in the range 1 ≤ day ≤ maxday, then fail.

Return month and day.

2.4.5.4 Times

A time consists of a specific time with no time-zone
information, consisting of an hour, a minute, a second, and a fraction of a second.

A string is a valid time string representing an hour hour, a
minute minute, and a second second if it consists of the
following components in the given order:

Two ASCII digits, representing the integer part of second,
in the range 0 ≤ s ≤ 59

Optionally (required if second is not an
integer):

A 002E FULL STOP character (.)

One, two, or three ASCII digits, representing the fractional part of second

The second component cannot be 60 or 61; leap seconds cannot
be represented.

The rules to parse a time string are as follows. This will return either a time, or
nothing. If at any point the algorithm says that it "fails", this means that it is aborted at that
point and returns nothing.

Let input be the string being parsed.

Let position be a pointer into input, initially
pointing at the start of the string.

Let time be the time with hour hour, minute minute, and second second.

Return time.

The rules to parse a time component, given an input string and a
position, are as follows. This will return either an hour, a minute, and a
second, or nothing. If at any point the algorithm says that it "fails", this means that it is
aborted at that point and returns nothing.

Collect a sequence of characters that are ASCII digits. If the
collected sequence is not exactly two characters long, then fail. Otherwise, interpret the
resulting sequence as a base-ten integer. Let that number be the hour.

If hour is not a number in the range 0 ≤ hour ≤ 23, then fail.

If position is beyond the end of input or if the
character at position is not a U+003A COLON character, then fail. Otherwise,
move position forwards one character.

Collect a sequence of characters that are ASCII digits. If the
collected sequence is not exactly two characters long, then fail. Otherwise, interpret the
resulting sequence as a base-ten integer. Let that number be the minute.

If minute is not a number in the range 0 ≤ minute ≤ 59, then fail.

Let second be a string with the value "0".

If position is not beyond the end of input and the
character at position is a U+003A COLON, then run these substeps:

Advance position to the next character in input.

If position is beyond the end of input, or at
the last character in input, or if the next two characters in input starting at position are not both ASCII
digits, then fail.

Collect a sequence of characters that are either ASCII digits
or U+002E FULL STOP characters. If the collected sequence is three characters long, or if it is
longer than three characters long and the third character is not a U+002E FULL STOP character,
or if it has more than one U+002E FULL STOP character, then fail. Otherwise, let the collected
string be second instead of its previous value.

Interpret second as a base-ten number (possibly with a fractional
part). Let second be that number instead of the string version.

If second is not a number in the range 0 ≤ second < 60, then fail.

Return hour, minute, and second.

2.4.5.5 Floating dates and times

A floating date and time consists of a specific
proleptic-Gregorian date, consisting of a year, a month, and a day, and a time,
consisting of an hour, a minute, a second, and a fraction of a second, but expressed without a
time zone. [GREGORIAN]

A string is a valid floating date and time string representing a date and time if it
consists of the following components in the given order:

A valid time string representing the time, expressed as the shortest possible
string for the given time (e.g. omitting the seconds component entirely if the given time is zero
seconds past the minute)

The rules to parse a floating date and time string are as follows. This will return
either a date and time, or nothing. If at any point the algorithm says that it "fails", this means
that it is aborted at that point and returns nothing.

Let input be the string being parsed.

Let position be a pointer into input, initially
pointing at the start of the string.

If position is beyond the end of input or if the
character at position is neither a U+0054 LATIN CAPITAL LETTER T character
(T) nor a U+0020 SPACE character, then fail. Otherwise, move position
forwards one character.

Let time be the time with hour hour, minute minute, and second second.

Return date and time.

2.4.5.6 Time zones

A time-zone offset consists of a signed number of hours and
minutes.

A string is a valid time-zone offset string representing a time-zone offset if it
consists of either:

A "Z" (U+005A) character, allowed only if the time zone is
UTC

Or, the following components, in the given order:

Either a "+" (U+002B) character or, if the time-zone offset is not zero, a "-" (U+002D) character, representing the sign of the time-zone offset

Two ASCII digits, representing the hours component hour of
the time-zone offset, in the range 0 ≤ hour ≤ 23

Optionally, a ":" (U+003A) character

Two ASCII digits, representing the minutes component minute of the time-zone offset, in the range 0 ≤ minute ≤ 59

This format allows for time-zone offsets from -23:59 to +23:59. In practice,
however, right now the range of offsets of actual time zones is -12:00 to +14:00, and the minutes
component of offsets of actual time zones is always either 00, 30, or 45. There is no guarantee
that this will remain so forever, however; time zones are changed by countries at will and do
not follow a standard.

See also the usage notes and examples in the global
date and time section below for details on using time-zone offsets with historical times
that predate the formation of formal time zones.

The rules to parse a time-zone offset string are as follows. This will return either
a time-zone offset, or nothing. If at any point the algorithm says that it "fails", this means
that it is aborted at that point and returns nothing.

Let input be the string being parsed.

Let position be a pointer into input, initially
pointing at the start of the string.

Return the time-zone offset that is timezonehours
hours and timezoneminutes minutes from UTC.

The rules to parse a time-zone offset component, given an input
string and a position, are as follows. This will return either time-zone hours
and time-zone minutes, or nothing. If at any point the algorithm says that it "fails", this means
that it is aborted at that point and returns nothing.

If the character at position is a U+005A LATIN CAPITAL LETTER Z character
(Z), then:

Let timezonehours be 0.

Let timezoneminutes be 0.

Advance position to the next character in input.

Otherwise, if the character at position is either a "+" (U+002B)
or a "-" (U+002D), then:

If the character at position is a "+" (U+002B), let sign be "positive". Otherwise, it's a "-" (U+002D); let sign be "negative".

Interpret s as a base-ten integer. Let that number be the timezonehours.

If position is beyond the end of input or if
the character at position is not a U+003A COLON character, then fail.
Otherwise, move position forwards one character.

Collect a sequence of characters that are ASCII digits. If
the collected sequence is not exactly two characters long, then fail. Otherwise, interpret
the resulting sequence as a base-ten integer. Let that number be the timezoneminutes.

If s is exactly four characters long, then run these substeps:

Interpret the first two characters of s as a base-ten integer. Let
that number be the timezonehours.

Interpret the last two characters of s as a base-ten integer. Let
that number be the timezoneminutes.

Otherwise, fail.

If timezonehours is not a number in the range
0 ≤ timezonehours ≤ 23, then
fail.

If sign is "negative", then negate timezonehours.

If timezoneminutes is not a number in the range
0 ≤ timezoneminutes ≤ 59,
then fail.

If sign is "negative", then negate timezoneminutes.

Otherwise, fail.

Return timezonehours and timezoneminutes.

2.4.5.7 Global dates and times

A global date and time consists of a specific
proleptic-Gregorian date, consisting of a year, a month, and a day, and a time,
consisting of an hour, a minute, a second, and a fraction of a second, expressed with a time-zone
offset, consisting of a signed number of hours and minutes. [GREGORIAN]

A string is a valid global date and time string representing a date, time, and a
time-zone offset if it consists of the following components in the given order:

Times in dates before the formation of UTC in the mid twentieth century must be expressed and
interpreted in terms of UT1 (contemporary Earth solar time at the 0° longitude), not UTC (the
approximation of UT1 that ticks in SI seconds). Time before the formation of time zones must be
expressed and interpeted as UT1 times with explicit time zones that approximate the contemporary
difference between the appropriate local time and the time observed at the location of Greenwich,
London.

Midnight in areas using London time on the birthday of Nero (the Roman Emperor). See below
for further discussion on which date this actually corresponds to.

"1979-10-14T12:00:00.001-04:00"

One millisecond after noon on October 14th 1979, in the time zone in use on the east coast
of the USA during daylight saving time.

"8592-01-01T02:09+02:09"

Midnight UTC on the 1st of January, 8592. The time zone associated with that time is two
hours and nine minutes ahead of UTC, which is not currently a real time zone, but is nonetheless
allowed.

Several things are notable about these dates:

Years with fewer than four digits have to be zero-padded. The date "37-12-13" would not be a
valid date.

If the "T" is replaced by a space, it must be a single space
character. The string "2001-12-21 12:00Z" (with two spaces
between the components) would not be parsed successfully.

To unambiguously identify a moment in time prior to the introduction of the Gregorian
calendar (insofar as moments in time before the formation of UTC can be unambiguously
identified), the date has to be first converted to the Gregorian calendar from the calendar in
use at the time (e.g. from the Julian calendar). The date of Nero's birth is the 15th of
December 37, in the Julian Calendar, which is the 13th of December 37 in the proleptic
Gregorian calendar.

The time and time-zone offset components are not optional.

Dates before the year one can't be represented as a datetime in this version of HTML.

Times of specific events in ancient times are, at best, approximations, since time was not
well coordinated or measured until relatively recent decades.

Time-zone offsets differ based on daylight savings time.

The zone offset is not a complete time zone specification. When working
with real date and time values, consider using a separate field for time zone,
perhaps using IANA time zone IDs. [TIMEZONES]

A string is a valid normalized forced-UTC global date and time
string representing a date, time, and a time-zone offset if it
consists of the following components in the given order:

A valid time string representing the time converted to the UTC time zone and
expressed as the shortest possible string for the given time (e.g. omitting the seconds component
entirely if the given time is zero seconds past the minute)

A "Z" (U+005A) character

The rules to parse a global date and time string are as follows. This will return
either a time in UTC, with associated time-zone offset information for round-tripping or display
purposes, or nothing. If at any point the algorithm says that it "fails", this means that it is
aborted at that point and returns nothing.

Let input be the string being parsed.

Let position be a pointer into input, initially
pointing at the start of the string.

If position is beyond the end of input or if the
character at position is neither a U+0054 LATIN CAPITAL LETTER T character
(T) nor a U+0020 SPACE character, then fail. Otherwise, move position
forwards one character.

Let time be the moment in time at year year, month
month, day day, hours hour, minute
minute, second second, subtracting timezonehours hours and timezoneminutes minutes. That moment in time is a moment in the UTC time
zone.

Let timezone be timezonehours
hours and timezoneminutes minutes from UTC.

Return time and timezone.

2.4.5.8 Weeks

A week consists of a week-year number and a week number
representing a seven-day period starting on a Monday. Each week-year in this calendaring system
has either 52 or 53 such seven-day periods, as defined below. The seven-day period starting on the
Gregorian date Monday December 29th 1969 (1969-12-29) is defined as week number 1 in week-year
1970. Consecutive weeks are numbered sequentially. The week before the number 1 week in a
week-year is the last week in the previous week-year, and vice versa. [GREGORIAN]

A week-year with a number year has 53 weeks if it corresponds to either a
year year in the proleptic Gregorian calendar that has a Thursday
as its first day (January 1st), or a year year in the proleptic
Gregorian calendar that has a Wednesday as its first day (January 1st) and where year is a number divisible by 400, or a number divisible by 4 but not by 100. All
other week-years have 52 weeks.

The week number of the last day of a week-year with 53 weeks is 53; the week number
of the last day of a week-year with 52 weeks is 52.

The week-year number of a particular day can be different than the number of the
year that contains that day in the proleptic Gregorian calendar. The first week in a
week-year y is the week that contains the first Thursday of the Gregorian year
y.

For modern purposes, a week as defined here is
equivalent to ISO weeks as defined in ISO 8601. [ISO8601]

A string is a valid week string representing a week-year year
and week week if it consists of the following components in the given
order:

The rules to parse a week string are as follows. This will return either a week-year
number and week number, or nothing. If at any point the algorithm says that it "fails", this means
that it is aborted at that point and returns nothing.

Let input be the string being parsed.

Let position be a pointer into input, initially
pointing at the start of the string.

Collect a sequence of characters that are ASCII digits. If the
collected sequence is not at least four characters long, then fail. Otherwise, interpret the
resulting sequence as a base-ten integer. Let that number be the year.

If year is not a number greater than zero, then fail.

If position is beyond the end of input or if the
character at position is not a U+002D HYPHEN-MINUS character, then fail.
Otherwise, move position forwards one character.

If position is beyond the end of input or if the
character at position is not a "W" (U+0057) character,
then fail. Otherwise, move position forwards one character.

Collect a sequence of characters that are ASCII digits. If the
collected sequence is not exactly two characters long, then fail. Otherwise, interpret the
resulting sequence as a base-ten integer. Let that number be the week.

2.4.5.9 Durations

A duration consists of a number of seconds.

Since months and seconds are not comparable (a month is not a precise number of
seconds, but is instead a period whose exact length depends on the precise day from which it is
measured) a duration as defined in this specification cannot
include months (or years, which are equivalent to
twelve months). Only durations that describe a specific number of seconds can be described.

A string is a valid duration string representing a durationt if it consists of either of the
following:

A literal U+0050 LATIN CAPITAL LETTER P character followed by one or more of the following
subcomponents, in the order given, where the number of days, hours, minutes, and
seconds corresponds to the same number of seconds as in t:

One or more ASCII digits followed by a U+0044 LATIN CAPITAL LETTER D
character, representing a number of days.

A U+0054 LATIN CAPITAL LETTER T character followed by one or more of the following
subcomponents, in the order given:

One or more ASCII digits followed by a U+0048 LATIN CAPITAL LETTER H
character, representing a number of hours.

One or more ASCII digits followed by a U+004D LATIN CAPITAL LETTER M
character, representing a number of minutes.

If the duration time component scale specified is 1 (i.e. the units are
seconds), then, optionally, a "." (U+002E) character followed by one, two, or three
ASCII digits, representing a fraction of a second.

This is not based on any of the formats in ISO 8601. It is intended to be a more
human-readable alternative to the ISO 8601 duration format.

The rules to parse a duration string are as follows. This will return either a duration or nothing. If at any point the algorithm says that it
"fails", this means that it is aborted at that point and returns nothing.

Let input be the string being parsed.

Let position be a pointer into input, initially
pointing at the start of the string.

Let months, seconds, and component
count all be zero.

Let M-disambiguator be minutes.

This flag's other value is months. It is used to disambiguate the "M"
unit in ISO8601 durations, which use the same unit for months and minutes. Months are not
allowed, but are parsed for future compatibility and to avoid misinterpreting ISO8601 durations
that would be valid in other contexts.

If the character in input pointed to by position
is a U+0050 LATIN CAPITAL LETTER P character, then advance position to the
next character, set M-disambiguator to months, and skip
whitespace.

Run the following substeps in a loop, until a step requiring the loop to be broken or the
entire algorithm to fail is reached:

Let units be undefined. It will be assigned one of the following
values: years, months, weeks, days, hours, minutes,
and seconds.

Let next character be undefined. It is used to process characters
from the input.

If position is past the end of input, then break
the loop.

If the character in input pointed to by position
is a U+0054 LATIN CAPITAL LETTER T character, then advance position to the
next character, set M-disambiguator to minutes, skip
whitespace, and return to the top of the loop.

Set next character to the character in input
pointed to by position.

If next character is a "." (U+002E) character, then let N equal zero. (Do not advance position. That is taken care
of below.)

Set next character to the character in input
pointed to by position, and this time advance position
to the next character. (If next character was a U+002E FULL STOP character
(.) before, it will still be that character this time.)

If next character is a "." (U+002E) character, then run these
substeps:

2.4.5.10 Vaguer moments in time

The rules to parse a date or time string are as follows. The algorithm will return
either a date, a time, a global date and time, or nothing. If at any point the algorithm
says that it "fails", this means that it is aborted at that point and returns nothing.

Let input be the string being parsed.

Let position be a pointer into input, initially
pointing at the start of the string.

Set start position to the same position as position.

Set the date present and time present flags to
true.

Parse a date component to obtain year, month, and day. If this fails, then set the date
present flag to false.

If date present is true, and position is not beyond
the end of input, and the character at position is
either a "T" (U+0054) character or a U+0020 SPACE character, then advance
position to the next character in input.

Otherwise, if date present is true, and either position is beyond the end of input or the character at position is neither a "T" (U+0054) character nor a U+0020
SPACE character, then set time present to false.

Otherwise, if date present is false, set position
back to the same position as start position.

If the time present flag is true, then parse a time
component to obtain hour, minute, and second. If this returns nothing, then fail.

If the date present and time present flags are
both true, but position is beyond the end of input, then
fail.

If the date present and time present flags are
both true, parse a time-zone offset component to obtain timezonehours and timezoneminutes. If this
returns nothing, then fail.

If position is not beyond the end of input, then fail.

If the date present flag is true and the time present
flag is false, then let date be the date with year year,
month month, and day day, and return date.

Otherwise, if the time present flag is true and the date
present flag is false, then let time be the time with hour hour, minute minute, and second second,
and return time.

Otherwise, let time be the moment in time at year year, month month, day day, hours hour, minute minute, second second,
subtracting timezonehours hours and timezoneminutes minutes, that moment in time being a moment
in the UTC time zone; let timezone be timezonehours hours and timezoneminutes
minutes from UTC; and return time and timezone.

2.4.6 Colors

A simple color consists of three 8-bit numbers in the range 0..255, representing the
red, green, and blue components of the color respectively, in the sRGB color space. [SRGB]

A string is a valid simple color if it is exactly seven characters long, and the
first character is a "#" (U+0023) character, and the remaining six characters are all
ASCII hex digits, with the first two digits representing the red component, the
middle two digits representing the green component, and the last two digits representing the blue
component, in hexadecimal.

A string is a valid lowercase simple color if it is a valid simple
color and doesn't use any characters in the range U+0041 LATIN CAPITAL LETTER A to U+0046
LATIN CAPITAL LETTER F.

The rules for parsing simple color values are as given in the following algorithm.
When invoked, the steps must be followed in the order given, aborting at the first step that
returns a value. This algorithm will return either a simple color or an error.

Let input be the string being parsed.

If input is not exactly seven characters long, then return an
error.

If the first character in input is not a U+0023 NUMBER SIGN character
(#), then return an error.

If the last six characters of input are not all ASCII hex
digits, then return an error.

Interpret the second and third characters as a hexadecimal number and let the result be
the red component of result.

Interpret the fourth and fifth characters as a hexadecimal number and let the result be
the green component of result.

Interpret the sixth and seventh characters as a hexadecimal number and let the result be
the blue component of result.

Return result.

The rules for serializing simple color values given a simple color are
as given in the following algorithm:

Let result be a string consisting of a single "#" (U+0023) character.

Convert the red, green, and blue components in turn to two-digit hexadecimal numbers using
lowercase ASCII hex digits, zero-padding if necessary, and append these numbers to
result, in the order red, green, blue.

Some obsolete legacy attributes parse colors in a more complicated manner, using the rules
for parsing a legacy color value, which are given in the following algorithm. When invoked,
the steps must be followed in the order given, aborting at the first step that returns a value.
This algorithm will return either a simple color or an error.

Interpret the first component as a hexadecimal number; let the red component of result be the resulting number.

Interpret the second component as a hexadecimal number; let the green component of result be the resulting number.

Interpret the third component as a hexadecimal number; let the blue component of result be the resulting number.

Return result.

2.4.7 Space-separated tokens

A set of space-separated tokens is a string containing zero or more words (known as
tokens) separated by one or more space characters, where
words consist of any string of one or more characters, none of which are space characters.

An ordered set of unique space-separated tokens is a set of space-separated
tokens where none of the tokens are duplicated but where the order of the tokens is
meaningful.

Sets of space-separated tokens sometimes
have a defined set of allowed values. When a set of allowed values is defined, the tokens must all
be from that list of allowed values; other values are non-conforming. If no such set of allowed
values is provided, then all values are conforming.

2.4.8 Comma-separated tokens

A set of comma-separated tokens is a string containing zero or more tokens each
separated from the next by a single "," (U+002C) character, where tokens consist of any string
of zero or more characters, neither beginning nor ending with space
characters, nor containing any "," (U+002C) characters, and optionally surrounded by
space characters.

For instance, the string " a ,b,,d d " consists of four tokens: "a", "b", the empty
string, and "d d". Leading and trailing whitespace around each token doesn't count as part of
the token, and the empty string can be a token.

Sets of comma-separated tokens sometimes
have further restrictions on what consists a valid token. When such restrictions are defined, the
tokens must all fit within those restrictions; other values are non-conforming. If no such
restrictions are specified, then all values are conforming.

When a user agent has to split a string on commas, it must use the following
algorithm:

Let input be the string being parsed.

Let position be a pointer into input, initially
pointing at the start of the string.

If position is not past the end of input, then
the character at position is a "," (U+002C) character; advance position past that character.

Jump back to the step labeled token.

Return tokens.

2.4.9 References

A valid hash-name reference to an element of type type is a
string consisting of a "#" (U+0023) character followed by a string which exactly matches
the value of the name attribute of an element with type type in the document.

The rules for parsing a hash-name reference to an element of type type are as follows:

If the string being parsed does not contain a U+0023 NUMBER SIGN character, or if the
first such character in the string is the last character in the string, then return null and
abort these steps.

Let s be the string from the character immediately after the first
U+0023 NUMBER SIGN character in the string being parsed up to the end of that string.

2.4.10 Media queries

A string is a valid media query if it matches the media_query_list production of the Media Queries specification. [MQ]

A string matches the environment of the user if it is the empty string, a string
consisting of only space characters, or is a media query
that matches the user's environment according to the definitions given in the Media Queries
specification. [MQ]

2.5 URLs

2.5.1 Terminology

A URL is a valid URL if it conforms to the authoring conformance
requirements in the URL standard. [URL]

A string is a valid non-empty URL if it is a valid URL but it is not
the empty string.

2.5.2 Resolving URLs

To resolve a URL to an absolute URL relative to either another
absolute URL or an element, the user agent must use the following steps. Resolving a
URL can result in an error, in which case the URL is not resolvable.

Let serialized URL be the result of apply the URL
serializer to parsed URL.

Return serialized URL as the resulting absolute URL and
parsed URL as the resulting parsed URL.

Given an element, the element's base URL is the base URI of the element, as
defined by the XML Base specification, with the base URI of the document entity being
defined as the document base URL of the Document that owns the element.
[XMLBASE]

For the purposes of the XML Base specification, user agents must act as if all
Document objects represented XML documents.

It is possible for xml:base attributes to be
present even in HTML fragments, as such attributes can be added dynamically using script. (Such
scripts would not be conforming, however, as xml:base
attributes are not allowed in HTML documents.)

If the absolute URL identified by the hyperlink is being shown to the user, or
if any data derived from that URL is affecting the display, then the href attribute should be re-resolved relative to the element and the UI updated appropriately.

For example, the CSS :link/:visited pseudo-classes might have been affected.

If the absolute URL identified by the cite attribute is
being shown to the user, or if any data derived from that URL is affecting the display, then the
URL should be re-resolved relative to the
element and the UI updated appropriately.

Otherwise

The element is not directly affected.

For instance, changing the base URL doesn't affect the image displayed by
img elements, although subsequent accesses of the src IDL attribute from script will return a new absolute
URL that might no longer correspond to the image being shown.

2.6 Fetching resources

2.6.1 Terminology

User agents can implement a variety of transfer protocols, but
this specification mostly defines behavior in terms of HTTP. [HTTP]

The HTTP GET method is equivalent to the default
retrieval action of the protocol. For example, RETR in FTP. Such actions are idempotent and safe,
in HTTP terms.

The HTTP response codes are equivalent to
statuses in other protocols that have the same basic meanings. For example, a "file not found"
error is equivalent to a 404 code, a server error is equivalent to a 5xx code, and so on.

The HTTP headers are equivalent to fields in
other protocols that have the same basic meaning. For example, the HTTP authentication headers are
equivalent to the authentication aspects of the FTP protocol.

2.6.2 Processing model

When a user agent is to fetch a resource or URL, optionally
from an origin origin, optionally using a
specific referrer source as an override referrer source, and optionally with
any of a synchronous flag, a manual redirect flag, a force same-origin flag,
and a block cookies flag, the following steps must be run. (When a URL is to be
fetched, the URL identifies a resource to be obtained.)

If there is a specific override referrer source, and it is a URL, then
let referrer be the override referrer source, and jump to the step
labeled clean referrer.

Let document be the appropriate Document as given by the
following list:

Let referrer be the result of applying the
URL serializer to parsed referrer, with the exclude fragment
flag set.

If referrer is not the empty string, is not a data: URL, and is not the URL
"about:blank", then generate the address of the resource from which Request-URIs
are obtained as required by HTTP for the Referer (sic)
header from referrer. [HTTP]

Otherwise, the Referer (sic) header must be omitted,
regardless of its value.

If the algorithm was not invoked with the synchronous flag, perform the remaining
steps asynchronously.

If the resource is identified by an absolute URL, and the resource is to be
obtained using an idempotent action (such as an HTTP GET or equivalent), and it is already being downloaded
for other reasons (e.g. another invocation of this algorithm), and this request would be
identical to the previous one (e.g. same Accept and Origin headers), and the user agent is configured such that it is to
reuse the data from the existing download instead of initiating a new one, then use the results
of the existing download instead of starting a new one.

Otherwise, if the resource is identified by an absolute URL with a scheme that
does not define a mechanism to obtain the resource (e.g. it is a mailto:
URL) or that the user agent does not support, then act as if the resource was an HTTP 204 No
Content response with no other metadata.

Otherwise, if the resource is identified by the URLabout:blank, then the resource is immediately available and consists of
the empty string, with no metadata.

Otherwise, at a time convenient to the user and the user agent, download (or otherwise
obtain) the resource, applying the semantics of the relevant specifications (e.g. performing an
HTTP GET or POST operation, or reading the file from disk, or expanding data: URLs, etc).

For the purposes of the Referer (sic) header, use the
address of the resource from which Request-URIs are obtained generated in the earlier
step.

For the purposes of the Origin header, if the fetching algorithm was explicitly initiated from an origin,
then the origin that initiated the HTTP request is origin.
Otherwise, this is a request from a "privacy-sensitive" context. [ORIGIN]

If the algorithm was not invoked with the block cookies flag, and there are cookies to
be set, then the user agent must run the following substeps:

If the force same-origin flag is set and the URL of the target of the
redirect does not have the same origin as the URL for which the
fetch algorithm was invoked

Abort these steps and return failure from this algorithm, as if the remote host could not
be contacted.

If the manual redirect flag is set

Continue, using the fetched resource (the redirect) as the result of the algorithm. If the
calling algorithm subsequently requires the user agent to transparently follow the
redirect, then the user agent must resume this algorithm from the main step, but
using the target of the redirect as the resource to fetch, rather than the original
resource.

Otherwise

First, apply any relevant requirements for redirects (such as showing any appropriate
prompts). Then, redo main step, but using the target of the redirect as the resource to
fetch, rather than the original resource. For HTTP requests, the new request must include the
same headers as the original request, except for headers for which other requirements are
specified (such as the Host header). [HTTP]

The HTTP specification requires that 301, 302, and 307 redirects, when applied
to methods other than the safe methods, not be followed without user confirmation. That would
be an appropriate prompt for the purposes of the requirement in the paragraph above. [HTTP]

If the algorithm was not invoked with the synchronous flag: When the resource is
available, or if there is an error of some description, queue a task that uses the
resource as appropriate. If the resource can be processed incrementally, as, for instance, with
a progressively interlaced JPEG or an HTML file, additional tasks may be queued to process the
data as it is downloaded. The task source for these tasks is the networking task source.

Otherwise, return the resource or error information to the calling algorithm.

If the user agent can determine the actual length of the resource being fetched for an instance of this algorithm, and if that length is finite, then
that length is the file's size. Otherwise, the subject of
the algorithm (that is, the resource being fetched) has no known size. (For example, the HTTP Content-Length header might provide this information.)

The user agent must also keep track of the number of bytes
downloaded for each instance of this algorithm. This number must exclude any out-of-band
metadata, such as HTTP headers.

The navigation processing model handles redirects
itself, overriding the redirection handling that would be done by the fetching algorithm.

Whether the type sniffing rules apply to the
fetched resource depends on the algorithm that invokes the rules — they are not always
applicable.

2.6.3 Encrypted HTTP and related security concerns

Anything in this specification that refers to HTTP also applies to HTTP-over-TLS, as
represented by URLs representing the https scheme.
[HTTPS]

User agents should report certificate errors to the user and must either refuse
to download resources sent with erroneous certificates or must act as if such resources were in
fact served with no encryption.

User agents should warn the user that there is a potential problem whenever the user visits a
page that the user has previously visited, if the page uses less secure encryption on the second
visit.

Not doing so can result in users not noticing man-in-the-middle attacks.

If a user connects to a server with a self-signed certificate, the user agent could allow the
connection but just act as if there had been no encryption. If the user agent instead allowed the
user to override the problem and then displayed the page as if it was fully and safely encrypted,
the user could be easily tricked into accepting man-in-the-middle connections.

If a user connects to a server with full encryption, but the page then refers to an external
resource that has an expired certificate, then the user agent will act as if the resource was
unavailable, possibly also reporting the problem to the user. If the user agent instead allowed
the resource to be used, then an attacker could just look for "secure" sites that used resources
from a different host and only apply man-in-the-middle attacks to that host, for example taking
over scripts in the page.

If a user bookmarks a site that uses a CA-signed certificate, and then later revisits that
site directly but the site has started using a self-signed certificate, the user agent could warn
the user that a man-in-the-middle attack is likely underway, instead of simply acting as if the
page was not encrypted.

2.6.4 Determining the type of a resource

The Content-Type metadata of a resource must be obtained and
interpreted in a manner consistent with the requirements of the MIME Sniffing specification. [MIMESNIFF]

The sniffed type of a resource must be found in a
manner consistent with the requirements given in the MIME Sniffing specification for finding the
sniffed media type of the relevant sequence of octets. [MIMESNIFF]

The rules for sniffing images specifically and
the rules for distinguishing if a resource is
text or binary are also defined in the MIME Sniffing specification. Both sets of rules
return a MIME type as their result. [MIMESNIFF]

It is imperative that the rules in the MIME Sniffing specification be followed
exactly. When a user agent uses different heuristics for content type detection than the server
expects, security problems can occur. For more details, see the MIME Sniffing specification. [MIMESNIFF]

The algorithm for extracting a character encoding from a meta element,
given a string s, is as follows. It either returns a character encoding or
nothing.

Let position be a pointer into s, initially
pointing at the start of the string.

Loop: Find the first seven characters in s after position that are an ASCII case-insensitive match for the word "charset". If no such match is found, return nothing and abort these
steps.

Skip any space characters that immediately follow the
word "charset" (there might not be any).

If the next character is not a "=" (U+003D), then move position to point just before that next character, and jump back to the step
labeled loop.

Skip any space characters that immediately follow the
equals sign (there might not be any).

Process the next character as follows:

If it is a """ (U+0022) character and there is a later """ (U+0022) character in s

If it is a "'" (U+0027) character and there is a later "'" (U+0027) character in s

Return the result of getting an encoding from the substring that is between
this character and the next earliest occurrence of this character.

If it is an unmatched """ (U+0022) character

If it is an unmatched "'" (U+0027) character

If there is no next character

Return nothing.

Otherwise

Return the result of getting an encoding from the substring that consists of
this character up to but not including the first space character or ";" (U+003B) character, or the end of s, whichever comes first.

This algorithm is distinct from those in the HTTP specification (for example, HTTP
doesn't allow the use of single quotes and requires supporting a backslash-escape mechanism that
is not supported by this algorithm). While the algorithm is used in
contexts that, historically, were related to HTTP, the syntax as supported by implementations
diverged some time ago. [HTTP]

2.6.6 CORS settings attributes

A CORS settings attribute is an enumerated attribute. The following
table lists the keywords and states for the attribute — the keywords in the left column map
to the states in the cell in the second column on the same row as the keyword.

The empty string is also a valid keyword, and maps to the Anonymous state. The attribute's invalid value
default is the Anonymous state. For the
purposes of reflection, the canonical case for the Anonymous state is the anonymous keyword. The missing value
default, used when the attribute is omitted, is the No
CORS state.

2.6.7 CORS-enabled fetch

When the user agent is required to perform a potentially CORS-enabled fetch of an
absolute URLURL with a mode mode that is
either "No CORS", "Anonymous", or "Use Credentials", optionally using a
referrer sourcereferrer source, with an originorigin, and with a default origin behaviour default
which is either "taint" or "fail", it must run the first applicable set of steps
from the following list. The default origin behaviour is only used if mode is
"No CORS". This algorithm wraps the fetch
algorithm above, and labels the obtained resource as either CORS-same-origin or
CORS-cross-origin, or blocks the resource entirely.

The tasks from the fetch algorithm are queued normally, but for the purposes of the calling algorithm, the
obtained resource is CORS-cross-origin. The user agent may report a cross-origin
resource access failure to the user (e.g. in a debugging console).

Discard any data fetched as part of this algorithm, and prevent any tasks from such invocations of the fetch algorithm
from being queued.
For the purposes of the calling algorithm, the user agent must act as if there was a fatal
network error and no resource was obtained. The user agent may report a cross-origin resource
access failure to the user (e.g. in a debugging console).

Discard all fetched data and prevent any tasks from
the fetch algorithm from being queued. For
the purposes of the calling algorithm, the user agent must act as if there was a fatal
network error and no resource was obtained. If a CORS resource sharing check
failed, the user agent may report a cross-origin resource access failure to the user (e.g.
in a debugging console).

2.7 Common DOM interfaces

2.7.1 Reflecting content attributes in IDL attributes

Some IDL attributes are defined to reflect a particular content attribute. This
means that on getting, the IDL attribute returns the current value of the content attribute, and
on setting, the IDL attribute changes the value of the content attribute to the given value.

In general, on getting, if the content attribute is not present, the IDL attribute must act as
if the content attribute's value is the empty string; and on setting, if the content attribute is
not present, it must first be added.

If a reflecting IDL attribute is a DOMString attribute whose content attribute is
defined to contain a URL, then on getting, the IDL attribute must resolve the value of the content attribute relative to the element
and return the resulting absolute URL if that was successful, or the empty string
otherwise; and on setting, must set the content attribute to the specified literal value. If the
content attribute is absent, the IDL attribute must return the default value, if the content
attribute has one, or else the empty string.

If a reflecting IDL attribute is a DOMString attribute whose content attribute is
defined to contain one or more URLs, then on getting, the IDL attribute
must split the content attribute on spaces and
return the concatenation of resolving each token URL to an
absolute URL relative to the element, with a single U+0020 SPACE character between
each URL, ignoring any tokens that did not resolve successfully. If the content attribute is
absent, the IDL attribute must return the default value, if the content attribute has one, or else
the empty string. On setting, the IDL attribute must set the content attribute to the specified
literal value.

If a reflecting IDL attribute is a DOMString attribute whose content attribute is
an enumerated attribute, and the IDL attribute is limited to only known
values, then, on getting, the IDL attribute must return the conforming value associated with
the state the attribute is in (in its canonical case), if any, or the empty string if the
attribute is in a state that has no associated keyword value or if the attribute is not in a defined state
(e.g. the attribute is missing and there is no missing value default); and on setting, the
content attribute must be set to the specified new value.

If a reflecting IDL attribute is a DOMString attribute but doesn't fall into any
of the above categories, then the getting and setting must be done in a transparent,
case-preserving manner.

If a reflecting IDL attribute is a boolean attribute, then on getting the
IDL attribute must return true if the content attribute is set, and false if it is absent. On
setting, the content attribute must be removed if the IDL attribute is set to false, and must be
set to the empty string if the IDL attribute is set to true. (This corresponds to the rules for
boolean content attributes.)

If a reflecting IDL attribute has a signed integer type (long) then, on getting,
the content attribute must be parsed according to the rules for parsing signed integers, and if that is successful, and the value is in
the range of the IDL attribute's type, the resulting value must be returned. If, on the other
hand, it fails or returns an out of range value, or if the attribute is absent, then the default
value must be returned instead, or 0 if there is no default value. On setting, the given value
must be converted to the shortest possible string representing the number as a valid
integer and then that string must be used as the new content attribute value.

If a reflecting IDL attribute has a signed integer type (long) that is
limited to only non-negative numbers then, on getting, the content attribute must be
parsed according to the rules for parsing non-negative integers, and if that is
successful, and the value is in the range of the IDL attribute's type, the resulting value must be
returned. If, on the other hand, it fails or returns an out of range value, or if the attribute is
absent, the default value must be returned instead, or −1 if there is no default value. On
setting, if the value is negative, the user agent must throw an IndexSizeError
exception. Otherwise, the given value must be converted to the shortest possible string
representing the number as a valid non-negative integer and then that string must be
used as the new content attribute value.

If a reflecting IDL attribute has an unsigned integer type (unsigned
long) then, on getting, the content attribute must be parsed according to the rules
for parsing non-negative integers, and if that is successful, and the value is in the range
0 to 2147483647 inclusive, the resulting value must be returned. If, on the other hand, it fails
or returns an out of range value, or if the attribute is absent, the default value must be
returned instead, or 0 if there is no default value. On setting, first, if the new value is in the
range 0 to 2147483647, then let n be the new value, otherwise let n be the default value, or 0 if there is no default value; then, n must be converted to the shortest possible string representing the number as a
valid non-negative integer and that string must be used as the new content attribute
value.

If a reflecting IDL attribute has an unsigned integer type (unsigned long) that is
limited to only non-negative numbers greater than zero, then the behavior is similar to
the previous case, but zero is not allowed. On getting, the content attribute must first be parsed
according to the rules for parsing non-negative integers, and if that is successful,
and the value is in the range 1 to 2147483647 inclusive, the resulting value must be returned. If,
on the other hand, it fails or returns an out of range value, or if the attribute is absent, the
default value must be returned instead, or 1 if there is no default value. On setting, if the
value is zero, the user agent must throw an IndexSizeError exception. Otherwise,
first, if the new value is in the range 1 to 2147483647, then let n be the new
value, otherwise let n be the default value, or 1 if there is no default
value; then, n must be converted to the shortest possible string representing
the number as a valid non-negative integer and that string must be used as the new
content attribute value.

If a reflecting IDL attribute has a floating-point number type (double or
unrestricted double), then, on getting, the content attribute must be parsed
according to the rules for parsing floating-point number values, and if that is
successful, the resulting value must be returned. If, on the other hand, it fails, or if the
attribute is absent, the default value must be returned instead, or 0.0 if there is no default
value. On setting, the given value must be converted to the best representation of the
number as a floating-point number and then that string must be used as the new content
attribute value.

If a reflecting IDL attribute has a floating-point number type (double or
unrestricted double) that is limited to numbers greater than zero, then
the behavior is similar to the previous case, but zero and negative values are not allowed. On
getting, the content attribute must be parsed according to the rules for parsing
floating-point number values, and if that is successful and the value is greater than 0.0,
the resulting value must be returned. If, on the other hand, it fails or returns an out of range
value, or if the attribute is absent, the default value must be returned instead, or 0.0 if there
is no default value. On setting, if the value is less than or equal to zero, then the value must
be ignored. Otherwise, the given value must be converted to the best representation of the
number as a floating-point number and then that string must be used as the new content
attribute value.

The values Infinity and Not-a-Number (NaN) values throw an exception on setting,
as defined in the Web IDL specification. [WEBIDL]

If a reflecting IDL attribute has the type HTMLElement, or an interface that
descends from HTMLElement, then, on getting, it must run the following algorithm
(stopping at the first point where a value is returned):

If the corresponding content attribute is absent, then the IDL attribute must return
null.

Let candidate be the element that the document.getElementById() method would find when
called on the content attribute's document if it were passed as its argument the current value of
the corresponding content attribute.

If candidate is null, or if it is not type-compatible with the IDL
attribute, then the IDL attribute must return null.

Otherwise, it must return candidate.

On setting, if the given element has an id attribute, and has the
same home subtree as the element of the attribute being set, and the given element is
the first element in that home subtree whose ID is
the value of that id attribute, then the content attribute must be
set to the value of that id attribute. Otherwise, the content
attribute must be set to the empty string.

The item(name) and namedItem(name)
methods must act according to the following algorithm:

If name is the empty string, return null and stop the algorithm.

Let collection be an HTMLCollection object rooted at the
same node as the HTMLAllCollection object on which the method was invoked, whose
filter matches only elements that already match the filter of the HTMLAllCollection
object on which the method was invoked and that are either:

Let element be the first element in tree order
represented by the RadioNodeList object that is an input element whose
type attribute is in the Radio Button state and whose value content attribute is present and equal to the new value, if
any. Otherwise, let it be null.

On setting, the behavior depends on whether the new value is equal to, greater than, or less
than the number of nodes represented by the collection at that time. If the number is
the same, then setting the attribute must do nothing. If the new value is greater, then n new option elements with no attributes and no child nodes must be
appended to the select element on which the HTMLOptionsCollection is
rooted, where n is the difference between the two numbers (new value minus old
value). Mutation events must be fired as if a DocumentFragment containing the new
option elements had been inserted. If the new value is lower, then the last n nodes in the collection must be removed from their parent nodes, where n is the difference between the two numbers (old value minus new value).

Setting length never removes
or adds any optgroup elements, and never adds new children to existing
optgroup elements (though it can remove children from them).

When the user agent is to set the value of a new
indexed property or set the value of an existing indexed property for a given property index index to a new value value, it must run the following algorithm:

If value is null, invoke the steps for the remove method with index as
the argument, and abort these steps.

The supported property names on a DOMStringMap object at any instant
are the names of each pair returned from the algorithm for getting the list of name-value pairs at
that instant, in the order returned.

To determine the value of a named propertyname in a DOMStringMap, the user agent must return the value component
of the name-value pair whose name component is name in the list returned by
the algorithm for getting the list of name-value pairs.

To set the value of a new or existing named property name to value
value, the algorithm for setting names to certain values must be run, passing
name as the name and the result of converting value to a
DOMString as the value.

To delete an existing named propertyname, the algorithm for deleting names must be run, passing name as the name.

The DOMStringMap interface definition here is only intended for
JavaScript environments. Other language bindings will need to define how DOMStringMap
is to be implemented for those languages.

The dataset attribute on elements exposes the data-* attributes on the element.

2.7.4 Transferable objects

Some objects support being copied and closed in one operation.
This is called transferring the object, and is used in
particular to transfer ownership of unsharable or expensive
resources across worker boundaries.

To transfer a Transferable object to a
new owner, the user agent must run the steps defined for the type of
object in question. The steps will return a new object of the same
type, and will permanently neuter the original
object. (This is an irreversible and non-idempotent operation; once
an object has been transferred, it cannot be transferred, or indeed
used, again.)

To transfer an
ArrayBuffer object old to a new owner owner,
a user agent must create a new ArrayBuffer object pointing at the same underlying
data as old, thus obtaining new, must neuter the old object, and must
finally return new. [TYPEDARRAY]

2.7.5 Safe passing of structured data

When a user agent is required to obtain a structured clone of a value, optionally
with a transfer map, it must run the following algorithm, which either returns a separate
value, or throws an exception. If a transfer map is provided, it consists of an association
list of Transferable objects to placeholder objects.

Let input be the value being cloned.

Let transfer map be the transfer map passed to the algorithm,
if any, or the empty list otherwise.

Let memory be an association list of pairs of objects, initially
empty. This is used to handle duplicate references. In each pair of objects, one is called the
source object and the other the destination object.

For each mapping in transfer map, add a mapping from the
Transferable object (the source object) to the placeholder object (the destination
object) to memory.

If input has been disabled through the close() method, throw a DataCloneError exception
and abort the overall structured clone algorithm. Otherwise, let output be a newly constructed object of the same class as input, corresponding to the same underlying data.

Let output be a newly constructed FileList object
containing a list of newly constructed File objects corresponding to the same
underlying data as those in input, maintaining their relative
order.

If input is an ImageData object

Let output be a newly constructed ImageData object
whose width, height, and resolution attributes have values equal to the
corresponding attributes on input, and whose data attribute has the value obtained from invoking the
internal structured cloning algorithm recursively with the value of the data attribute on input as the new "input" argument and memory as the new "memory" argument.

Let output be a newly constructed object of the same class as input, with each IDL attribute defined for that class being set to the value
obtained from invoking the internal structured cloning algorithm recursively with
the value of the attribute on input as the new "input"
argument and memory as the new "memory" argument.

Only IDL attributes defined on the class (including the
ArrayBufferView attributes) are cloned. Properties added by a script, for
example, are not cloned.

If input is an Array object

Let output be a newly constructed empty Array object whose
length is equal to the length of input, and set deep clone to own.

This means that the length of sparse arrays is preserved.

If input is an Object object

Let output be a newly constructed empty Object
object, and set deep clone to own.

For the purposes of the algorithm above, an object is a particular type of object class if its [[Class]] internal property is equal to class.

For example, "input is an Object object" if
input's [[Class]] internal property is equal to the string "Object".

Add a mapping from input (the source object) to output (the destination object) to memory.

If deep clone is set to map, then run these substeps. These
substeps use the terminology and typographic conventions used in the JavaScript specification's
definition of Maps. [ECMA262]

Let source be the List that is the value of input's [[MapData]] internal slot, if any. If there is no such slot, then
instead throw a DataCloneError exception and abort the overall structured
clone algorithm. [ECMA262]

Let target be the List that is the value of output's [[MapData]] internal slot.

For each Record {[[key]], [[value]]} entry that is an element of
source, run the following substeps:

Let key have the value obtained from invoking the
internal structured cloning algorithm recursively with entry.[[key]] as the new "input" argument and memory as the new "memory" argument.

Let value have the value obtained from invoking the
internal structured cloning algorithm recursively with entry.[[value]] as the new "input" argument and memory as the new "memory" argument.

Let new entry be the Record {[[key]]: key,
[[value]]: value}.

Append new entry as the last element of target.

Set deep clone to own.

If deep clone is set to set, then run these substeps. These
substeps use the terminology and typographic conventions used in the JavaScript specification's
definition of Sets. [ECMA262]

Let source be the List that is the value of input's [[SetData]] internal slot, if any. If there is no such slot, then
instead throw a DataCloneError exception and abort the overall structured
clone algorithm. [ECMA262]

Let target be the List that is the value of output's [[SetData]] internal slot.

For each entry that is an element of source that
is not empty, run the following substeps:

Let new entry have the value obtained from invoking the
internal structured cloning algorithm recursively with entry as the new "input" argument and memory as the new "memory" argument.

Append new entry as the last element of target.

Set deep clone to own.

If deep clone is set to own, then, for each enumerable own property in input, run the following steps:

Let name be the name of the property.

Let source value be the result of calling the [[Get]] internal
method of input with the argument name. If the [[Get]]
internal method of a property involved executing script, and that script threw an uncaught
exception, then abort the overall structured clone algorithm, with that exception
being passed through to the caller.

Let cloned value be the result of invoking the internal
structured cloning algorithm recursively with source value as the
"input" argument and memory as the "memory" argument. If this results in an exception, then abort the overall
structured clone algorithm, with that exception being passed through to the
caller.

Add a new property to output having the name name, and having the value cloned value.

The order of the properties in the input and output
objects must be the same, and any properties whose [[Get]] internal method involves running
script must be processed in that same order.

This does not walk the prototype chain.

Property descriptors, setters, getters, and analogous features are not copied in
this process. For example, the property in the input could be marked as read-only, but in the
output it would just have the default state (typically read-write, though that could depend on
the scripting environment).

Properties of Array objects are not treated any differently than those of other
Objects. In particular, this means that non-index properties of arrays are copied as well.

Return output.

This algorithm preserves cycles and preserves the identity of duplicate objects in
graphs.

2.7.6 Callbacks

The following callback function type is used in various APIs that interact with
File objects:

2.7.7 Garbage collection

There is an implied strong reference from any IDL
attribute that returns a pre-existing object to that object.

For example, the document.location attribute means
that there is a strong reference from a Document
object to its Location object. Similarly, there is
always a strong reference from a Document to any
descendant nodes, and from any node to its owner
Document.

2.8 Namespaces

The HTML namespace is: http://www.w3.org/1999/xhtml

The MathML namespace is: http://www.w3.org/1998/Math/MathML

The SVG namespace is: http://www.w3.org/2000/svg

The XLink namespace is: http://www.w3.org/1999/xlink

The XML namespace is: http://www.w3.org/XML/1998/namespace

The XMLNS namespace is: http://www.w3.org/2000/xmlns/

Data mining tools and other user agents that perform operations
on content without running scripts, evaluating CSS or XPath
expressions, or otherwise exposing the resulting DOM to arbitrary
content, may "support namespaces" by just asserting that their DOM
node analogues are in certain namespaces, without actually exposing
the above strings.

In the HTML syntax, namespace prefixes
and namespace declarations do not have the same effect as in XML.
For instance, the colon has no special meaning in HTML element
names.

3 Semantics, structure, and APIs of HTML documents

3.1 Documents

Every XML and HTML document in an HTML UA is represented by a Document object. [DOM]

The document's referrer is an absolute URL that can be set when the
Document is created. If it is not explicitly set, then its value is the empty
string.

Each Document object has a reload override flag that is originally
unset. The flag is set by the document.open() and document.write() methods in certain situations. When the flag is
set, the Document also has a reload override buffer which is a Unicode
string that is used as the source of the document when it is reloaded.

In the case of HTTP, the referrer IDL
attribute will match the Referer (sic) header that was sent when
fetching the current page.

Typically user agents are configured to not report referrers in the case where the
referrer uses an encrypted protocol and the current page does not (e.g. when navigating from an
https: page to an http: page).

Since the cookie attribute is accessible
across frames, the path restrictions on cookies are only a tool to help manage which cookies are
sent to which parts of the site, and are not in any way a security feature.

Returns the date of the last modification to the document, as reported by the server, in the
form "MM/DD/YYYY hh:mm:ss", in the user's local time zone.

If the last modification date is not known, the current time is returned instead.

The lastModified attribute, on
getting, must return the date and time of the Document's source file's last
modification, in the user's local time zone, in the following format:

The month component of the date.

A "/" (U+002F) character.

The day component of the date.

A "/" (U+002F) character.

The year component of the date.

A U+0020 SPACE character.

The hours component of the time.

A ":" (U+003A) character.

The minutes component of the time.

A ":" (U+003A) character.

The seconds component of the time.

All the numeric components above, other than the year, must be given as two ASCII
digits representing the number in base ten, zero-padded if necessary. The year must be
given as the shortest possible string of four or more ASCII digits representing the
number in base ten, zero-padded if necessary.

The Document's source file's last modification date and time must be derived from
relevant features of the networking protocols used, e.g. from the value of the HTTP Last-Modified header of the document, or from metadata in the
file system for local files. If the last modification date and time are not known, the attribute
must return the current date and time in the above format.

Each document has a current document readiness. When a Document object
is created, it must have its current document readiness set to the string "loading" if the document is associated with an HTML parser, an
XML parser, or an XSLT processor, and to the string "complete"
otherwise. Various algorithms during page loading affect this value. When the value is set, the
user agent must fire a simple event named readystatechange at the Document
object.

Can be set, to update the document's title. If there is no
head element,
the new value is ignored.

In SVG documents, the SVGDocument interface's
title attribute takes
precedence.

The title element of a document is the
first title element in the document (in tree order), if
there is one, or null otherwise.

The title attribute must,
on getting, run the following algorithm:

If the root element is an svg
element in the "http://www.w3.org/2000/svg"
namespace, and the user agent supports SVG, then return the value
that would have been returned by the IDL attribute of the same name
on the SVGDocument interface. [SVG]

On setting, the following algorithm must be run. Mutation events
must be fired as appropriate.

If the root element is an svg
element in the "http://www.w3.org/2000/svg"
namespace, and the user agent supports SVG, then the setter must
act as if it was the setter for the IDL attribute of the same name
on the Document interface defined by the SVG
specification. Stop the algorithm here. [SVG]

Otherwise, if the new value is the same as the body element, do nothing. Abort
these steps.

Otherwise, if the body element is not null, then replace that element with the
new value in the DOM, as if the root element's replaceChild() method had
been called with the new value and the incumbent body
element as its two arguments respectively, then abort these steps.

Returns a NodeList of elements in the
Document that have a name
attribute with the value name.

The getElementsByName(name) method takes a string name, and must return a liveNodeList containing all the HTML elements
in that document that have a name attribute
whose value is equal to the name argument (in a
case-sensitive manner), in tree order.
When the method is invoked on a Document object again
with the same argument, the user agent may return the same as the
object returned by the earlier call. In other cases, a new
NodeList object must be returned.

The dir attribute on the
Document interface is defined along with the dir
content attribute.

3.2 Elements

3.2.1 Semantics

Elements, attributes, and attribute values in HTML are defined (by this specification) to have
certain meanings (semantics). For example, the ol element represents an ordered list,
and the lang attribute represents the language of the content.

These definitions allow HTML processors, such as Web browsers or search engines, to present and
use documents and applications in a wide variety of contexts that the author might not have
considered.

As a simple example, consider a Web page written by an author who only considered desktop
computer Web browsers:

<!DOCTYPE HTML>
<html>
<head>
<title>My Page</title>
</head>
<body>
<h1>Welcome to my page</h1>
<p>I like cars and lorries and have a big Jeep!</p>
<h2>Where I live</h2>
<p>I live in a small hut on a mountain!</p>
</body>
</html>

Because HTML conveys meaning, rather than presentation, the same
page can also be used by a small browser on a mobile phone, without any change to the page.
Instead of headings being in large letters as on the desktop, for example, the browser on the
mobile phone might use the same size text for the whole the page, but with the headings in
bold.

But it goes further than just differences in screen size: the same page could equally be used
by a blind user using a browser based around speech synthesis, which instead of displaying the
page on a screen, reads the page to the user, e.g. using headphones. Instead of large text for
the headings, the speech browser might use a different volume or a slower voice.

That's not all, either. Since the browsers know which parts of the page are the headings, they
can create a document outline that the user can use to quickly navigate around the document,
using keys for "jump to next heading" or "jump to previous heading". Such features are especially
common with speech browsers, where users would otherwise find quickly navigating a page quite
difficult.

Even beyond browsers, software can make use of this information. Search engines can use the
headings to more effectively index a page, or to provide quick links to subsections of the page
from their results. Tools can use the headings to create a table of contents (that is in fact how
this very specification's table of contents is generated).

This example has focused on headings, but the same principle applies to all of the semantics
in HTML.

Authors must not use elements, attributes, or attribute values for purposes other than their
appropriate intended semantic purpose, as doing so prevents software from correctly processing the
page.

For example, the following document is non-conforming, despite being syntactically
correct:

...because the data placed in the cells is clearly not tabular data (and the cite
element mis-used). This would make software that relies on these semantics fail: for example, a
speech browser that allowed a blind user to navigate tables in the document would report the
quote above as a table, confusing the user; similarly, a tool that extracted titles of works from
pages would extract "Ernest" as the title of a work, even though it's actually a person's name,
not a title.

Authors must not use elements, attributes, or attribute values that are not permitted by this
specification or other applicable specifications, as doing so makes it significantly
harder for the language to be extended in the future.

In the next example, there is a non-conforming attribute value ("carpet") and a non-conforming
attribute ("texture"), which is not permitted by this specification:

Through scripting and using other mechanisms, the values of attributes, text, and indeed the
entire structure of the document may change dynamically while a user agent is processing it. The
semantics of a document at an instant in time are those represented by the state of the document
at that instant in time, and the semantics of a document can therefore change over time. User
agents must update their presentation of the document as this
occurs.

HTML has a progress element that describes a progress bar. If its
"value" attribute is dynamically updated by a script, the UA would update the rendering to show
the progress changing.

3.2.2 Elements in the DOM

The nodes representing HTML elements in the DOM must
implement, and expose to scripts, the interfaces listed for them in the relevant sections of this
specification. This includes HTML elements in XML documents, even when
those documents are in another context (e.g. inside an XSLT transform).

Elements in the DOM represent things; that is, they have
intrinsic meaning, also known as semantics.

The HTMLElement interface holds methods and attributes related to a number of
disparate features, and the members of this interface are therefore described in various different
sections of this specification.

A normative description of what content must be included as children and descendants of
the element.

Tag omission in text/html

A non-normative description of whether, in the text/html syntax, the
start and end tags can
be omitted. This information is redundant with the normative requirements given in the optional tags section, and is provided in the element
definitions only as a convenience.

Content attributes

A normative list of attributes that may be specified on the element (except where
otherwise disallowed), along with non-normative descriptions of those attributes. (The content to
the left of the dash is normative, the content to the right of the dash is not.)

DOM interface

A normative definition of a DOM interface that such elements must implement.

This is then followed by a description of what the element represents, along with
any additional normative conformance criteria that may apply to authors and implementations. Examples are sometimes also included.

3.2.3.1 Attributes

Except where otherwise specified, attributes on HTML elements
may have any string value, including the empty string. Except where explicitly stated, there is no
restriction on what text can be specified in such attributes.

3.2.4 Content models

Each element defined in this specification has a content model: a description of the element's
expected contents. An HTML
element must have contents that match the requirements described in the element's content
model. The contents of an element are its children in the
DOM, except for template elements, where the children are those in the template
contents (a separate DocumentFragment assigned to the element when the element
is created).

The space characters are always allowed between elements.
User agents represent these characters between elements in the source markup as Text
nodes in the DOM. Empty
Text nodes and Text nodes consisting of just sequences of those
characters are considered inter-element whitespace.

Inter-element whitespace, comment nodes, and processing instruction nodes must be
ignored when establishing whether an element's contents match the element's content model or not,
and must be ignored when following algorithms that define document and element semantics.

Thus, an element A is said to be preceded or followed
by a second element B if A and B have
the same parent node and there are no other element nodes or Text nodes (other than
inter-element whitespace) between them. Similarly, a node is the only child of
an element if that element contains no other nodes other than inter-element
whitespace, comment nodes, and processing instruction nodes.

Authors must not use HTML elements anywhere except where they are explicitly
allowed, as defined for each element, or as explicitly required by other specifications. For XML
compound documents, these contexts could be inside elements from other namespaces, if those
elements are defined as providing the relevant contexts.

For example, the Atom specification defines a content element. When its
type attribute has the value xhtml, the Atom
specification requires that it contain a single HTML div element. Thus, a
div element is allowed in that context, even though this is not explicitly
normatively stated by this specification. [ATOM]

In addition, HTML elements may be orphan nodes (i.e. without a parent node).

For example, creating a td element and storing it in a global variable in a
script is conforming, even though td elements are otherwise only supposed to be used
inside tr elements.

var data = {
name: "Banana",
cell: document.createElement('td'),
};

3.2.4.1 Kinds of content

Each element in HTML falls into zero or more categories
that group elements with similar characteristics together. The following broad categories are used
in this specification:

Other categories are also used for specific purposes, e.g. form controls are specified using a
number of categories to define common requirements. Some elements have unique requirements and do
not fit into any particular category.

3.2.4.1.1 Metadata content

Metadata content is content that sets up the presentation or behavior of the rest of
the content, or that sets up the relationship of the document with other documents, or that
conveys other "out of band" information.

Text nodes and attribute values must consist of Unicode characters, must not contain U+0000 characters, must not contain
permanently undefined Unicode characters (noncharacters), and must not contain control characters
other than space characters.
This specification includes extra constraints on the exact value of Text nodes and
attribute values depending on their precise context.

3.2.4.1.6 Embedded content

Embedded content is content that imports another
resource into the document, or content from another vocabulary that
is inserted into the document.

Elements that are from namespaces other than the HTML namespace and that convey
content but not metadata, are embedded content for the purposes of the content models
defined in this specification. (For example, MathML, or SVG.)

Some embedded content elements can have fallback content: content that is to be used
when the external resource cannot be used (e.g. because it is of an unsupported format). The
element definitions state what the fallback is, if any.

3.2.4.1.7 Interactive content

Interactive content is content that is specifically
intended for user interaction.

Certain elements in HTML have an activation behavior, which means that the user
can activate them. This triggers a sequence of events dependent on the activation mechanism, and
normally culminating in a click event, as
described below.

The user agent should allow the user to manually trigger elements that have an activation
behavior, for instance using keyboard or voice input, or through mouse clicks. When the
user triggers an element with a defined activation behavior in a manner other than
clicking it, the default action of the interaction event must be to run synthetic click
activation steps on the element.

Each element has a click in progress flag, initially set to false.

When a user agent is to run synthetic click activation steps on an element, the user
agent must run the following steps:

If the element's click in progress flag is set to true, then abort
these steps.

When a user agent is to run pre-click activation steps on an element, it must run
the pre-click activation steps defined for that element, if any.

When a user agent is to run canceled activation steps on an element, it must run the
canceled activation steps defined for that element, if any.

When a user agent is to run post-click activation steps on an element, it must run
the activation behavior defined for that element, if any. Activation behaviors can
refer to the click event that was fired by the steps above
leading up to this point.

3.2.4.1.8 Palpable content

As a general rule, elements whose content model allows any flow content or
phrasing content should have at least one node in its contents that is palpable
content and that does not have the hidden attribute
specified.

This requirement is not a hard requirement, however, as there are many cases where an element
can be empty legitimately, for example when it is used as a placeholder which will later be filled
in by a script, or when the element is part of a template and would on most pages be filled in but
on some pages is not relevant.

Conformance checkers are encouraged to provide a mechanism for authors to find elements that
fail to fulfill this requirement, as an authoring aid.

3.2.4.2 Transparent content models

Some elements are described as transparent; they have "transparent" in the
description of their content model. The content model of a transparent element is
derived from the content model of its parent element: the elements required in the part of the
content model that is "transparent" are the same elements as required in the part of the content
model of the parent of the transparent element in which the transparent element finds itself.

To check whether "Apples" is allowed inside the a element, the content models are
examined. The a element's content model is transparent, as is the map
element's, as is the ins element's, as is the part of the object
element's in which the ins element is found. The object element is
found in the p element, whose content model is phrasing content. Thus,
"Apples" is allowed, as text is phrasing content.

When a transparent element has no parent, then the part of its content model that is
"transparent" must instead be treated as accepting any flow content.

3.2.4.3 Paragraphs

The term paragraph as defined in this section is used for more than
just the definition of the p element. The paragraph concept defined here
is used to describe how to interpret documents. The p element is merely one of
several ways of marking up a paragraph.

A paragraph is typically a run of phrasing content that forms a block
of text with one or more sentences that discuss a particular topic, as in typography, but can also
be used for more general thematic grouping. For instance, an address is also a paragraph, as is a
part of a form, a byline, or a stanza in a poem.

In the following example, there are two paragraphs in a section. There is also a heading,
which contains phrasing content that is not a paragraph. Note how the comments and
inter-element whitespace do not form paragraphs.

<section>
<h1>Example of paragraphs</h1>
This is the <em>first</em> paragraph in this example.
<p>This is the second.</p>
<!-- This is not a paragraph. -->
</section>

Paragraphs in flow content are defined relative to what the document looks like
without the a, ins, del, and map elements
complicating matters, since those elements, with their hybrid content models, can straddle
paragraph boundaries, as shown in the first two examples below.

Generally, having elements straddle paragraph boundaries is best avoided.
Maintaining such markup can be difficult.

The following example takes the markup from the earlier example and puts ins and
del elements around some of the markup to show that the text was changed (though in
this case, the changes admittedly don't make much sense). Notice how this example has exactly the
same paragraphs as the previous one, despite the ins and del elements
— the ins element straddles the heading and the first paragraph, and the
del element straddles the boundary between the two paragraphs.

<section>
<ins><h1>Example of paragraphs</h1>
This is the <em>first</em> paragraph in</ins> this example<del>.
<p>This is the second.</p></del>
<!-- This is not a paragraph. -->
</section>

Let view be a view of the DOM that replaces all a,
ins, del, and map elements in the document with their
contents. Then, in view, for each run of sibling phrasing content
nodes uninterrupted by other types of content, in an element that accepts content other than
phrasing content as well as phrasing content, let first be the first node of the run, and let last be the last
node of the run. For each such run that consists of at least one node that is neither
embedded content nor inter-element whitespace, a paragraph exists in the
original DOM from immediately before first to immediately after last. (Paragraphs can thus span across a, ins,
del, and map elements.)

Conformance checkers may warn authors of cases where they have paragraphs that overlap each
other (this can happen with object, video, audio, and
canvas elements, and indirectly through elements in other namespaces that allow HTML
to be further embedded therein, like svg or math).

It is possible for paragraphs to overlap when using certain elements that define fallback
content. For example, in the following section:

<section>
<h1>My Cats</h1>
You can play with my cat simulator.
<object data="cats.sim">
To see the cat simulator, use one of the following links:
<ul>
<li><a href="cats.sim">Download simulator file</a>
<li><a href="http://sims.example.com/watch?v=LYds5xY4INU">Use online simulator</a>
</ul>
Alternatively, upgrade to the Mellblom Browser.
</object>
I'm quite proud of it.
</section>

There are five paragraphs:

The paragraph that says "You can play with my cat simulator. object I'm
quite proud of it.", where object is the object element.

The paragraph that says "To see the cat simulator, use one of the following links:".

The paragraph that says "Download simulator file".

The paragraph that says "Use online simulator".

The paragraph that says "Alternatively, upgrade to the Mellblom Browser.".

The first paragraph is overlapped by the other four. A user agent that supports the "cats.sim"
resource will only show the first one, but a user agent that shows the fallback will confusingly
show the first sentence of the first paragraph as if it was in the same paragraph as the second
one, and will show the last paragraph as if it was at the start of the second sentence of the
first paragraph.

To avoid this confusion, explicit p elements can be used. For example:

These attributes are only defined by this specification as attributes for HTML
elements. When this specification refers to elements having these attributes, elements from
namespaces that are not defined as having these attributes must not be considered as being
elements with these attributes.

For example, in the following XML fragment, the "bogus" element does not
have a dir attribute as defined in this specification, despite
having an attribute with the literal name "dir". Thus, the
directionality of the inner-most span element is 'rtl', inherited from the div element indirectly through
the "bogus" element.

In HTML, the xmlns attribute has absolutely no effect. It is
basically a talisman. It is allowed merely to make migration to and from XHTML mildly easier. When
parsed by an HTML parser, the attribute ends up in no namespace, not the
"http://www.w3.org/2000/xmlns/" namespace like namespace declaration attributes in
XML do.

In XML, an xmlns attribute is part of the namespace
declaration mechanism, and an element cannot actually have an xmlns
attribute in no namespace specified.

The XML specification also allows the use of the xml:space
attribute in the XML namespace on any element in an XML
document. This attribute has no effect on HTML elements, as the default
behavior in HTML is to preserve whitespace. [XML]

3.2.5.1 The id attribute

The value must be unique amongst all the IDs in the element's
home subtree and must contain at least one character. The value must not contain any
space characters.

There are no other restrictions on what form an ID can take; in particular, IDs
can consist of just digits, start with a digit, start with an underscore, consist of just
punctuation, etc.

An element's unique identifier can be used for a
variety of purposes, most notably as a way to link to specific parts of a document using fragment
identifiers, as a way to target an element when scripting, and as a way to style a specific
element from CSS.

Identifiers are opaque strings. Particular meanings should not be derived from the value of the
id attribute.

The title attribute represents advisory
information for the element, such as would be appropriate for a tooltip. On a link, this could be
the title or a description of the target resource; on an image, it could be the image credit or a
description of the image; on a paragraph, it could be a footnote or commentary on the text; on a
citation, it could be further information about the source; on interactive content,
it could be a label for, or instructions for, use of the element; and so forth. The value is
text.

Relying on the title attribute is currently
discouraged as many user agents do not expose the attribute in an accessible manner as required by
this specification (e.g. requiring a pointing device such as a mouse to cause a tooltip to appear,
which excludes keyboard-only users and touch-only users, such as anyone with a modern phone or
tablet).

If this attribute is omitted from an element, then it implies that the title attribute of the nearest ancestor HTML
element with a title attribute set is also relevant to this
element. Setting the attribute overrides this, explicitly stating that the advisory information of
any ancestors is not relevant to this element. Setting the attribute to the empty string indicates
that the element has no advisory information.

If the title attribute's value contains "LF" (U+000A)
characters, the content is split into multiple lines. Each "LF" (U+000A) character
represents a line break.

Caution is advised with respect to the use of newlines in title attributes.

For instance, the following snippet actually defines an abbreviation's expansion with a
line break in it:

<p>My logs show that there was some interest in <abbr title="Hypertext
Transport Protocol">HTTP</abbr> today.</p>

Some elements, such as link, abbr, and input, define
additional semantics for the title attribute beyond the semantics
described above.

The advisory information of an element is the value that the following algorithm
returns, with the algorithm being aborted once a value is returned. When the algorithm returns the
empty string, then there is no advisory information.

If the element is a link, style, dfn,
or abbr element, then: if the element has a title attribute, return the value of that attribute,
otherwise, return the empty string.

Otherwise, if the element has a title attribute, then
return its value.

Otherwise, if the element has a parent element, then return the parent element's
advisory information.

Otherwise, return the empty string.

User agents should inform the user when elements have advisory information,
otherwise the information would not be discoverable.

The lang attribute (in no namespace) specifies the
primary language for the element's contents and for any of the element's attributes that contain
text. Its value must be a valid BCP 47 language tag, or the empty string. Setting the attribute to
the empty string indicates that the primary language is unknown. [BCP47]

The attribute in no namespace with no prefix and with the literal localname "xml:lang" has no effect on language processing.

To determine the language of a node, user agents must look at the nearest ancestor
element (including the element itself if the node is an element) that has a lang attribute in the XML
namespace set or is an HTML element and has a
lang in no namespace attribute set. That attribute specifies the
language of the node (regardless of its value).

If neither the node nor any of the node's ancestors, including the root element,
have either attribute set, but there is a pragma-set default language set, then that
is the language of the node. If there is no pragma-set default language set, then
language information from a higher-level protocol (such as HTTP), if any, must be used as the
final fallback language instead. In the absence of any such language information, and in cases
where the higher-level protocol reports multiple languages, the language of the node is unknown,
and the corresponding language tag is the empty string.

If the resulting value is not a recognized language tag, then it must be treated as an unknown
language having the given language tag, distinct from all other languages. For the purposes of
round-tripping or communicating with other services that expect language tags, user agents should
pass unknown language tags through unmodified, and tagged as being BCP 47 language tags, so that
subsequent services do not interpret the data as another type of language description. [BCP47]

Thus, for instance, an element with lang="xyzzy" would be
matched by the selector :lang(xyzzy) (e.g. in CSS), but it would not be
matched by :lang(abcde), even though both are equally invalid. Similarly, if
a Web browser and screen reader working in unison communicated about the language of the element,
the browser would tell the screen reader that the language was "xyzzy", even if it knew it was
invalid, just in case the screen reader actually supported a language with that tag after all.
Even if the screen reader supported both BCP 47 and another syntax for encoding language names,
and in that other syntax the string "xyzzy" was a way to denote the Belarusian language, it would
be incorrect for the screen reader to then start treating text as Belarusian, because
"xyzzy" is not how Belarusian is described in BCP 47 codes (BCP 47 uses the code "be" for
Belarusian).

If the resulting value is the empty string, then it must be interpreted as meaning that the
language of the node is explicitly unknown.

User agents may use the element's language to determine proper processing or rendering (e.g. in
the selection of appropriate fonts or pronunciations, for dictionary selection, or for the user
interfaces of form controls such as date pickers).

The lang IDL attribute must reflect the
lang content attribute in no namespace.

The translate attribute is an enumerated
attribute that is used to specify whether an element's attribute values and the values of
its Text node children are to be translated when the page is localized, or whether to
leave them unchanged.

The attribute's keywords are the empty string, yes, and no. The empty string and the yes keyword map to the
yes state. The no keyword maps to the no state. In addition,
there is a third state, the inherit state, which is the missing value default (and
the invalid value default).

When an element is in the translate-enabled state, the element's translatable
attributes and the values of its Text node children are to be translated when
the page is localized. Attributes of the element that are not listed as translatable
attributes should not be translated.

When an element is in the no-translate state, the element's attribute values (including
the values of translatable attributes) and the values of its Text node
children are to be left as-is when the page is localized, e.g. because the element contains a person's
name or a the name of a computer program.

The translate IDL attribute must, on getting,
return true if the element's translation mode is translate-enabled, and
false otherwise. On setting, it must set the content attribute's value to "yes" if the new value is true, and set the content attribute's value to "no" otherwise.

In this example, everything in the document is to be translated when the page is localized,
except the sample keyboard input and sample program output:

<!DOCTYPE HTML>
<html> <!-- default on the root element is translate=yes -->
<head>
<title>The Bee Game</title> <!-- implied translate=yes inherited from ancestors -->
</head>
<body>
<p>The Bee Game is a text adventure game in English.</p>
<p>When the game launches, the first thing you should do is type
<kbd translate=no>eat honey</kbd>. The game will respond with:</p>
<pre><samp translate=no>Yum yum! That was some good honey!</samp></pre>
</body>
</html>

3.2.5.6 The dir attribute

The dir attribute specifies the element's text directionality.
The attribute is an enumerated attribute with the following keywords and states:

The ltr keyword, which maps to the ltr state

Indicates that the contents of the element are explicitly
directionally isolated left-to-right text.

The rtl keyword, which maps to the rtl state

Indicates that the contents of the element are explicitly
directionally isolated right-to-left text.

The auto keyword, which maps to the auto state

Indicates that the contents of the element are explicitly directionally isolated text, but that the
direction is to be determined programmatically using the contents of the element (as described
below).

The heuristic used by this state is very crude (it just looks at the first
character with a strong directionality, in a manner analogous to the Paragraph Level
determination in the bidirectional algorithm). Authors are urged to only use this value as a
last resort when the direction of the text is truly unknown and no better server-side heuristic
can be applied. [BIDI]

For textarea and pre elements, the heuristic is
applied on a per-paragraph level.

The attribute has no invalid value default and no missing value default.

The directionality of an element (any element, not just an HTML element) is either 'ltr' or 'rtl', and is determined as per the first appropriate set of steps from
the following list:

If the element is a textarea element and the dir
attribute is in the auto state

If the element's value contains a character of
bidirectional character type AL or R, and there is no character of bidirectional character type
L anywhere before it in the element's value, then
the directionality of the element is 'rtl'. [BIDI]

Since the dir attribute is only defined for
HTML elements, it cannot be present on elements from other namespaces. Thus, elements
from other namespaces always just inherit their directionality from their parent element, or, if they don't have one,
default to 'ltr'.

The directionality of an attribute of an
HTML element, which is used when the text of that attribute is
to be included in the rendering in some manner, is determined as per the first appropriate set of
steps from the following list:

Authors are strongly encouraged to use the dir
attribute to indicate text direction rather than using CSS, since that way their documents will
continue to render correctly even in the absence of CSS (e.g. as interpreted by search
engines).

Given a suitable style sheet and the default alignment styles for the p element,
namely to align the text to the start edge of the paragraph, the resulting rendering could
be as follows:

As noted earlier, the auto value is not a panacea. The
final paragraph in this example is misinterpreted as being right-to-left text, since it begins
with an Arabic character, which causes the "right?" to be to the left of the Arabic text.

3.2.5.7 The class attribute

The attribute, if specified, must have a value that is a set of space-separated
tokens representing the various classes that the element belongs to.

The classes that an HTML element has assigned to it consists
of all the classes returned when the value of the class attribute
is split on spaces. (Duplicates are ignored.)

Assigning classes to an element affects class matching in selectors in CSS, the
getElementsByClassName() method in the
DOM, and other such features.

There are no additional restrictions on the tokens authors can use in the class attribute, but authors are encouraged to use values that describe
the nature of the content, rather than values that describe the desired presentation of the
content.

3.2.5.8 The style attribute

In user agents that support CSS, the attribute's value must be parsed when the attribute is
added or has its value changed,
according to the rules given for CSS styling
attributes. [CSSATTR]

Documents that use style attributes on any of their elements
must still be comprehensible and usable if those attributes were removed.

In particular, using the style attribute to hide
and show content, or to convey meaning that is otherwise not included in the document, is
non-conforming. (To hide and show content, use the hidden
attribute.)

A custom data attribute is an attribute in no namespace whose name starts with the
string "data-", has at least one character after the
hyphen, is XML-compatible, and contains no uppercase ASCII letters.

All attribute names on HTML elements in HTML documents
get ASCII-lowercased automatically, so the restriction on ASCII uppercase letters doesn't affect
such documents.

Custom data attributes are intended to store custom
data private to the page or application, for which there are no more appropriate attributes or
elements.

These attributes are not intended for use by software that is independent of the site that uses
the attributes.

For instance, a site about music could annotate list items representing tracks in an album
with custom data attributes containing the length of each track. This information could then be
used by the site itself to allow the user to sort the list by track length, or to filter the list
for tracks of certain lengths.

<ol>
<li data-length="2m11s">Beyond The Sea</li>
...
</ol>

It would be inappropriate, however, for the user to use generic software not associated with
that music site to search for tracks of a certain length by looking at this data.

This is because these attributes are intended for use by the site's own scripts, and are not a
generic extension mechanism for publicly-usable metadata.

The dataset IDL attribute provides convenient
accessors for all the data-* attributes on an element. On
getting, the dataset IDL attribute must return a
DOMStringMap object, associated with the following algorithms, which expose these
attributes on their element:

The algorithm for getting the list of name-value pairs

Let list be an empty list of name-value
pairs.

For each content attribute on the element whose first five characters are the string "data-" and whose remaining characters (if any) do not include any
uppercase ASCII letters, in the order that those attributes are listed in the
element's attribute list, add a name-value pair to list whose
name is the attribute's name with the first five characters removed and whose value is the
attribute's value.

Set the value of the attribute with the name name, to the value value, replacing any previous value if the attribute already existed. If setAttribute() would have thrown an exception when setting an attribute with
the name name, then this must throw the same exception.

Notice how the hyphenated attribute name becomes camel-cased in the API.

Authors should carefully design such extensions so that when the attributes are ignored and any
associated CSS dropped, the page is still usable.

User agents must not derive any implementation behavior from these attributes or values.
Specifications intended for user agents must not define these attributes to have any meaningful
values.

JavaScript libraries may use the custom data
attributes, as they are considered to be part of the page on which they are used. Authors
of libraries that are reused by many authors are encouraged to include their name in the attribute
names, to reduce the risk of clashes. Where it makes sense, library authors are also encouraged to
make the exact name used in the attribute names customizable, so that libraries whose authors
unknowingly picked the same name can be used on the same page, and so that multiple versions of a
particular library can be used on the same page even when those versions are not mutually
compatible.

For example, a library called "DoQuery" could use attribute names like data-doquery-range, and a library called "jJo" could use attributes names like
data-jjo-range. The jJo library could also provide an API to set which
prefix to use (e.g. J.setDataPrefix('j2'), making the attributes have names
like data-j2-range).

3.2.6 Requirements relating to the bidirectional algorithm

Text content in HTML elements with Text nodes in their
contents, and text in attributes of HTML
elements that allow free-form text, may contain characters in the ranges U+202A to U+202E
and U+2066 to U+2069 (the bidirectional-algorithm formatting characters). However, the use of
these characters is restricted so that any embedding or overrides generated by these characters do
not start and end with different parent elements, and so that all such embeddings and overrides
are explicitly terminated by a U+202C POP DIRECTIONAL FORMATTING character. This helps reduce
incidences of text being reused in a manner that has unforeseen effects on the bidirectional
algorithm. [BIDI]

While the U+2069 POP DIRECTIONAL ISOLATE character implicitly also ends open
embeddings and overrides, text that relies on this implicit scope closure is not conforming to
this specification. All strings of embeddings, overrides, and isolations need to be explicitly
terminated to conform to this section's requirements.

Authors are encouraged to use the dir attribute, the
bdo element, and the bdi element, rather than maintaining the
bidirectional-algorithm formatting characters manually. The bidirectional-algorithm formatting
characters interact poorly with CSS.

3.2.6.2 User agent conformance criteria

User agents must implement the Unicode bidirectional algorithm to determine the proper ordering
of characters when rendering documents and parts of documents. [BIDI]

The mapping of HTML to the Unicode bidirectional algorithm must be done in one of three ways.
Either the user agent must implement CSS, including in particular the CSS 'unicode-bidi',
'direction', and 'content' properties, and must have, in its user agent style sheet, the rules
using those properties given in this specification's rendering section,
or, alternatively, the user agent must act as if it implemented just the aforementioned properties
and had a user agent style sheet that included all the aforementioned rules, but without letting
style sheets specified in documents override them, or, alternatively, the user agent must
implement another styling language with equivalent semantics. [CSSWM][CSSGC]

3.2.7 WAI-ARIA

Authors are encouraged to make use of the following documents for guidance on using ARIA in
HTML beyond that which is provided in this section:

Using WAI-ARIA in HTML
- A practical guide for developers on how to to add accessibility information to HTML elements using
the Accessible Rich Internet Applications specification [ARIA].
In particular the
Recommendations Table
provides a complete reference for authors as to which ARIA roles, states and properties
are appropriate to use on each HTML element.

Authors may use the ARIA role and aria-* attributes on HTML elements, in accordance with the
requirements described in the ARIA specifications, except where these conflict with the
strong native semantics
described below. These exceptions are intended to prevent authors from making
assistive technology products report nonsensical states that do not represent the actual state of
the document. [ARIA]

The ARIA attributes defined in the ARIA specifications, and the strong
native semantics and default implicit ARIA semantics defined below, do not
have any effect on CSS pseudo-class matching, user interface modalities that don't use assistive
technologies, or the default actions of user interaction events as described in this
specification.

ARIA State and Property attributes can be used on any element. They
are not always meaningful, however, and in such cases user agents
might not perform any processing aside from including them in the DOM.
State and property attributes are processed according to the
requirements of the sections Strong Native Semantics and Implicit ARIA semantics, as
well as [ARIA] and [ARIAIMPL].

3.2.7.3 Strong Native Semantics

The following table defines the strong native semantics and corresponding
default implicit ARIA semantics that apply to HTML elements. Each
language feature (element or attribute) in a cell in the first column implies the ARIA semantics
(any role, states, and properties) given in the cell in the second column of the same row. When multiple rows apply to an element, the role from the last row to define a role
must be applied, and the states and properties from all the rows must be combined.

Documents must not use any role values with elements
in the following table other than the corresponding role value (if any) as listed for that element in the second column,
or the role value "presentation", if the second column indicates that element's
semantics can be removed by using the "presentation" role value.

In the majority of cases setting an ARIA role and/or aria-* attribute that matches the default implicit ARIA semantics is
unnecessary and not recommended as these properties are already set by the browser.

spinbutton role, with the aria-readonly property set to "true" if the element has a readonly attribute, the aria-valuemax property set to the element's maximum, the aria-valuemin property set to the element's minimum, and, if the result of applying the rules for parsing floating-point number values to the element's value is a number, with the aria-valuenow property set to that number

progressbar role, with, if the progress bar is determinate, the aria-valuemax property set to the maximum value of the progress bar, the aria-valuemin property set to zero, and the aria-valuenow property set to the current value of the progress bar

3.2.7.4 Implicit ARIA Semantics

Some HTML elements have native semantics that can be overridden. The following
table lists these elements and their default implicit ARIA semantics, along with the
restrictions that apply to those elements. Each language feature (element or attribute) in a cell
in the first column implies, unless otherwise overridden, the ARIA semantic (role, state, or
property) given in the cell in the second column of the same row, but this semantic may be
overridden under the conditions listed in the cell in the third column of that row.

The entry "no role", when used as a strong native semantic, means that no role can be used and that the
user agent has no default mapping to ARIA roles. (However, it could have its own mappings to the
accessibility layer.) When used as a default
implicit ARIA semantic, it means the user agent has no default mapping to ARIA roles.
(However, it could have its own mappings to the accessibility layer.)

The WAI-ARIA specification neither requires or forbids user
agents from enhancing native presentation and interaction behaviors
on the basis of WAI- ARIA markup. Even mainstream user agents might
choose to expose metadata or navigational features directly or via
user-installed extensions; for example, exposing required form
fields or landmark navigation. User agents are encouraged to
maximize their usefulness to users, including users without
disabilities.

Conformance checkers are encouraged to phrase errors such that authors are encouraged to use
more appropriate elements rather than remove accessibility annotations. For example, if an
a element is marked as having the button
role, a conformance checker could say "Use a more appropriate element to represent a button, for
example a button element or an input element" rather than "The button role cannot be used with a elements".

These features can be used to make accessibility tools render content to their users in more
useful ways. For example, ASCII art, which is really an image, appears to be text, and in the
absence of appropriate annotations would end up being rendered by screen readers as a very
painful reading of lots of punctuation. Using the features described in this section, one can
instead make the ATs skip the ASCII art and just read the caption:

3.2.7.5 Allowed ARIA roles, states and properties

This section is non-normative.

The following table provides an informative reference to the ARIA roles, states and properties permitted for use in HTML. All ARIA roles, states and properties are normatively defined in the [ARIA] specification. Links to ARIA roles, states and properties in the table reference the normative [ARIA] definitions.

A dialog is an application window that is designed to interrupt the current processing of an application in order to prompt the user to enter information or require a response. See related alertdialog.

A large perceivable section of a web page or document, that the author feels is important enough to be included in a page summary or table of contents, for example, an area of the page containing live sporting event statistics.

Authors are encouraged to specify a lang attribute on the root
html element, giving the document's language. This aids speech synthesis tools to
determine what pronunciations to use, translation tools to determine what rules to use, and so
forth.

The html element in the following example declares that the document's language
is English.

<!DOCTYPE html>
<html lang="en">
<head>
<title>Swapping Songs</title>
</head>
<body>
<h1>Swapping Songs</h1>
<p>Tonight I swapped some of the songs I wrote with some friends, who
gave me some of the songs they wrote. I love sharing my music.</p>
</body>
</html>

The title element is a required child in most situations, but when a
higher-level protocol provides title information, e.g. in the Subject line of an e-mail when HTML
is used as an e-mail authoring format, the title element can be omitted.

The title element represents the document's title or name. Authors
should use titles that identify their documents even when they are used out of context, for
example in a user's history or bookmarks, or in search results. The document's title is often
different from its first heading, since the first heading does not have to stand alone when taken
out of context.

Returns the contents of the element, ignoring child nodes that aren't Text
nodes.

Can be set, to replace the element's children with the given value.

The IDL attribute text must return a
concatenation of the contents of all the Text nodes that are children of the
title element (ignoring any other nodes such as comments or elements), in tree order.
On setting, it must act the same way as the textContent IDL attribute.

Here are some examples of appropriate titles, contrasted with the top-level headings that
might be used on those same pages.

<title>Introduction to The Mating Rituals of Bees</title>
...
<h1>Introduction</h1>
<p>This companion guide to the highly successful
<cite>Introduction to Medieval Bee-Keeping</cite> book is...

The next page might be a part of the same site. Note how the title describes the subject
matter unambiguously, while the first heading assumes the reader knows what the context is and
therefore won't wonder if the dances are Salsa or Waltz:

The string to use as the document's title is given by the document.title IDL attribute.

User agents should use the document's title when referring to the document in their user
interface. When the contents of a title element are used in this way, the
directionality of that title element should be used to set the directionality
of the document's title in the user interface.

A base element, if it has an href attribute,
must come before any other elements in the tree that have attributes defined as taking URLs, except the html element (its manifest attribute isn't affected by base
elements).

If there are multiple base elements with href attributes, all but the first are ignored.

A base element, if it has a target
attribute, must come before any elements in the tree that represent hyperlinks.

If there are multiple base elements with target attributes, all but the first are ignored.

A base element that is the first base element with an href content attribute in a particular Document has a
frozen base URL. The frozen base URL must be set, synchronously, whenever any of the following situations occur:

If the rel attribute is used, the element is
restricted to the head element.

The types of link indicated (the relationships) are given by the value of the rel attribute, which, if present, must have a value that
is a set of space-separated tokens. The allowed keywords and
their meanings are defined in a later section. If the rel attribute is absent, has no keywords, or if none of the keywords
used are allowed according to the definitions in this specification, then the element does not
create any links.

Two categories of links can be created using the link element: Links to external resources and hyperlinks. The link types section defines
whether a particular link type is an external resource or a hyperlink. One link
element can create multiple links (of which some might be external resource links and some might
be hyperlinks); exactly which and how many links are created depends on the keywords given in the
rel attribute. User agents must process the links on a per-link
basis, not a per-element basis.

Each link created for a link element is handled separately. For
instance, if there are two link elements with rel="stylesheet",
they each count as a separate external resource, and each is affected by its own attributes
independently. Similarly, if a single link element has a rel attribute with the value next stylesheet,
it creates both a hyperlink (for the next keyword) and
an external resource link (for the stylesheet
keyword), and they are affected by other attributes (such as media or title)
differently.

For example, the following link element creates two hyperlinks (to the same
page):

<link rel="author license" href="/about">

The two links created by this element are one whose semantic is that the target page has
information about the current page's author, and one whose semantic is that the target page has
information regarding the license under which the current page is provided.

The exact behavior for links to external resources depends on the exact relationship, as
defined for the relevant link type. Some of the attributes control whether or not the external
resource is to be applied (as defined below).

For external resources that are represented in the DOM (for example, style sheets), the DOM
representation must be made available (modulo cross-origin restrictions) even if the resource is
not applied. To obtain the resource, the user agent must
run the following steps:

If the href attribute's value is the empty string,
then abort these steps.

User agents may opt to only try to obtain such resources when they are needed, instead of
pro-actively fetching all the external resources that are not
applied.

The semantics of the protocol used (e.g. HTTP) must be followed when fetching external
resources. (For example, redirects will be followed and 404 responses will cause the external
resource to not be applied.)

Once the attempts to obtain the resource and its critical subresources are
complete, the user agent must, if the loads were successful, queue a task to
fire a simple event named load at the
link element, or, if the resource or one of its critical subresources
failed to completely load for any reason (e.g. DNS error, HTTP 404 response, a connection being
prematurely closed, unsupported Content-Type), queue a task to fire a simple
event named error at the link element.
Non-network errors in processing the resource or its subresources (e.g. CSS parse errors, PNG
decoding errors) are not failures for the purposes of this paragraph.

The element must delay the load event of the element's document until all the
attempts to obtain the resource and its critical subresources are complete.
(Resources that the user agent has not yet attempted to obtain, e.g. because it is waiting for the
resource to be needed, do not delay the load event.)

Interactive user agents may provide users with a means to follow the hyperlinks created using the link element, somewhere
within their user interface. The exact interface is not defined by this specification, but it
could include the following information (obtained from the element's attributes, again as defined
below), in some form or another (possibly simplified), for each hyperlink created with each
link element in the document:

The relationship between this document and the resource (given by the rel attribute)

User agents could also include other information, such as the type of the resource (as given by
the type attribute).

Hyperlinks created with the link element and its rel attribute apply to the whole page. This contrasts with the rel attribute of a and area elements,
which indicates the type of a link whose context is given by the link's location within the
document.

The media attribute says which media the
resource applies to. The value must be a valid media query.

If the link is a hyperlink then the media
attribute is purely advisory, and describes for which media the document in question was
designed.

The external resource might have further restrictions defined within that limit
its applicability. For example, a CSS style sheet might have some @media
blocks. This specification does not override such further restrictions or requirements.

The default, if the media attribute is
omitted, is "all", meaning that by default links apply to all media.

The type attribute gives the MIME
type of the linked resource. It is purely advisory. The value must be a valid MIME
type.

For external resource links, the type attribute is used as a hint to user agents so that they can
avoid fetching resources they do not support. If the attribute is present, then
the user agent must assume that the resource is of the given type (even if that is not a
valid MIME type, e.g. the empty string). If the attribute is omitted, but the
external resource link type has a default type defined, then the user agent must assume that the
resource is of that type. If the UA does not support the given MIME type for the
given link relationship, then the UA should not obtain
the resource; if the UA does support the given MIME type for the given link
relationship, then the UA should obtain the resource at
the appropriate time as specified for the external resource link's particular type.
If the attribute is omitted, and the external resource link type does not have a default type
defined, but the user agent would obtain the resource if
the type was known and supported, then the user agent should obtain the resource under the assumption that it will be
supported.

User agents must not consider the type attribute
authoritative — upon fetching the resource, user agents must not use the type attribute to determine its actual type. Only the actual type
(as defined in the next paragraph) is used to determine whether to apply the resource,
not the aforementioned assumed type.

If the external resource link type defines rules for processing
the resource's Content-Type metadata, then those rules apply.
Otherwise, if the resource is expected to be an image, user agents may apply the image sniffing rules, with the official
type being the type determined from the resource's Content-Type
metadata, and use the resulting sniffed type of the resource as if it was the actual type.
Otherwise, if neither of these conditions apply or if the user agent opts not to apply the image
sniffing rules, then the user agent must use the resource's Content-Type metadata to determine the type of the resource. If there
is no type metadata, but the external resource link type has a default type defined, then the user
agent must assume that the resource is of that type.

Once the user agent has established the type of the resource, the user agent must apply the
resource if it is of a supported type and the other relevant conditions apply, and must ignore the
resource otherwise.

...then a compliant UA that supported only CSS style sheets would fetch the B and C files, and
skip the A file (since text/plain is not the MIME type for CSS style
sheets).

For files B and C, it would then check the actual types returned by the server. For those that
are sent as text/css, it would apply the styles, but for those labeled as
text/plain, or any other type, it would not.

If one of the two files was returned without a Content-Type metadata, or with a
syntactically incorrect type like Content-Type: "null", then the
default type for stylesheet links would kick in. Since that
default type is text/css, the style sheet would nonetheless be
applied.

The title attribute gives the title of the
link. With one exception, it is purely advisory. The value is text. The exception is for style
sheet links, where the title attribute defines
alternative style sheet sets.

The title attribute on link
elements differs from the global title attribute of most other
elements in that a link without a title does not inherit the title of the parent element: it
merely has no title.

The sizes attribute is used with the icon link type. The attribute must not be specified on link
elements that do not have a rel attribute that specifies the
icon keyword.

HTTP Link: headers, if supported, must be assumed to come before
any links in the document, in the order that they were given in the HTTP message. These headers
are to be processed according to the rules given in the relevant specifications. [HTTP][WEBLINK]

Registration of relation types in HTTP Link: headers is distinct from HTML link types, and thus their semantics can be different from same-named
HTML types.

The IDL attributes href, rel, media,
hreflang, type, and sizes each must reflect the respective
content attributes of the same name.

The IDL attribute disabled only applies to
style sheet links. When the link element defines a style sheet link, then the disabled attribute behaves as defined for the alternative style sheets DOM. For all other
link elements it always return false and does nothing on setting.

The meta element can represent document-level metadata with the name attribute, pragma directives with the http-equiv attribute, and the file's character encoding
declaration when an HTML document is serialized to string form (e.g. for transmission over
the network or for disk storage) with the charset
attribute.

The charset attribute on the
meta element has no effect in XML documents, and is only allowed in order to
facilitate migration to and from XHTML.

There must not be more than one meta element with a charset attribute per document.

The content attribute gives the value of the
document metadata or pragma directive when the element is used for those purposes. The allowed
values depend on the exact context, as described in subsequent sections of this specification.

If a meta element has a name
attribute, it sets document metadata. Document metadata is expressed in terms of name-value pairs,
the name attribute on the meta element giving the
name, and the content attribute on the same element giving
the value. The name specifies what aspect of metadata is being set; valid names and the meaning of
their values are described in the following sections. If a meta element has no content attribute, then the value part of the metadata name-value
pair is the empty string.

The name and content IDL attributes must reflect the
respective content attributes of the same name. The IDL attribute httpEquiv must reflect the content
attribute http-equiv.

4.2.5.1 Standard metadata names

This specification defines a few names for the name
attribute of the meta element.

The value must be a short free-form string giving the name of the Web application that the
page represents. If the page is not a Web application, the application-name metadata name must not be used.
Translations of the Web application's name may be given, using the attribute to specify the language of each name.

User agents may use the application name in UI in preference to the page's
title, since the title might include status messages and the like relevant to the
status of the page at a particular moment in time instead of just being the name of the
application.

To find the application name to use given an ordered list of languages (e.g. British English,
American English, and English), user agents must run the following steps:

If there is a default language, and if it is not the same language
as any of the languages is languages, append it to languages.

Let winning language be the first language in languages for which there is a meta element in the
Document that has its name attribute set to
the value application-name and whose
language is the language in question.

If none of the languages have such a meta element, then abort these steps;
there's no given application name.

The value must be a free-form string giving the name of one of the page's
authors.

description

The value must be a free-form string that describes the page. The value must be
appropriate for use in a directory of pages, e.g. in a search engine. There must not be more than
one meta element with its name attribute set to
the value description per document.

generator

The value must be a free-form string that identifies one of the software packages used to
generate the document. This value must not be used on pages whose markup is not generated by
software, e.g. pages whose markup was written by a user in a text editor.

Here is what a tool called "Frontweaver" could include in its output, in the page's
head element, to identify itself as the tool used to generate the page:

Many search engines do not consider such keywords, because this feature has
historically been used unreliably and even misleadingly as a way to spam search engine results
in a way that is not helpful for users.

To obtain the list of keywords that the author has specified as applicable to the page, the
user agent must run the following steps:

Let keywords be an empty list.

For each meta element with a name
attribute and a content attribute and whose name attribute's value is keywords, run the following substeps:

Return keywords. This is the list of keywords that the author has
specified as applicable to the page.

User agents should not use this information when there is insufficient confidence in the
reliability of the value.

For instance, it would be reasonable for a content management system to use
the keyword information of pages within the system to populate the index of a site-specific
search engine, but a large-scale content aggregator that used this information would likely find
that certain users would try to game its ranking mechanism through the use of inappropriate
keywords.

4.2.5.2 Other metadata names

Anyone is free to edit the WHATWG Wiki MetaExtensions page at any time to add a type. These new
names must be specified with the following information:

Keyword

The actual name being defined. The name should not be confusingly similar to any other
defined name (e.g. differing only in case).

Brief description

A short non-normative description of what the metadata name's meaning is, including the
format the value is required to be in.

Specification

A link to a more detailed description of the metadata name's semantics and requirements. It
could be another page on the Wiki, or a link to an external page.

Synonyms

A list of other names that have exactly the same processing requirements. Authors should
not use the names defined to be synonyms, they are only intended to allow user agents to support
legacy content. Anyone may remove synonyms that are not used in practice; only names that need to
be processed as synonyms for compatibility with legacy content are to be registered in this
way.

Status

One of the following:

Proposed

The name has not received wide peer review and approval. Someone has proposed it and is, or
soon will be, using it.

Ratified

The name has received wide peer review and approval. It has a specification that
unambiguously defines how to handle pages that use the name, including when they use it in
incorrect ways.

Discontinued

The metadata name has received wide peer review and it has been found wanting. Existing
pages are using this metadata name, but new pages should avoid it. The "brief description" and
"specification" entries will give details of what authors should use instead, if anything.

If a metadata name is found to be redundant with existing values, it should be removed and
listed as a synonym for the existing value.

If a metadata name is registered in the "proposed" state for a period of a month or more
without being used or specified, then it may be removed from the registry.

If a metadata name is added with the "proposed" status and found to be redundant with
existing values, it should be removed and listed as a synonym for the existing value. If a
metadata name is added with the "proposed" status and found to be harmful, then it should be
changed to "discontinued" status.

Anyone can change the status at any time, but should only do so in accordance with the
definitions above.

Conformance checkers may use the information given on the WHATWG
Wiki MetaExtensions page to establish if a value is allowed or not:
values defined in this specification or marked as "proposed" or
"ratified" must be accepted, whereas values marked as "discontinued"
or not listed in either this specification or on the aforementioned
page must be reported as invalid. Conformance checkers may cache
this information (e.g. for performance reasons or to avoid the use
of unreliable network connectivity).

When an author uses a new metadata name not defined by either this specification or the Wiki
page, conformance checkers should offer to add the value to the Wiki, with the details described
above, with the "proposed" status.

Metadata names whose values are to be URLs must not be proposed or
accepted. Links must be represented using the link element, not the meta
element.

4.2.5.3 Pragma directives

When the http-equiv attribute is specified
on a meta element, the element is a pragma directive.

The http-equiv attribute is an enumerated
attribute. The following table lists the keywords defined for this attribute. The states
given in the first cell of the rows with keywords give the states to which those keywords map.
Some of the keywords are non-conforming, as noted in the last
column.

When a meta element is inserted
into the document, if its http-equiv attribute is
present and represents one of the above states, then the user agent must run the algorithm
appropriate for that state, as described in the following list:

Content language state
(http-equiv="content-language")

This feature is non-conforming. Authors are encouraged to use the lang attribute instead.

This pragma sets the pragma-set default language. Until such a pragma is
successfully processed, there is no pragma-set default language.

If another meta element with an http-equiv attribute in the Refresh state has already been successfully
processed (i.e. when it was inserted the user agent processed it and reached the last step of
this list of steps), then abort these steps.

If the meta element has no content
attribute, or if that attribute's value is the empty string, then abort these steps.

If the character in input pointed to by position
is a "U" (U+0055) character or a U+0075 LATIN SMALL LETTER U character
(u), then advance position to the next character. Otherwise, jump to the
last step.

If the character in input pointed to by position
is a "R" (U+0052) character or a U+0072 LATIN SMALL LETTER R character
(r), then advance position to the next character. Otherwise, jump to the
last step.

If the character in input pointed to by position
is s "L" (U+004C) character or a U+006C LATIN SMALL LETTER L character
(l), then advance position to the next character. Otherwise, jump to the
last step.

If the character in input pointed to by position
is either a "'" (U+0027) character or """ (U+0022) character, then let
quote be that character, and advance position to the
next character. Otherwise, let quote be the empty string.

Let url be equal to the substring of input from
the character at position to the end of the string.

If quote is not the empty string, and there is a character in url equal to quote, then truncate url at
that character, so that it and all subsequent characters are removed.

In the former case, the integer represents a number of seconds before the page is to be
reloaded; in the latter case the integer represents a number of seconds before the page is to be
replaced by the page at the given URL.

A news organization's front page could include the following markup in the page's
head element, to ensure that the page automatically reloads from the server every
five minutes:

<meta http-equiv="Refresh" content="300">

A sequence of pages could be used as an automated slide show by making each page refresh to
the next page in the sequence, using markup such as the following:

4.2.5.4 Other pragma directives

Such extensions must use a name that is identical to an HTTP header registered in the Permanent
Message Header Field Registry, and must have behavior identical to that described for the HTTP
header. [IANAPERMHEADERS]

Pragma directives corresponding to headers describing metadata, or not requiring specific user
agent processing, must not be registered; instead, use metadata names. Pragma directives corresponding to headers
that affect the HTTP processing model (e.g. caching) must not be registered, as they would result
in HTTP-level behavior being different for user agents that implement HTML than for user agents
that do not.

Anyone is free to edit the WHATWG Wiki PragmaExtensions page at any time to add a pragma
directive satisfying these conditions. Such registrations must specify the following
information:

Keyword

The actual name being defined. The name must match a previously-registered HTTP name with
the same requirements.

Brief description

A short non-normative description of the purpose of the pragma directive.

Specification

A link to the specification defining the corresponding HTTP header.

Conformance checkers must use the information given on the WHATWG Wiki PragmaExtensions page to
establish if a value is allowed or not: values defined in this specification or listed on the
aforementioned page must be accepted, whereas values not listed in either this specification or on
the aforementioned page must be rejected as invalid. Conformance checkers may cache this
information (e.g. for performance reasons or to avoid the use of unreliable network
connectivity).

4.2.5.5 Specifying the document's character encoding

A character encoding declaration is a mechanism by which the character encoding used to store or transmit a document is specified.

A character encoding declaration is required (either in the Content-Type metadata or explicitly in the file) even if the encoding
is US-ASCII, because a character encoding is needed to process non-ASCII characters entered by the
user in forms, in URLs generated by scripts, and so forth.

Authors should use UTF-8. Conformance checkers may advise authors against using legacy
encodings. [RFC3629]

Authoring tools should default to using UTF-8 for newly-created documents. [RFC3629]

Encodings in which a series of bytes in the range 0x20 to 0x7E can encode characters other than
the corresponding characters in the range U+0020 to U+007E represent a potential security
vulnerability: a user agent that does not support the encoding (or does not support the label used
to declare the encoding, or does not use the same mechanism to detect the encoding of unlabeled
content as another user agent) might end up interpreting technically benign plain text content as
HTML tags and JavaScript. Authors should therefore not use these encodings. For example, this
applies to encodings in which the bytes corresponding to "<script>" in
ASCII can encode a different string. Authors should not use such encodings, which are known to
include JIS_C6226-1983, JIS_X0212-1990,
HZ-GB-2312, JOHAB (Windows code page 1361), encodings based on
ISO-2022, and encodings
based on EBCDIC. Furthermore, authors must not use the CESU-8, UTF-7, BOCU-1 and SCSU encodings,
which also fall into this category; these encodings were never intended for use for Web content.
[RFC1345][RFC1842][RFC1468][RFC2237][RFC1554][CP50220][RFC1922][RFC1557][CESU8][UTF7][BOCU1][SCSU]

Authors should not use UTF-32, as the encoding detection algorithms described in this
specification intentionally do not distinguish it from UTF-16. [UNICODE]

Using non-UTF-8 encodings can have unexpected results on form submission and URL
encodings, which use the document's character encoding by default.

In XHTML, the XML declaration should be used for inline character encoding information, if
necessary.

In HTML, to declare that the character encoding is UTF-8, the author could include the
following markup near the top of the document (in the head element):

<meta charset="utf-8">

In XML, the XML declaration would be used instead, at the very top of the markup:

The type attribute gives the styling language.
If the attribute is present, its value must be a valid MIME type that designates a
styling language. The charset parameter must not be specified. The default
value for the type attribute, which is used if the attribute
is absent, is "text/css". [RFC2318]

When examining types to
determine if they support the language, user agents must not ignore unknown MIME parameters
— types with unknown parameters must be assumed to be unsupported. The charset parameter must be treated as an unknown parameter for the purpose of
comparing MIME types here.

The media attribute says which media the
styles apply to. The value must be a valid media query. The user
agent must apply the styles when the media attribute's value
matches the environment and the other relevant conditions apply, and must not apply
them otherwise.

The styles might be further limited in scope, e.g. in CSS with the use of @media blocks. This specification does not override such further restrictions or
requirements.

The default, if the media
attribute is omitted, is "all", meaning that by default styles apply to all
media.

The title attribute on style
elements, like the title attribute on link
elements, differs from the global title attribute in that a
style block without a title does not inherit the title of the parent element: it
merely has no title.

The textContent of a style element must match the style production in the following ABNF, the character set for which is Unicode. [ABNF]

All descendant elements must be processed, according to their semantics, before the
style element itself is evaluated. For styling languages that consist of pure text
(as opposed to XML), user agents must evaluate style elements by passing the
concatenation of the contents of all the Text nodes that are children of the
style element (not any other nodes such as comments or elements), in tree
order, to the style system. For XML-based styling languages, user agents must pass all the
child nodes of the style element to the style system.

All URLs found by the styling language's processor must be resolved, relative to the element (or as defined by the styling
language), when the processor is invoked.

Once the attempts to obtain the style sheet's critical subresources, if any, are
complete, or, if the style sheet has no critical subresources, once the style sheet
has been parsed and processed, the user agent must, if the loads were successful or there were
none, queue a task to fire a simple event named load at the style element, or, if one of the style sheet's
critical subresources failed to completely load for any reason (e.g. DNS error, HTTP
404 response, a connection being prematurely closed, unsupported Content-Type), queue a
task to fire a simple event named error at
the style element. Non-network errors in processing the style sheet or its
subresources (e.g. CSS parse errors, PNG decoding errors) are not failures for the purposes of
this paragraph.

The following document has its stress emphasis styled as bright red text rather than italics
text, while leaving titles of works and Latin words in their default italics. It shows how using
appropriate elements enables easier restyling of documents.

4.2.7 Styling

The link and style elements can provide styling information for the
user agent to use when rendering the document. The CSS and CSSOM specifications specify what
styling information is to be used by the user agent and how it is to be used. [CSS][CSSOM]

For link elements, the location must be the result of resolving the URL given by the element's href content attribute, relative to the element, or the empty
string if that fails. For style elements, there is no location.

The style sheet media

The media must be the same as the value of the element's media
content attribute, or the empty string, if the attribute is omitted.

The style sheet title

The title must be the same as the value of the element's title content attribute, if the attribute is present and has a non-empty
value. If the attribute is absent or its value is the empty string, then the style sheet does not
have a title (it is the empty string). The title is used for defining alternative style
sheet sets.

The disabled IDL attribute on
link and style elements must return false and do nothing on setting, if
the sheet attribute of their LinkStyle
interface is null. Otherwise, it must return the value of the StyleSheet interface's
disabled attribute on getting, and forward the new
value to that same attribute on setting.

The rules for handling alternative style sheets are defined in the
CSS object model specification. [CSSOM]

Style sheets, whether added by a link element, a style element, an
<?xml-stylesheet> PI, an HTTP Link: header, or some
other mechanism, have a style sheet ready flag, which is initially unset.

When a style sheet is ready to be applied, its style sheet ready flag must be set.
If the style sheet referenced no other resources (e.g. it was an internal style sheet given by a
style element with no @import rules), then the style rules must
be synchronously made available to script; otherwise, the style rules must only be made available
to script once the event loop reaches its "update the rendering" step.

Giving up on a style sheet before the style sheet loads, if the style sheet
eventually does still load, means that the script might end up operating with incorrect
information. For example, if a style sheet sets the color of an element to green, but a script
that inspects the resulting style is executed before the sheet is loaded, the script will find
that the element is black (or whatever the default color is), and might thus make poor choices
(e.g. deciding to use black as the color elsewhere on the page, instead of green). Implementors
have to balance the likelihood of a script using incorrect information with the performance impact
of doing nothing while waiting for a slow network request to finish.

In conforming documents, there is only one body
element. The document.body
IDL attribute provides scripts with easy access to a document's
body element.

Some DOM operations (for example, parts of the
drag and drop model) are defined in terms of "the
body element". This refers to a particular element in the
DOM, as per the definition of the term, and not any arbitrary
body element.

The article element represents a complete, or self-contained,
composition in a document, page, application, or site and that is, in principle, independently
distributable or reusable, e.g. in syndication. This could be a forum post, a magazine or
newspaper article, a blog entry, a user-submitted comment, an interactive widget or gadget, or any
other independent item of content.

When article elements are nested, the inner article elements
represent articles that are in principle related to the contents of the outer article. For
instance, a blog entry on a site that accepts user-submitted comments could represent the comments
as article elements nested within the article element for the blog
entry.

Author information associated with an article element (q.v. the
address element) does not apply to nested article elements.

When used specifically with content to be redistributed in syndication, the
article element is similar in purpose to the entry element in
Atom. [ATOM]

The schema.org microdata vocabulary can be used to provide the publication date
for an article element, using one of the CreativeWork subtypes.

When the main content of the page (i.e. excluding footers, headers, navigation blocks, and
sidebars) is all one single self-contained composition, the content should be marked up with a
main element and the content may also be marked with an article, but
it is technically redundant in this case (since it's self-evident that the page is a single
composition, as it is a single document).

This example shows a blog post using the article element, with some schema.org
annotations:

Notice the use of footer to give the information for each comment (such as who
wrote it and when): the footer element can appear at the start of its
section when appropriate, such as in this case. (Using header in this case wouldn't
be wrong either; it's mostly a matter of authoring preference.)

The section element represents a generic section of a document or
application. A section, in this context, is a thematic grouping of content. The theme of each section
should be identified, typically by including a heading (h1-h6 element) as
a child of the section element.

Examples of sections would be chapters, the various tabbed pages in a tabbed
dialog box, or the numbered sections of a thesis. A Web site's home page could be split into
sections for an introduction, news items, and contact information.

Authors are encouraged to use the article element instead of the
section element when it would make sense to syndicate the contents of the
element.

The section element is not a generic
container element. When an element is needed only for styling purposes or as a convenience for
scripting, authors are encouraged to use the div element instead. A general rule is
that the section element is appropriate only if the element's contents would be
listed explicitly in the document's outline.

In the following example, we see an article (part of a larger Web page) about apples,
containing two short sections.

<article>
<header>
<h2>Apples</h2>
<p>Tasty, delicious fruit!</p>
</header>
<p>The apple is the pomaceous fruit of the apple tree.</p>
<section>
<h3>Red Delicious</h3>
<p>These bright red apples are the most common found in many
supermarkets.</p>
</section>
<section>
<h3>Granny Smith</h3>
<p>These juicy, green apples make a great filling for
apple pies.</p>
</section>
</article>

Here is a graduation programme with two sections, one for the list of people graduating, and
one for the description of the ceremony. (The markup in this example features an uncommon style
sometimes used to minimize the amount of inter-element whitespace.)

In this example, a book author has marked up some sections as chapters and some as appendices,
and uses CSS to style the headers in these two classes of section differently. The whole book is
wrapped in an article element as part of an even larger document containing other
books.

The nav element represents a section of a page that links to other
pages or to parts within the page: a section with navigation links.

In cases where the content of a nav element represents a list of items,
use list markup to aid understanding and navigation.

Not all groups of links on a page need to be in a nav element —
the element is primarily intended for sections that consist of major navigation blocks. In
particular, it is common for footers to have a short list of links to various pages of a site,
such as the terms of service, the home page, and a copyright page. The footer element
alone is sufficient for such cases; while a nav element can be used in such cases, it
is usually unnecessary.

User agents (such as screen readers) that are targeted at users who can benefit
from navigation information being omitted in the initial rendering, or who can benefit from
navigation information being immediately available, can use this element as a way to determine
what content on the page to initially skip or provide on request (or both).

In the following example, the page has several places where links are present, but only one of
those places is considered a navigation section.

A nav element doesn't have to contain a list, it can contain other kinds of
content as well. In this navigation block, links are provided in prose:

<nav>
<h1>Navigation</h1>
<p>You are on my home page. To the north lies <a href="/blog">my
blog</a>, from whence the sounds of battle can be heard. To the east
you can see a large mountain, upon which many <a
href="/school">school papers</a> are littered. Far up thus mountain
you can spy a little figure who appears to be me, desperately
scribbling a <a href="/school/thesis">thesis</a>.</p>
<p>To the west are several exits. One fun-looking exit is labeled <a
href="http://games.example.com/">"games"</a>. Another more
boring-looking exit is labeled <a
href="http://isp.example.net/">ISP™</a>.</p>
<p>To the south lies a dark and dank <a href="/about">contacts
page</a>. Cobwebs cover its disused entrance, and at one point you
see a rat run quickly out of the page.</p>
</nav>

The aside element represents a section of a page that consists of
content that is tangentially related to the content around the aside element, and
which could be considered separate from that content. Such sections are often represented as
sidebars in printed typography.

The element can be used for typographical effects like pull quotes or sidebars, for
advertising, for groups of nav elements, and for other content that is considered
separate from the main content of the page.

It's not appropriate to use the aside element just for
parentheticals, since those are part of the main flow of the document.

The following example shows how an aside is used to mark up background material on Switzerland
in a much longer news story on Europe.

<aside>
<h1>Switzerland</h1>
<p>Switzerland, a land-locked country in the middle of geographic
Europe, has not joined the geopolitical European Union, though it is
a signatory to a number of European treaties.</p>
</aside>

The following example shows how an aside is used to mark up a pull quote in a longer
article.

...
<p>He later joined a large company, continuing on the same work.
<q>I love my job. People ask me what I do for fun when I'm not at
work. But I'm paid to do my hobby, so I never know what to
answer. Some people wonder what they would do if they didn't have to
work... but I know what I would do, because I was unemployed for a
year, and I filled that time doing exactly what I do now.</q></p>
<aside>
<q> People ask me what I do for fun when I'm not at work. But I'm
paid to do my hobby, so I never know what to answer. </q>
</aside>
<p>Of course his work — or should that be hobby? —
isn't his only passion. He also enjoys other pleasures.</p>
...

The following extract shows how aside can be used for blogrolls and other side
content on a blog:

These elements have a rank given by the number in their name. The h1
element is said to have the highest rank, the h6 element has the lowest rank, and two
elements with the same name have equal rank.

h1–h6 elements must not be used to markup subheadings, subtitles, alternative titles and taglines unless intended to be the heading for a new section or subsection. Instead use the markup patterns in the Common idioms without dedicated elements section of the specification.

As far as their respective document outlines (their heading and section structures) are
concerned, these two snippets are semantically equivalent:

A header element is intended to usually contain the section's heading
(an h1–h6 element), but this is
not required. The header element can also be used to wrap a section's table of
contents, a search form, or any relevant logos.

Here are some sample headers. This first one is for a game:

<header>
<p>Welcome to...</p>
<h1>Voidwars!</h1>
</header>

The following snippet shows how the element can be used to mark
up a specification's header:

In this example, the page has a page heading given by the h1 element, and two
subsections whose headings are given by h2 elements. The content after the
header element is still part of the last subsection started in the
header element, because the header element doesn't take part in the
outline algorithm.

<body>
<header>
<h1>Little Green Guys With Guns</h1>
<nav>
<ul>
<li><a href="/games">Games</a>
<li><a href="/forum">Forum</a>
<li><a href="/download">Download</a>
</ul>
</nav>
<h2>Important News</h2> <!-- this starts a second subsection -->
<!-- this is part of the subsection entitled "Important News" -->
<p>To play today's games you will need to update your client.</p>
<h2>Games</h2> <!-- this starts a third subsection -->
</header>
<p>You have three active games:</p>
<!-- this is still part of the subsection entitled "Games" -->
...

The footer element represents a footer
for its nearest ancestor sectioning content or
sectioning root element. A footer typically contains
information about its section such as who wrote it, links to related
documents, copyright data, and the like.

When the footer element contains entire sections,
they represent appendices, indexes,
long colophons, verbose license agreements, and other such
content.

Contact information for the author or editor of a
section belongs in an address element, possibly itself
inside a footer. Bylines and other information that
could be suitable for both a header or a
footer can be placed in either (or neither). The
primary purpose of these elements is merely to help the author write
self-explanatory markup that is easy to maintain and style; they are
not intended to impose specific structures on authors.

Footers don't necessarily have to appear at the end of a
section, though they usually do.

Some site designs have what is sometimes referred to as "fat
footers" — footers that contain a lot of material, including
images, links to other articles, links to pages for sending
feedback, special offers... in some ways, a whole "front page" in
the footer.

This fragment shows the bottom of a page on a site with a "fat
footer":

The address element must not be used to represent
arbitrary addresses (e.g. postal addresses), unless those addresses
are in fact the relevant contact information. (The p
element is the appropriate element for marking up postal addresses
in general.)

The address element must not contain information
other than contact information.

For example, the following is non-conforming use of the
address element:

<ADDRESS>Last Modified: 1999/12/24 23:37:50</ADDRESS>

Typically, the address element would be included
along with other information in a footer element.

The contact information for a node node is a
collection of address elements defined by the first
applicable entry from the following list:

4.3.10 Headings and sections

The first element of heading content in an element
of sectioning contentrepresents the
heading for that section. Subsequent headings of equal or higher
rank start new (implied) sections, headings of lower
rank start implied subsections that are part of the
previous one. In both cases, the element represents the
heading of the implied section.

h1–h6 elements must not be used to markup subheadings, subtitles, alternative titles and taglines unless intended to be the heading for a new section or subsection. Instead use the markup patterns in the Common idioms without dedicated elements section of the specification.

Certain elements are said to be sectioning roots, including blockquote and
td elements. These elements can have their own
outlines, but the sections and headings inside these elements do not
contribute to the outlines of their ancestors.

Notice how the section ends the earlier implicit
section so that a later paragraph ("Grunt") is back at the top
level.

Sections may contain headings of any rank, and
authors are strongly encouraged to use headings of the appropriate rank
for the section's nesting level.

Authors are also encouraged to explicitly wrap sections in
elements of sectioning content, instead of relying on
the implicit sections generated by having multiple headings in one
element of sectioning content.

This final example would need explicit style rules to be rendered well in legacy browsers.
Legacy browsers without CSS support would render all the headings as top-level headings.

4.3.10.1 Creating an outline

This section defines an algorithm for creating an outline for a sectioning content
element or a sectioning root element. It is defined in terms of a walk over the nodes
of a DOM tree, in tree order, with each node being visited when it is entered and when it
is exited during the walk.

The outline for a sectioning content element or a sectioning
root element consists of a list of one or more potentially nested sections. A section is a
container that corresponds to some nodes in the original DOM tree. Each section can have one
heading associated with it, and can contain any number of further nested sections. The algorithm for the outline also associates each node in the DOM tree with a
particular section and potentially a heading. (The sections in the outline aren't
section elements, though some may correspond to such elements — they are merely
conceptual sections.)