This document is a strict subset of
the
full HTML5 specification
that omits user-agent (UA) implementation details. It is
targeted toward Web authors and others who are not UA
implementors and who want a view of the HTML
specification that focuses more precisely on details relevant to
using the HTML language to create Web documents and Web applications.
Because this document does not provide implementation conformance
criteria, UA implementors should not rely on it, but should instead
refer to the
full HTML5 specification.
This document is an automated redaction of the
full HTML5 specification.
As such, the two documents are supposed to agree on normative matters
concerning Web authors. However, if the documents disagree, this is a
bug in the redaction process and the unredacted full HTML
specification takes precedence. Readers are encouraged to report such
discrepancies as bugs in the bug tracking system of the HTML Working
Group.
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.
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 7389 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.
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.
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.
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.
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 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 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.
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.
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]
2.2.1
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.
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.)
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.
A string pattern is a prefix match for a string s when pattern is not longer than
s and truncating s to
pattern's length leaves the two strings as
matches of each other.
2.4 Common
microsyntaxes
There are various places in HTML that accept particular data
types, such as dates or numbers. This section describes what the
conformance criteria for content in those formats is, and how to
parse them.
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.
2.4.1
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.4.3 Numbers
2.4.3.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.
2.4.3.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.
2.4.3.3
Floating-point numbers
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.
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.
2.4.4 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.
2.4.4.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
2.4.4.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:
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.
2.4.4.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.
2.4.4.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)
2.4.4.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.
2.4.4.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
2.4.4.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
2.4.4.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:
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 "http://dev.w3.org/html5/spec/single-page.html#"
(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.
2.4.6
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.
2.4.7
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.
2.4.8
References
A valid hash-name
reference to an element of type type is a
string consisting of a
"http://dev.w3.org/html5/spec/single-page.html#" (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.
2.4.9 Media queries
A string is a valid media
query if it matches the media_query_list production of the Media Queries
specification. [MQ]
A string matches the
environment of the user if it is the empty string, a string
consisting of only space characters,
or is a media query that matches the user's environment according
to the definitions given in the Media Queries specification.
[MQ]
2.5 URLs
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.5.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]
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.5.3 Resolving
URLs
Resolving a URL is the process of taking a relative URL and
obtaining the absolute URL that it implies.
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.5.4 Interfaces for URL manipulation
An interface that has a complement of URL decomposition IDL
attributes has seven attributes with the following
definitions:
A CORS settings
attribute is an enumerated attribute. The following
table lists the keywords and states for the attribute — the
keywords in the left column map to the states in the cell in the
second column on the same row as the keyword.
The empty string is also a valid keyword, and maps to the
Anonymous state. The attribute's
invalid value default is the Anonymous state. The missing
value default, used when the attribute is omitted, is the
No
CORS state.
2.6
Common DOM interfaces
2.6.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.
Returns the item with ID or namename from the
collection.
If there are multiple matching items, then a RadioNodeList object containing all
those elements is returned.
radioNodeList . value [
= value ]
Returns the value of the first checked radio button represented
by the object.
Can be set, to check the first radio button with the given value
represented by the object.
2.6.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.
Returns the index of the first selected item, if any, or −1 if
there is no selected item.
Can be set, to change the selection.
2.6.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.
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.6.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.
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.
2.7 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.
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.
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.
Returns "loading" while the Document is loading, "interactive" once it is finished parsing but still
loading sub-resources, and "complete" once it
has loaded.
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.
Returns a NodeList
of elements in the Document that have a name attribute with the value name.
The dir
attribute on the Document interface is defined along with
the dir content attribute.
3.2 Elements
3.2.1
Semantics
Elements, attributes, and attribute values in HTML are defined
(by this specification) to have certain meanings (semantics). For
example, the ol element represents an ordered list, and the
lang attribute represents the language of the
content.
These definitions allow HTML processors, such as Web browsers or
search engines, to present and use documents and applications in a
wide variety of contexts that the author might not have
considered.
As a simple example, consider a Web page written by an author
who only considered desktop computer Web browsers. 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
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 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, 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.
3.2.3
Global attributes
The following attributes are common to and may be specified on
all HTML elements :
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.
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 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.
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.
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.
Can be set, to either "ltr", "rtl", or "auto" to replace the html element's
dir attribute's value.
If there is no html
element, returns the empty string and ignores new values.
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.
Assigning classes to an element affects class
matching in selectors in CSS, the getElementsByClassName()
method in the DOM, and other such features.
There are no additional restrictions on the tokens authors can
use in the class attribute, but authors are encouraged to
use values that describe the nature of the content, rather than
values that describe the desired presentation of the content.
3.2.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]
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.)
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 attributes 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.
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.
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 . 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: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.
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>
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]
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.
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.
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.)
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
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.3.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.
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.
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.
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.
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).
<!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".
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).
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.
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.
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.
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.
4.2.5.1
Standard metadata names
This specification defines a few names for the name attribute of the meta
element.
Names are case-insensitive.
application-name
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.
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.
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.
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.
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.
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 an 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]
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]
The media attribute says which
media the styles apply to. The value must be a valid media query.
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.
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 = "-->"
This specification does not specify a style system,
but CSS is expected to be supported by most Web browsers. [CSS]
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]
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.
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.
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>
4.3.1.1
Scripting languages
The following lists some MIME type strings and the languages to which they
refer:
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>
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.
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.
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.
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>
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 aside element represents
a section of a page that consists of content that is tangentially
related to the content around the aside element, and which could be
considered separate from that content. Such sections are often
represented as sidebars in printed typography.
The element can be used for typographical effects like pull
quotes or sidebars, for advertising, for groups of nav elements, and for other content that is
considered separate from the main content of the page.
It's not appropriate to use the aside element just for parentheticals,
since those are part of the main flow of the document.
The following example shows how an aside is used to mark up
background material on Switzerland in a much longer news story on
Europe.
<aside>
<h1>Switzerland</h1>
<p>Switzerland, a land-locked country in the middle of geographic
Europe, has not joined the geopolitical European Union, though it is
a signatory to a number of European treaties.</p>
</aside>
The following example shows how an aside is used to mark up a
pull quote in a longer article.
...
<p>He later joined a large company, continuing on the same work.
<q>I love my job. People ask me what I do for fun when I'm not at
work. But I'm paid to do my hobby, so I never know what to
answer. Some people wonder what they would do if they didn't have to
work... but I know what I would do, because I was unemployed for a
year, and I filled that time doing exactly what I do now.</q></p>
<aside>
<q> People ask me what I do for fun when I'm not at work. But I'm
paid to do my hobby, so I never know what to answer. </q>
</aside>
<p>Of course his work — or should that be hobby? —
isn't his only passion. He also enjoys other pleasures.</p>
...
The following extract shows how aside can be used for blogrolls and other
side content on a blog:
<body>
<header>
<h1>My wonderful blog</h1>
<p>My tagline</p>
</header>
<aside>
<!-- this aside contains two sections that are tangentially related
to the page, namely, links to other blogs, and links to blog posts
from this blog -->
<nav>
<h1>My blogroll</h1>
<ul>
<li><a href="http://blog.example.com/">Example Blog</a>
</ul>
</nav>
<nav>
<h1>Archives</h1>
<ol reversed>
<li><a href="/last-post">My last post</a>
<li><a href="/first-post">My first post</a>
</ol>
</nav>
</aside>
<aside>
<!-- this aside is tangentially related to the page also, it
contains twitter messages from the blog author -->
<h1>Twitter Feed</h1>
<blockquote cite="http://twitter.example.net/t31351234">
I'm on vacation, writing my blog.
</blockquote>
<blockquote cite="http://twitter.example.net/t31219752">
I'm going to go on vacation soon.
</blockquote>
</aside>
<article>
<!-- this is a blog post -->
<h1>My last post</h1>
<p>This is my last post.</p>
<footer>
<p><a href="/last-post" rel=bookmark>Permalink</a>
</footer>
</article>
<article>
<!-- this is also a blog post -->
<h1>My first post</h1>
<p>This is my first post.</p>
<aside>
<!-- this aside is about the blog post, since it's inside the
<article> element; it would be wrong, for instance, to put the
blogroll here, since the blogroll isn't really related to this post
specifically, only to the page as a whole -->
<h1>Posting</h1>
<p>While I'm thinking about it, I wanted to say something about
posting. Posting is fun!</p>
</aside>
<footer>
<p><a href="/first-post" rel=bookmark>Permalink</a>
</footer>
</article>
<footer>
<nav>
<a href="/archives">Archives</a> —
<a href="/about">About me</a> —
<a href="/copyright">Copyright</a>
</nav>
</footer>
</body>
These elements represent headings for their sections.
The semantics and meaning of these elements are defined in the
section on headings and sections.
These elements have a rank given by the
number in their name. The
h1 element is said to have the highest rank, the
h6 element has the lowest rank, and two elements with
the same name have equal rank.
As far as their respective document outlines (their heading and
section structures) are concerned, these two snippets are
semantically equivalent:
<body>
<h1>Let's call it a draw(ing surface)</h1>
<h2>Diving in</h2>
<h2>Simple shapes</h2>
<h2>Canvas coordinates</h2>
<h3>Canvas coordinates diagram</h3>
<h2>Paths</h2>
</body>
Authors might prefer the former style for its terseness, or the
latter style for its convenience in the face of heavy editing;
which is best is purely an issue of preferred authoring style.
The hgroup element represents
the heading of a section. The element is used to group a set of
h1–h6
elements when the heading has multiple levels, such as subheadings,
alternative titles, or taglines.
Other elements of heading content in the hgroup element indicate subheadings or
subtitles.
The rank of an hgroup element is the rank of the
highest-ranked
h1–h6
element descendant of the hgroup element, if there are any such
elements, or otherwise the same as for an
h1 element (the highest rank).
<hgroup>
<h1>The reality dysfunction</h1>
<h2>Space is not the only void</h2>
</hgroup>
<hgroup>
<h1>Dr. Strangelove</h1>
<h2>Or: How I Learned to Stop Worrying and Love the Bomb</h2>
</hgroup>
The point of using hgroup in these examples is to mask the
h2 element (which acts as a secondary title) from the
outline algorithm.
How a user agent exposes such multi-level headings in user
interfaces (e.g. in tables of contents or search results) is left
open to implementors, as it is a user interface issue. The first
example above could be rendered as:
The reality dysfunction: Space is not the only void
Alternatively, it could look like this:
The reality dysfunction (Space is not the only void)
In interfaces where a title can be rendered on multiple lines,
it could be rendered as follows, maybe with the first line in a
bigger font size:
The reality dysfunction
Space is not the only void
The header element represents
a group of introductory or navigational aids.
A header element is intended to usually
contain the section's heading (an
h1–h6
element or an hgroup element), but this is not
required. The header element can also be used to wrap a
section's table of contents, a search form, or any relevant
logos.
Here are some sample headers. This first one is for a game:
In this example, the page has a page heading given by the
h1 element, and two subsections whose headings are given
by
h2 elements. The content after the header element is still part of the last
subsection started in the header element, because the
header element doesn't take part in the
outline algorithm.
<body>
<header>
<h1>Little Green Guys With Guns</h1>
<nav>
<ul>
<li><a href="/games">Games</a>
<li><a href="/forum">Forum</a>
<li><a href="/download">Download</a>
</ul>
</nav>
<h2>Important News</h2> <!-- this starts a second subsection -->
<!-- this is part of the subsection entitled "Important News" -->
<p>To play today's games you will need to update your client.</p>
<h2>Games</h2> <!-- this starts a third subsection -->
</header>
<p>You have three active games:</p>
<!-- this is still part of the subsection entitled "Games" -->
...
The footer element represents
a footer for its nearest ancestor sectioning content or sectioning root element. A footer typically
contains information about its section such as who wrote it, links
to related documents, copyright data, and the like.
When the footer element contains entire sections,
they represent appendices, indexes, long colophons,
verbose license agreements, and other such content.
Contact information for the author or editor of a
section belongs in an address element, possibly itself inside a
footer. Bylines and other information
that could be suitable for both a header or a footer can be placed in either (or
neither). The primary purpose of these elements is merely to help
the author write self-explanatory markup that is easy to maintain
and style; they are not intended to impose specific structures on
authors.
Footers don't necessarily have to appear at the end of
a section, though they usually do.
Here is a page with two footers, one at the top and one at the
bottom, with the same content:
<body>
<footer><a href="../">Back to index...</a></footer>
<hgroup>
<h1>Lorem ipsum</h1>
<h2>The ipsum of all lorems</h2>
</hgroup>
<p>A dolor sit amet, consectetur adipisicing elit, sed do eiusmod
tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim
veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex
ea commodo consequat. Duis aute irure dolor in reprehenderit in
voluptate velit esse cillum dolore eu fugiat nulla
pariatur. Excepteur sint occaecat cupidatat non proident, sunt in
culpa qui officia deserunt mollit anim id est laborum.</p>
<footer><a href="../">Back to index...</a></footer>
</body>
Here is an example which shows the footer element being used both for a
site-wide footer and for a section footer.
Some site designs have what is sometimes referred to as "fat
footers" — footers that contain a lot of material, including
images, links to other articles, links to pages for sending
feedback, special offers... in some ways, a whole "front page" in
the footer.
This fragment shows the bottom of a page on a site with a "fat
footer":
The address element represents
the contact information for its nearest article or body element ancestor. If that is the body element, then the contact
information applies to the document as a whole.
For example, a page at the W3C Web site related to HTML might
include the following contact information:
<ADDRESS>
<A href="../People/Raggett/">Dave Raggett</A>,
<A href="../People/Arnaud/">Arnaud Le Hors</A>,
contact persons for the <A href="Activity">W3C HTML Activity</A>
</ADDRESS>
The address element must not be used to
represent arbitrary addresses (e.g. postal addresses), unless those
addresses are in fact the relevant contact information. (The
p element is the appropriate element for marking
up postal addresses in general.)
The address element must not contain
information other than contact information.
For example, the following is non-conforming use of the
address element:
The
h1–h6
elements and the hgroup element are headings.
The first element of heading content in an element of
sectioning contentrepresents
the heading for that section. Subsequent headings of equal or
higher rank start new (implied) sections, headings of
lower rank start implied subsections that are part of the
previous one. In both cases, the element represents
the heading of the implied section.
Certain elements are said to be sectioning roots, including blockquote and td elements. These elements can have their own
outlines, but the sections and headings inside these elements do
not contribute to the outlines of their ancestors.
Sectioning content elements are
always considered subsections of their nearest ancestor sectioning root or their nearest ancestor
element of sectioning content, whichever is
nearest, regardless of what implied sections other headings may
have created.
Notice how the section ends the earlier implicit
section so that a later paragraph ("Grunt") is back at the top
level.
Sections may contain headings of any rank, but authors are strongly encouraged to either
use only
h1 elements, or to use elements of the appropriate
rank for the section's nesting level.
Authors are also encouraged to explicitly wrap sections in
elements of sectioning content, instead of
relying on the implicit sections generated by having multiple
headings in one element of sectioning content.
For example, the following is correct:
<body>
<h4>Apples</h4>
<p>Apples are fruit.</p>
<section>
<h2>Taste</h2>
<p>They taste lovely.</p>
<h6>Sweet</h6>
<p>Red apples are sweeter than green ones.</p>
<h1>Color</h1>
<p>Apples come in various colors.</p>
</section>
</body>
However, the same document would be more clearly expressed
as:
<body>
<h1>Apples</h1>
<p>Apples are fruit.</p>
<section>
<h2>Taste</h2>
<p>They taste lovely.</p>
<section>
<h3>Sweet</h3>
<p>Red apples are sweeter than green ones.</p>
</section>
</section>
<section>
<h2>Color</h2>
<p>Apples come in various colors.</p>
</section>
</body>
Both of the documents above are semantically identical and would
produce the same outline in compliant user agents.
This third example is also semantically identical, and might be
easier to maintain (e.g. if sections are often moved around in
editing):
<body>
<h1>Apples</h1>
<p>Apples are fruit.</p>
<section>
<h1>Taste</h1>
<p>They taste lovely.</p>
<section>
<h1>Sweet</h1>
<p>Red apples are sweeter than green ones.</p>
</section>
</section>
<section>
<h1>Color</h1>
<p>Apples come in various colors.</p>
</section>
</body>
This final example would need explicit style rules to be
rendered well in legacy browsers. Legacy browsers without CSS
support would render all the headings as top-level headings.
4.4.11.1 Creating an
outline
The outline for a sectioning content element or a
sectioning root element consists of a list
of one or more potentially nested sections. A
section is
a container that corresponds to some nodes in the original DOM
tree. Each section can have one heading associated with it, and can
contain any number of further nested sections. (The sections in the
outline aren't section elements, though some may
correspond to such elements — they are merely conceptual
sections.)
While paragraphs are usually represented in visual
media by blocks of text that are physically separated from adjacent
blocks through blank lines, a style sheet or user agent would be
equally justified in presenting paragraph breaks in a different
manner, for instance using inline pilcrows (¶).
The following examples are conforming HTML fragments:
<p>The little kitten gently seated himself on a piece of
carpet. Later in his life, this would be referred to as the time the
cat sat on the mat.</p>
<fieldset>
<legend>Personal information</legend>
<p>
<label>Name: <input name="n"></label>
<label><input name="anon" type="checkbox"> Hide from other users</label>
</p>
<p><label>Address: <textarea name="a"></textarea></label></p>
</fieldset>
<p>There was once an example from Femley,<br>
Whose markup was of dubious quality.<br>
The validator complained,<br>
So the author was pained,<br>
To move the error from the markup to the rhyming.</p>
The p element should not be used when a more specific
element is more appropriate.
List elements (in particular, ol and ul elements) cannot be children of p elements. When a sentence contains a bulleted
list, therefore, one might wonder how it should be marked up.
For instance, this fantastic sentence has bullets relating
to
wizards,
faster-than-light travel, and
telepathy,
and is further discussed below.
The solution is to realise that a paragraph, in HTML terms, is not a logical
concept, but a structural one. In the fantastic example above,
there are actually fiveparagraphs as defined by this
speciication: one before the list, one for each bullet, and one
after the list.
The markup for the above example could therefore be:
<p>For instance, this fantastic sentence has bullets relating to</p>
<ul>
<li>wizards,
<li>faster-than-light travel, and
<li>telepathy,
</ul>
<p>and is further discussed below.</p>
Authors wishing to conveniently style such "logical" paragraphs
consisting of multiple "structural" paragraphs can use the
div element instead of the p element.
Thus for instance the above example could become the
following:
<div>For instance, this fantastic sentence has bullets relating to
<ul>
<li>wizards,
<li>faster-than-light travel, and
<li>telepathy,
</ul>
and is further discussed below.</div>
This example still has five structural paragraphs, but now the
author can style just the div instead of having to consider each part of
the example separately.
The hr element represents
a paragraph-level thematic break, e.g. a scene
change in a story, or a transition to another topic within a
section of a reference book.
The following fictional extract from a project manual shows two
sections that use the hr element to separate topics within the
section.
<section>
<h1>Communication</h1>
<p>There are various methods of communication. This section
covers a few of the important ones used by the project.</p>
<hr>
<p>Communication stones seem to come in pairs and have mysterious
properties:</p>
<ul>
<li>They can transfer thoughts in two directions once activated
if used alone.</li>
<li>If used with another device, they can transfer one's
consciousness to another body.</li>
<li>If both stones are used with another device, the
consciousnesses switch bodies.</li>
</ul>
<hr>
<p>Radios use the electromagnetic spectrum in the meter range and
longer.</p>
<hr>
<p>Signal flares use the electromagnetic spectrum in the
nanometer range.</p>
</section>
<section>
<h1>Food</h1>
<p>All food at the project is rationed:</p>
<dl>
<dt>Potatoes</dt>
<dd>Two per day</dd>
<dt>Soup</dt>
<dd>One bowl per day</dd>
</dl>
<hr>
<p>Cooking is done by the chefs on a set rotation.</p>
</section>
There is no need for an hr element between the sections themselves,
since the section elements and the
h1 elements imply thematic changes themselves.
The following extract from Pandora's Star by Peter
F. Hamilton shows two paragraphs that precede a scene change and
the paragraph that follows it. The scene change, represented in the
printed book by a gap containing a solitary centered star between
the second and third paragraphs, is here represented using the
hr element.
<p>Dudley was ninety-two, in his second life, and fast approaching
time for another rejuvenation. Despite his body having the physical
age of a standard fifty-year-old, the prospect of a long degrading
campaign within academia was one he regarded with dread. For a
supposedly advanced civilization, the Intersolar Commonwealth could be
appallingly backward at times, not to mention cruel.</p>
<p><i>Maybe it won't be that bad</i>, he told himself. The lie was
comforting enough to get him through the rest of the night's
shift.</p>
<hr>
<p>The Carlton AllLander drove Dudley home just after dawn. Like the
astronomer, the vehicle was old and worn, but perfectly capable of
doing its job. It had a cheap diesel engine, common enough on a
semi-frontier world like Gralmond, although its drive array was a
thoroughly modern photoneural processor. With its high suspension and
deep-tread tyres it could plough along the dirt track to the
observatory in all weather and seasons, including the metre-deep snow
of Gralmond's winters.</p>
The hr element does not affect the document's
outline.
The pre element represents
a block of preformatted text, in which structure is represented by
typographic conventions rather than by elements.
In the HTML syntax, a leading newline
character immediately following the pre element start tag is stripped.
Some examples of cases where the pre element could be used:
Including an e-mail, with paragraphs indicated by blank lines,
lists indicated by lines prefixed with a bullet, and so on.
Including fragments of computer code, with structure indicated
according to the conventions of that language.
Displaying ASCII art.
Authors are encouraged to consider how preformatted
text will be experienced when the formatting is lost, as will be
the case for users of speech synthesizers, braille displays, and
the like. For cases like ASCII art, it is likely that an
alternative presentation, such as a textual description, would be
more universally accessible to the readers of the document.
To represent a block of computer code, the pre element can be used with a code element; to represent a block of
computer output the pre element can be used with a samp element. Similarly, the kbd element can be used within a pre element to indicate text that the user is to
enter.
In the following snippet, a sample of computer code is
presented.
<p>This is the <code>Panel</code> constructor:</p>
<pre><code>function Panel(element, canClose, closeHandler) {
this.element = element;
this.canClose = canClose;
this.closeHandler = function () { if (closeHandler) closeHandler() };
}</code></pre>
In the following snippet, samp and kbd elements are mixed in the contents of a
pre element to show a session of Zork I.
<pre><samp>You are in an open field west of a big white house with a boarded
front door.
There is a small mailbox here.
></samp> <kbd>open mailbox</kbd>
<samp>Opening the mailbox reveals:
A leaflet.
></samp></pre>
The following shows a contemporary poem that uses the
pre element to preserve its unusual formatting,
which forms an intrinsic part of the poem itself.
<pre> maxling
it is with a heart
heavy
that i admit loss of a feline
so loved
a friend lost to the
unknown
(night)
~cdr 11dec07</pre>
The content of a blockquote may be abbreviated or may
have context added in the conventional manner for the text's
language.
For example, in English this is traditionally done using square
brackets. Consider a page with the sentence "Fred ate the cracker.
He then said he liked apples and fish."; it could be quoted as
follows:
<blockquote>
<p>[Fred] then said he liked [...] fish.</p>
</blockquote>
Attribution for the quotation, if any, must be placed outside
the blockquote element.
For example, here the attribution is given in a paragraph after
the quote:
<blockquote>
<p>I contend that we are both atheists. I just believe in one fewer
god than you do. When you understand why you dismiss all the other
possible gods, you will understand why I dismiss yours.</p>
</blockquote>
<p>— Stephen Roberts</p>
The other examples below show other ways of showing
attribution.
Here a blockquote element is used in
conjunction with a figure element and its figcaption to clearly relate a quote
to its attribution (which is not part of the quote and therefore
doesn't belong inside the blockquote itself):
<figure>
<blockquote>
<p>The truth may be puzzling. It may take some work to grapple with.
It may be counterintuitive. It may contradict deeply held
prejudices. It may not be consonant with what we desperately want to
be true. But our preferences do not determine what's true. We have a
method, and that method helps us to reach not absolute truth, only
asymptotic approaches to the truth — never there, just closer
and closer, always finding vast new oceans of undiscovered
possibilities. Cleverly designed experiments are the key.</p>
</blockquote>
<figcaption>Carl Sagan, in "<cite>Wonder and Skepticism</cite>", from
the <cite>Skeptical Enquirer</cite> Volume 19, Issue 1 (January-February
1995)</figcaption>
</figure>
This next example shows the use of cite alongside blockquote:
<p>His next piece was the aptly named <cite>Sonnet 130</cite>:</p>
<blockquote cite="http://quotes.example.org/s/sonnet130.html">
<p>My mistress' eyes are nothing like the sun,<br>
Coral is far more red, than her lips red,<br>
...
This example shows how a forum post could use blockquote to show what post a user
is replying to. The article element is used for each post,
to mark up the threading.
<article>
<h1><a href="http://bacon.example.com/?blog=109431">Bacon on a crowbar</a></h1>
<article>
<header><strong>t3yw</strong> 12 points 1 hour ago</header>
<p>I bet a narwhal would love that.</p>
<footer><a href="?pid=29578">permalink</a></footer>
<article>
<header><strong>greg</strong> 8 points 1 hour ago</header>
<blockquote><p>I bet a narwhal would love that.</p></blockquote>
<p>Dude narwhals don't eat bacon.</p>
<footer><a href="?pid=29579">permalink</a></footer>
<article>
<header><strong>t3yw</strong> 15 points 1 hour ago</header>
<blockquote>
<blockquote><p>I bet a narwhal would love that.</p></blockquote>
<p>Dude narwhals don't eat bacon.</p>
</blockquote>
<p>Next thing you'll be saying they don't get capes and wizard
hats either!</p>
<footer><a href="?pid=29580">permalink</a></footer>
<article>
<article>
<header><strong>boing</strong> -5 points 1 hour ago</header>
<p>narwhals are worse than ceiling cat</p>
<footer><a href="?pid=29581">permalink</a></footer>
</article>
</article>
</article>
</article>
<article>
<header><strong>fred</strong> 1 points 23 minutes ago</header>
<blockquote><p>I bet a narwhal would love that.</p></blockquote>
<p>I bet they'd love to peel a banana too.</p>
<footer><a href="?pid=29582">permalink</a></footer>
</article>
</article>
</article>
This example shows the use of a blockquote for short snippets,
demonstrating that one does not have to use p elements inside blockquote elements:
<p>He began his list of "lessons" with the following:</p>
<blockquote>One should never assume that his side of
the issue will be recognized, let alone that it will
be conceded to have merits.</blockquote>
<p>He continued with a number of similar points, ending with:</p>
<blockquote>Finally, one should be prepared for the threat
of breakdown in negotiations at any given moment and not
be cowed by the possiblity.</blockquote>
<p>We shall now discuss these points...
The ol element represents
a list of items, where the items have been intentionally ordered,
such that changing the order would change the meaning of the
document.
The items of the list are the li element child nodes of the ol element, in tree order.
The reversed attribute is a
boolean attribute. If present, it
indicates that the list is a descending list (..., 3, 2, 1). If the
attribute is omitted, the list is an ascending list (1, 2, 3,
...).
The start attribute, if present,
must be a valid integer giving the ordinal value of the first list item.
The type attribute can be used to
specify the kind of marker to use in the list, in the cases where
that matters (e.g. because items are to be referenced by their
number/letter). The attribute, if specified, must have a value that
is a case-sensitive match for one of the
characters given in the first cell of one of the rows of the
following table.
The following markup shows a list where the order matters, and
where the ol element is therefore appropriate. Compare this
list to the equivalent list in the ul section to see an example of the same items
using the ul element.
<p>I have lived in the following countries (given in the order of when
I first lived there):</p>
<ol>
<li>Switzerland
<li>United Kingdom
<li>United States
<li>Norway
</ol>
Note how changing the order of the list changes the meaning of
the document. In the following example, changing the relative order
of the first two items has changed the birthplace of the
author:
<p>I have lived in the following countries (given in the order of when
I first lived there):</p>
<ol>
<li>United Kingdom
<li>Switzerland
<li>United States
<li>Norway
</ol>
The ul element represents
a list of items, where the order of the items is not important —
that is, where changing the order would not materially change the
meaning of the document.
The items of the list are the li element child nodes of the ul element.
The following markup shows a list where the order does not
matter, and where the ul element is therefore appropriate. Compare
this list to the equivalent list in the ol section to see an example of the same items
using the ol element.
<p>I have lived in the following countries:</p>
<ul>
<li>Norway
<li>Switzerland
<li>United Kingdom
<li>United States
</ul>
Note that changing the order of the list does not change the
meaning of the document. The items in the snippet above are given
in alphabetical order, but in the snippet below they are given in
order of the size of their current account balance in 2007, without
changing the meaning of the document whatsoever:
<p>I have lived in the following countries:</p>
<ul>
<li>Switzerland
<li>Norway
<li>United Kingdom
<li>United States
</ul>
interface HTMLLIElement : HTMLElement {
attribute long value;
};
The li element represents
a list item. If its parent element is an ol, ul, or menu
element, then the element is an item of the parent element's list,
as defined for those elements. Otherwise, the list item has no
defined list-related relationship to any other li element.
If the parent element is an ol element, then the li element has an ordinal value.
The following example, the top ten movies are listed (in reverse
order). Note the way the list is given a title by using a
figure element and its figcaption element.
<figure>
<figcaption>The top 10 movies of all time</figcaption>
<ol>
<li value="10"><cite>Josie and the Pussycats</cite>, 2001</li>
<li value="9"><cite lang="sh">Црна мачка, бели мачор</cite>, 1998</li>
<li value="8"><cite>A Bug's Life</cite>, 1998</li>
<li value="7"><cite>Toy Story</cite>, 1995</li>
<li value="6"><cite>Monsters, Inc</cite>, 2001</li>
<li value="5"><cite>Cars</cite>, 2006</li>
<li value="4"><cite>Toy Story 2</cite>, 1999</li>
<li value="3"><cite>Finding Nemo</cite>, 2003</li>
<li value="2"><cite>The Incredibles</cite>, 2004</li>
<li value="1"><cite>Ratatouille</cite>, 2007</li>
</ol>
</figure>
The markup could also be written as follows, using the
reversed attribute on the ol element:
<figure>
<figcaption>The top 10 movies of all time</figcaption>
<ol reversed>
<li><cite>Josie and the Pussycats</cite>, 2001</li>
<li><cite lang="sh">Црна мачка, бели мачор</cite>, 1998</li>
<li><cite>A Bug's Life</cite>, 1998</li>
<li><cite>Toy Story</cite>, 1995</li>
<li><cite>Monsters, Inc</cite>, 2001</li>
<li><cite>Cars</cite>, 2006</li>
<li><cite>Toy Story 2</cite>, 1999</li>
<li><cite>Finding Nemo</cite>, 2003</li>
<li><cite>The Incredibles</cite>, 2004</li>
<li><cite>Ratatouille</cite>, 2007</li>
</ol>
</figure>
If the li element is the child of a menu
element and itself has a child that defines a command, then the
li element will match the :enabled
and :disabled
pseudo-classes in the same way as the first such child element
does.
While it is conforming to include heading elements
(e.g.
h1) inside li elements, it likely does not convey the
semantics that the author intended. A heading starts a new section,
so a heading in a list implicitly splits the list into spanning
multiple sections.
The dl element represents
an association list consisting of zero or more name-value groups (a
description list). Each group must consist of one or more names
(dt elements) followed by one or more values
(dd elements). Within a single dl element, there should not be more than one
dt element for each name.
Name-value groups may be terms and definitions, metadata topics
and values, questions and answers, or any other groups of
name-value data.
The values within a group are alternatives; multiple paragraphs
forming part of the same value must all be given within the same
dd element.
The order of the list of groups, and of the names and values
within each group, may be significant.
In the following example, one entry ("Authors") is linked to two
values ("John" and "Luke").
<dl>
<dt> Authors
<dd> John
<dd> Luke
<dt> Editor
<dd> Frank
</dl>
In the following example, one definition is linked to two
terms.
<dl>
<dt lang="en-US"> <dfn>color</dfn> </dt>
<dt lang="en-GB"> <dfn>colour</dfn> </dt>
<dd> A sensation which (in humans) derives from the ability of
the fine structure of the eye to distinguish three differently
filtered analyses of a view. </dd>
</dl>
The following example illustrates the use of the dl element to mark up metadata of sorts. At the
end of the example, one group has two metadata labels ("Authors"
and "Editors") and two values ("Robert Rothman" and "Daniel
Jackson").
<dl>
<dt> Last modified time </dt>
<dd> 2004-12-23T23:33Z </dd>
<dt> Recommended update interval </dt>
<dd> 60s </dd>
<dt> Authors </dt>
<dt> Editors </dt>
<dd> Robert Rothman </dd>
<dd> Daniel Jackson </dd>
</dl>
The following example shows the dl element used to give a set of instructions.
The order of the instructions here is important (in the other
examples, the order of the blocks was not important).
<p>Determine the victory points as follows (use the
first matching case):</p>
<dl>
<dt> If you have exactly five gold coins </dt>
<dd> You get five victory points </dd>
<dt> If you have one or more gold coins, and you have one or more silver coins </dt>
<dd> You get two victory points </dd>
<dt> If you have one or more silver coins </dt>
<dd> You get one victory point </dd>
<dt> Otherwise </dt>
<dd> You get no victory points </dd>
</dl>
The following snippet shows a dl element being used as a glossary. Note the use
of dfn to indicate the word being defined.
<dl>
<dt><dfn>Apartment</dfn>, n.</dt>
<dd>An execution context grouping one or more threads with one or
more COM objects.</dd>
<dt><dfn>Flat</dfn>, n.</dt>
<dd>A deflated tire.</dd>
<dt><dfn>Home</dfn>, n.</dt>
<dd>The user's login directory.</dd>
</dl>
The dt element represents
the term, or name, part of a term-description group in a
description list (dl element).
The dt element itself, when used in a dl element, does not indicate that its contents
are a term being defined, but this can be indicated using the
dfn element.
This example shows a list of frequently asked questions (a FAQ)
marked up using the dt element for questions and the dd element for answers.
<article>
<h1>FAQ</h1>
<dl>
<dt>What do we want?</dt>
<dd>Our data.</dd>
<dt>When do we want it?</dt>
<dd>Now.</dd>
<dt>Where is it?</dt>
<dd>We are not sure.</dd>
</dl>
</article>
The dd element represents
the description, definition, or value, part of a term-description
group in a description list (dl element).
A dl can be used to define a vocabulary list, like
in a dictionary. In the following example, each entry, given by a
dt with a dfn, has several dds, showing the various parts of the
definition.
<dl>
<dt><dfn>happiness</dfn></dt>
<dd class="pronunciation">/'hæ p. nes/</dd>
<dd class="part-of-speech"><i><abbr>n.</abbr></i></dd>
<dd>The state of being happy.</dd>
<dd>Good fortune; success. <q>Oh <b>happiness</b>! It worked!</q></dd>
<dt><dfn>rejoice</dfn></dt>
<dd class="pronunciation">/ri jois'/</dd>
<dd><i class="part-of-speech"><abbr>v.intr.</abbr></i> To be delighted oneself.</dd>
<dd><i class="part-of-speech"><abbr>v.tr.</abbr></i> To cause one to be delighted.</dd>
</dl>
The figure element represents
some flow content, optionally with a caption, that
is self-contained and is typically referenced as a single unit from
the main flow of the document.
The element can thus be used to annotate illustrations,
diagrams, photos, code listings, etc, that are referred to from the
main content of the document, but that could, without affecting the
flow of the document, be moved away from that primary content, e.g.
to the side of the page, to dedicated pages, or to an appendix.
The figcaption element child of the
element, if any, represents the caption of the figure element's contents. If there is no
child figcaption element, then there is no
caption.
This example shows the figure element to mark up a code
listing.
<p>In <a href="http://dev.w3.org/html5/spec/single-page.html#l4">listing 4</a> we see the primary core interface
API declaration.</p>
<figure id="l4">
<figcaption>Listing 4. The primary core interface API declaration.</figcaption>
<pre><code>interface PrimaryCore {
boolean verifyDataLine();
void sendData(in sequence<byte> data);
void initSelfDestruct();
}</code></pre>
</figure>
<p>The API is designed to use UTF-8.</p>
<figure>
<img src="bubbles-work.jpeg"
alt="Bubbles, sitting in his office chair, works on his
latest project intently.">
<figcaption>Bubbles at work</figcaption>
</figure>
In this example, we see an image that is not a figure,
as well as an image and a video that are.
<h2>Malinko's comics</h2>
<p>This case centered on some sort of "intellectual property"
infringement related to a comic (see Exhibit A). The suit started
after a trailer ending with these words:
<blockquote>
<img src="promblem-packed-action.png" alt="ROUGH COPY! Promblem-Packed Action!">
</blockquote>
<p>...was aired. A lawyer, armed with a Bigger Notebook, launched a
preemptive strike using snowballs. A complete copy of the trailer is
included with Exhibit B.
<figure>
<img src="ex-a.png" alt="Two squiggles on a dirty piece of paper.">
<figcaption>Exhibit A. The alleged <cite>rough copy</cite> comic.</figcaption>
</figure>
<figure>
<video src="ex-b.mov"></video>
<figcaption>Exhibit B. The <cite>Rough Copy</cite> trailer.</figcaption>
</figure>
<p>The case was resolved out of court.
<figure>
<p>'Twas brillig, and the slithy toves<br>
Did gyre and gimble in the wabe;<br>
All mimsy were the borogoves,<br>
And the mome raths outgrabe.</p>
<figcaption><cite>Jabberwocky</cite> (first verse). Lewis Carroll, 1832-98</figcaption>
</figure>
In this example, which could be part of a much larger work
discussing a castle, nested figure elements are used to provide both
a group caption and individual captions for each figure in the
group:
<figure>
<figcaption>The castle through the ages: 1423, 1858, and 1999 respectively.</figcaption>
<figure>
<figcaption>Etching. Anonymous, ca. 1423.</figcaption>
<img src="castle1423.jpeg" alt="The castle has one tower, and a tall wall around it.">
</figure>
<figure>
<figcaption>Oil-based paint on canvas. Maria Towle, 1858.</figcaption>
<img src="castle1858.jpeg" alt="The castle now has two towers and two walls.">
</figure>
<figure>
<figcaption>Film photograph. Peter Jankle, 1999.</figcaption>
<img src="castle1999.jpeg" alt="The castle lies in ruins, the original tower all that remains in one piece.">
</figure>
</figure>
The div element has no special meaning at all. It
represents
its children. It can be used with the class, lang, and title attributes to mark up semantics common
to a group of consecutive elements.
Authors are strongly encouraged to view the
div element as an element of last resort, for
when no other element is suitable. Use of more appropriate elements
instead of the div element leads to better accessibility for
readers and easier maintainability for authors.
For example, a blog post would be marked up using article, a chapter using section, a page's navigation aids using
nav, and a group of form controls using
fieldset.
On the other hand, div elements can be useful for stylistic
purposes or to wrap multiple paragraphs within a section that are
all to be annotated in a similar way. In the following example, we
see div elements used as a way to set the language
of two paragraphs at once, instead of setting the language on the
two paragraph elements separately:
<article lang="en-US">
<h1>My use of language and my cats</h1>
<p>My cat's behavior hasn't changed much since her absence, except
that she plays her new physique to the neighbors regularly, in an
attempt to get pets.</p>
<div lang="en-GB">
<p>My other cat, coloured black and white, is a sweetie. He followed
us to the pool today, walking down the pavement with us. Yesterday
he apparently visited our neighbours. I wonder if he recognises that
their flat is a mirror image of ours.</p>
<p>Hm, I just noticed that in the last paragraph I used British
English. But I'm supposed to write in American English. So I
shouldn't say "pavement" or "flat" or "colour"...</p>
</div>
<p>I should say "sidewalk" and "apartment" and "color"!</p>
</article>
If the a element has no href attribute, then the element represents
a placeholder for where a link might otherwise have been placed, if
it had been relevant.
If a site uses a consistent navigation toolbar on every page,
then the link that would normally link to the page itself could be
marked up using an a element:
The a element may be wrapped around entire
paragraphs, lists, tables, and so forth, even entire sections, so
long as there is no interactive content within (e.g. buttons or
other links). This example shows how this can be used to make an
entire advertising block into a link:
<aside class="advertising">
<h1>Advertising</h1>
<a href="http://ad.example.com/?adid=1929&pubid=1422">
<section>
<h1>Mellblomatic 9000!</h1>
<p>Turn all your widgets into mellbloms!</p>
<p>Only $9.99 plus shipping and handling.</p>
</section>
</a>
<a href="http://ad.example.com/?adid=375&pubid=1422">
<section>
<h1>The Mellblom Browser</h1>
<p>Web browsing at the speed of light.</p>
<p>No other browser goes faster!</p>
</section>
</a>
</aside>
The em element represents
stress emphasis of its contents.
The level of stress that a particular piece of content has is
given by its number of ancestor em elements.
The placement of stress emphasis changes the meaning of the
sentence. The element thus forms an integral part of the content.
The precise way in which stress is used in this way depends on the
language.
These examples show how changing the stress emphasis changes the
meaning. First, a general statement of fact, with no stress:
<p>Cats are cute animals.</p>
By emphasizing the first word, the statement implies that the
kind of animal under discussion is in question (maybe someone is
asserting that dogs are cute):
<p><em>Cats</em> are cute animals.</p>
Moving the stress to the verb, one highlights that the truth of
the entire sentence is in question (maybe someone is saying cats
are not cute):
<p>Cats <em>are</em> cute animals.</p>
By moving it to the adjective, the exact nature of the cats is
reasserted (maybe someone suggested cats were mean
animals):
<p>Cats are <em>cute</em> animals.</p>
Similarly, if someone asserted that cats were vegetables,
someone correcting this might emphasize the last word:
<p>Cats are cute <em>animals</em>.</p>
By emphasizing the entire sentence, it becomes clear that the
speaker is fighting hard to get the point across. This kind of
stress emphasis also typically affects the punctuation, hence the
exclamation mark here.
<p><em>Cats are cute animals!</em></p>
Anger mixed with emphasizing the cuteness could lead to markup
such as:
<p><em>Cats are <em>cute</em> animals!</em></p>
The em element isn't a generic "italics" element.
Sometimes, text is intended to stand out from the rest of the
paragraph, as if it was in a different mood or voice. For this, the
i element is more appropriate.
The em element also isn't intended to convey
importance; for that purpose, the strong element is more appropriate.
The strong element represents
strong importance for its contents.
The relative level of importance of a piece of content is given
by its number of ancestor strong elements; each strong element increases the importance of
its contents.
Changing the importance of a piece of text with the
strong element does not change the meaning
of the sentence.
Here is an example of a warning notice in a game, with the
various parts marked up according to how important they are:
<p><strong>Warning.</strong> This dungeon is dangerous.
<strong>Avoid the ducks.</strong> Take any gold you find.
<strong><strong>Do not take any of the diamonds</strong>,
they are explosive and <strong>will destroy anything within
ten meters.</strong></strong> You have been warned.</p>
The small element represents
side comments such as small print.
Small print typically features disclaimers,
caveats, legal restrictions, or copyrights. Small print is also
sometimes used for attribution, or for satisfying licensing
requirements.
The small element does not "de-emphasize" or
lower the importance of text emphasized by the em element or marked as important with the
strong element. To mark text as not
emphasized or important, simply do not mark it up with the
em or strong elements respectively.
The small element should not be used for
extended spans of text, such as multiple paragraphs, lists, or
sections of text. It is only intended for short runs of text. The
text of a page listing terms of use, for instance, would not be a
suitable candidate for the small element: in such a case, the text is
not a side comment, it is the main content of the page.
In this example, the small element is used to indicate that
value-added tax is not included in a price of a hotel room:
<dl>
<dt>Single room
<dd>199 € <small>breakfast included, VAT not included</small>
<dt>Double room
<dd>239 € <small>breakfast included, VAT not included</small>
</dl>
In this second example, the small element is used for a side comment in
an article.
<p>Example Corp today announced record profits for the
second quarter <small>(Full Disclosure: Foo News is a subsidiary of
Example Corp)</small>, leading to speculation about a third quarter
merger with Demo Group.</p>
This is distinct from a sidebar, which might be multiple
paragraphs long and is removed from the main flow of text. In the
following example, we see a sidebar from the same article. This
sidebar also has small print, indicating the source of the
information in the sidebar.
<aside>
<h1>Example Corp</h1>
<p>This company mostly creates small software and Web
sites.</p>
<p>The Example Corp company mission is "To provide entertainment
and news on a sample basis".</p>
<p><small>Information obtained from <a
href="http://example.com/about.html">example.com</a> home
page.</small></p>
</aside>
In this last example, the small element is marked as being
important small print.
<p><strong><small>Continued use of this service will result in a kiss.</small></strong></p>
The s element represents
contents that are no longer accurate or no longer relevant.
The s element is not appropriate when indicating
document edits; to mark a span of text as having been removed from
a document, use the del element.
In this example a recommended retail price has been marked as no
longer relevant as the product in question has a new sale
price.
<p>Buy our Iced Tea and Lemonade!</p>
<p><s>Recommended retail price: $3.99 per bottle</s></p>
<p><strong>Now selling for just $2.99 a bottle!</strong></p>
The cite element represents
the title of a work (e.g. a book, a paper, an essay, a poem, a
score, a song, a script, a film, a TV show, a game, a sculpture, a
painting, a theatre production, a play, an opera, a musical, an
exhibition, a legal case report, etc). This can be a work that is
being quoted or referenced in detail (i.e. a citation), or it can
just be a work that is mentioned in passing.
A person's name is not the title of a work — even if people call
that person a piece of work — and the element must therefore not be
used to mark up people's names. (In some cases, the b element might be appropriate for names; e.g. in
a gossip article where the names of famous people are keywords
rendered with a different style to draw attention to them. In other
cases, if an element is really needed, the span element can be used.)
This next example shows a typical use of the cite element:
<p>My favorite book is <cite>The Reality Dysfunction</cite> by
Peter F. Hamilton. My favorite comic is <cite>Pearls Before
Swine</cite> by Stephan Pastis. My favorite track is <cite>Jive
Samba</cite> by the Cannonball Adderley Sextet.</p>
This is correct usage:
<p>According to the Wikipedia article <cite>HTML</cite>, as it
stood in mid-February 2008, leaving attribute values unquoted is
unsafe. This is obviously an over-simplification.</p>
The following, however, is incorrect usage, as the
cite element here is containing far more
than the title of the work:
<!-- do not copy this example, it is an example of bad usage! -->
<p>According to <cite>the Wikipedia article on HTML</cite>, as it
stood in mid-February 2008, leaving attribute values unquoted is
unsafe. This is obviously an over-simplification.</p>
The cite element is obviously a key part of any
citation in a bibliography, but it is only used to mark the
title:
<p><cite>Universal Declaration of Human Rights</cite>, United Nations,
December 1948. Adopted by General Assembly resolution 217 A (III).</p>
A citation is not a quote (for
which the q element is appropriate).
This is incorrect usage, because cite is not for quotes:
<p><cite>This is wrong!</cite>, said Ian.</p>
This is also incorrect usage, because a person is not a
work:
<p><q>This is still wrong!</q>, said <cite>Ian</cite>.</p>
Quotation punctuation (such as quotation marks) that is quoting
the contents of the element must not appear immediately before,
after, or inside q elements; they will be inserted into the
rendering by the user agent.
Content inside a q element must be quoted from another source,
whose address, if it has one, may be cited in the cite
attribute. The source may be fictional, as when quoting characters
in a novel or screenplay.
The q element must not be used in place of quotation
marks that do not represent quotes; for example, it is
inappropriate to use the q element for marking up sarcastic
statements.
The use of q elements to mark up quotations is entirely
optional; using explicit quotation punctuation without
q elements is just as correct.
Here is a simple example of the use of the q element:
<p>The man said <q>Things that are impossible just take
longer</q>. I disagreed with him.</p>
Here is an example with both an explicit citation link in the
q element, and an explicit citation outside:
<p>The W3C page <cite>About W3C</cite> says the W3C's
mission is <q cite="http://www.w3.org/Consortium/">To lead the
World Wide Web to its full potential by developing protocols and
guidelines that ensure long-term growth for the Web</q>. I
disagree with this mission.</p>
In the following example, the quotation itself contains a
quotation:
<p>In <cite>Example One</cite>, he writes <q>The man
said <q>Things that are impossible just take longer</q>. I
disagreed with him</q>. Well, I disagree even more!</p>
In the following example, quotation marks are used instead of
the q element:
<p>His best argument was ❝I disagree❞, which
I thought was laughable.</p>
In the following example, there is no quote — the quotation
marks are used to name a word. Use of the q element in this case would be
inappropriate.
<p>The word "ineffable" could have been used to describe the disaster
resulting from the campaign's mismanagement.</p>
Defining term: If the
dfn element has a title attribute, then the
exact value of that attribute is the term being defined. Otherwise,
if it contains exactly one element child node and no child
Text
nodes, and that child element is an abbr element with a title attribute, then the exact value of
that attribute is the term being defined. Otherwise, it is
the exact textContent
of the dfn element that gives the term being
defined.
If the title attribute of the dfn element is present, then it must contain
only the term being defined.
The title attribute of ancestor elements does not
affect dfn elements.
An a element that links to a dfn element represents an instance of the term
defined by the dfn element.
In the following fragment, the term "Garage Door Opener" is
first defined in the first paragraph, then used in the second. In
both cases, its abbreviation is what is actually displayed.
<p>The <dfn><abbr title="Garage Door Opener">GDO</abbr></dfn>
is a device that allows off-world teams to open the iris.</p>
<!-- ... later in the document: -->
<p>Teal'c activated his <abbr title="Garage Door Opener">GDO</abbr>
and so Hammond ordered the iris to be opened.</p>
With the addition of an a element, the reference can be made
explicit:
<p>The <dfn id=gdo><abbr title="Garage Door Opener">GDO</abbr></dfn>
is a device that allows off-world teams to open the iris.</p>
<!-- ... later in the document: -->
<p>Teal'c activated his <a href=#gdo><abbr title="Garage Door Opener">GDO</abbr></a>
and so Hammond ordered the iris to be opened.</p>
The abbr element represents
an abbreviation or acronym, optionally with its expansion. The
title attribute may be used to
provide an expansion of the abbreviation. The attribute, if
specified, must contain an expansion of the abbreviation, and
nothing else.
The paragraph below contains an abbreviation marked up with the
abbr element. This paragraph defines the term "Web
Hypertext Application Technology Working Group".
<p>The <dfn id=whatwg><abbr
title="Web Hypertext Application Technology Working Group">WHATWG</abbr></dfn>
is a loose unofficial collaboration of Web browser manufacturers and
interested parties who wish to develop new technologies designed to
allow authors to write and deploy Applications over the World Wide
Web.</p>
An alternative way to write this would be:
<p>The <dfn id=whatwg>Web Hypertext Application Technology
Working Group</dfn> (<abbr
title="Web Hypertext Application Technology Working Group">WHATWG</abbr>)
is a loose unofficial collaboration of Web browser manufacturers and
interested parties who wish to develop new technologies designed to
allow authors to write and deploy Applications over the World Wide
Web.</p>
This paragraph has two abbreviations. Notice how only one is
defined; the other, with no expansion associated with it, does not
use the abbr element.
<p>The
<abbr title="Web Hypertext Application Technology Working Group">WHATWG</abbr>
started working on HTML5 in 2004.</p>
This paragraph links an abbreviation to its definition.
<p>The <a href="http://dev.w3.org/html5/spec/single-page.html#whatwg"><abbr
title="Web Hypertext Application Technology Working Group">WHATWG</abbr></a>
community does not have much representation from Asia.</p>
This paragraph marks up an abbreviation without giving an
expansion, possibly as a hook to apply styles for abbreviations
(e.g. smallcaps).
<p>Philip` and Dashiva both denied that they were going to
get the issue counts from past revisions of the specification to
backfill the <abbr>WHATWG</abbr> issue graph.</p>
If an abbreviation is pluralized, the expansion's grammatical
number (plural vs singular) must match the grammatical number of
the contents of the element.
Here the plural is outside the element, so the expansion is in
the singular:
<p>Two <abbr title="Working Group">WG</abbr>s worked on
this specification: the <abbr>WHATWG</abbr> and the
<abbr>HTMLWG</abbr>.</p>
Here the plural is inside the element, so the expansion is in
the plural:
<p>Two <abbr title="Working Groups">WGs</abbr> worked on
this specification: the <abbr>WHATWG</abbr> and the
<abbr>HTMLWG</abbr>.</p>
Abbreviations do not have to be marked up using this element. It
is expected to be useful in the following cases:
Abbreviations for which the author wants to give expansions,
where using the abbr element with a title attribute is an alternative to
including the expansion inline (e.g. in parentheses).
Abbreviations that are likely to be unfamiliar to the
document's readers, for which authors are encouraged to either mark
up the abbreviation using an abbr element with a title attribute or include the expansion
inline in the text the first time the abbreviation is used.
Abbreviations whose presence needs to be semantically
annotated, e.g. so that they can be identified from a style sheet
and given specific styles, for which the abbr element can be used without a
title attribute.
Providing an expansion in a title attribute once will not necessarily
cause other abbr elements in the same document with the
same contents but without a title attribute to behave as if they had the
same expansion. Every abbr element is independent.
The time element represents
its contents, along with a machine-readable form of those contents
in the datetime attribute. The kind of content
is limited to various kinds of dates, times, time-zone offsets, and
durations, as described below.
The datetime attribute may be
present. If present, its value must be a representation of the
element's contents in a machine-readable format.
A time element that does not have a
datetime content attribute must not have
any element descendants.
The datetime value of a
time element is the value of the element's
datetime content attribute, if it has
one, or the element's textContent,
if it does not.
The datetime value of a time element must match one of the following
syntaxes.
The time element can be used to encode dates,
for example in microformats. The following shows a hypothetical way
of encoding an event using a variant on hCalendar that uses the
time element:
<div class="vevent">
<a class="url" href="http://www.web2con.com/">http://www.web2con.com/</a>
<span class="summary">Web 2.0 Conference</span>:
<time class="dtstart" datetime="2005-10-05">October 5</time> -
<time class="dtend" datetime="2005-10-07">7</time>,
at the <span class="location">Argent Hotel, San Francisco, CA</span>
</div>
In the following snippet, the time element is used to encode a date in
the ISO8601 format, for later processing by a script:
<p>Our first date was <time datetime="2006-09-23">a Saturday</time>.</p>
In this second snippet, the value includes a time:
<p>We stopped talking at <time datetime="2006-09-24T05:00-07:00">5am the next morning</time>.</p>
A script loaded by the page (and thus privy to the page's
internal convention of marking up dates and times using the
time element) could scan through the page
and look at all the time elements therein to create an index of
dates and times.
For example, this element conveys the string "Tuesday" with the
additional semantic that the 12th of November 2011 is the meaning
that corresponds to "Tuesday":
Today is <time datetime="2011-11-12">Tuesday</time>.
In this example, a specific time in the Pacific Standard Time
timezone is specified:
Your next meeting is at <time datetime="2011-11-12T15:00-08:00">3pm</time>.
The code element represents
a fragment of computer code. This could be an XML element name, a
filename, a computer program, or any other string that a computer
would recognize.
Although there is no formal way to indicate the language of
computer code being marked up, authors who wish to mark
code elements with the language used, e.g.
so that syntax highlighting scripts can use the right rules, may do
so by adding a class prefixed with "language-" to the element.
The following example shows how the element can be used in a
paragraph to mark up element names and computer code, including
punctuation.
<p>The <code>code</code> element represents a fragment of computer
code.</p>
<p>When you call the <code>activate()</code> method on the
<code>robotSnowman</code> object, the eyes glow.</p>
<p>The example below uses the <code>begin</code> keyword to indicate
the start of a statement block. It is paired with an <code>end</code>
keyword, which is followed by the <code>.</code> punctuation character
(full stop) to indicate the end of the program.</p>
The following example shows how a block of code could be marked
up using the pre and code elements.
<pre><code class="language-pascal">var i: Integer;
begin
i := 1;
end.</code></pre>
A class is used in that example to indicate the language
used.
The var element represents
a variable. This could be an actual variable in a mathematical
expression or programming context, an identifier representing a
constant, a symbol identifying a physical quantity, a function
parameter, or just be a term used as a placeholder in prose.
In the paragraph below, the letter "n" is being used as a
variable in prose:
<p>If there are <var>n</var> pipes leading to the ice
cream factory then I expect at <em>least</em> <var>n</var>
flavors of ice cream to be available for purchase!</p>
For mathematics, in particular for anything beyond the simplest
of expressions, MathML is more appropriate. However, the
var element can still be used to refer to
specific variables that are then mentioned in MathML
expressions.
In this example, an equation is shown, with a legend that
references the variables in the equation. The expression itself is
marked up with MathML, but the variables are mentioned in the
figure's legend using var.
<figure>
<math>
<mi>a</mi>
<mo>=</mo>
<msqrt>
<msup><mi>b</mi><mn>2</mn></msup>
<mi>+</mi>
<msup><mi>c</mi><mn>2</mn></msup>
</msqrt>
</math>
<figcaption>
Using Pythagoras' theorem to solve for the hypotenuse <var>a</var> of
a triangle with sides <var>b</var> and <var>c</var>
</figcaption>
</figure>
Here, the equation describing mass-energy equivalence is used in
a sentence, and the var element is used to mark the variables and
constants in that equation:
<p>Then he turned to the blackboard and picked up the chalk. After a few moment's
thought, he wrote <var>E</var> = <var>m</var> <var>c</var><sup>2</sup>. The teacher
looked pleased.</p>
This example shows the samp element being used inline:
<p>The computer said <samp>Too much cheese in tray
two</samp> but I didn't know what that meant.</p>
This second example shows a block of sample output. Nested
samp and kbd elements allow for the styling of specific
elements of the sample output using a style sheet.
<pre><samp><span class="prompt">jdoe@mowmow:~$</span> <kbd>ssh demo.example.com</kbd>
Last login: Tue Apr 12 09:10:17 2005 from mowmow.example.com on pts/1
Linux demo 2.6.10-grsec+gg3+e+fhs6b+nfs+gr0501+++p3+c4a+gr2b-reslog-v6.189 #1 SMP Tue Feb 1 11:22:36 PST 2005 i686 unknown
<span class="prompt">jdoe@demo:~$</span> <span class="cursor">_</span></samp></pre>
The kbd element represents
user input (typically keyboard input, although it may also be used
to represent other input, such as voice commands).
When the kbd element is nested inside a samp element, it represents the input as it
was echoed by the system.
When the kbd element contains a samp element, it represents input based on
system output, for example invoking a menu item.
When the kbd element is nested inside another
kbd element, it represents an actual key or
other single unit of input as appropriate for the input
mechanism.
Here the kbd element is used to indicate keys to
press:
<p>To make George eat an apple, press <kbd><kbd>Shift</kbd>+<kbd>F3</kbd></kbd></p>
In this second example, the user is told to pick a particular
menu item. The outer kbd element marks up a block of input, with the
inner kbd elements representing each individual step
of the input, and the samp elements inside them indicating that
the steps are input based on something being displayed by the
system, in this case menu labels:
<p>To make George eat an apple, select
<kbd><kbd><samp>File</samp></kbd>|<kbd><samp>Eat Apple...</samp></kbd></kbd>
</p>
Such precision isn't necessary; the following is equally
fine:
<p>To make George eat an apple, select <kbd>File | Eat Apple...</kbd></p>
These elements must be used only to mark up typographical
conventions with specific meanings, not for typographical
presentation for presentation's sake. For example, it would be
inappropriate for the
sub and
sup elements to be used in the name of the LaTeX
document preparation system. In general, authors should use these
elements only if the absence of those elements would
change the meaning of the content.
In certain languages, superscripts are part of the typographical
conventions for some abbreviations.
<p>The most beautiful women are
<span lang="fr"><abbr>M<sup>lle</sup></abbr> Gwendoline</span> and
<span lang="fr"><abbr>M<sup>me</sup></abbr> Denise</span>.</p>
The
sub element can be used inside a var element, for variables that have
subscripts.
Here, the
sub element is used to represents the subscript that
identifies the variable in a family of variables:
<p>The coordinate of the <var>i</var>th point is
(<var>x<sub><var>i</var></sub></var>, <var>y<sub><var>i</var></sub></var>).
For example, the 10th point has coordinate
(<var>x<sub>10</sub></var>, <var>y<sub>10</sub></var>).</p>
Mathematical expressions often use subscripts and superscripts.
Authors are encouraged to use MathML for marking up mathematics,
but authors may opt to use
sub and
sup if detailed mathematical markup is not desired.
[MATHML]
The i element represents
a span of text in an alternate voice or mood, or otherwise offset
from the normal prose in a manner indicating a different quality of
text, such as a taxonomic designation, a technical term, an
idiomatic phrase from another language, a thought, or a ship name
in Western texts.
<p>The <i class="taxonomy">Felis silvestris catus</i> is cute.</p>
<p>The term <i>prose content</i> is defined above.</p>
<p>There is a certain <i lang="fr">je ne sais quoi</i> in the air.</p>
In the following example, a dream sequence is marked up using
i elements.
<p>Raymond tried to sleep.</p>
<p><i>The ship sailed away on Thursday</i>, he
dreamt. <i>The ship had many people aboard, including a beautiful
princess called Carey. He watched her, day-in, day-out, hoping she
would notice him, but she never did.</i></p>
<p><i>Finally one night he picked up the courage to speak with
her—</i></p>
<p>Raymond woke with a start as the fire alarm rang out.</p>
Authors can use the class attribute on the i element to identify why the element is being
used, so that if the style of a particular use (e.g. dream
sequences as opposed to taxonomic terms) is to be changed at a
later date, the author doesn't have to go through the entire
document (or series of related documents) annotating each use.
Authors are encouraged to consider whether other elements might
be more applicable than the i element, for instance the em element for marking up stress emphasis, or the
dfn element to mark up the defining instance of
a term.
Style sheets can be used to format i elements, just like any other element can be
restyled. Thus, it is not the case that content in i elements will necessarily be italicized.
The b element represents
a span of text to which attention is being drawn for utilitarian
purposes without conveying any extra importance and with no
implication of an alternate voice or mood, such as key words in a
document abstract, product names in a review, actionable words in
interactive text-driven software, or an article lede.
The following example shows a use of the b element to highlight key words without marking
them up as important:
<p>The <b>frobonitor</b> and <b>barbinator</b> components are fried.</p>
In the following example, objects in a text adventure are
highlighted as being special by use of the b element.
<p>You enter a small room. Your <b>sword</b> glows
brighter. A <b>rat</b> scurries past the corner wall.</p>
<article>
<h2>Kittens 'adopted' by pet rabbit</h2>
<p><b class="lede">Six abandoned kittens have found an
unexpected new mother figure — a pet rabbit.</b></p>
<p>Veterinary nurse Melanie Humble took the three-week-old
kittens to her Aberdeen home.</p>
[...]
As with the i element, authors can use the class attribute on the b element to identify why the element is being
used, so that if the style of a particular use is to be changed at
a later date, the author doesn't have to go through annotating each
use.
The b element should be used as a last resort when no
other element is more appropriate. In particular, headings should
use the
h1 to
h6 elements, stress emphasis should use the
em element, importance should be denoted with
the strong element, and text marked or
highlighted should use the mark element.
The following would be incorrect usage:
<p><b>WARNING!</b> Do not frob the barbinator!</p>
In the previous example, the correct element to use would have
been strong, not b.
Style sheets can be used to format b elements, just like any other element can be
restyled. Thus, it is not the case that content in b elements will necessarily be boldened.
The u element represents
a span of text with an unarticulated, though explicitly rendered,
non-textual annotation, such as labeling the text as being a proper
name in Chinese text (a Chinese proper name mark), or labeling the
text as being misspelt.
In most cases, another element is likely to be more appropriate:
for marking stress emphasis, the em element should be used; for marking key words
or phrases either the b element or the mark element should be used, depending on
the context; for marking book titles, the cite element should be used
; for labeling text with explicit textual
annotations, the ruby element should be used; for labeling
ship names in Western texts, the i element should be used.
The default rendering of the u element in visual presentations clashes with the
conventional rendering of hyperlinks (underlining). Authors are
encouraged to avoid using the u element where it could be confused for a
hyperlink.
The mark element represents
a run of text in one document marked or highlighted for reference
purposes, due to its relevance in another context. When used in a
quotation or other block of text referred to from the prose, it
indicates a highlight that was not originally present but which has
been added to bring the reader's attention to a part of the text
that might not have been considered important by the original
author when the block was originally written, but which is now
under previously unexpected scrutiny. When used in the main prose
of a document, it indicates a part of the document that has been
highlighted due to its likely relevance to the user's current
activity.
This example shows how the mark element can be used to bring attention
to a particular part of a quotation:
<p lang="en-US">Consider the following quote:</p>
<blockquote lang="en-GB">
<p>Look around and you will find, no-one's really
<mark>colour</mark> blind.</p>
</blockquote>
<p lang="en-US">As we can tell from the <em>spelling</em> of the word,
the person writing this quote is clearly not American.</p>
(If the goal was to mark the element as misspelt, however, the
u element, possibly with a class, would be more
appropriate.)
Another example of the mark element is highlighting parts of a
document that are matching some search string. If someone looked at
a document, and the server knew that the user was searching for the
word "kitten", then the server might return the document with one
paragraph modified as follows:
<p>I also have some <mark>kitten</mark>s who are visiting me
these days. They're really cute. I think they like my garden! Maybe I
should adopt a <mark>kitten</mark>.</p>
In the following snippet, a paragraph of text refers to a
specific part of a code fragment.
<p>The highlighted part below is where the error lies:</p>
<pre><code>var i: Integer;
begin
i := <mark>1.1</mark>;
end.</code></pre>
This is separate from syntax highlighting, for which
span is more appropriate. Combining both,
one would get:
<p>The highlighted part below is where the error lies:</p>
<pre><code><span class=keyword>var</span> <span class=ident>i</span>: <span class=type>Integer</span>;
<span class=keyword>begin</span>
<span class=ident>i</span> := <span class=literal><mark>1.1</mark></span>;
<span class=keyword>end</span>.</code></pre>
This is another example showing the use of mark to highlight a part of quoted text that
was originally not emphasized. In this example, common typographic
conventions have led the author to explicitly style mark elements in quotes to render in
italics.
<article>
<style scoped>
blockquote mark, q mark {
font: inherit; font-style: italic;
text-decoration: none;
background: transparent; color: inherit;
}
.bubble em {
font: inherit; font-size: larger;
text-decoration: underline;
}
</style>
<h1>She knew</h1>
<p>Did you notice the subtle joke in the joke on panel 4?</p>
<blockquote>
<p class="bubble">I didn't <em>want</em> to believe. <mark>Of course
on some level I realized it was a known-plaintext attack.</mark> But I
couldn't admit it until I saw for myself.</p>
</blockquote>
<p>(Emphasis mine.) I thought that was great. It's so pedantic, yet it
explains everything neatly.</p>
</article>
Note, incidentally, the distinction between the em element in this example, which is part of the
original text being quoted, and the mark element, which is highlighting a part
for comment.
The following example shows the difference between denoting the
importance of a span of text (strong) as opposed to denoting the
relevance of a span of text (mark). It is an extract from a textbook,
where the extract has had the parts relevant to the exam
highlighted. The safety warnings, important though they may be, are
apparently not relevant to the exam.
<h3>Wormhole Physics Introduction</h3>
<p><mark>A wormhole in normal conditions can be held open for a
maximum of just under 39 minutes.</mark> Conditions that can increase
the time include a powerful energy source coupled to one or both of
the gates connecting the wormhole, and a large gravity well (such as a
black hole).</p>
<p><mark>Momentum is preserved across the wormhole. Electromagnetic
radiation can travel in both directions through a wormhole,
but matter cannot.</mark></p>
<p>When a wormhole is created, a vortex normally forms.
<strong>Warning: The vortex caused by the wormhole opening will
annihilate anything in its path.</strong> Vortexes can be avoided when
using sufficiently advanced dialing technology.</p>
<p><mark>An obstruction in a gate will prevent it from accepting a
wormhole connection.</mark></p>
The ruby element allows one or more spans of
phrasing content to be marked with ruby annotations. Ruby
annotations are short runs of text presented alongside base text,
primarily used in East Asian typography as a guide for
pronunciation or to include other annotations. In Japanese, this
form of typography is also known as furigana.
The content model of ruby elements consists of one or more of the
following sequences:
An rp element followed by one or more rt elements, each of which is itself followed by
an rp element
The ruby and rt elements can be used for a variety of kinds of
annotations, including in particular those described below. For
more details on Japanese Ruby in particular, and how to render Ruby
for Japanese, see Requirements for Japanese Text
Layout. [JLREQ]
At the time of writing, CSS does not yet provide a
way to fully control the rendering of the HTML ruby element. It is hoped that CSS will be
extended to support the styles described below in due course.
Mono-ruby for individual base characters
One or more hiragana or katakana characters (the ruby
annotation) are placed with each ideographic character (the base
text). This is used to provide readings of kanji characters.
<ruby>B<rt>annotation</ruby>
In this example, notice how each annotation corresponds to a
single base character.
This is similar to the previous case: each ideographic character
in the compound word (the base text) has its reading given in
hiragana or katakana characters (the ruby annotation). The
difference is that the base text segments form a compound word
rather than being separate from each other.
<ruby>B<rt>annotation</rt>B<rt>annotation</ruby>
In this example, notice again how each annotation corresponds to
a single base character. In this example, each compound word
(jukugo) corresponds to a single ruby element.
The rendering here is expected to be that each annotation be
placed over (or next to, in vertical text) the corresponding base
character, with the annotations not overhanging any of the adjacent
characters.
This is semantically identical to the previous case (each
individual ideographic character in the base compound word has its
reading given in an annotation in hiragana or katakana characters),
but the rendering is the more complicated Jukugo Ruby
rendering.
This is the same example as above for mono-ruby for compound
words. The different rendering is expected to be achieved using
different styling (e.g. in CSS), and is not shown here.
The annotation describes the meaning of the base text, rather
than (or in addition to) the pronunciation. As such, both the base
text and the annotation can be multiple characters long.
<ruby>BASE<rt>annotation</ruby>
Here a compound ideographic word has its corresponding katakana
given as an annotation.
<ruby>境界面<rt>インターフェース</ruby>
境界面
Here a compound ideographic word has its translation in English
provided as an annotation.
<ruby lang="ja">編集者<rt lang="en">editor</ruby>
編集者
Group ruby for Jukuji readings
A phonetic reading that corresponds to multiple base characters,
because a one-to-one mapping would be difficult. (In English, the
words "Colonel" and "Lieutenant" are examples of words where a
direct mapping of pronunciation to individual letters is, in some
dialects, rather unclear.)
In this example, the name of a species of flowers has a phonetic
reading provided using group ruby:
<ruby>紫陽花<rt>あじさい</ruby>
紫陽花
Text with both phonetic and semantic annotations (double-sided
ruby)
Sometimes, ruby styles described above are combined.
Here both a phonetic reading and the meaning are given in ruby
annotations. The annotation on the nested ruby element gives a mono-ruby phonetic
annotation for each base character, while the annotation in the
rt element that is a child of the outer
ruby element gives the meaning using
hiragana.
Within a ruby element that does not have a
ruby element ancestor, content is segmented
and segments are placed into three categories: base text segments,
annotation segments, and ignored segments. Ignored segments do not
form part of the document's semantics (they consist of some
inter-element whitespace and
rp elements, the latter of which are used for
legacy user agents that do not support ruby at all). Base text
segments can overlap (with a limit of two segments overlapping any
one position in the DOM, and with any segment having an earlier
start point than an overlapping segment also having an equal or
later end point, and any segment have a later end point than an
overlapping segment also having an equal or earlier start point
). Annotation
segments correspond to rt elements. Each annotation segment can be
associated with a base text segment, and each base text segment can
have annotation segments associated with it. (In a conforming
document, each base text segment is associated with at least one
annotation segment, and each annotation segment is associated with
one base text segment.) A ruby element represents
the union of the segments of base text it contains, along with the
mapping from those base text segments to annotation segments.
Segments are described in terms of DOM ranges; annotation segment
ranges always consist of exactly one element. [DOMCORE]
At any particular time, the segmentation and categorisation of
content of a ruby element is the result that would be
obtained from running the following algorithm:
Let base text segments be an empty list of
base text segments, each potentially with a list of base text
subsegments.
Let annotation segments be an empty list of
annotation segments, each potentially being associated with a base
text segment or subsegment.
Let root be the ruby element for which the algorithm is
being run.
If root has a ruby element ancestor, then jump to the
step labeled end.
Let current parent be root.
Let index be 0.
Let start index be null.
Let parent start index be null.
Let current base text be null.
Start mode: If index is equal to or
greater than the number of child nodes in current
parent, then jump to the step labeled end mode.
If the indexth node in current
parent is an rt or rp element, jump to the step labeled
annotation mode.
Set start index to the value of index.
Base mode: If the indexth node in
current parent is a ruby element, and if current
parent is the same element as root, then
push a ruby level and then jump to the
step labeled start mode.
If the indexth node in current
parent is an rt or rp element, then set the current base text and
then jump to the step labeled annotation mode.
Increment index by one.
Base mode post-increment: If index is
equal to or greater than the number of child nodes in current parent, then jump to the step labeled end
mode.
Jump back to the step labeled base mode.
Annotation mode: If the indexth node
in current parent is an rt element, then push a ruby annotation and jump
to the step labeled annotation mode increment.
If the indexth node in current
parent is an rp element, jump to the step labeled
annotation mode increment.
If the indexth node in current
parent is not a Text
node, or is a Text
node that is not inter-element whitespace, then
jump to the step labeled base mode.
Annotation mode increment: Let lookahead
index be index plus one.
Annotation mode white-space skipper: If lookahead index is equal to the number of child nodes in
current parent then jump to the step labeled
end mode.
If the lookahead indexth node in current parent is an rt element or an rp element, then set index to
lookahead index and jump to the step labeled
annotation mode.
If the lookahead indexth node in current parent is not a Text
node, or is a Text
node that is not inter-element whitespace, then
jump to the step labeled base mode (without further
incrementing index, so the inter-element whitespace seen
so far becomes part of the next base text segment).
Increment lookahead index by one.
Jump to the step labeled annotation mode white-space
skipper.
End mode: If current parent is not
the same element as root, then pop a ruby level and jump to the step
labeled base mode post-increment.
End: Return base text segments and
annotation segments. Any content of the
ruby element not described by segments in
either of thost lists is implicitly in an ignored
segment.
When the steps above say to set the current base text, it
means to run the following steps at that point in the
algorithm:
Let text range a DOM range whose start is the boundary point (current
parent, start index) and whose end is the boundary point (current
parent, index).
Let new text segment be a base text segment
described by the range annotation range.
Add new text segment to base
text segments.
Let current base text be new
text segment.
Let start index be null.
When the steps above say to push a
ruby level, it means to run the following steps at that point
in the algorithm:
Let current parent be the indexth node in current parent.
Let index be 0.
Set saved start index to the value of
start index.
Let start index be null.
When the steps above say to pop a
ruby level, it means to run the following steps at that point
in the algorithm:
Let index be the position of current parent in root.
Let current parent be root.
Increment index by one.
Set start index to the value of saved start index.
Let saved start index be null.
When the steps above say to push a ruby annotation, it means to
run the following steps at that point in the algorithm:
Let rt be the rt element that is the indexth node of current parent.
Let annotation range a DOM range whose
start is the boundary point (current
parent, index) and whose end is the boundary point (current
parent, index plus one) (i.e. that
contains only rt).
Let new annotation segment be an annotation
segment described by the range annotation
range.
If current base text is not null, associate
new annotation segment with current base text.
Add new annotation segment to annotation segments.
In this example, each ideograph in the Japanese text 漢字 is annotated with its reading in
hiragana.
...
<ruby>漢<rt>かん</rt>字<rt>じ</rt></ruby>
...
This might be rendered as:
In this example, each ideograph in the traditional Chinese text
漢字 is annotated with its
bopomofo reading.
<ruby>漢<rt>ㄏㄢˋ</rt>字<rt>ㄗˋ</rt></ruby>
This might be rendered as:
In this example, each ideograph in the simplified Chinese text
汉字 is annotated with its pinyin
reading.
...<ruby>汉<rt>hàn</rt>字<rt>zì</rt></ruby>...
This might be rendered as:
In this more contrived example, the acronym "HTML" has four
annotations: one for the whole acronym, briefly describing what it
is, one for the letters "HT" expanding them to "Hypertext", one for
the letter "M" expanding it to "Markup", and one for the letter "L"
expanding it to "Language".
<ruby>
<ruby>HT<rt>Hypertext</rt>M<rt>Markup</rt>L<rt>Language</rt></ruby>
<rt>An abstract language for describing documents and applications
</ruby>
The rt element marks the ruby text component of a
ruby annotation.
An rt element represents
an annotation (given by its children) for the zero or more nodes of
phrasing content that immediately precedes it in the ruby element, ignoring rp elements.
The rp element can be used to provide parentheses
around a ruby text component of a ruby annotation, to be shown by
user agents that don't support ruby annotations.
The example above, in which each ideograph in the text
漢字 is annotated with its phonetic
reading, could be expanded to use rp so that in legacy user agents the readings
are in parentheses:
The bdi element represents
a span of text that is to be isolated from its surroundings for the
purposes of bidirectional text formatting. [BIDI]
The dir global attribute defaults to
auto on this element (it never inherits from
the parent element like with other elements).
This element is especially useful when embedding user-generated
content with an unknown directionality.
In this example, usernames are shown along with the number of
posts that the user has submitted. If the bdi element were not used, the username of the
Arabic user would end up confusing the text (the bidirectional
algorithm would put the colon and the number "3" next to the word
"User" rather than next to the word "posts").
The bdo element represents
explicit text directionality formatting control for its children.
It allows authors to override the Unicode bidirectional algorithm
by explicitly specifying a direction override. [BIDI]
Authors must specify the dir attribute on this element, with the
value ltr to specify a left-to-right override and with
the value rtl to specify a right-to-left override.
In this example, a code fragment is marked up using
span elements and class attributes so that its keywords and
identifiers can be color-coded from CSS:
While line breaks are usually represented in visual
media by physically moving subsequent text to a new line, a style
sheet or user agent would be equally justified in causing line
breaks to be rendered in a different manner, for instance as green
dots, or as extra spacing.
br elements must be used only for line breaks
that are actually part of the content, as in poems or
addresses.
The following example is correct usage of the br element:
<p>P. Sherman<br>
42 Wallaby Way<br>
Sydney</p>
br elements must not be used for separating
thematic groups in a paragraph.
The following examples are non-conforming, as they abuse the
br element:
<p><a ...>34 comments.</a><br>
<a ...>Add a comment.</a></p>
If a paragraph consists of nothing but a single
br element, it represents a placeholder blank
line (e.g. as in a template). Such blank lines must not be used for
presentation purposes.
The wbr element represents
a line break opportunity.
In the following example, someone is quoted as saying something
which, for effect, is written as one long word. However, to ensure
that the text can be wrapped in a readable fashion, the individual
words in the quote are separated using a wbr element.
<p>So then he pointed at the tiger and screamed
"there<wbr>is<wbr&
