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.
The bulk of the text of this specification is also
available in the WHATWG Web Applications 1.0 specification, 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 Working Draft 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 latest stable version of the editor's draft of this
specification is always available on the W3C CVS server.
There are various ways to follow the change history for this specification:
The W3C HTML Working
Group is the W3C working group responsible for this
specification's progress along the W3C Recommendation
track.
This specification is the 25 October 2012 Working Draft.
Work on this specification is also done at the WHATWG. The W3C HTML working group
actively pursues convergence with the WHATWG, as required by the W3C HTML working
group charter. There are various ways to follow this work at the WHATWG:
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 Core and DOM
Events 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. For instance online purchasing
systems, searching systems, games (especially multiplayer online
games), public telephone books or address books, communications
software (e-mail clients, instant messaging clients, discussion
software), document editing software, etc.
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.
Since then, both groups have been working together.
The HTML
specification published by the WHATWG is not identical to
this specification. At the time of this publication, the main
differences were that the WHATWG version included features not
included in this W3C version: some features have been omitted, but
may be considered for future revisions of HTML beyond HTML5; and
other features were omitted because at the W3C they are published as
separate specifications. At time of publication of this document,
patches from the WHATWG spec have been merged until revision
7436 inclusive.
A separate document has been published by the W3C HTML working
group 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.
The navigator.yieldForStorageUpdates()
method, in this model, is equivalent to allowing other scripts to
run while the calling script is blocked.
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.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 of the HTML syntax, known as
"HTML5".
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 of the XHTML syntax, known as
"XHTML5".
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.
1.7 Structure of this specification
This section is non-normative.
This specification is divided into the following major
sections:
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.
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.
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
};
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.
Other code fragments are marked up like
this.
Variables are marked up like this.
This is an implementation requirement.
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 illstrations (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 minimise 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:
The exact list of which features a user agents supports.
The maximum allowed stack depth for recursion in script.
Features that describe the user's environment, like Media
Queries and the Screen object. [MQ][CSSOMVIEW]
The user's time zone.
1.9 A quick introduction to HTML
This section is non-normative.
A basic HTML document looks like this:
<!DOCTYPE html>
<html>
<head>
<title>Sample page</title>
</head>
<body>
<h1>Sample page</h1>
<p>This is a <a href="demo.html">simple</a> sample.</p>
<!-- this is a comment -->
</body>
</html>
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.
<!-- empty attributes -->
<input name=address disabled>
<input name=address disabled="">
<!-- attributes with a value -->
<input name=address maxlength=200>
<input name=address maxlength='200'>
<input name=address maxlength="200">
HTML user agents (e.g. Web browsers) then parse this
markup, turning it into a DOM (Document Object Model) tree. A DOM
tree is an in-memory representation of a document.
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.
<!DOCTYPE html>
<html>
<head>
<title>Sample styled page</title>
<style>
body { background: navy; color: yellow; }
</style>
</head>
<body>
<h1>Sample styled page</h1>
<p>This page is just a demo.</p>
</body>
</html>
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:
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:
<script>
var img = new Image();
img.src = 'games.png';
img.alt = 'Games';
img.onload = gamesLogoHasLoaded;
// img.addEventListener('load', gamesLogoHasLoaded, false); // would work also
</script>
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.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:
<p><i>He dreamt.
<p><i>He dreamt that he ate breakfast.
<p><i>Then lunch.
<p><i>And finally dinner.
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.
In this fragment, the attribute's value is "?bill&ted":
To avoid this problem, all named character references are
required to end with a semicolon, and uses of named character
references without a semicolon are flagged as errors.
Thus, the correct way to express the above cases is as
follows:
<a href="?bill&ted">Bill and Ted</a> <!-- &ted is ok, since it's not a named character reference -->
Errors involving known interoperability problems in legacy user agents
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.
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:
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 Recommended reading
This section is non-normative.
The following documents might be of interest to readers of this
specification.
Character Model for the World Wide Web 1.0: Fundamentals [CHARMOD]
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 [WCAG]
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.
User Agent Accessibility Guidelines (UAAG) 2.0 [UAAG]
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.
HTML to Platform Accessibility APIs Implementation Guide [HPAAIG]
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 Core specification,
and refer specifically to two different modes that
Document objects can find themselves in. [DOMCORE] (Such uses are always hyperlinked
to their definition.)
In the context of byte streams, the term HTML document refers to
resources labeled as text/html, and the term XML
document refers to resources labeled with an XML MIME
type.
The term XHTML document is used to refer to both
Documents in the XML
document mode that contains element nodes in the HTML
namespace, and byte streams labeled with an XML MIME
type that contain elements from the HTML
namespace, depending on context.
For simplicity, terms such as shown, displayed, and visible might
sometimes be used when referring to the way a document is rendered
to the user. These terms are not meant to imply a visual medium;
they must be considered to apply to other media in equivalent
ways.
When an algorithm B says to return to another algorithm A, it
implies that A called B. Upon returning to A, the implementation
must continue from where it left off in calling B.
The term "transparent black" refers to the color with red, green,
blue, and alpha channels all set to zero.
2.1.1 Resources
The specification uses the term supported
when referring to whether a user agent has an implementation capable
of decoding the semantics of an external resource. A format or type
is said to be supported if the implementation can process an
external resource of that format or type without critical aspects of
the resource being ignored. Whether a specific resource is
supported can depend on what features of the resource's
format are in use.
For example, a PNG image would be considered to
be in a supported format if its pixel data could be decoded and
rendered, even if, unbeknownst to the implementation, the image also
contained animation data.
An MPEG-4 video file would not be considered to
be in a supported format if the compression format used was not
supported, even if the implementation could determine the dimensions
of the movie from the file's metadata.
What some specifications, in particular the HTTP and URI
specifications, refer to as a representation is referred to
in this specification as a resource. [HTTP][RFC3986]
The term MIME type is used to refer to what is
sometimes called an Internet media type in protocol
literature. The term media type in this specification is used
to refer to the type of media intended for presentation, as used by
the CSS specifications. [RFC2046][MQ]
A string is a valid MIME type if it matches the media-type rule defined in section 3.7 "Media Types"
of RFC 2616. In particular, a valid MIME type may
include MIME type parameters. [HTTP]
A string is a valid MIME type with no parameters if it
matches the media-type rule defined in section
3.7 "Media Types" of RFC 2616, but does not contain any ";" (U+003B) characters. In other words, if it consists only of a
type and subtype, with no MIME Type parameters. [HTTP]
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.
When an element's root element is the root
element of a Document object, it is said to be
in a Document. An element is said to have
been inserted into a
document when its root element changes and is now
the document's root element. Analogously, an element is
said to have been removed from a document when its root
element changes from being the document's root
element to being another element.
The Document of a content attribute is the
Document of the attribute's element.
The term tree order means a pre-order, depth-first
traversal of DOM nodes involved (through the parentNode/childNodes relationship).
When it is stated that some element or attribute is ignored, or treated as some other value, or
handled as if it was something else, this refers only to the
processing of the node after it is in the DOM. 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 Core specification: firing an event means to
create and dispatch it, and dispatching an event means to follow the
steps that propagate the event through the tree. The term trusted event is used to refer
to events whose isTrusted
attribute is initialized to true. [DOMCORE]
2.1.5 Plugins
The term plugin refers to a user-agent defined set of
content handlers used by the user agent that can take part in the
user agent's rendering of a Document object, but that
neither act as child browsing
contexts of the Document nor introduce any
Node objects to the Document's DOM.
Typically such content handlers are provided by third parties,
though a user agent can also designate built-in content handlers as
plugins.
A user agent must not consider the types text/plain
and application/octet-stream as having a registered
plugin.
One example of a plugin would be a PDF viewer
that is instantiated in a browsing context when the
user navigates to a PDF file. This would count as a plugin
regardless of whether the party that implemented the PDF viewer
component was the same as that which implemented the user agent
itself. However, a PDF viewer application that launches separate
from the user agent (as opposed to using the same interface) is not
a plugin by this definition.
This specification does not define a mechanism for
interacting with plugins, as it is expected to be user-agent- and
platform-specific. Some UAs might opt to support a plugin mechanism
such as the Netscape Plugin API; others might use remote content
converters or have built-in support for certain types. Indeed, this
specification doesn't require user agents to support plugins at all.
[NPAPI]
A plugin can be secured
if it honors the semantics of the sandbox attribute.
For example, a secured plugin would prevent its
contents from creating pop-up windows when the plugin is
instantiated inside a sandboxed iframe.
Browsers should take extreme care when
interacting with external content intended for plugins. When third-party software is run with
the same privileges as the user agent itself, vulnerabilities in the
third-party software become as dangerous as those in the user
agent.
2.1.6 Character encodings
The preferred MIME name of a character encoding is the
name or alias labeled as "preferred MIME name" in the IANA
Character Sets registry, if there is one, or the
encoding's name, if none of the aliases are so labeled. [IANACHARSET]
An ASCII-compatible character encoding is a
single-byte or variable-length encoding in which the bytes 0x09,
0x0A, 0x0C, 0x0D, 0x20 - 0x22, 0x26, 0x27, 0x2C - 0x3F, 0x41 - 0x5A,
and 0x61 - 0x7A, ignoring bytes that
are the second and later bytes of multibyte sequences, all
correspond to single-byte sequences that map to the same Unicode
characters as those bytes in ANSI_X3.4-1968 (US-ASCII). [RFC1345]
This includes such encodings as Shift_JIS,
HZ-GB-2312, and variants of ISO-2022, even though it is possible in
these encodings for bytes like 0x70 to be part of longer sequences
that are unrelated to their interpretation as ASCII. It excludes
such encodings as UTF-7, UTF-16, GSM03.38, and EBCDIC variants.
The term a UTF-16 encoding refers to any variant of
UTF-16: self-describing UTF-16 with a BOM, ambiguous UTF-16 without
a BOM, raw UTF-16LE, and raw UTF-16BE. [RFC2781]
The term code unit is used as defined in the Web IDL
specification: a 16 bit unsigned integer, the smallest atomic
component of a DOMString. (This is a narrower
definition than the one used in Unicode.) [WEBIDL]
The term Unicode code point means a Unicode scalar value where possible, and an isolated
surrogate code point when not. When a conformance requirement is
defined in terms of characters or Unicode code points, a pair of
code units consisting of a high
surrogate followed by a low surrogate must be treated as the single
code point represented by the surrogate pair, but isolated
surrogates must each be treated as the single code point with the
value of the surrogate. [UNICODE]
In this specification, the term character, when not
qualified as Unicode character, is synonymous with the term
Unicode code point.
The term Unicode character is used to mean a Unicode scalar value (i.e. any Unicode code point that
is not a surrogate code point). [UNICODE]
The code-unit length of a string is the number of
code units in that string.
This complexity results from the historical decision
to define the DOM API in terms of 16 bit (UTF-16) code units, rather than in terms of Unicode characters.
2.2 Conformance requirements
All diagrams, examples, and notes in this specification are
non-normative, as are all sections explicitly marked non-normative.
Everything else in this specification is normative.
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in the normative parts of this document are to be
interpreted as described in RFC2119. The key word "OPTIONALLY" in
the normative parts of this document is to be interpreted with the
same normative meaning as "MAY" and "OPTIONAL". For readability,
these words do not appear in all uppercase letters in this
specification. [RFC2119]
Requirements phrased in the imperative as part of algorithms
(such as "strip any leading space characters" or "return false and
abort these steps") are to be interpreted with the meaning of the
key word ("must", "should", "may", etc) used in introducing the
algorithm.
For example, were the spec to say:
To eat a kiwi, the user must:
1. Peel the kiwi.
2. Eat the kiwi flesh.
...it would be equivalent to the following:
To eat a kiwi:
1. The user must peel the kiwi.
2. The user must eat the kiwi flesh.
Here the key word is "must".
The former (imperative) style is generally preferred in this
specification for stylistic reasons.
Conformance requirements phrased as algorithms or specific steps
may be implemented in any manner, so long as the end result is
equivalent. (In particular, the algorithms defined in this
specification are intended to be easy to follow, and not intended to
be performant.)
2.2.1 Conformance classes
This specification describes the conformance criteria for user agents (relevant to implementors) and
documents (relevant to authors and authoring tool
implementors).
Conforming HTML5 documents
are those that comply with all the conformance criteria for documents.
For readability, some of these conformance requirements are phrased as
conformance requirements on authors; such requirements are implicitly
requirements on documents: by definition, all documents are assumed to
have had an author. (In some cases, that author may itself be a user
agent — such user agents are subject to additional rules, as
explained below.)
For example, if a requirement states that
"authors must not use the foobar element", it
would imply that documents are not allowed to contain elements named
foobar.
There is no implied relationship between
document conformance requirements and implementation conformance
requirements. User agents are not free to handle non-conformant
documents as they please; the processing model described in this
specification applies to implementations regardless of the
conformity of the input documents.
User agents fall into several (overlapping) categories with
different conformance requirements.
Web browsers and other interactive user agents
Web browsers that support the XHTML syntax must
process elements and attributes from the HTML
namespace found in XML documents as described in this
specification, so that users can interact with them, unless the
semantics of those elements have been overridden by other
specifications.
A conforming XHTML processor would, upon
finding an XHTML script element in an XML document,
execute the script contained in that element. However, if the
element is found within a transformation expressed in XSLT
(assuming the user agent also supports XSLT), then the processor
would instead treat the script element as an opaque
element that forms part of the transform.
Web browsers that support the HTML syntax must
process documents labeled with an HTML MIME type as
described in this specification, so that users can interact with
them.
User agents that support scripting must also be conforming
implementations of the IDL fragments in this specification, as
described in the Web IDL specification. [WEBIDL]
Unless explicitly stated, specifications that
override the semantics of HTML elements do not override the
requirements on DOM objects representing those elements. For
example, the script element in the example above
would still implement the HTMLScriptElement
interface.
Non-interactive presentation user agents
User agents that process HTML and XHTML documents purely to
render non-interactive versions of them must comply to the same
conformance criteria as Web browsers, except that they are exempt
from requirements regarding user interaction.
Typical examples of non-interactive presentation
user agents are printers (static UAs) and overhead displays
(dynamic UAs). It is expected that most static non-interactive
presentation user agents will also opt to lack scripting support.
A non-interactive but dynamic presentation UA
would still execute scripts, allowing forms to be dynamically
submitted, and so forth. However, since the concept of "focus" is
irrelevant when the user cannot interact with the document, the UA
would not need to support any of the focus-related DOM APIs.
Visual user agents that support the suggested default rendering
User agents, whether interactive or not, may be designated
(possibly as a user option) as supporting the suggested default
rendering defined by this specification.
This is not required. In particular, even user agents that do
implement the suggested default rendering are encouraged to offer
settings that override this default to improve the experience for
the user, e.g. changing the color contrast, using different focus
styles, or otherwise making the experience more accessible and
usable to the user.
User agents that are designated as supporting the suggested
default rendering must, while so designated, implement the rules
in the rendering section that that
section defines as the behavior that user agents are
expected to implement.
User agents with no scripting support
Implementations that do not support scripting (or which have
their scripting features disabled entirely) are exempt from
supporting the events and DOM interfaces mentioned in this
specification. For the parts of this specification that are
defined in terms of an events model or in terms of the DOM, such
user agents must still act as if events and the DOM were
supported.
Scripting can form an integral part of an
application. Web browsers that do not support scripting, or that
have scripting disabled, might be unable to fully convey the
author's intent.
Conformance checkers
Conformance checkers must verify that a document conforms to
the applicable conformance criteria described in this
specification. Automated conformance checkers are exempt from
detecting errors that require interpretation of the author's
intent (for example, while a document is non-conforming if the
content of a blockquote element is not a quote,
conformance checkers running without the input of human judgement
do not have to check that blockquote elements only
contain quoted material).
Conformance checkers must check that the input document
conforms when parsed without a browsing context
(meaning that no scripts are run, and that the parser's
scripting flag is disabled), and should also check
that the input document conforms when parsed with a browsing
context in which scripts execute, and that the scripts
never cause non-conforming states to occur other than transiently
during script execution itself. (This is only a "SHOULD" and not a
"MUST" requirement because it has been proven to be impossible. [COMPUTABLE])
The term "HTML5 validator" can be used to refer to a
conformance checker that itself conforms to the applicable
requirements of this specification.
XML DTDs cannot express all the conformance requirements of
this specification. Therefore, a validating XML processor and a
DTD cannot constitute a conformance checker. Also, since neither
of the two authoring formats defined in this specification are
applications of SGML, a validating SGML system cannot constitute
a conformance checker either.
To put it another way, there are three types of conformance
criteria:
Criteria that can be expressed in a DTD.
Criteria that cannot be expressed by a DTD, but can still be
checked by a machine.
Criteria that can only be checked by a human.
A conformance checker must check for the first two. A simple
DTD-based validator only checks for the first class of errors and
is therefore not a conforming conformance checker according to
this specification.
Data mining tools
Applications and tools that process HTML and XHTML documents
for reasons other than to either render the documents or check
them for conformance should act in accordance with the semantics
of the documents that they process.
A tool that generates document outlines but increases the nesting
level for each paragraph and does not increase the nesting level
for each section would not be conforming.
Authoring tools and markup generators
Authoring tools and markup generators must generate
conforming
HTML5
documents. Conformance criteria that apply to authors also
apply to authoring tools, where appropriate.
Authoring tools are exempt from the strict requirements of
using elements only for their specified purpose, but only to the
extent that authoring tools are not yet able to determine author
intent. However, authoring tools must not automatically misuse
elements or encourage their users to do so.
For example, it is not conforming to use an
address element for arbitrary contact information;
that element can only be used for marking up contact information
for the author of the document or section. However, since an
authoring tool is likely unable to determine the difference, an
authoring tool is exempt from that requirement. This does not
mean, though, that authoring tools can use address
elements for any block of italics text (for instance); it just
means that the authoring tool doesn't have to verify that when the
user uses a tool for inserting contact information for a section,
that the user really is doing that and not inserting something
else instead.
In terms of conformance checking, an editor has to
output documents that conform to the same extent that a
conformance checker will verify.
When an authoring tool is used to edit a non-conforming
document, it may preserve the conformance errors in sections of
the document that were not edited during the editing session
(i.e. an editing tool is allowed to round-trip erroneous
content). However, an authoring tool must not claim that the
output is conformant if errors have been so preserved.
Authoring tools are expected to come in two broad varieties:
tools that work from structure or semantic data, and tools that
work on a What-You-See-Is-What-You-Get media-specific editing
basis (WYSIWYG).
The former is the preferred mechanism for tools that author
HTML, since the structure in the source information can be used to
make informed choices regarding which HTML elements and attributes
are most appropriate.
However, WYSIWYG tools are legitimate. WYSIWYG tools should use
elements they know are appropriate, and should not use elements
that they do not know to be appropriate. This might in certain
extreme cases mean limiting the use of flow elements to just a few
elements, like div, 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.
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]
DOM
The Document Object Model (DOM) is a representation — a
model — of a document and its content. The DOM is not just
an API; the conformance criteria of HTML implementations are
defined, in this specification, in terms of operations on the DOM.
[DOMCORE]
Implementations must support DOM Core and the events defined in
DOM Events, because this specification is defined in terms of the
DOM, and some of the features are defined as extensions to the DOM
Core interfaces. [DOMCORE][DOMEVENTS]
In particular, the following features are defined in the DOM
Core specification: [DOMCORE]
Attr interface
Comment interface
DOMImplementation interface
Document interface
DocumentFragment interface
DocumentType interface
DOMException interface
Element interface
Node interface
NodeList interface
ProcessingInstruction interface
Text interface
HTMLCollection interface, and the terms collections and represented by the collection
DOMTokenList interface
DOMSettableTokenList interface
createDocument() method
createHTMLDocument() method
createElement() method
createElementNS() method
getElementById() method
insertBefore() method
ownerDocument attribute
childNodes attribute
localName attribute
parentNode attribute
namespaceURI attribute
tagName attribute
id attribute
textContent attribute
The insert, append, and replace algorithms for nodes
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
The term throw in this specification is used as
defined in the DOM Core specification. The following
DOMException types are defined in the DOM Core
specification: [DOMCORE]
IndexSizeError
HierarchyRequestError
WrongDocumentError
InvalidCharacterError
NoModificationAllowedError
NotFoundError
NotSupportedError
InvalidStateError
SyntaxError
InvalidModificationError
NamespaceError
InvalidAccessError
TypeMismatchError
SecurityError
NetworkError
AbortError
URLMismatchError
QuotaExceededError
TimeoutError
InvalidNodeTypeError
DataCloneError
For example, to throw a
TimeoutError exception, a user agent would
construct a DOMException object whose type was the
string "TimeoutError" (and whose code was
the number 23, for legacy reasons) and actually throw that object
as an exception.
The URL associated
with a Document, as defined in the DOM Core
specification, is referred to in this specification as the
document's address.
The following features are defined in the DOM Events
specification: [DOMEVENTS]
MouseEvent interface
The MouseEvent interface's screenX attribute
The MouseEvent interface's screenY attribute
The MouseEvent interface's clientX attribute
The MouseEvent interface's clientY attribute
The MouseEvent interface's ctrlKey attribute
The MouseEvent interface's shiftKey attribute
The MouseEvent interface's altKey attribute
The MouseEvent interface's metaKey attribute
The MouseEvent interface's button attribute
The MouseEvent interface's buttons attribute
The MouseEvent interface's relatedTarget attribute
The UIEvent interface's view attribute
The UIEvent interface's detail attribute
click event
This specification sometimes uses the term name to refer to the event's type; as in, "an event named click" or "if the event name is keypress". The terms "name" and "type" for events
are synonymous.
The following features are defined in the DOM Parsing and
Serialization specification: [DOMPARSING]
innerHTML
outerHTML
insertAdjacentHTML
User agents are also encouraged to implement the
features described in the HTML Editing APIs and
UndoManager and DOM Transaction
specifications.
[EDITING][UNDO]
File API
This specification uses the following interfaces defined in the
File API specification: [FILEAPI]
Blob
File
FileList
It also uses the following interface defined in the File System
API specification: [FILESYSTEMAPI]
FileCallback
XMLHttpRequest
This specification references the XMLHttpRequest specification
to define how the two specifications interact. The terms
document response entity body,
XMLHttpRequest base URL,
XMLHttpRequest origin, and
XMLHttpRequest referrer source are defined
in that specification. [XHR]
Web IDL
The terms expose, supported property
indices, determine the value of an indexed
property, support named properties,
supported property names, determine the value of a
named property, platform array objects, and read only (when applied to
arrays) are used as defined in the Web IDL specification. The
algorithm to convert a DOMString to a sequence of Unicode
characters is similarly that defined in the Web IDL
specification.
When this specification requires a user agent to create a
Date object representing a particular time
(which could be the special value Not-a-Number), the milliseconds
component of that time, if any, must be truncated to an integer
and the time value of the newly created Date object
must represent the time after that truncation.
For instance, given the time 23045 millionths
of a second after 01:00 UTC on January 1st 2000, i.e. the time
2000-01-01T00:00:00.023045Z, then the Date object
created representing that time would represent the same time as
that created representing the time 2000-01-01T00:00:00.023Z, 45
millionths earlier. If the given time is NaN, then the result is a
Date object that represents a time value NaN
(indicating that the object does not represent a specific instant
of time).
Typed Arrays
The ArrayBuffer interface and underlying concepts
from the Typed Array Specification are used for several features
in this specification. The Uint8ClampedArray interface
type is specifically used in the definition of the
canvas element's 2D API. [TYPEDARRAY]
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.
Media Queries
Implementations must support the Media Queries language. [MQ]
WebVTT
Implementations may support WebVTT as a text track
format for subtitles, captions, chapter titles, metadata, etc, for
media resources. [WEBVTT]
The following terms, used in this specification, are defined in
the WebVTT specification:
WebVTT file
WebVTT file using cue text
WebVTT file using chapter title text
WebVTT file using only nested cues
WebVTT parser
WebVTT cue settings and how to parse the WebVTT settings
The rules for updating the display of WebVTT text tracks
The WebVTT cue text DOM construction rules
The WebVTT cue text rendering rules
The WebVTT cue text parsing rules
URIs, IRIs, IDNA
Implementations must support the semantics of URLs defined in the URI and IRI specifications,
as well as the semantics of IDNA domain names defined in the
Internationalizing Domain Names in Applications
(IDNA) specification. [RFC3986][RFC3987][RFC3490]
Cookies
The following terms are defined in the Cookie specification: [COOKIES]
cookie-string
receives a set-cookie-string
CORS
The following terms are defined in the CORS specification: [CORS]
cross-origin request
cross-origin request status
custom request headers
simple cross-origin request
redirect steps
omit credentials flag
resource sharing check
CSS modules
While support for CSS as a whole is not required of
implementations of this specification (though it is encouraged, at
least for Web browsers), some features are defined in terms of
specific CSS requirements.
In particular, some features require that a string be
parsed as a CSS <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 provides a paint source is used
as defined in the CSS Image Values and Replaced
Content specification to define the interaction of certain
HTML elements with the CSS 'element()' function. [CSSIMAGES]
Support for the CSS Object Model is required for
implementations that support scripting. The following features and
terms are defined in the CSSOM specifications: [CSSOM][CSSOMVIEW]
LinkStyle
CSSStyleDeclaration
StyleSheet
sheet
disabled
Alternative style sheet sets and the preferred style sheet set
Serializing a CSS value
Scroll an element into view
Parts of the Fullscreen specification, in particular the
top layer concept, are used to define the rendering of
the dialog element. [FULLSCREEN]
SVG
The following interface is defined in the SVG specification: [SVG]
SVGMatrix
This specification does not require support of any
particular network protocol, style sheet language, scripting
language, or any of the DOM specifications beyond those described
above. However, the language described by this specification is
biased towards CSS as the styling language, JavaScript as the
scripting language, and HTTP as the network protocol, and several
features assume that those languages and protocols are in use.
A user agent that implements the HTTP protocol must implement the Web Origin Concept
specification and the HTTP State Management Mechanism specification (Cookies) as well. [HTTP][ORIGIN][COOKIES]
This specification might have certain additional
requirements on character encodings, image formats, audio formats,
and video formats in the respective sections.
2.2.3 Extensibility
HTML has a wide number of extensibility mechanisms that can be
used for adding semantics in a safe manner:
Authors can use the class
attribute to extend elements, effectively creating their own
elements, while using the most applicable existing "real" HTML
element, so that browsers and other tools that don't know of the
extension can still support it somewhat well. This is the tack used
by microformats, for example.
Authors can include data for inline client-side scripts or
server-side site-wide scripts to process using the data-*="" attributes. These are
guaranteed to never be touched by browsers, and allow scripts to
include data on HTML elements that scripts can then look for and
process.
Authors can use the 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.
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:
<p>This smells of lemons!
<span x-ferret-smellovision x-ferret-smellcode="LEM01"
x-mb-outputsmell x-mb-smell="lemon juice"></span></p>
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.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. [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 UTF-8
When a user agent is required to decode a byte string as UTF-8, with error
handling, it means that the byte stream must be converted to a
Unicode string by interpreting it as UTF-8, except that any errors
must be handled as described in the following list. Bytes in the
following list are represented in hexadecimal. [RFC3629]
One byte in the range C0 to C1, followed by one byte in the range 80 to BF
One byte in the range F0 to F4, followed by three bytes in the range 80 to BF that represent a code point above U+10FFFF
One byte in the range F5 to F7, followed by three bytes in the range 80 to BF
One byte in the range F8 to FB, followed by four bytes in the range 80 to BF
One byte in the range FC to FD, followed by five bytes in the range 80 to BF
One byte in the range C0 to FD that is not followed by a byte in the range 80 to BF
One byte in the range E0 to FD, followed by a byte in the range 80 to BF that is not followed by a byte in the range 80 to BF
One byte in the range F0 to FD, followed by two bytes in the range 80 to BF, the last of which is not followed by a byte in the range 80 to BF
One byte in the range F8 to FD, followed by three bytes in the range 80 to BF, the last of which is not followed by a byte in the range 80 to BF
One byte in the range FC to FD, followed by four bytes in the range 80 to BF, the last of which is not followed by a byte in the range 80 to BF
Any byte sequence that represents a code point in the range U+D800 to U+DFFF
The whole matched sequence must be replaced by a single U+FFFD
REPLACEMENT CHARACTER.
One byte in the range 80 to BF not preceded by a byte in the range 80 to FD
One byte in the range 80 to BF preceded by a byte that is part of a complete UTF-8 sequence that does not include this byte
One byte in the range 80 to BF preceded by a byte that is part of a sequence that has been replaced by a U+FFFD REPLACEMENT CHARACTER, either alone or as part of a sequence
Each such byte must be replaced with a U+FFFD REPLACEMENT CHARACTER.
For the purposes of the above requirements, an overlong
form in UTF-8 is a sequence that encodes a code point using
more bytes than the minimum needed to encode that code point in
UTF-8.
For example, the byte string "41 98 BA 42 E2 98
43 E2 98 BA E2 98" would be converted to the string
"A��B�C☺�".
2.5 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.5.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 ASCII digits are those in the range ASCII digits.
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.
When a user agent is to strip line breaks from a
string, the user agent must remove any "LF" (U+000A) and
"CR" (U+000D) characters from that string.
When a user agent is to strip leading and trailing
whitespace from a string, the user agent must remove all space characters that are at the
start or end of the string.
When a user agent has to strictly split a string on a
particular delimiter character delimiter, 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.
Add the string collected in the previous step to tokens.
Advance position to the next character
in input.
Return tokens.
For the special cases of splitting a string on spaces and on commas, this algorithm
does not apply (those algorithms also perform whitespace trimming).
2.5.2 Boolean attributes
A number of attributes are boolean
attributes. The presence of a boolean attribute on an element
represents the true value, and the absence of the attribute
represents the false value.
If the attribute is present, its value must either be the empty
string or a value that is an ASCII case-insensitive
match for the attribute's canonical name, with no leading or
trailing whitespace.
The values "true" and "false" are not allowed on
boolean attributes. To represent a false value, the attribute has to
be omitted altogether.
Here is an example of a checkbox that is checked and disabled.
The checked and disabled attributes are the
boolean 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.5.4 Numbers
2.5.4.1 Signed integers
A string is a valid integer if it consists of one or
more characters in the range ASCII digits, optionally prefixed with a U+002D HYPHEN-MINUS 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.
If sign is "positive", return value, otherwise return the result of subtracting
value from zero.
2.5.4.2 Non-negative integers
A string is a valid non-negative integer if it
consists of one or more characters in the range ASCII digits.
A valid non-negative integer represents the number
that is represented in base ten by that string of digits.
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 string is a valid floating-point number if it
consists of:
Optionally, a "-" (U+002D) character.
One or both of the following, in the given order:
A series of one or more characters in the range ASCII digits.
A single "." (U+002E) character.
A series of one or more characters in the range ASCII digits.
Optionally:
Either a "e" (U+0065) character or a
"E" (U+0045) character.
Optionally, a "-" (U+002D) character or "+" (U+002B) character.
A series of one or more characters in the range ASCII digits.
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 position is past the end of input, return an error.
If the character indicated by position is a
"-" (U+002D) 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 one of ASCII digits, then set value to zero and jump to the step labeled
fraction.
If the character indicated by position
is not one of ASCII digits, then
return an error.
If position is past the end of input, jump to the step labeled
conversion.
Fraction: If the character indicated by position is a "." (U+002E), run these
substeps:
Advance position to the next
character.
If position is past the end of input, or if the character indicated by position is not one of ASCII digits, "e" (U+0065), or "E" (U+0045), then jump to the step labeled
conversion.
If the character indicated by position
is a "e" (U+0065) character or a "E" (U+0045) character, skip the remainder of these
substeps.
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 jump to the step labeled
conversion.
If the character indicated by position
is one of ASCII digits, jump
back to the step labeled fraction loop in these
substeps.
If the character indicated by position
is a "e" (U+0065) character or a "E" (U+0045) character, run these substeps:
Advance position to the next
character.
If position is past the end of input, then jump to the step labeled
conversion.
If the character indicated by position is
a "-" (U+002D) character:
Change exponent to −1.
Advance position to the next
character.
If position is past the end of input, then jump to the step labeled
conversion.
Otherwise, if the character indicated by position is a "+" (U+002B) character:
Advance position to the next
character.
If position is past the end of input, then jump to the step labeled
conversion.
If the character indicated by position
is not one of ASCII digits,
then jump to the step labeled conversion.
Multiply value by ten raised to the
exponentth power.
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.5.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 position is past the end of input, return value as a
length.
If the character indicated by position is a
"." (U+002E) character:
Advance position to the next
character.
If position is past the end of input, or if the character indicated by position is not one of ASCII digits, 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 one of ASCII digits, 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.5.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 finished is true, skip to the next
step in the overall set of steps.
Multiply value by ten.
Add the value of the digit, interpreted in base ten, to
value.
Let started be true.
Let got number be true.
A U+0020 SPACE character
A U+002C COMMA character
A U+003B SEMICOLON character
Follow these substeps:
If got number is false, return the numbers list and abort. This happens if an entry
in the list has no digits, as in "1,2,x,4".
If negated is true, then negate value.
Append value to the numbers list.
Jump to step 4 in the overall set of steps.
A character in the range U+0001 to U+001F, U+0021 to U+002B, U+002D to U+002F, U+003A, U+003C to U+0040, U+005B to U+0060, U+007b to U+007F
(i.e. any other non-alphabetic ASCII 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.
Let negated be false.
Any other character
Follow these substeps:
If finished is true, skip to the next
step in the overall set of steps.
Let negated be false.
Let bogus be true.
If started is true, then return the
numbers list, and abort. (The value in value is not appended to the list first; it is
dropped.)
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 a character (and
not to beyond the end of input), jump to the
big Parser step above.
If negated is true, then negate value.
If got number is true, then append value to the numbers list.
Return the numbers list and
abort.
2.5.4.6 Lists of dimensions
The rules for parsing a list of dimensions are as
follows. These rules return a list of zero or more pairs consisting
of a number and a unit, the unit being one of percentage,
relative, and absolute.
Let raw input be the string being
parsed.
If the last character in raw input is a
"," (U+002C) character, then remove that character from raw input.
For each token in raw tokens, run the
following substeps:
Let input be the token.
Let position be a pointer into input, initially pointing at the start of the
string.
Let value be the number 0.
Let unit be absolute.
If position is past the end of input, set unit to
relative and jump to the last substep.
If the character at position is a
character in the range ASCII digits, collect a sequence of characters in the range
ASCII digits, interpret the
resulting sequence as an integer in base ten, and increment value by that integer.
If the character at position is a "." (U+002E) character, run these substeps:
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) 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.5.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]
The digits in the date
and time syntaxes defined in this section must be characters in the
range ASCII digits, used to
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]
2.5.5.1 Months
A month consists of a specific
proleptic Gregorian date with no time-zone information and no date
information beyond a year and a month. [GREGORIAN]
A string is a valid month string representing a year
year and month month if it
consists of the following components in the given order:
Four or more digits, representing year, where year > 0
A "-" (U+002D) character
Two digits,
representing the month month, in the range
1 ≤ month ≤ 12
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.
If position is not beyond the
end of input, then fail.
Return year and month.
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 in the range
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 in the range
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.
Return year and month.
2.5.5.2 Dates
A date consists of a specific
proleptic Gregorian date with no time-zone information, consisting
of a year, a month, and a day. [GREGORIAN]
A string is a valid date string representing a year
year, month month, and day
day if it consists of the following components
in the given order:
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.
Parse a date component to obtain year, month, and day. If this returns nothing, then fail.
If position is not beyond the
end of input, then fail.
Let date be the date with year year, month month, and day day.
Return date.
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 in the range
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.5.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:
Optionally, two "-" (U+002D) characters
Two digits,
representing the month month, in the range
1 ≤ month ≤ 12
A "-" (U+002D) character
Two 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.
If position is not beyond the
end of input, then fail.
Return month and day.
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
"-" (U+002D) characters. If the collected sequence is
not exactly zero or two characters long, then fail.
Collect a sequence of characters in the range
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 in the range
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.5.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 digits,
representing hour, in the range
0 ≤ hour ≤ 23
A ":" (U+003A) character
Two digits,
representing minute, in the range
0 ≤ minute ≤ 59
Optionally (required if second is
non-zero):
A ":" (U+003A) character
Two 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 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.
Parse a time component to obtain hour, minute, and second. If this returns nothing, then fail.
If position is not beyond the
end of input, then fail.
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 in the range
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 in the range
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 two characters both in the range
ASCII digits, then
fail.
Collect a sequence of characters that are
either characters in the range 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.5.5.5 Local dates and times
A local 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 local 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 local 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.
Parse a date component to obtain year, month, and day. If this returns nothing, then fail.
If position is beyond the end of input or if the character at position is neither a "T" (U+0054) character nor a U+0020 SPACE character, then fail. Otherwise,
move position forwards one character.
Parse a time component to obtain hour, minute, and second. If this returns nothing, then fail.
If position is not beyond the
end of input, then fail.
Let date be the date with year year, month month, and day day.
Let time be the time with hour hour, minute minute, and second
second.
Return date and time.
2.5.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 HYPHEN-MINUS character
(-), representing the sign of the time-zone offset
Two digits,
representing the hours component hour of
the time-zone offset, in the range 0 ≤ hour ≤ 23
Optionally, a ":" (U+003A) character
Two 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.
If position is not beyond the
end of input, then fail.
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 "Z" (U+005A) character, 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".
If s is exactly two characters long, then
run these substeps:
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 in the range
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.5.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 date string representing the date converted to the UTC time zone
A "T" (U+0054) character
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.
Parse a date component to obtain year, month, and day. If this returns nothing, then fail.
If position is beyond the end of input or if the character at position is neither a "T" (U+0054) character nor a U+0020 SPACE character, then fail. Otherwise,
move position forwards one character.
Parse a time component to obtain hour, minute, and second. If this returns nothing, then fail.
If position is beyond the end of input, then fail.
If position is not beyond the
end of input, then fail.
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.5.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:
Four or more digits, representing year, where year > 0
A "-" (U+002D) character
A "W" (U+0057) character
Two digits,
representing the week week, in the range
1 ≤ week ≤ maxweek, where maxweek is the
week number of the last day of week-year year
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 in the range
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 in the range
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.
If week is not a number in the range
1 ≤ week ≤ maxweek, then fail.
If position is not beyond the
end of input, then fail.
Return the week-year number year and the
week number week.
2.5.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 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 digits followed by a
U+0048 LATIN CAPITAL LETTER H character, representing a number
of hours.
One or more digits followed by a
U+004D LATIN CAPITAL LETTER M character, representing a number
of minutes.
The following components:
One or more digits, representing a
number of seconds.
Optionally, a "." (U+002E) character followed
by one, two, or three digits, representing a
fraction of a second.
A U+0053 LATIN CAPITAL LETTER S character.
This, as with a number of other date- and
time-related microsyntaxes defined in this specification, is based
on one of the formats defined in ISO 8601. [ISO8601]
One or more digits, representing a
number of time units, scaled by the duration time component
scale specified (see below) to represent a number of
seconds.
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 digits, representing a
fraction of a second.
One of the following characters, representing the
duration time component scale of the time unit used
in the numeric part of the duration time
component:
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 the first step in
the loop requires that the loop be broken, or until a step
requiring the 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.)
Otherwise next character is not part of a
number; fail.
If position is past the end of input, then fail.
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:
Set next character to the character
in input pointed to by position, and advance position to the next character.
If next character is neither a
U+0053 LATIN CAPITAL LETTER S character nor a U+0073 LATIN
SMALL LETTER S character, then fail.
Set units to seconds.
Otherwise, run these substeps:
If next character is a space
character, then skip whitespace, set next character to the character in input pointed to by position, and advance position to the next character.
If next character is a U+0059 LATIN
CAPITAL LETTER Y character, or a U+0079 LATIN SMALL LETTER Y
character, set units to years and
set M-disambiguator to
months.
If next character is a U+004D LATIN
CAPITAL LETTER M character or a U+006D LATIN SMALL LETTER M
character, and M-disambiguator is
months, then set units to
months.
If next character is a U+0057 LATIN
CAPITAL LETTER W character or a U+0077 LATIN SMALL LETTER W
character, set units to weeks and
set M-disambiguator to
minutes.
If next character is a U+0044 LATIN
CAPITAL LETTER D character or a U+0064 LATIN SMALL LETTER D
character, set units to days and
set M-disambiguator to
minutes.
If next character is a U+0048 LATIN
CAPITAL LETTER H character or a U+0068 LATIN SMALL LETTER H
character, set units to hours and
set M-disambiguator to
minutes.
If next character is a U+004D LATIN
CAPITAL LETTER M character or a U+006D LATIN SMALL LETTER M
character, and M-disambiguator is
minutes, then set units to
minutes.
If next character is a U+0053 LATIN
CAPITAL LETTER S character or a U+0073 LATIN SMALL LETTER S
character, set units to seconds and
set M-disambiguator to
minutes.
Otherwise if next character is none of
the above characters, then fail.
Increment component count.
Let multiplier be 1.
If units is years, multiply
multiplier by 12 and set units to months.
If units is months, add the
product of N and multiplier to months.
Otherwise, run these substeps:
If units is weeks, multiply
multiplier by 7 and set units to days.
If units is days, multiply
multiplier by 24 and set units to hours.
If units is hours, multiply
multiplier by 60 and set units to minutes.
If units is minutes, multiply
multiplier by 60 and set units to seconds.
Forcibly, units is now
seconds. Add the product of N and
multiplier to seconds.
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.5.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 in the
range ASCII digits, U+0041 LATIN
CAPITAL LETTER A to U+0046 LATIN CAPITAL LETTER F, U+0061 LATIN
SMALL LETTER A to U+0066 LATIN SMALL LETTER F, 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) character, then return an error.
If the last six characters of input are
not all in the range ASCII digits, U+0041 LATIN CAPITAL LETTER A to U+0046 LATIN CAPITAL LETTER
F, U+0061 LATIN SMALL LETTER A to U+0066 LATIN SMALL LETTER F, 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 the digits ASCII digits and U+0061 LATIN SMALL LETTER A
to U+0066 LATIN SMALL LETTER F, 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.
Let input be the string being
parsed.
If input is the empty string, then
return an error.
If input is four characters long, and the
first character in input is a "#" (U+0023) character, and the last three characters of input are all in the range 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, then run these substeps:
Interpret the second character of input as a hexadecimal digit; let the red
component of result be the resulting number
multiplied by 17.
Interpret the third character of input
as a hexadecimal digit; let the green component of result be the resulting number multiplied by
17.
Interpret the fourth character of input as a hexadecimal digit; let the blue
component of result be the resulting number
multiplied by 17.
Return result.
Replace any characters in input that
have a Unicode code point greater than U+FFFF (i.e. any characters
that are not in the basic multilingual plane) with the
two-character string "00".
If input is longer than 128 characters,
truncate input, leaving only the first 128
characters.
If the first character in input is a
"#" (U+0023) character, remove it.
Replace any character in input that is
not in the range 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 with the
character "0" (U+0030).
While input's length is zero or not a
multiple of three, append a "0" (U+0030) character to input.
Split input into three strings of equal
length, to obtain three components. Let length
be the length of those components (one third the length of input).
If length is greater than 8, then remove
the leading length-8
characters in each component, and let length be
8.
While length is greater than two and the
first character in each component is a "0" (U+0030)
character, remove that character and reduce length by one.
If length is still greater than
two, truncate each component, leaving only the first two
characters in each.
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.5.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 unordered set of unique space-separated tokens is a
set of space-separated tokens where none of the tokens
are duplicated.
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.
How tokens in a set of space-separated
tokens are to be compared (e.g. case-sensitively or not) is
defined on a per-set basis.
When a user agent has to split a string on spaces, 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, and output is not
the empty string, append a single U+0020 SPACE character at the
end of output.
Otherwise, append s to the end of output.
Return to the step labeled loop.
This causes any occurrences of the token to be
removed from the string, and any spaces that were surrounding the
token to be collapsed to a single space, except at the start and end
of the string, where such spaces are removed.
2.5.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.
Let tokens be a list of tokens,
initially empty.
Token: If position is past the
end of input, jump to the last step.
Collect a sequence of characters that are not
"," (U+002C) characters. Let s be the resulting sequence (which might be the
empty 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.5.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.
Return the first element of type type
that has an id attribute whose value
is a case-sensitive match for s or
a name attribute whose value is a
compatibility caseless match for s.
2.5.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.6 URLs
This specification defines the term URL, and defines
various algorithms for dealing with URLs, because for historical
reasons the rules defined by the URI and IRI specifications are not
a complete description of what HTML user agents need to implement to
be compatible with Web content.
The term "URL" in this specification is used in a
manner distinct from the precise technical meaning it is given in
RFC 3986. Readers familiar with that RFC will find it easier to read
this specification if they pretend the term "URL" as used
herein is really called something else altogether. This is a
willful violation of RFC 3986. [RFC3986]
2.6.1 Terminology
A URL is a string used to identify a resource.
A URL is a valid URL if at least one of
the following conditions holds:
This specification defines the URL
about:legacy-compat as a reserved, though
unresolvable, about: URI, for use in DOCTYPEs in HTML
documents when needed for compatibility with XML tools. [ABOUT]
Parse url in the manner defined by RFC
3986, with the following exceptions:
Add all characters with code points less than or equal to
U+0020 or greater than or equal to U+007F to the
<unreserved> production.
Add the characters U+0022, U+003C, U+003E, U+005B .. U+005E,
U+0060, and U+007B .. U+007D to the <unreserved>
production.
Add a single U+0025 PERCENT SIGN character as a second
alternative way of matching the <pct-encoded> production,
except when the <pct-encoded> is used in the
<reg-name> production.
Add the U+0023 NUMBER SIGN character to the characters
allowed in the <fragment> production.
If url doesn't match the
<URI-reference> production, even after the above changes are
made to the ABNF definitions, then parsing the URL fails with an
error. [RFC3986]
Otherwise, parsing url was successful; the
components of the URL are substrings of url
defined as follows:
<scheme>
The substring matched by the <scheme> production, if any.
<host>
The substring matched by the <host> production, if any.
<port>
The substring matched by the <port> production, if any.
<hostport>
If there is a <scheme> component and a <port>
component and the port given by the <port> component is
different than the default port defined for the protocol given by
the <scheme> component, then <hostport> is the
substring that starts with the substring matched by the
<host> production and ends with the substring matched by the
<port> production, and includes the colon in between the
two. Otherwise, it is the same as the <host> component.
<path>
The substring matched by one of the following productions, if
one of them was matched:
<path-abempty>
<path-absolute>
<path-noscheme>
<path-rootless>
<path-empty>
<query>
The substring matched by the <query> production, if any.
<fragment>
The substring matched by the <fragment> production, if any.
<host-specific>
The substring that follows the substring matched
by the <authority> production, or the whole string if the
<authority> production wasn't matched.
These parsing rules are a willful
violation of RFC 3986 and RFC 3987 (which do not define error
handling), motivated by a desire to handle legacy content. [RFC3986][RFC3987]
2.6.3 Base URLs
The fallback base URL of a Document
object is the absolute URL obtained by running these
substeps:
If there is no base element that has an href attribute, then the
document base URL is fallback base
url; abort these steps. Otherwise, let url be the value of the href attribute of the first such
element.
Resolveurl relative to fallback base
url (thus, the basehref attribute isn't affected by
xml:base attributes).
The document base URL is the result of the
previous step if it was successful; otherwise it is fallback base url.
2.6.4 Resolving URLs
Resolving a URL is the process of taking a relative URL and
obtaining the absolute URL that it implies.
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.
If encoding is a UTF-16
encoding, then change the value of encoding to UTF-8.
If the algorithm was invoked with an absolute URL
to use as the base URL, let base be that
absolute URL.
Otherwise, let base be 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 parsing url resulted in a <host> component, then replace the
matching substring of url with the string that
results from expanding any sequences of percent-encoded octets in
that component that are valid UTF-8 sequences into Unicode
characters as defined by UTF-8.
If any percent-encoded octets in that component are not valid
UTF-8 sequences (e.g. sequences of percent-encoded octets that
expand to surrogate code points), then return an error and abort
these steps.
Apply the IDNA ToASCII algorithm to the matching substring,
with both the AllowUnassigned and UseSTD3ASCIIRules flags
set. Replace the matching substring with the result of the ToASCII
algorithm.
If ToASCII fails to convert one of the components of the
string, e.g. because it is too long or because it contains invalid
characters, then return an error and abort these steps. [RFC3490]
If parsing url resulted in a <path> component, then replace the
matching substring of url with the string that
results from applying the following steps to each character other
than "%" (U+0025) that doesn't match the original
<path> production defined in RFC 3986:
Encode the character into a sequence of octets as defined by
UTF-8.
Replace the character with the percent-encoded form of those
octets. [RFC3986]
For instance if url was "//example.com/a^b☺c%FFd%z/?e", then the
<path> component's substring
would be "/a^b☺c%FFd%z/" and the two
characters that would have to be escaped would be "^" and "☺". The
result after this step was applied would therefore be that url now had the value "//example.com/a%5Eb%E2%98%BAc%FFd%z/?e".
If parsing url resulted in a <query> component, then replace the
matching substring of url with the string that
results from applying the following steps to each character other
than "%" (U+0025) that doesn't match the original
<query> production defined in RFC 3986:
If the character in question cannot be expressed in the
encoding encoding, then replace it with a
single 0x3F octet (an ASCII question mark) and skip the remaining
substeps for this character.
Encode the character into a sequence of octets as defined by
the encoding encoding.
Replace the character with the percent-encoded form of those
octets. [RFC3986]
Apply the algorithm described in RFC 3986 section 5.2
Relative Resolution, using url as the
potentially relative URI reference (R), and
base as the base URI (Base). [RFC3986]
Apply any relevant conformance criteria of RFC 3986 and RFC
3987, returning an error and aborting these steps if
appropriate. [RFC3986][RFC3987]
For instance, if an absolute URI that would be
returned by the above algorithm violates the restrictions specific
to its scheme, e.g. a data: URI using the
"//" server-based naming authority syntax,
then user agents are to treat this as an error instead.
Let result be the target URI (T) returned by the Relative Resolution
algorithm.
If result uses a scheme with a
server-based naming authority, replace all "\" (U+005C) characters in result with "/" (U+002F) characters.
Return result.
Some of the steps in these rules, for example the
processing of "\" (U+005C) characters, are a
willful violation of RFC 3986 and RFC 3987, motivated
by a desire to handle legacy content. [RFC3986][RFC3987]
A URL is an absolute URL if resolving it results in the same output
regardless of what it is resolved relative to, and that output is
not a failure.
An absolute URL is a hierarchical URL if,
when resolved and then parsed, there is a character immediately
after the <scheme> component
and it is a "/" (U+002F) character.
An absolute URL is an authority-based URL
if, when resolved and then parsed, there are two characters
immediately after the <scheme>
component and they are both "//" (U+002F) characters.
2.6.5 URL manipulation and creation
To fragment-escape a string
input, a user agent must run the following
steps:
Let input be the string to be
escaped.
Let position point at the first
character of input.
Let output be an empty string.
Loop: If position is past the end
of input, then jump to the step labeled
end.
If the character in input pointed to by
position is in the range U+0000 to U+0020 or
is one of the following characters:
""" (U+0022) character
"#" (U+0023) character
"%" (U+0025) character
U+003C LESS-THAN SIGN character (<)
">" (U+003E) character
"[" (U+005B) character
"\" (U+005C) character
"]" (U+005D) character
"^" (U+005E) character
"{" (U+007B) character
"|" (U+007C) character
"}" (U+007D) character
...then append the percent-encoded form of the character to
output. [RFC3986]
Otherwise, append the character itself to output.
This escapes any ASCII characters that are not
valid in the URI <fragment> production without being
escaped.
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 element is a q, blockquote,
ins, or del element with a cite attribute
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.7 Interfaces for URL manipulation
An interface that has a complement of URL decomposition IDL
attributes has seven attributes with the following
definitions:
Returns the current fragment identifier in the underlying URL.
Can be set, to change the underlying URL's fragment identifier.
The attributes defined to be URL decomposition IDL
attributes must act as described for the attributes with the
same corresponding names in this section.
In addition, an interface with a complement of URL
decomposition IDL attributes defines an input, which is a URL
that the attributes act on, and a common setter action, which is a
set of steps invoked when any of the attributes' setters are
invoked.
On getting, if the input
is an absolute URL that fulfills the condition given in
the "getter condition" column corresponding to the attribute in the
table below, the user agent must return the part of the input URL given in the "component"
column, with any prefixes specified in the "prefix" column
appropriately added to the start of the string and any suffixes
specified in the "suffix" column appropriately added to the end of
the string. Otherwise, the attribute must return the empty
string.
On setting, the new value must first be mutated as described by
the "setter preprocessor" column, then mutated by %-escaping any
characters in the new value that are not valid in the relevant
component as given by the "component" column. Then, if the input is an absolute
URL and the resulting new value fulfills the condition given
in the "setter condition" column, the user agent must make a new
string output by replacing the component of the
URL given by the "component" column in the input URL with the new value;
otherwise, the user agent must let output be
equal to the input. Finally,
the user agent must invoke the common setter action with the
value of output.
When replacing a component in the URL, if the component is part
of an optional group in the URL syntax consisting of a character
followed by the component, the component (including its prefix
character) must be included even if the new value is the empty
string.
The previous paragraph applies in particular to the
":" before a <port> component, the "?" before a <query> component, and the "#" before a <fragment> component.
For the purposes of the above definitions, URLs must be parsed
using the URL parsing rules defined
in this specification.
Remove all characters in the new value from the first that is not in the range ASCII digits, if any.
Remove any leading "0" (U+0030) characters in the new value.
If the resulting string is empty, set it to a single "0" (U+0030) character.
input is an authority-based URL,
and the new value, when interpreted as a base-ten integer, is less than or equal to 65535
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.
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 a synchronous flag, a manual redirect
flag, a force same-origin flag, and/or 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:
Clean referrer: Remove any <fragment> component from referrer.
If referrer is not the empty string, is not
a data:
URL, is not a javascript: 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.
This is the main step.
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, dereferencing javascript: 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:
Wait until ownership of the storage mutex can
be taken by this instance of the fetching algorithm.
Release the storage mutex so that it is once
again free.
If the fetched resource is an HTTP redirect or equivalent,
then:
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.7.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.7.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 Media Type Sniffing
specification. [MIMESNIFF]
The sniffed type of a
resource must be found in a manner consistent with the
requirements given in the Media Type Sniffing
specification for finding the sniffed-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 Media Type Sniffing
specification. Both sets of rules return a MIME type as
their result. [MIMESNIFF]
It is imperative that the rules in the Media Type
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
Media Type Sniffing specification. [MIMESNIFF]
2.7.5 Extracting character encodings from meta elements
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 encoding corresponding to the string 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 encoding corresponding to the string from this
character to 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.7.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.
Cross-origin CORS requests for the element will not have the omit credentials flag set.
The empty string is also a valid keyword, and maps to the Anonymous state. The
attribute's invalid value default is the Anonymous state. The
missing value default, used when the attribute is omitted, is
the No CORS state.
2.7.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.
FetchURL,
using referrer source if one was specified,
with the manual redirect flag set.
Loop: Wait for the fetch algorithm
to know if the result is a redirect or not.
Follow the first appropriate steps from the following list:
If the result of the fetch is a redirect, and
the origin of the target URL of the redirect is
not the same origin as origin
Set URL to the the target URL of the
redirect and return to the top of the potentially
CORS-enabled fetch algorithm (this time, one of the
other branches below might be taken, based on the value of
mode).
FetchURL, using
referrer source if one was specified.
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).
The URL does not have the
same origin as origin, and default is fail.
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).
Perform a cross-origin request
with the request URL set to URL, using
referrer source if one was specified, with
the source origin set to origin, and
with the omit credentials flag set if mode is "Anonymous" and not set
otherwise. [CORS]
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).
The tasks from the
fetch algorithm are queued normally, and for the purposes of the
calling algorithm, the obtained resource is
CORS-same-origin.
2.8 Common DOM interfaces
2.8.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 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
DOMTokenList or DOMSettableTokenList, then
on getting it must return a DOMTokenList or
DOMSettableTokenList object (as appropriate) whose
underlying string is the element's corresponding content attribute.
When the object mutates its underlying string, the content attribute
must itself be immediately mutated. When the attribute is absent,
then the string represented by the object is the empty string; when
the object mutates this empty string, the user agent must add the
corresponding content attribute, with its value set to the value it
would have been set to after mutating the empty string. The same
DOMTokenList or DOMSettableTokenList
object must be returned every time for each attribute.
If an element with no attributes has its element.classList.remove()
method invoked, the underlying string won't be changed, since the
result of removing any token from the empty string is still the
empty string. However, if the element.classList.add() method is
then invoked, a class attribute
will be added to the element with the value of the token to be
added.
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:
Let collection be an
HTMLAllCollection 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:
The namedItem(name) method must act according to the
following algorithm:
If, at the time the method is called, there is exactly one node
in the collection that has either an id attribute or a name attribute equal to name, then return that node and stop the
algorithm.
Otherwise, if there are no nodes in the collection that have
either an id attribute or a name attribute equal to name, then return null and stop the algorithm.
If element is null, or if it is an
element with no value
attribute, return the empty string.
Otherwise, return the value of element's
value attribute.
On setting, the value IDL attribute must run
the following steps:
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.
If element is not null, then set its
checkedness to true.
2.8.2.3 HTMLOptionsCollection
The HTMLOptionsCollection interface is used for
collections of option elements. It is
always rooted on a select element and has attributes
and methods that manipulate that element's descendants.
The before argument can be a number, in
which case element is inserted before the item
with that number, or an element from the collection, in which case
element is inserted before that element.
If before is omitted, null, or a number out
of range, then element will be added at the
end of the list.
This method will throw a HierarchyRequestError
exception if element is an ancestor of the
element into which it is to be inserted.
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).
The namedItem(name) method must act according to the
following algorithm:
If, at the time the method is called, there is exactly one node
in the collection that has either an id attribute or a name attribute equal to name, then return that node and stop the
algorithm.
Otherwise, if there are no nodes in the collection that have
either an id attribute or a name attribute equal to name, then return null and stop the algorithm.
Otherwise, create a new NodeList object
representing a live view of the
HTMLOptionsCollection object, further filtered so that
the only nodes in the NodeList object are those that
have either an id attribute or a name attribute equal to name. The nodes in the NodeList object
must be sorted in tree order.
When the user agent is to set the value of a new
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.
If before is an element, but that
element isn't a descendant of the select element on
which the HTMLOptionsCollection is rooted, then throw
a NotFoundError exception.
If element and before are the same element, then return and abort
these steps.
If before is a node, then let reference be that node. Otherwise, if before is an integer, and there is a beforeth node in the collection, let reference be that node. Otherwise, let reference be null.
If reference is not null, let parent be the parent node of reference. Otherwise, let parent
be the select element on which the
HTMLOptionsCollection is rooted.
Act as if the DOM Core insertBefore() method was
invoked on the parent node, with element as the first argument and reference as the second argument.
The remove(index) method must act according to
the following algorithm:
If index is not a number greater than or
equal to 0 and less than the number of nodes represented by
the collection, abort these steps.
Let element be the indexth element in the collection.
Remove element from its parent
node.
The selectedIndex
IDL attribute must act like the identically named attribute on the
select element on which the
HTMLOptionsCollection is rooted
2.8.3 DOMStringMap
The DOMStringMap interface represents a set of
name-value pairs. It exposes these using the scripting language's
native mechanisms for property access.
When a DOMStringMap object is instantiated, it is
associated with three algorithms, one for getting the list of
name-value pairs, one for setting names to certain values, and one
for deleting names.
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.
To determine the value of
a named property name 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 property name, 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.
Given the following fragment and elements with similar
constructions:
...one could imagine a function splashDamage() that takes some arguments, the first
of which is the element to process:
function splashDamage(node, x, y, damage) {
if (node.classList.contains('tower') && // checking the 'class' attribute
node.dataset.x == x && // reading the 'data-x' attribute
node.dataset.y == y) { // reading the 'data-y' attribute
var hp = parseInt(node.dataset.hp); // reading the 'data-hp' attribute
hp = hp - damage;
if (hp < 0) {
hp = 0;
node.dataset.ai = 'dead'; // setting the 'data-ai' attribute
delete node.dataset.ability; // removing the 'data-ability' attribute
}
node.dataset.hp = hp; // setting the 'data-hp' attribute
}
}
2.8.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.
[NoInterfaceObject]
interface Transferable { };
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.)
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.
Let output be the value resulting from
calling the internal structured cloning algorithm with
input as the "input"
argument, and memory as the "memory" argument.
Return output.
The internal structured cloning algorithm is always
called with two arguments, input and memory, and its behavior is as follows:
If input is the source object of a pair
of objects in memory, then return the
destination object in that pair of objects and abort these
steps.
If input is a primitive value, then
return that value and abort these steps.
The input value is an object. Jump to the
appropriate step below:
If input is a Boolean object
Let output be a newly constructed Boolean object with the same value as input.
If input is a Number object
Let output be a newly constructed Number object with the same value as input.
If input is a String object
Let output be a newly constructed String object with the same value as input.
If input is a Date object
Let output be a newly constructed Date object with the same value as input.
If input is a RegExp object
Let output be a newly constructed RegExp object with the same pattern and flags as input.
The value of the lastIndex property is not copied.
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 and height 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.
If input is an Array object
Let output be a newly constructed empty
Array object whose length is
equal to the length of input.
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.
If input is an object that another specification defines how to clone
Let output be a clone of the object as defined by the other specification.
If input is another native object type (e.g. Error, Function)
Add a mapping from input (the source
object) to output (the destination object) to
memory.
If input is an Array object or an Object
object, then, for each enumerable property in input, add a new property to output having the same name, and having a value
created from invoking the internal structured cloning
algorithm recursively with the value of the property as the
"input" argument and memory as the "memory"
argument. The order of the properties in the input and output objects must
be the same, and any properties that involve running script must
be processed in that same order. If obtaining the value of the
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.
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.8.6 DOM feature strings
DOM3 Core defines mechanisms for checking for interface support,
and for obtaining implementations of interfaces, using feature
strings. [DOMCORE]
Authors are strongly discouraged from using these, as they are
notoriously unreliable and imprecise. Authors are encouraged to rely
on explicit feature testing or the graceful degradation behavior
intrinsic to some of the features in this specification.
For historical reasons, user agents should return the true value
when the hasFeature(feature, version)
method of the DOMImplementation interface is invoked
with feature set to either "HTML" or "XHTML" and version set to either "1.0" or
"2.0".
2.8.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.9 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. [DOMCORE]
Interactive user agents typically expose
the document's address in their user interface. This is
the primary mechanism by which a user can tell if a site is
attempting to impersonate another.
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.
When the user agent is to perform an overridden
reload, it must act as follows:
Returns the address
of the Document from which the user navigated to this
one, unless it was blocked or there was no such document, in which
case it returns the empty string.
The noreferrer link
type can be used to block the referrer.
The referrer attribute
must return either the address of the active document of the
source browsing contextat the time the navigation
was started (that is, the page which navigated the browsing context
to the current document), with any <fragment> component removed; or
the empty string if there is no such originating page, or if the UA
has been configured not to report referrers in this case, or if the
navigation was initiated for a hyperlink with a noreferrer keyword.
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).
Returns the HTTP cookies that apply to the
Document. If there are no cookies or cookies can't be
applied to this resource, the empty string will be returned.
Can be set, to add a new cookie to the element's set of HTTP
cookies.
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 digits in the range 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 digits in the range 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.
Returns "loading" while the Document is loading, "interactive" once it is finished parsing but still loading sub-resources, and "complete" once it has loaded.
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]
The children of element (if any) must all
be removed.
A single Text node whose data is the new value
being assigned must be appended to element.
The title IDL attribute
defined above must replace the attribute of the same name on the
Document interface defined by the SVG specification
when the user agent supports both HTML and SVG. [SVG]
The body element of a document is the first child of
the html element that is either a
body element or a frameset element. If
there is no such element, it is null.
The body
attribute, on getting, must return the body element of
the document (either a body element, a
frameset element, or null). On setting, the following
algorithm must be run:
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.
Otherwise, the body element is null. Append
the new value to the root element.
The images
attribute must return an HTMLCollection rooted at the
Document node, whose filter matches only
img elements.
The embeds
attribute must return an HTMLCollection rooted at the
Document node, whose filter matches only
embed elements.
The plugins
attribute must return the same object as that returned by the embeds attribute.
The links
attribute must return an HTMLCollection rooted at the
Document node, whose filter matches only a
elements with href
attributes and area elements with href attributes.
The forms
attribute must return an HTMLCollection rooted at the
Document node, whose filter matches only
form elements.
The scripts
attribute must return an HTMLCollection rooted at the
Document node, whose filter matches only
script elements.
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.
To determine the value of a named propertyname when the
Document object is indexed for property
retrieval, the user agent must return the value obtained using
the following steps:
There will be at least one such element, by
definition.
If elements has only one element, and that
element is an iframe element, then return the
WindowProxy object of the nested browsing
context represented by that iframe element,
and abort these steps.
Otherwise, if elements has only one
element, return that element and abort these steps.
The load(url) method must run the following
steps:
Let document be the XMLDocument
object on which the method was invoked.
Resolve the method's
first argument, relative to the entry script's base URL. If this is not
successful, throw a SyntaxError exception and abort
these steps. Otherwise, let url be the
resulting absolute URL.
If the origin of url is not
the same as the origin of document, throw a SecurityError
exception and abort these steps.
Remove all child nodes of document,
without firing any mutation events.
Replace all the children of document
by the children of result (even if it has no
children), firing mutation events as if a
DocumentFragment containing the new children had
been inserted.
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. 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:
<!DOCTYPE HTML>
<html lang="en-GB">
<head> <title> Demonstration </title> </head>
<body>
<table>
<tr> <td> My favourite animal is the cat. </td> </tr>
<tr>
<td>
—<a href="http://example.org/~ernest/"><cite>Ernest</cite></a>,
in an essay from 1992
</td>
</tr>
</table>
</body>
</html>
...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.
A corrected version of this document might be:
<!DOCTYPE HTML>
<html lang="en-GB">
<head> <title> Demonstration </title> </head>
<body>
<blockquote>
<p> My favourite animal is the cat. </p>
</blockquote>
<p>
—<a href="http://example.org/~ernest/">Ernest</a>,
in an essay from 1992
</p>
</body>
</html>
This next document fragment, intended to represent the heading
of a corporate site, is similarly non-conforming because the second
line is not intended to be a heading of a subsection, but merely a
subheading or subtitle (a subordinate heading for the same
section).
<body>
<h1>ABC Company</h1>
<h2>Leading the way in widget design since 1432</h2>
...
The hgroup element is intended for these kinds of
situations:
<body>
<hgroup>
<h1>ABC Company</h1>
<h2>Leading the way in widget design since 1432</h2>
</hgroup>
...
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.
For example, an ol element
represents an ordered list.
The basic interface, from which all the HTML
elements' interfaces inherit, and which
must be used by elements that have no additional
requirements, is the HTMLElement interface.
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.
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.
The attributes marked with an asterisk have a
different meaning when specified on body elements as
those elements expose event handlers of the
Window object with the same names.
While these attributes apply to all elements, they
are not useful on all elements. For example, only media elements will ever receive a volumechange event fired by
the user agent.
Custom data attributes
(e.g. data-foldername or data-msgid) can be specified on any HTML element, to store custom data
specific to the page.
In HTML documents, elements in the HTML
namespace may have an xmlns attribute
specified, if, and only if, it has the exact value
"http://www.w3.org/1999/xhtml". This does not apply to
XML documents.
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]
There is no way to serialize the xml:space attribute on HTML
elements in the text/html syntax.
To enable assistive technology products to expose a more
fine-grained interface than is otherwise possible with HTML elements
and attributes, a set of annotations for
assistive technology products can be specified (the ARIA
role and aria-* attributes).
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.
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 apear, 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, abbr, or title 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 title IDL attribute
must reflect the title
content attribute.
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]
Authors must not use the lang attribute in the XML
namespace on HTML elements in HTML
documents. To ease migration to and from XHTML, authors may
specify an attribute in no namespace with no prefix and with the
literal localname "xml:lang" on HTML
elements in HTML documents, but such attributes
must only be specified if a lang
attribute in no namespace is also specified, and both attributes
must have the same value when compared in an ASCII
case-insensitive manner.
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.
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.
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 attribute values and the values of its Text
node children are to be translated when the page is localized.
When an element is in the no-translate state, the
element's attribute values 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 localised, 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>
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 embedded left-to-right text.
The rtl keyword, which maps to the rtl state
Indicates that the contents of the element are explicitly
directionally embedded right-to-left text.
The auto keyword, which maps to the auto state
Indicates that the contents of the element are explicitly
embedded 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 is either 'ltr' or 'rtl', and is determined as per the first
appropriate set of steps from the following list:
If the element's dir attribute is
in the ltr state
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'. Otherwise, the
directionality of the element is 'ltr'. [BIDI]
If the element's dir attribute is
in the auto state
If the element is a bdi element and the dir attribute is not in a defined state
(i.e. it is not present or has an invalid value)
Find the first character in tree order that
matches the following criteria:
The character is from a Text node that is a
descendant of the element whose directionality is being
determined.
The character is of bidirectional character type L, AL,
or R. [BIDI]
The character is not in a Text node that has an
ancestor element that is a descendant of the element whose directionality is being
determined and that is either:
The effect of this attribute is primarily on the presentation
layer. For example, the rendering section in this specification
defines a mapping from this attribute to the CSS 'direction' and
'unicode-bidi' properties, and CSS defines rendering in terms of
those properties.
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).
This markup fragment is of an IM conversation.
<p dir=auto class="u1"><b><bdi>Student</bdi>:</b> How do you write "What's your name?" in Arabic?</p>
<p dir=auto class="u2"><b><bdi>Teacher</bdi>:</b> ما اسمك؟</p>
<p dir=auto class="u1"><b><bdi>Student</bdi>:</b> Thanks.</p>
<p dir=auto class="u2"><b><bdi>Teacher</bdi>:</b> That's written "شكرًا".</p>
<p dir=auto class="u2"><b><bdi>Teacher</bdi>:</b> Do you know how to write "Please"?</p>
<p dir=auto class="u1"><b><bdi>Student</bdi>:</b> "من فضلك", right?</p>
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.
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.
The className and classList IDL attributes,
defined in the DOM Core specification, reflect the
class content attribute. [DOMCORE]
3.2.3.8 The style attribute
All HTML elements may have the style content attribute set. This is a
CSS styling attribute as defined by the CSS Styling
Attribute Syntax specification. [CSSATTR]
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.)
The style IDL attribute
must return a CSSStyleDeclaration whose value
represents the declarations specified in the attribute. (If the
attribute is absent, the object represents an empty declaration.)
Mutating the CSSStyleDeclaration object must create a
style attribute on the element (if
there isn't one already) and then change its value to be a value
representing the serialized form of the
CSSStyleDeclaration object. The same object must be
returned each time. [CSSOM]
In the following example, the words that refer to colors are
marked up using the span element and the style attribute to make those words show
up in the relevant colors in visual media.
<p>My sweat suit is <span style="color: green; background:
transparent">green</span> and my eyes are <span style="color: blue;
background: transparent">blue</span>.</p>
3.2.3.9 Embedding custom non-visible data with the data-* attributes
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 characters in the range U+0041 to U+005A (LATIN CAPITAL
LETTER A to LATIN CAPITAL LETTER Z).
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.
Hyphenated names become camel-cased. For example, data-foo-bar="" becomes element.dataset.fooBar.
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 characters in
the range U+0041 to U+005A (LATIN CAPITAL LETTER A to LATIN
CAPITAL LETTER Z), 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.
For each name list, for each "-" (U+002D) character in the name that is followed by a
character in the range U+0061 to U+007A (lowercase ASCII letters), remove the "-" (U+002D) character and replace the character that
followed it by the same character converted to ASCII
uppercase.
Return list.
The algorithm for setting names to certain values
Let name be the name passed to the
algorithm.
Let value be the value passed to the
algorithm.
If name contains a "-" (U+002D) character followed by a character in the range U+0061 to
U+007A (lowercase ASCII letters), throw a SyntaxError exception and abort these
steps.
For each character in the range U+0041 to U+005A (uppercase ASCII letters) in name, insert a "-" (U+002D) character
before the character and replace the character with the same
character converted to ASCII lowercase.
Insert the string data- at the front of
name.
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.
The algorithm for deleting names
Let name be the name passed to the
algorithm.
For each character in the range U+0041 to U+005A (uppercase ASCII letters) in name, insert a "-" (U+002D) character
before the character and replace the character with the same
character converted to ASCII lowercase.
Insert the string data- at the front of
name.
Remove the attribute with the name name,
if such an attribute exists. Do nothing otherwise.
The same object must be returned each time.
If a Web page wanted an element to represent a space ship,
e.g. as part of a game, it would have to use the class attribute along with data-* attributes:
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.4 Element definitions
Each element in this specification has a definition that includes
the following information:
Categories
A list of categories
to which the element belongs. These are used when defining the
content models for each element.
Contexts in which this element can be used
A non-normative description of where the element can
be used. This information is redundant with the content models of
elements that allow this one as a child, and is provided only as a
convenience.
A normative description of what content must be included as
children and descendants of the element.
Content attributes
A normative list of attributes that may be specified on the
element (except where otherwise disallowed).
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.4.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.5 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 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.5.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:
Some elements also fall into other categories, which
are defined in other parts of this specification.
These categories are related as follows:
Sectioning content, heading content, phrasing content, embedded
content, and interactive content are all types of flow content.
Metadata is sometimes flow content. Metadata and interactive content
are sometimes phrasing content. Embedded content is also a type of
phrasing content, and sometimes is interactive content.
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.5.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.
Elements from other namespaces whose semantics are primarily
metadata-related (e.g. RDF) are also metadata
content.
Thus, in the XML serialization, one can use RDF, like this:
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:r="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<head>
<title>Hedral's Home Page</title>
<r:RDF>
<Person xmlns="http://www.w3.org/2000/10/swap/pim/contact#"
r:about="http://hedral.example.com/#">
<fullName>Cat Hedral</fullName>
<mailbox r:resource="mailto:hedral@damowmow.com"/>
<personalTitle>Sir</personalTitle>
</Person>
</r:RDF>
</head>
<body>
<h1>My home page</h1>
<p>I like playing with string, I guess. Sister says squirrels are fun
too so sometimes I follow her to play with them.</p>
</body>
</html>
This isn't possible in the HTML serialization, however.
3.2.5.1.2 Flow content
Most elements that are used in the body of documents and
applications are categorized as flow content.
Heading content defines the header of a section
(whether explicitly marked up using sectioning content
elements, or implied by the heading content itself).
Phrasing content is the text of the document, as well
as elements that mark up that text at the intra-paragraph
level. Runs of phrasing content form paragraphs.
As a general rule, elements whose content model allows any
phrasing content should have either at least one
descendant Text node that is not inter-element
whitespace, or at least one descendant element node that is
embedded content. For the purposes of this requirement,
nodes that are descendants of del elements must not be
counted as contributing to the ancestors of the del
element.
Most elements that are categorized as phrasing
content can only contain elements that are themselves categorized as
phrasing content, not any flow content.
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.5.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.5.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.
Set the click in progress flag on the
element to true.
Set the click in progress flag on the
element to false.
The above doesn't happen for arbitrary synthetic
events dispatched by author script. However, the click() method can be used to make it
happen programmatically.
Click-focusing behavior (e.g. the focusing of a text
field when user clicks in one) typically happens before the click,
when the mouse button is first depressed, and is therefore not
discussed here.
Given an element target, the nearest
activatable element is the element returned by the following
algorithm:
If target has a defined activation
behavior, then return target and abort
these steps.
If target has a parent element, then set
target to that parent element and return to the
first step.
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.5.1.8 Palpable content
As a general rule, elements whose content model allows any
flow content or phrasing content should
have at least one child node 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.
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.
For instance, an ins element inside a
ruby element cannot contain an rt
element, because the part of the ruby element's
content model that allows ins elements is the part
that allows phrasing content, and the rt
element is not phrasing content.
In some cases, where transparent elements are nested
in each other, the process has to be applied iteratively.
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. The ins 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.5.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).
A paragraph is also formed explicitly by
p elements.
The p element can be used to wrap
individual paragraphs when there would otherwise not be any content
other than phrasing content to separate the paragraphs from each
other.
In the following example, the link spans half of the first
paragraph, all of the heading separating the two paragraphs, and
half of the second paragraph. It straddles the paragraphs and the
heading.
<header>
Welcome!
<a href="about.html">
This is home of...
<h1>The Falcons!</h1>
The Lockheed Martin multirole jet fighter aircraft!
</a>
This page discusses the F-16 Fighting Falcon's innermost secrets.
</header>
Here is another way of marking this up, this time showing the
paragraphs explicitly, and splitting the one link element into
three:
<header>
<p>Welcome! <a href="about.html">This is home of...</a></p>
<h1><a href="about.html">The Falcons!</a></h1>
<p><a href="about.html">The Lockheed Martin multirole jet
fighter aircraft!</a> This page discusses the F-16 Fighting
Falcon's innermost secrets.</p>
</header>
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:
<section>
<h1>My Fish</h1>
You can play with my fish simulator.
<object data="fish.sim">
<p>To see the fish simulator, use one of the following links:</p>
<ul>
<li><a href="fish.sim">Download simulator file</a>
<li><a href="http://sims.example.com/watch?v=LYds5xY4INU">Use online simulator</a>
</ul>
<p>Alternatively, upgrade to the Mellblom Browser.</p>
</object>
I'm quite proud of it.
</section>
3.2.6 Requirements relating to bidirectional-algorithm formatting
characters
Text content in HTML elements with
child Text nodes, and text in attributes of HTML
elements that allow free-form text, may contain characters in
the range U+202A to U+202E (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]
Any strings that, as described above, are
bidirectional-algorithm formatting character ranges must
match the string production in the following
ABNF, the character set for which is Unicode. [ABNF]
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.7 WAI-ARIA
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]
User agents are required to implement ARIA semantics on all
HTML elements, as defined in the ARIA specifications.
The implicit ARIA semantics defined below must be
recognized by implementations for the purposes of ARIA processing.
[ARIAIMPL]
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.
The attribute, if specified, must have a value that is a set of
space-separated tokens representing the various WAI-ARIA roles that
the element belongs to.
The WAI-ARIA role that an HTML element has assigned to it is the
first non-abstract role found in the list of values generated when the
role attribute is split on
spaces.
These attributes, if specified, must have a value that is the ARIA
value type in the "Value" field of the definition for the state or
property, mapped to the appropriate HTML value type according to [ARIA]Section
10.2 Mapping WAI-ARIA Value types to languages using the HTML 5
mapping.
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 (role, states, and/or 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.
Language feature
Strong native semantics and default implied ARIA semantics
aria-checked state set to "mixed" if the element's indeterminate IDL attribute is true, or "true" if the element's checkedness is true, or "false" otherwise
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
slider role, with the aria-valuemax property set to the element's maximum, the aria-valuemin property set to the element's minimum, and the aria-valuenow property set to the result of applying the rules for parsing floating-point number values to the element's value, if that results in a number, or the default value otherwise
combobox role, with the aria-owns property set to the same value as the list attribute, and the aria-readonly property set to "true" if the element has a readonly attribute
input element with a type attribute in the Time state
No role, with the aria-readonly property set to "true" if the element has a readonly attribute
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
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. In addition, any element may be
given the presentation role,
regardless of the restrictions below.
The entry "no role", when
used as a strong native
semantic, means that no role other than presentation can be used.
When used as a default
implied ARIA semantic, it means the user agent has no default
mapping to ARIA roles. (However, it probably will 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:
<figure role="img" aria-labelledby="fish-caption">
<pre>
o .'`/
' / (
O .-'` ` `'-._ .')
_/ (o) '. .' /
) ))) >< <
`\ |_\ _.' '. \
'-._ _ .-' '.)
jgs `\__\
</pre>
<figcaption id="fish-caption">
Joan G. Stark, "<cite>fish</cite>".
October 1997. ASCII on electrons. 28×8.
</figcaption>
</figure>
3.3 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).
There are also additional non-normative comments
regarding the interaction of XSLT and HTML in the script element
section.
3.4 Dynamic markup insertion
APIs for dynamically inserting markup into the
document interact with the parser, and thus their behavior varies
depending on whether they are used with HTML documents
(and the HTML parser) or XHTML in XML
documents (and the XML parser).
3.4.1 Opening the input stream
The open()
method comes in several variants with different numbers of
arguments.
Causes the Document to be replaced in-place, as if
it was a new Document object, but reusing the
previous object, which is then returned.
If the type argument is omitted or has the
value "text/html", then the resulting
Document has an HTML parser associated with it, which
can be given data to parse using document.write(). Otherwise, all
content passed to document.write() will be parsed
as plain text.
If the replace argument is present and has
the value "replace", the existing entries in
the session history for the Document object are
removed.
The method has no effect if the Document is still
being parsed.
Document objects have an
ignore-opens-during-unload counter, which is used to
prevent scripts from invoking the document.open() method (directly or
indirectly) while the document is being unloaded. Initially, the counter must be set
to zero.
When called with two or fewer arguments, the document.open() method must act as
follows:
Let type be the value of the first
argument, if there is one, or "text/html"
otherwise.
Let replace be true if there is a second
argument and it is an ASCII case-insensitive match for
the value "replace", and false otherwise.
If the Document has an active parser
that isn't a script-created parser, and the
insertion point associated with that parser's
input stream is not undefined (that is, it
does point to somewhere in the input stream), then the
method does nothing. Abort these steps and return the
Document object on which the method was invoked.
This basically causes document.open() to be ignored
when it's called in an inline script found during the parsing of
data sent over the network, while still letting it have an effect
when called asynchronously or on a document that is itself being
spoon-fed using these APIs.
This basically causes document.open() to be ignored
when it's called from a beforeunloadpagehide, or unload event handler while the
Document is being unloaded.
Remove all child nodes of the document, without firing any
mutation events.
Replace the Document's singleton objects with
new instances of those objects. (This includes in particular the
Window, Location, History,
ApplicationCache, and Navigator, objects,
the various BarProp objects, the two
Storage objects, the various
HTMLCollection objects, and objects defined by other
specifications, like Selection and the document's
UndoManager. It also includes all the Web IDL
prototypes in the JavaScript binding, including the
Document object's prototype.)
Create a new HTML parser and associate it with
the document. This is a script-created parser (meaning
that it can be closed by the document.open() and document.close() methods, and
that the tokenizer will wait for an explicit call to document.close() before emitting
an end-of-file token). The encoding confidence is
irrelevant.
If type is not now an ASCII
case-insensitive match for the string
"text/html", then act as if the tokenizer had emitted
a start tag token with the tag name "pre" followed by a single
"LF" (U+000A) character, then
switch the HTML parser's tokenizer to the
PLAINTEXT state.
Remove any earlier entries that share the same
Document.
If replace is false, then add a new
entry, just before the last entry, and associate with the new entry
the text that was parsed by the previous parser associated with the
Document object, as well as the state of the document
at the start of these steps. This allows the user to step backwards
in the session history to see the page before it was blown away by
the document.open() call.
This new entry does not have a Document object, so a
new one will be created if the session history is traversed to that
entry.
Finally, set the insertion point to point at
just before the end of the input stream (which at this
point will be empty).
Return the Document on which the method was
invoked.
When called with three or more arguments, the open() method on the
Document object must call the open() method on the Window
object of the Document object, with the same
arguments as the original call to the open() method, and return whatever
that method returned. If the Document object has no
Window object, then the method must throw an
InvalidAccessError exception.
In general, adds the given string(s) to the
Document's input stream.
This method has very idiosyncratic behavior. In
some cases, this method can affect the state of the HTML
parser while the parser is running, resulting in a DOM that
does not correspond to the source of the document (e.g. if the
string written is the string "<plaintext>" or "<!--"). In other cases, the call can clear the
current page first, as if document.open() had been called.
In yet more cases, the method is simply ignored, or throws an
exception. To make matters worse, the exact behavior of this
method can in some cases be dependent on network latency, which can lead to failures that are very hard to debug.
For all these reasons, use of this method is strongly
discouraged.
Document objects have an
ignore-destructive-writes counter, which is used in
conjunction with the processing of script elements to
prevent external scripts from being able to use document.write() to blow away the
document by implicitly calling document.open(). Initially, the
counter must be set to zero.
The document.write(...)
method must act as follows:
If there is no pending parsing-blocking script,
have the HTML parser process the characters that were
inserted, one at a time, processing resulting tokens as they are
emitted, and stopping when the tokenizer reaches the insertion
point or when the processing of the tokenizer is aborted by the
tree construction stage (this can happen if a script
end tag token is emitted by the tokenizer).
The document.writeln(...)
method, when invoked, must act as if the document.write() method had been
invoked with the same argument(s), plus an extra argument consisting
of a string containing a single line feed character (U+000A).
The html element represents the root of
an HTML document.
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 manifest attribute
only has an effect during
the early stages of document load. Changing the attribute
dynamically thus has no effect (and thus, no DOM API is provided for
this attribute).
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.
There must be no more than one title element per
document.
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:
<title>Dances used during bee mating rituals</title>
...
<h1>The Dances</h1>
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.
<!DOCTYPE html>
<html>
<head>
<title>This is an example for the <base> element</title>
<base href="http://www.example.com/news/index.html">
</head>
<body>
<p>Visit the <a href="archives.html">archives</a>.</p>
</body>
</html>
The link in the above example would be a link to "http://www.example.com/news/archives.html".
The link element allows authors to link their
document to other resources.
The destination of the link(s) is given by the href attribute, which must
be present and must contain a valid non-empty URL potentially
surrounded by spaces. If the href attribute is absent, then the
element does not define a link.
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 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.
Resolve the
URL given by the href attribute, relative to the
element.
If the previous step fails, 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)
The title of the resource (given by the title attribute).
The address of the resource (given by the href attribute).
The language of the resource (given by the hreflang attribute).
The optimum media for the resource (given by the media 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.
However, if the link is an external resource link,
then the media attribute is
prescriptive. The user agent must apply the external resource when
the media attribute's value
matches the environment and the other relevant
conditions apply, and must not apply it otherwise.
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.
If a document contains style sheet links labeled as follows:
...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: header fields, 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 header
fields are to be processed according to the rules given in the
relevant specifications. [HTTP][WEBLINK]
Registration of relation types in HTTP Link: header
fields 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 relListmustreflect the rel content attribute.
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 following example shows how you can specify versions of the
page that use alternative formats, are aimed at other languages,
and that are intended for other media:
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.
If either name or http-equiv is specified, then
the content attribute must
also be specified. Otherwise, it must be omitted.
The charset
attribute specifies the character encoding used by the
document. This is a character encoding declaration. If
the attribute is present in an XML
document, its value must be an ASCII
case-insensitive match for the string "UTF-8" (and the document is therefore forced to use
UTF-8 as its encoding).
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. There must not be more than one meta
element with its name attribute
set to the value application-name per
document. 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.
author
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.
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:
This page about typefaces on British motorways uses a
meta element to specify some keywords that users
might use to look for the page:
<!DOCTYPE HTML>
<html>
<head>
<title>Typefaces on UK motorways</title>
<meta name="keywords" content="british,type face,font,fonts,highway,highways">
</head>
<body>
...
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.
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 may
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 the meta element has no content attribute, or if that
attribute's value is the empty string, then abort these
steps.
If the element's content attribute contains a
"," (U+002C) character then abort these steps.
Let input be the value of the
element's content
attribute.
Let position point at the first
character of input.
This pragma is not exactly equivalent to the HTTP
Content-Language header. [HTTP]
Encoding declaration state (http-equiv="content-type")
The Encoding
declaration state is just an alternative form of setting
the charset attribute: it is a
character encoding declaration. This state's user agent requirements are all handled
by the parsing section of the specification.
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.
Let input be the value of the
element's content
attribute.
Let position point at the first
character of input.
If the character in input pointed to
by position is a "U" (U+0055) character or a "u" (U+0075) character,
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 "r" (U+0072) character,
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 "l" (U+006C) character,
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.
For the purposes of the previous paragraph, a refresh is
said to have come due as soon as the later of the
following two conditions occurs:
At least time seconds have elapsed
since the document has completely loaded,
adjusted to take into account user or user agent
preferences.
At least time seconds have elapsed
since the meta element was inserted into the
Document, adjusted to take into account
user or user agent preferences.
In addition, the user agent may, as with anything, inform the
user of any and all aspects of its operation, including the
state of any timers, the destinations of any timed redirects,
and so forth.
a valid non-negative integer, followed by a
";" (U+003B) character, followed by one or more space characters, followed by a
substring that is an ASCII case-insensitive match
for the string "URL", followed by a "=" (U+003D) character, followed by a valid URL
that does not start with a literal "'" (U+0027) or
""" (U+0022) character.
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:
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 may 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
reported 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.
The following restrictions apply to character encoding
declarations:
The character encoding name given must be the name of the
character encoding used to serialize the file.
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 are encouraged to 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 unlabelled content as another
user agent) might end up interpreting technically benign plain text
content as HTML tags and JavaScript. 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, because 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 style element allows authors to embed style
information in their documents. The style element is
one of several inputs to the styling processing
model. The element does not represent content for the user.
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 scoped
attribute is a boolean attribute. If present, it
indicates that the styles are intended just for the subtree rooted
at the style element's parent element, as opposed to
the whole Document.
If the scoped attribute is
present and the element has a parent element, then the
style element must be the first node of flow
content in its parent element other than inter-element
whitespace, and the parent element's content model must not
have a transparent component.
This implies that only one scoped style
element is allowed at a time, and that such elements cannot be
children of, e.g., a or ins elements, even
when those are used as flow content containers.
If the scoped attribute is
present, then the user agent must apply the specified style
information only to the style element's parent element
(if any), and that element's descendants. Otherwise, the specified
styles must, if applied, be applied to the entire document.
The following will eventually be moved to a CSS
specification; it is specified here only on an interim basis until
an editor can be found to own this.
Within scoped CSS resources, authors may use an @global @-rule. The syntax of this rule is defined
as follows.
The following production is added to the grammar:
global
: GLOBAL_SYM S* ruleset
;
The following rules are added to the Flex tokenizer:
B b|\\0{0,4}(42|62)(\r\n|[ \t\r\n\f])?
@{G}{L}{O}{B}{A}{L} {return GLOBAL_SYM;}
Simple selectors in rule sets prefixed by the @global @-rule in scoped CSS resources must be
processed in the same way as normal rule sets in non-scoped CSS
resources.
Simple selectors in scoped CSS resources that are not prefixed by
an @global @-rule must only match the
style element's parent element (if any), and that
element's descendants.
For scoped CSS resources, the effect of other @-rules must be
scoped to either the scoped sheet and its subresources or to the
subtree rooted at the style element's parent (if any),
even if the @-rule in question would ordinarily apply to all style
sheets that affect the Document, or to all nodes in the
Document. Any '@page' rules in scoped CSS resources
must be ignored.
For example, an '@font-face' rule defined in a
scoped style sheet would only define the font for the purposes of
elements in the scoped section; the font would not be used for
elements outside the subtree. However, rules outside the subtree
that refer to font names declared in '@font-face' rules in a scoped
section, when those rules are inherited by nodes in the scoped
section, would end up referring to the fonts declared in that
section.
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]
style = no-c-start *( c-start no-c-end c-end no-c-start )
no-c-start = <any string that doesn't contain a substring that matches c-start >
c-start = "<!--"
no-c-end = <any string that doesn't contain a substring that matches c-end >
c-end = "-->"
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.
<!DOCTYPE html>
<html lang="en-US">
<head>
<title>My favorite book</title>
<style>
body { color: black; background: white; }
em { font-style: normal; color: red; }
</style>
</head>
<body>
<p>My <em>favorite</em> book of all time has <em>got</em> to be
<cite>A Cat's Life</cite>. It is a book by P. Rahmel that talks
about the <i lang="la">Felis Catus</i> in modern human society.</p>
</body>
</html>
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]
The style sheet type must be the same as the style's specified
type. For style elements, this is the same as the
type content attribute's
value, or text/css if that is omitted. For
link elements, this is the Content-Type metadata of the specified
resource.
The style sheet location
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.
A style sheet in the context of the Document of an
HTML parser or XML parser is said to be
a style sheet that is blocking scripts if the element was
created by that Document's parser, and the element is
either a style element or a link element
that was an external resource link that
contributes to the styling processing model when the element
was created by the parser, and the element's style sheet was enabled
when the element was created by the parser, and the element's
style sheet ready flag is not yet set, and, the last
time the event loop reached step 1, the element was
in that Document,
and the user agent hasn't given up on that particular style sheet
yet. A user agent may give up on a style sheet at any time.
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.
Scripts allow authors to add interactivity to their documents.
Authors are encouraged to use declarative alternatives to
scripting where possible, as declarative mechanisms are often more
maintainable, and many users disable scripting.
For example, instead of using script to show or hide a section
to show more details, the details element could be
used.
Authors are also encouraged to make their applications degrade
gracefully in the absence of scripting support.
For example, if an author provides a link in a table header to
dynamically resort the table, the link could also be made to
function without scripts by requesting the sorted table from the
server.
The script element allows authors to include dynamic
script and data blocks in their documents. The element does not
represent content for the user.
When used to include dynamic scripts, the scripts may either be
embedded inline or may be imported from an external file using the
src attribute. If the language
is not that described by "text/javascript",
then the type attribute must
be present, as described below. Whatever language is used, the
contents of the script element must conform with the
requirements of that language's specification.
When used to include data blocks (as opposed to scripts), the
data must be embedded inline, the format of the data must be given
using the type attribute, the
src attribute must not be
specified, and the contents of the script element must
conform to the requirements defined for the format used.
The type
attribute gives the language of the script or format of the data. If
the attribute is present, its value must be a valid MIME
type. The charset parameter must not be
specified. The default, which is used if the attribute is absent,
is "text/javascript".
The src
attribute, if specified, gives the address of the external script
resource to use. The value of the attribute must be a valid
non-empty URL potentially surrounded by spaces identifying a
script resource of the type given by the type attribute, if the attribute is
present, or of the type "text/javascript", if
the attribute is absent. A resource is a script resource of a given
type if that type identifies a scripting language and the resource
conforms with the requirements of that language's specification.
The charset
attribute gives the character encoding of the external script
resource. The attribute must not be specified if the src attribute is not present. If the
attribute is set, its value must be a valid character encoding name,
must be an ASCII case-insensitive match for the
preferred MIME name for that encoding, and must match
the encoding given in the charset parameter of
the Content-Type metadata of the
external file, if any. [IANACHARSET]
The async and
defer attributes
are boolean attributes that
indicate how the script should be executed. The defer and async attributes must not be
specified if the src attribute
is not present.
There are three possible modes that can be selected using these
attributes. If the async
attribute is present, then the script will be executed
asynchronously, as soon as it is available. If the async attribute is not present but
the defer attribute is
present, then the script is executed when the page has finished
parsing. If neither attribute is present, then the script is
fetched and executed immediately, before the user agent continues
parsing the page.
The exact processing details for these attributes
are, for mostly historical reasons, somewhat non-trivial, involving
a number of aspects of HTML. The implementation requirements are
therefore by necessity scattered throughout the specification. The
algorithms below (in this section) describe the core of this
processing, but these algorithms reference and are referenced by the
parsing rules for scriptstart
and end tags in HTML, in foreign content, and in XML, the rules for the document.write() method, the
handling of scripting, etc.
The defer attribute may be
specified even if the async
attribute is specified, to cause legacy Web browsers that only
support defer (and not async) to fall back to the defer behavior instead of the
synchronous blocking behavior that is the default.
Changing the src, type, charset, async, and defer attributes dynamically has no
direct effect; these attribute are only used at specific times
described below.
A script element has several associated pieces of
state.
The first is a flag indicating whether or not the script block
has been "already started". Initially,
script elements must have this flag unset (script
blocks, when created, are not "already started"). The cloning steps for
script elements must set the "already started" flag on
the copy if it is set on the element being cloned.
The second is a flag indicating whether the element was
"parser-inserted". Initially, script
elements must have this flag unset. It is set by the HTML
parser and the XML parser on script
elements they insert and affects the processing of those
elements.
The third is a flag indicating whether the element will
"force-async". Initially, script elements
must have this flag set. It is unset by the HTML parser
and the XML parser on script elements they
insert. In addition, whenever a script element whose
"force-async" flag is set has a async content attribute added, the
element's "force-async" flag must be unset.
The fourth is a flag indicating whether or not the script block is
"ready to be parser-executed". Initially,
script elements must have this flag unset (script
blocks, when created, are not "ready to be parser-executed"). This
flag is used only for elements that are also
"parser-inserted", to let the parser know when to
execute the script.
The last few pieces of state are the script block's
type, the script block's character
encoding, and the script block's fallback
character encoding. They are determined when the script
is prepared, based on the attributes on the element at that time,
and the Document of the script
element.
When a script element that is not marked as being
"parser-inserted" experiences one of the events listed
in the following list, the user agent must synchronously prepare the script
element:
The script element is in a
Document and has a src attribute set where previously
the element had no such attribute.
To prepare a script, the user
agent must act as follows:
If the script element is marked as having
"already started", then the user agent must abort
these steps at this point. The script is not executed.
If the element has its "parser-inserted" flag set,
then set was-parser-inserted to true and unset
the element's "parser-inserted" flag. Otherwise, set
was-parser-inserted to false.
This is done so that if parser-inserted
script elements fail to run when the parser tries to
run them, e.g. because they are empty or specify an unsupported
scripting language, another script can later mutate them and cause
them to run again.
If was-parser-inserted is true and the
element does not have an async attribute, then set the
element's "force-async" flag to true.
This is done so that if a parser-inserted
script element fails to run when the parser tries to
run it, but it is later executed after a script dynamically
updates it, it will execute asynchronously even if the
async attribute isn't
set.
If the element has no src
attribute, and its child nodes, if any, consist only of comment
nodes and empty Text nodes, then the user agent must
abort these steps at this point. The script is not executed.
If the element is not in a Document,
then the user agent must abort these steps at this point. The
script is not executed.
If either:
the script element has a type attribute and its value is
the empty string, or
the script element has no type attribute but it has a language attribute and
that attribute's value is the empty string, or
the script element has neither a type attribute nor a language attribute, then
Otherwise, the element has a non-empty language attribute; let
the script block's type for this script
element be the concatenation of the string "text/" followed by the value of the language attribute.
The language attribute is never
conforming, and is always ignored if there is a type attribute present.
The state of the element at this moment is later used to
determine the script source.
If the element is flagged as "parser-inserted",
but the element's Document is not the
Document of the parser that created the element, then
abort these steps.
If scripting is
disabled for the script element, then the user
agent must abort these steps at this point. The script is not
executed.
The definition of scripting is disabled means
that, amongst others, the following scripts will not execute:
scripts in XMLHttpRequest's responseXML
documents, scripts in DOMParser-created documents,
scripts in documents created by XSLTProcessor's transformToDocument
feature, and scripts that are first inserted by a script into a
Document that was created using the createDocument()
API. [XHR][DOMPARSING][DOMCORE]
If the script element has an event attribute and a for attribute, then run these
substeps:
If for is not an ASCII
case-insensitive match for the string "window", then the user agent must abort these
steps at this point. The script is not executed.
If event is not an ASCII
case-insensitive match for either the string "onload" or the string "onload()", then the user agent must abort these
steps at this point. The script is not executed.
If the element has a src
attribute whose value is not the empty string, then the value of
that attribute must be resolved
relative to the element, and if that is successful, the specified
resource must then be fetched, from the
origin of the element's Document.
If the src attribute's
value is the empty string or if it could not be resolved, then the
user agent must queue a task to fire a simple
event named error at the
element, and abort these steps.
For historical reasons, if the URL is a javascript:
URL, then the user agent must not, despite the requirements
in the definition of the fetching
algorithm, actually execute the script in the URL; instead the
user agent must act as if it had received an empty HTTP 400
response.
For performance reasons, user agents may start fetching the
script as soon as the attribute is set, instead, in the hope that
the element will be inserted into the document. Either way, once
the element is inserted into the document, the load must have
started. If the UA performs such prefetching, but the element is
never inserted in the document, or the src attribute is dynamically
changed, then the
user agent will not execute the script, and the fetching process
will have been effectively wasted.
Then, the first of the following options that describes the
situation must be followed:
If the element has a src attribute, and the element has
a defer attribute, and the
element has been flagged as "parser-inserted", and
the element does not have an async attribute
The element must be added to the end of the list of
scripts that will execute when the document has finished
parsing associated with the Document of the
parser that created the element.
If the element has a src attribute, does not have an
async attribute, and does
not have the "force-async" flag set
The element must be added to the end of the list of
scripts that will execute in order as soon as possible
associated with the Document of the
script element at the time the prepare a
script algorithm started.
The element must be added to the set of scripts that
will execute as soon as possible of the
Document of the script element at the
time the prepare a script algorithm started.
The pending parsing-blocking script of a
Document is used by the Document's
parser(s).
If a script element that blocks a
parser gets moved to another Document before it would
normally have stopped blocking that parser, it nonetheless continues
blocking that parser until the condition that causes it to be
blocking the parser no longer applies (e.g. if the script is a
pending parsing-blocking script because there was
a style sheet that is blocking scripts when it was
parsed, but then the script is moved to another
Document before the style sheet loads, the script still
blocks the parser until the style sheets are all loaded, at which
time the script executes and the parser is unblocked).
When the user agent is required to execute a script block, it must run the following
steps:
If the element is flagged as "parser-inserted",
but the element's Document is not the
Document of the parser that created the element, then
abort these steps.
Jump to the appropriate set of steps from the list below:
If the load resulted in an error (for example a DNS error, or
an HTTP 404 error)
Executing the script block must just consist of firing a simple event named
error at the element.
If the load was successful
Executing the script block must consist of running the
following steps. For the purposes of these steps, the script is
considered to be from an external file if, while the
prepare a script algorithm above was running for
this script, the script element had a src attribute specified.
The contents of that file, interpreted as a Unicode
string, are the script source.
To obtain the Unicode string, the user agent run the
following steps:
If the resource's Content
Type metadata, if any, specifies a character
encoding, and the user agent supports that encoding, then
let character encoding be that
encoding, and jump to the bottom step in this series of
steps.
If the algorithm above set the script block's
character encoding, then let character
encoding be that encoding, and jump to the bottom
step in this series of steps.
For each of the rows in the following table,
starting with the first one and going down, if the file has
as many or more bytes available than the number of bytes in
the first column, and the first bytes of the file match the
bytes given in the first column, then set character encoding to the encoding given in
the cell in the second column of that row, and jump to the
bottom step in this series of steps:
Bytes in Hexadecimal
Encoding
FE FF
Big-endian UTF-16
FF FE
Little-endian UTF-16
EF BB BF
UTF-8
This step looks for Unicode Byte Order
Marks (BOMs).
The external file is the script source. When it is later
executed, it must be interpreted in a manner consistent with
the specification defining the language given by the
script block's type.
The IDL attributes src, type, charset, and defer, each must
reflect the respective content attributes of the same
name.
The async IDL
attribute controls whether the element will execute asynchronously
or not. If the element's "force-async" flag is set,
then, on getting, the async
IDL attribute must return true, and on setting, the
"force-async" flag must first be unset, and then the
content attribute must be removed if the IDL attribute's new value
is false, and must be set to the empty string if the IDL attribute's
new value is true. If the element's "force-async" flag
is not set, the IDL attribute must reflect the
async content attribute.
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 script 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.
When inserted using the document.write() method,
script elements execute (typically synchronously), but
when inserted using innerHTML and outerHTML attributes, they do not
execute at all.
In this example, two script elements are used. One
embeds an external script, and the other includes some data.
The data in this case might be used by the script to generate
the map of a video game. The data doesn't have to be used that way,
though; maybe the map data is actually embedded in other parts of
the page's markup, and the data block here is just used by the
site's search engine to help users who are looking for particular
features in their game maps.
The following sample shows how a script element can be used to
define a function that is then used by other parts of the
document. It also shows how a script element can be
used to invoke script while the document is being parsed, in this
case to initialize the form's output.
<script>
function calculate(form) {
var price = 52000;
if (form.elements.brakes.checked)
price += 1000;
if (form.elements.radio.checked)
price += 2500;
if (form.elements.turbo.checked)
price += 5000;
if (form.elements.sticker.checked)
price += 250;
form.elements.result.value = price;
}
</script>
<form name="pricecalc" onsubmit="return false" onchange="calculate(this)">
<fieldset>
<legend>Work out the price of your car</legend>
<p>Base cost: £52000.</p>
<p>Select additional options:</p>
<ul>
<li><label><input type=checkbox name=brakes> Ceramic brakes (£1000)</label></li>
<li><label><input type=checkbox name=radio> Satellite radio (£2500)</label></li>
<li><label><input type=checkbox name=turbo> Turbo charger (£5000)</label></li>
<li><label><input type=checkbox name=sticker> "XZ" sticker (£250)</label></li>
</ul>
<p>Total: £<output name=result></output></p>
</fieldset>
<script>
calculate(document.forms.pricecalc);
</script>
</form>
User agents may support other MIME
types and other languages.
The following MIME types must not
be interpreted as scripting languages:
"text/plain"
"text/xml"
"application/octet-stream"
"application/xml"
These types are explicitly listed here because they
are poorly-defined types that are nonetheless likely to be used as
formats for data blocks, and it would be problematic if they were
suddenly to be interpreted as script by a user agent.
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.
4.3.1.2 Restrictions for contents of script elements
The textContent of a script element
must match the script production in the
following ABNF, the character set for which is Unicode. [ABNF]
script = data1 *( escape [ script-start data3 ] "-->" data1 ) [ escape ]
escape = "<!--" data2 *( script-start data3 script-end data2 )
data1 = <any string that doesn't contain a substring that matches not-data1>
not-data1 = "<!--"
data2 = <any string that doesn't contain a substring that matches not-data2>
not-data2 = script-start / "-->"
data3 = <any string that doesn't contain a substring that matches not-data3>
not-data3 = script-end / "-->"
script-start = lt s c r i p t tag-end
script-end = lt slash s c r i p t tag-end
lt = %x003C ; U+003C LESS-THAN SIGN character (<)
slash = %x002F ; "/" (U+002F) character
s = %x0053 ; U+0053 LATIN CAPITAL LETTER S
s =/ %x0073 ; U+0073 LATIN SMALL LETTER S
c = %x0043 ; U+0043 LATIN CAPITAL LETTER C
c =/ %x0063 ; U+0063 LATIN SMALL LETTER C
r = %x0052 ; U+0052 LATIN CAPITAL LETTER R
r =/ %x0072 ; U+0072 LATIN SMALL LETTER R
i = %x0049 ; U+0049 LATIN CAPITAL LETTER I
i =/ %x0069 ; U+0069 LATIN SMALL LETTER I
p = %x0050 ; U+0050 LATIN CAPITAL LETTER P
p =/ %x0070 ; U+0070 LATIN SMALL LETTER P
t = %x0054 ; U+0054 LATIN CAPITAL LETTER T
t =/ %x0074 ; U+0074 LATIN SMALL LETTER T
tag-end = %x0009 ; "tab" (U+0009)
tag-end =/ %x000A ; "LF" (U+000A)
tag-end =/ %x000C ; "FF" (U+000C)
tag-end =/ %x0020 ; U+0020 SPACE
tag-end =/ %x002F ; "/" (U+002F)
tag-end =/ %x003E ; U+003E GREATER-THAN SIGN (>)
When a script element contains script
documentation, there are further restrictions on the contents
of the element, as described in the section below.
4.3.1.3 Inline documentation for external scripts
If a script element's src attribute is specified, then the
contents of the script element, if any, must be such
that the value of the text IDL
attribute, which is derived from the element's contents, matches the
documentation production in the following
ABNF, the character set for which is Unicode. [ABNF]
documentation = *( *( space / tab / comment ) [ line-comment ] newline )
comment = slash star *( not-star / star not-slash ) 1*star slash
line-comment = slash slash *not-newline
; characters
tab = %x0009 ; "tab" (U+0009)
newline = %x000A ; "LF" (U+000A)
space = %x0020 ; U+0020 SPACE
star = %x002A ; "*" (U+002A)
slash = %x002F ; "/" (U+002F)
not-newline = %x0000-0009 / %x000B-10FFFF
; a Unicode character other than "LF" (U+000A)
not-star = %x0000-0029 / %x002B-10FFFF
; a Unicode character other than "*" (U+002A)
not-slash = %x0000-002E / %x0030-10FFFF
; a Unicode character other than "/" (U+002F)
This corresponds to putting the contents of the
element in JavaScript comments.
This requirement is in addition to the earlier
restrictions on the syntax of contents of script
elements.
This allows authors to include documentation, such as license
information or API information, inside their documents while still
referring to external script files. The syntax is constrained so
that authors don't accidentally include what looks like valid
script while also providing a src attribute.
<script src="cool-effects.js">
// create new instances using:
// var e = new Effect();
// start the effect using .play, stop using .stop:
// e.play();
// e.stop();
</script>
This specification does not define how XSLT interacts with the
script element. However, in the absence of another
specification actually defining this, here are some guidelines for
implementors, based on existing implementations:
When an XSLT transformation program is triggered by an <?xml-stylesheet?> processing instruction and
the browser implements a direct-to-DOM transformation,
script elements created by the XSLT processor need to
be marked "parser-inserted" and run in document order
(modulo scripts marked defer
or async), asynchronously
while the transformation is occurring.
The XSLTProcessor.transformToFragment()
method needs to create a fragment that is equivalent to one built
manually by creating the elements using document.createElementNS().
For instance, it needs to create script elements that
aren't "parser-inserted" and that don't have their
"already started" flag set, so that they will execute
when the fragment is inserted into a document.
The main distinction between the first two cases and the last
case is that the first two operate on Documents and the
last operates on a fragment.
The noscript element represents nothing
if scripting is enabled, and
represents its children if scripting is disabled. It is used
to present different markup to user agents that support scripting
and those that don't support scripting, by affecting how the
document is parsed.
When used in HTML documents, the allowed content
model is as follows:
The noscript element must contain only text,
except that invoking the HTML fragment parsing
algorithm with
the noscript element as the context element and the
text contents as the input must result in a
list of nodes that consists only of link,
style, and meta elements that would be
conforming if they were children of the noscript
element, and no parse
errors.
The noscript element's content model is
transparent, with the additional restriction that a
noscript element must not have a noscript
element as an ancestor (that is, noscript can't be
nested).
The noscript element must contain only text,
except that the text must be such that running the following
algorithm results in a conforming document with no
noscript elements and no script
elements, and such that no step in the algorithm causes an
HTML parser to flag a parse error:
Make a list of every noscript element in the
document. For every noscript element in that list,
perform the following steps:
Let the parent element be the parent
element of the noscript element.
Take all the children of the parent element
that come before the noscript element, and call these
elements the before children.
Take all the children of the parent element
that come after the noscript element, and
call these elements the after children.
Let s be the concatenation of all the
Text node children of the noscript
element.
Set the innerHTML
attribute of the parent element to the value
of s. (This, as a side-effect, causes the
noscript element to be removed from the
document.)
Insert the before children at the start of
the parent element, preserving their original
relative order.
Insert the after children at the end of the
parent element, preserving their original
relative order.
All these contortions are required because, for
historical reasons, the noscript element is handled
differently by the HTML parser based on whether scripting was enabled or not when the
parser was invoked.
The noscript element is only effective
in the HTML syntax, it has no effect in the XHTML
syntax. This is because the way it works is by essentially
"turning off" the parser when scripts are enabled, so that the
contents of the element are treated as pure text and not as real
elements. XML does not define a mechanism by which to do this.
The noscript element has no other requirements. In
particular, children of the noscript element are not
exempt from form submission, scripting, and so forth,
even when scripting is enabled
for the element.
In the following example, a noscript element is
used to provide fallback for a script.
<form action="calcSquare.php">
<p>
<label for=x>Number</label>:
<input id="x" name="x" type="number">
</p>
<script>
var x = document.getElementById('x');
var output = document.createElement('p');
output.textContent = 'Type a number; it will be squared right then!';
x.form.appendChild(output);
x.form.onsubmit = function () { return false; }
x.oninput = function () {
var v = x.valueAsNumber;
output.textContent = v + ' squared is ' + v * v;
};
</script>
<noscript>
<input type=submit value="Calculate Square">
</noscript>
</form>
When script is disabled, a button appears to do the calculation
on the server side. When script is enabled, the value is computed
on-the-fly instead.
The noscript element is a blunt
instrument. Sometimes, scripts might be enabled, but for some
reason the page's script might fail. For this reason, it's
generally better to avoid using noscript, and to
instead design the script to change the page from being a
scriptless page to a scripted page on the fly, as in the next
example:
<form action="calcSquare.php">
<p>
<label for=x>Number</label>:
<input id="x" name="x" type="number">
</p>
<input id="submit" type=submit value="Calculate Square">
<script>
var x = document.getElementById('x');
var output = document.createElement('p');
output.textContent = 'Type a number; it will be squared right then!';
x.form.appendChild(output);
x.form.onsubmit = function () { return false; }
x.oninput = function () {
var v = x.valueAsNumber;
output.textContent = v + ' squared is ' + v * v;
};
var submit = document.getElementById('submit');
submit.parentNode.removeChild(submit);
</script>
</form>
The above technique is also useful in XHTML, since
noscript is not supported in the XHTML
syntax.
The body element represents the main
content of the document.
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
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]
This example shows a blog post using the article
element:
<article>
<header>
<h1>The Very First Rule of Life</h1>
<p><time datetime="2009-10-09">3 days ago</time></p>
</header>
<p>If there's a microphone anywhere near you, assume it's hot and
sending whatever you're saying to the world. Seriously.</p>
<p>...</p>
<footer>
<a href="?comments=1">Show comments...</a>
</footer>
</article>
Here is that same blog post, but showing some of the comments:
<article>
<header>
<h1>The Very First Rule of Life</h1>
<p><time datetime="2009-10-09">3 days ago</time></p>
</header>
<p>If there's a microphone anywhere near you, assume it's hot and
sending whatever you're saying to the world. Seriously.</p>
<p>...</p>
<section>
<h1>Comments</h1>
<article id="c1">
<footer>
<p>Posted by: George Washington</p>
<p><time datetime="2009-10-10">15 minutes ago</time></p>
</footer>
<p>Yeah! Especially when talking about your lobbyist friends!</p>
</article>
<article id="c2">
<footer>
<p>Posted by: George Hammond</p>
<p><time datetime="2009-10-10">5 minutes ago</time></p>
</footer>
<p>Hey, you have the same first name as me.</p>
</article>
</section>
</article>
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, typically with a
heading.
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>
<hgroup>
<h1>Apples</h1>
<h2>Tasty, delicious fruit!</h2>
</hgroup>
<p>The apple is the pomaceous fruit of the apple tree.</p>
<section>
<h1>Red Delicious</h1>
<p>These bright red apples are the most common found in many
supermarkets.</p>
</section>
<section>
<h1>Granny Smith</h1>
<p>These juicy, green apples make a great filling for
apple pies.</p>
</section>
</article>
Notice how the use of section means that the author
can use h1 elements throughout, without having to
worry about whether a particular section is at the top level, the
second level, the third level, and so on.
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 minimise 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.
<article class="book">
<style>
section { border: double medium; margin: 2em; }
section.chapter h1 { font: 2em Roboto, Helvetica Neue, sans-serif; }
section.appendix h1 { font: small-caps 2em Roboto, Helvetica Neue, sans-serif; }
</style>
<header>
<hgroup>
<h1>My Book</h1>
<h2>A sample with not much content</h2>
</hgroup>
<p><small>Published by Dummy Publicorp Ltd.</small></p>
</header>
<section class="chapter">
<h1>My First Chapter</h1>
<p>This is the first of my chapters. It doesn't say much.</p>
<p>But it has two paragraphs!</p>
</section>
<section class="chapter">
<h1>It Continutes: The Second Chapter</h1>
<p>Bla dee bla, dee bla dee bla. Boom.</p>
</section>
<section class="chapter">
<h1>Chapter Three: A Further Example</h1>
<p>It's not like a battle between brightness and earthtones would go
unnoticed.</p>
<p>But it might ruin my story.</p>
</section>
<section class="appendix">
<h1>Appendix A: Overview of Examples</h1>
<p>These are demonstrations.</p>
</section>
<section class="appendix">
<h1>Appendix B: Some Closing Remarks</h1>
<p>Hopefully this long example shows that you <em>can</em> style
sections, so long as they are used to indicate actual sections.</p>
</section>
</article>
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.
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 and/or
provide on request.
In the following example, the page has several places where
links are present, but only one of those places is considered a
navigation section.
Notice the div elements being used to wrap all the
contents of the page other than the header and footer, and all the
contents of the blog entry other than its header and footer.
In the following example, there are two nav
elements, one for primary navigation around the site, and one for
secondary navigation around the page itself.
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>
