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.
Abstract
This specification defines the 5th major revision of the core
language of the World Wide Web: the Hypertext Markup Language
(HTML). In this version, new features are introduced to help Web
application authors, new elements are introduced based on research
into prevailing authoring practices, and special attention has been
given to defining clear conformance criteria for user agents in an
effort to improve interoperability.
Status of This document
This section describes the status of this document at the
time of its publication. Other documents may supersede this
document. A list of current W3C publications and the most recently
formally published revision of this technical report can be found in
the W3C technical reports index
at http://www.w3.org/TR/.
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.
The publication of this document by the W3C as a W3C Working
Draft does not imply that all of the participants in the W3C HTML
working group endorse the contents of the specification. Indeed, for
any section of the specification, one can usually find many members
of the working group or of the W3C as a whole who object strongly to
the current text, the existence of the section at all, or the idea
that the working group should even spend time discussing the concept
of that section.
The latest stable version of the editor's draft of this
specification is always available on the W3C CVS server and in the WHATWG Subversion
repository. The latest
editor's working copy (which may contain unfinished text in the
process of being prepared) contains the latest draft text of this
specification (amongst others). For more details, please see the WHATWG
FAQ.
There are various ways to follow the change history for the
HTML specifications:
Raw Subversion interface: svn checkout http://svn.whatwg.org/webapps/
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 24 June 2010 Working Draft snapshot.
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.
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
Status: Last call for comments
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
Status: Last call for comments
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
Status: Last call for comments
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 followed, reaching
completion in 1998.
At this time, 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.
A separate document has been published by the W3C HTML working
group to document the differences between this specification and the
language described in the HTML4 specification. [HTMLDIFF]
1.5 Design notes
Status: Last call for comments
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
Status: Last call for comments
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
Status: Last call for comments
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
Status: Last call for comments
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. This specification defines version 5 of DOM HTML, known
as "DOM5 HTML".
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 an HTML MIME
type, such as text/html, 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 XML 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 XML.
Similarly, documents that use the noscript feature can
be represented using the HTML syntax, but cannot be represented with
the DOM or in XML. Comments that contain the string "-->" can be represented in the DOM but not in the
HTML syntax or in XML.
1.7 Structure of this specification
Status: Last call for comments
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, 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.
1.7.2 Typographic conventions
Status: Last call for comments
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 A quick introduction to HTML
Status: Last call for comments
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 spaces 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.
DOM trees contain several kinds of nodes, in particular a DOCTYPE
node, elements, text nodes, and comment nodes.
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.
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 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.9.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.
Higher 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 four elements that were previously
presentational have been redefined in this specification to be
media-independent: b, i, hr,
and small.
1.9.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. 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
when hitting the highlighted end tag, since all the open elements
are examined first to see if they match the close tag:
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 "?hello=1&world=2":
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="?hello=1&world=2">Demo</a> <!-- &world 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 GRAVE ACCENT 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.9.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 row cannot simultaneously be a cell, nor can a
radio button be a progress bar.
<tr 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 realising 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 LOW LINE 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.10 Recommended reading
Status: Last call for comments
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.
2 Common infrastructure
2.1 Terminology
Status: Last call for comments
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.
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.
2.1.1 Resources
Status: Last call for comments
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.
A MPEG4 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
SEMICOLON 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. For CSS resources,
only @import rules introduce critical
subresources; other resources, e.g. fonts or backgrounds, are
not.
2.1.2 XML
Status: Last call for comments
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
http://www.w3.org/1999/xhtml namespace, and all
attributes defined or mentioned in this specification have no
namespace.
Attribute names are said to be XML-compatible if they
match the Name production defined in XML, they contain no
U+003A COLON 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
Status: Last call for comments
The term root element, when not explicitly qualified
as referring to the document'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, 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 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.
The term text node refers to any Text
node, including CDATASection nodes; specifically, any
Node with node type TEXT_NODE (3)
or CDATA_SECTION_NODE (4). [DOMCORE]
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.
2.1.4 Scripting
Status: Last call for comments
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.
The terms fire and dispatch are used interchangeably in the context of
events, as in the DOM Events specifications. The term trusted event is used as
defined by the DOM Events specification. [DOMEVENTS]
2.1.5 Plugins
Status: Last call for comments
The term plugin refers to a user-agent defined set of
content handlers used by the user agent that can take part in the
user agent's rendering of a Document object, but that
neither act as child browsing
contexts of the Document nor introduce any
Node objects to the Document's DOM.
Typically such content handlers are provided by third parties,
though a user agent can also designate built-in content handlers as
plugins.
A user agent must not consider the types text/plain
and application/octet-stream as having a registered
plugin.
One example of a plugin would be a PDF viewer
that is instantiated in a browsing context when the
user navigates to a PDF file. This would count as a plugin
regardless of whether the party that implemented the PDF viewer
component was the same as that which implemented the user agent
itself. However, a PDF viewer application that launches separate
from the user agent (as opposed to using the same interface) is not
a plugin by this definition.
This specification does not define a mechanism for
interacting with plugins, as it is expected to be user-agent- and
platform-specific. Some UAs might opt to support a plugin mechanism
such as the Netscape Plugin API; others might use remote content
converters or have built-in support for certain types. [NPAPI]
Browsers should take extreme care when
interacting with external content intended for plugins. When third-party software is run with
the same privileges as the user agent itself, vulnerabilities in the
third-party software become as dangerous as those in the user
agent.
2.1.6 Character encodings
Status: Last call for comments. ISSUE-101 (us-ascii-ref) blocks progress to Last Call
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 Unicode character is used to mean a
Unicode scalar value (i.e. any Unicode code point
that is not a surrogate code point). [UNICODE]
2.2 Conformance requirements
Status: Last call for comments
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. For readability, these words do
not appear in all uppercase letters in this specification. [RFC2119]
This specification describes the conformance criteria for
documents.
Conforming documents are those that comply with all
the conformance criteria for documents. For readability, some of
these conformance requirements are phrased as conformance
requirements on authors; such requirements are implicitly
requirements on documents: by definition, all documents are assumed
to have had an author. (In some cases, that author may itself be a
user agent â such user agents are subject to additional rules,
as explained below.)
For example, if a requirement states that
"authors must not use the foobar element", it
would imply that documents are not allowed to contain elements named
foobar.
For compatibility with existing content and prior specifications,
this specification describes two authoring formats: one based on XML
(referred to as the XHTML syntax), and one using a custom format inspired by SGML (referred to as
the HTML syntax).
2.2.1 Extensibility
Status: Last call for comments. ISSUE-41 (Decentralized-extensibility) blocks progress to Last Call
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 embed raw data using the <script type=""> mechanism with a custom
type, for further handling by a 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.
Authors can use the microdata feature (the item="" and itemprop="" attributes) to embed
nested name-value pairs of data to be shared with other
applications and sites.
2.3 Case-sensitivity and string comparison
Status: Last call for comments
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]
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
Status: Last call for comments
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.
2.4.1 Boolean attributes
Status: Last call for comments
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.
2.4.2 Keywords and enumerated attributes
Status: Last call for comments
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 must
be ignored.
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
Status: Last call for comments
2.4.3.1 Non-negative integers
Status: Last call for comments
A string is a valid non-negative integer if it
consists of one or more characters in the range U+0030 DIGIT ZERO
(0) to U+0039 DIGIT NINE (9).
A valid non-negative integer represents the number
that is represented in base ten by that string of digits.
2.4.3.2 Signed integers
Status: Last call for comments
A string is a valid integer if it consists of one or
more characters in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT
NINE (9), optionally prefixed with a U+002D HYPHEN-MINUS character
(-).
A valid integer without a U+002D HYPHEN-MINUS (-)
prefix represents the number that is represented in base ten by that
string of digits. A valid integerwith a
U+002D HYPHEN-MINUS (-) 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.3 Real numbers
Status: Last call for comments
A string is a valid floating point number if it
consists of:
Optionally, a U+002D HYPHEN-MINUS character (-).
A series of one or more characters in the range U+0030 DIGIT
ZERO (0) to U+0039 DIGIT NINE (9).
Optionally:
A single U+002E FULL STOP character (.).
A series of one or more characters in the range U+0030 DIGIT
ZERO (0) to U+0039 DIGIT NINE (9).
Optionally:
Either a U+0065 LATIN SMALL LETTER E character (e) or a
U+0045 LATIN CAPITAL LETTER E character (E).
Optionally, a U+002D HYPHEN-MINUS character (-) or U+002B
PLUS SIGN character (+).
A series of one or more characters in the range U+0030 DIGIT
ZERO (0) to U+0039 DIGIT NINE (9).
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
HYPHEN-MINUS 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 HYPHEN-MINUS character (-)
between the E and the number and the number is not zero, or else
ignoring a U+002B PLUS SIGN 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
Status: Last call for comments
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 U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9), used to
express numbers in base ten.
2.4.4.1 Months
Status: Last call for comments
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 HYPHEN-MINUS character (-)
Two digits,
representing the month month, in the range
1 â¤Â month â¤Â 12
2.4.4.2 Dates
Status: Last call for comments
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 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 COLON character (:)
Two digits,
representing minute, in the range
0 â¤Â minute â¤Â 59
Optionally (required if second is
non-zero):
A U+003A COLON 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 or more digits, representing the
fractional part of second
The second component cannot be
60 or 61; leap seconds cannot be represented.
2.4.4.4 Local dates and times
Status: Last call for comments
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 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:
A U+005A LATIN CAPITAL LETTER Z character (Z), allowed only
if the time zone is UTC
Or:
Either a U+002B PLUS SIGN character (+) or 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
A U+003A COLON 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, 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.
Midnight UTC 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.
To unambiguously identify a moment in time prior to the
introduction of the Gregorian calendar, 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.
Time-zone offsets differ based on daylight savings time.
2.4.4.6 Weeks
Status: Last call for comments
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.
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 HYPHEN-MINUS character (-)
A U+0057 LATIN CAPITAL LETTER W character (W)
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.7 Vaguer moments in time
Status: Last call for comments
A string is a valid date or time string if it is also
one of the following:
A string is a valid date or time string in content if
it consists of zero or more White_Space characters,
followed by a valid date or time string, followed by
zero or more further White_Space characters.
A string is a valid date string with optional time if
it is also one of the following:
A simple color consists of three 8-bit numbers in the
range 0..255, representing the red, green, and blue components of
the color respectively, in the sRGB color space. [SRGB]
A string is a valid simple color if it is exactly
seven characters long, and the first character is a U+0023 NUMBER
SIGN character (#), and the remaining six characters are all in the
range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9), 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
Status: Last call for comments
A set of space-separated tokens is a string containing
zero or more words 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 words
are duplicated.
An ordered set of unique space-separated tokens is a
set of space-separated tokens where none of the words
are duplicated but where the order of the tokens is meaningful.
Sets of
space-separated tokens sometimes have a defined set of
allowed values. When a set of allowed values is defined, the tokens
must all be from that list of allowed values; other values are
non-conforming. If no such set of allowed values is provided, then
all values are conforming.
2.4.7 Comma-separated tokens
Status: Last call for comments
A set of comma-separated tokens is a string containing
zero or more tokens each separated from the next by a single U+002C
COMMA character (,), where tokens consist of any string of zero or
more characters, neither beginning nor ending with space characters, nor containing any
U+002C COMMA 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
Status: Last call for comments
A valid hash-name reference to an element of type type is a string consisting of a U+0023 NUMBER SIGN
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
Status: Last call for comments
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
Status: Last call for comments. ISSUE-56 (urls-webarch) blocks progress to Last Call
2.5.1 Terminology
Status: Last call for comments
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:
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 SOLIDUS 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 SOLIDUS characters (//).
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]
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.2 Interfaces for URL manipulation
Status: Last call for comments
An interface that has a complement of URL decomposition IDL
attributes will have seven attributes with the following
definitions:
The (empty) <fragment> component is not part of the <query> component.
2.6 Common DOM interfaces
Status: Last call for comments
2.6.1 Reflecting content attributes in IDL attributes
Status: Last call for comments
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.
When a collection is created, a
filter and a root are associated with the collection.
For example, when the HTMLCollection
object for the document.images attribute is
created, it is associated with a filter that selects only
img elements, and rooted at the root of the
document.
The collection then represents a
live view of the subtree rooted at the collection's
root, containing only nodes that match the given filter. The view is
linear.
interface HTMLCollection {
readonly attribute unsigned long length;
caller getter object item(in unsigned long index); // only returns Element
caller getter object namedItem(in DOMString name); // only returns Element
};
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.
Returns null if no element with that ID or name could be found.
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.4 HTMLOptionsCollection
Status: Last call for comments
The HTMLOptionsCollection interface represents a
list of option elements. It is always rooted on a
select element and has attributes and methods that
manipulate that element's descendants.
interface HTMLOptionsCollection : HTMLCollection {
// inherits item()
attribute unsigned long length; // overrides inherited length
caller getter object namedItem(in DOMString name); // overrides inherited namedItem()
void add(in HTMLElement element, in optional HTMLElement before);
void add(in HTMLElement element, in long before);
void remove(in long index);
};
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 HIERARCHY_REQUEST_ERR
exception if element is an ancestor of the
element into which it is to be inserted. If element is not an option or
optgroup element, then the method does nothing.
Adds token if it is not present, or removes
it if it is. Returns true if token is now
present (it was added); returns false if it is not (it was
removed).
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.6 DOM feature strings
Status: Last call for comments
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.
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.
3 Semantics, structure, and APIs of HTML documents
Status: Last call for comments
3.1 Documents
Status: Last call for comments
Every XML and HTML document in an HTML UA is represented by a
Document object. [DOMCORE]
Document objects are assumed to be XML
documents unless they are flagged as being HTML
documents when they are created. Whether a document is an
HTML document or an XML document affects the behavior of
certain APIs and the case-sensitivity of some selectors.
3.1.1 Documents in the DOM
Status: Last call for comments
All Document objects (in user agents implementing
this specification) also implement
the HTMLDocument interface, available using
binding-specific methods. (This is the case whether or not the
document in question is an HTML
document or indeed whether it contains any HTML
elements at all.) Document objects also implement the document-level interface
of any other namespaces that the UA supports.
For example, if an HTML implementation also
supports SVG, then the Document object implements both
HTMLDocument and SVGDocument.
Because the HTMLDocument interface is
now obtained using binding-specific casting methods instead of
simply being the primary interface of the document object, it is no
longer defined as inheriting from Document.
Since the HTMLDocument interface holds methods and
attributes related to a number of disparate features, the members of
this interface are described in various different sections.
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.
In a conforming document, returns the string "CSS1Compat". (In quirks mode
documents, returns the string "BackCompat",
but a conforming document can never trigger quirks
mode.)
Returns what might be the user agent's default character
encoding. (The user agent might return another character encoding
altogether, e.g. to protect the user's privacy, or if the user
agent doesn't use a single default encoding.)
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 the elements in the object
on which the method was invoked (a Document or an
Element) that have all the classes given by classes.
The classes argument is interpreted as a
space-separated list of classes.
HTML, SVG, and MathML elements define which classes they are in
by having an attribute with no namespace with the name class containing a space-separated list of classes
to which the element belongs. Other specifications may also allow
elements in their namespaces to be labeled as being in specific
classes.
A call to document.getElementById('example').getElementsByClassName('aaa')
would return a NodeList with the two paragraphs p1 and p2 in it.
A call to getElementsByClassName('ccc bbb') would only
return one node, however, namely p3. A call
to document.getElementById('example').getElementsByClassName('bbb  ccc ')
would return the same thing.
A call to getElementsByClassName('aaa,bbb') would return no
nodes; none of the elements above are in the "aaa,bbb" class.
The dir
attribute on the HTMLDocument interface is defined
along with the dir content
attribute.
Returns a new Document, with a basic DOM already
constructed with an appropriate title element.
3.2 Elements
Status: Last call for comments
3.2.1 Semantics
Status: Last call for comments. ISSUE-41 (Decentralized-extensibility) blocks progress to Last Call
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.
Authors must not use elements, attributes, or attribute values
for purposes other than their appropriate intended semantic
purpose. Authors must not use elements, attributes, or attribute
values that are not permitted by this specification or other
applicable specifications.
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). 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>
...
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
Status: Last call for comments
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
Status: Last call for comments
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.
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).
3.2.3.1 The id attribute
Status: Last call for comments
The id attribute specifies its
element's unique identifier (ID). 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.
3.2.3.2 The title attribute
Status: Last call for comments
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; and so forth. The
value is text.
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 U+000A LINE FEED (LF) characters, the content is split into
multiple lines. Each U+000A LINE FEED (LF) 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 dir attribute specifies the
element's text directionality. The attribute is an enumerated
attribute with the keyword ltr mapping
to the state ltr, and the keyword rtl
mapping to the state rtl. The attribute has no invalid
value default and no missing value default.
The directionality of an element, which is used in
particular by the canvas element's text rendering API,
is either 'ltr' or 'rtl'. If the user agent supports CSS and the
'direction' property on this element has a computed value of either
'ltr' or 'rtl', then that is the directionality of the
element. Otherwise, if the element is being rendered,
then the directionality of the element is the
directionality used by the presentation layer, potentially
determined from the value of the dir
attribute on the element. Otherwise, if the element's dir attribute has the state ltr, the
element's directionality is 'ltr' (left-to-right); if the attribute
has the state rtl, the element's directionality is 'rtl'
(right-to-left); and otherwise, the element's directionality is the
same as its parent element, or 'ltr' if there is no parent
element.
Can be set, to either "ltr" or "rtl", 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).
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.7 The style attribute
Status: Last call for comments
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.)
Returns a CSSStyleDeclaration object for the element's style 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.8 Embedding custom non-visible data
Status: Last call for comments
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 capitalized 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.
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.
3.2.4 Element definitions
Status: Last call for comments
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 may 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.
Content model
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
Status: Last call for comments
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
Status: Last call for comments
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.
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.
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
Status: Last call for comments
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:
In addition, certain elements are categorized as form-associated elements and
further subcategorized to define their role in various form-related
processing models.
Some elements have unique requirements and do not fit into any
particular category.
3.2.5.1.1 Metadata content
Status: Last call for comments
Metadata content is content that sets up the
presentation or behavior of the rest of the content, or that sets
up the relationship of the document with other documents, or that
conveys other "out of band" information.
Elements from other namespaces whose semantics are primarily
metadata-related (e.g. RDF) are also metadata
content.
Thus, in the XML serialization, one can use RDF, like this:
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:r="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<head>
<title>Hedral's Home Page</title>
<r:RDF>
<Person xmlns="http://www.w3.org/2000/10/swap/pim/contact#"
r:about="http://hedral.example.com/#">
<fullName>Cat Hedral</fullName>
<mailbox r:resource="mailto:hedral@damowmow.com"/>
<personalTitle>Sir</personalTitle>
</Person>
</r:RDF>
</head>
<body>
<h1>My home page</h1>
<p>I like playing with string, I guess. Sister says squirrels are fun
too so sometimes I follow her to play with them.</p>
</body>
</html>
This isn't possible in the HTML serialization, however.
3.2.5.1.2 Flow content
Status: Last call for comments
Most elements that are used in the body of documents and
applications are categorized as flow content.
As a general rule, elements whose content model allows any
flow 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,
del elements and their descendants must not be counted
as contributing to the ancestors of the del
element.
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.
3.2.5.1.3 Sectioning content
Status: Last call for comments
Sectioning content is content that defines the scope
of headings and footers.
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.
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
Status: Last call for comments
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 followed by a DOMActivate event.
3.2.5.2 Transparent content models
Status: Last call for comments
Some elements are described as transparent; they have
"transparent" in the description of their content model.
When a content model includes a part that is "transparent", those
parts must not contain content that would not be conformant if all
transparent elements in the tree were replaced, in their parent
element, by the children in the "transparent" part of their content
model, retaining order.
Since that is conforming, the contents of the a are
conforming in the original fragment.
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
Status: Last call for comments
The term paragraph as defined in this
section is distinct from (though related to) the p
element defined later. The paragraph concept defined
here is used to describe how to interpret documents.
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.
<aside>
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.
</aside>
Here is another way of marking this up, this time showing the
paragraphs explicitly, and splitting the one link element into
three:
<aside>
<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>
</aside>
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.
3.2.6 Annotations for assistive technology products (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 following table defines the strong native
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. Authors must not set the ARIA role and aria-* attributes in a manner that
conflicts with the semantics described in the following table.
checkbox role, with the 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 state 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 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 state 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 state 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,
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 overriden, 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.
Role must be either region, document, application, contentinfo (ARIA restricts usage of this role to one per page), main (ARIA restricts usage of this role to one per page), search, alert, dialog, alertdialog, status, or log
For HTML documents, and for HTML
elements in HTML documents, certain APIs defined
in DOM Core become case-insensitive or case-changing, as sometimes
defined in DOM Core, and as summarized below. [DOMCORE]
These attributes return element
names converted to ASCII uppercase, regardless of the case
with which they were created.
Document.createElement()
The canonical form of HTML markup is all-lowercase; thus, this
method will lowercase
the argument before creating the requisite element. .
This doesn't apply to Document.createElementNS(). Thus, it is possible,
by passing this last method a tag name in the wrong case, to
create an element that appears to have the same tag name as that
of an element defined in this specification when its tagName attribute is examined, but that
doesn't support the corresponding interfaces. The "real" element
name (unaffected by case conversions) can be obtained from the
localName attribute.
This doesn't apply to Element.getAttributeNS() and Element.getAttributeNodeNS().
Document.getElementsByTagName()
Element.getElementsByTagName()
HTML elements match by lower-casing the argument before
comparison, elements from other namespaces are treated as in XML
(case-sensitively).
Thus, in an HTML
document with nodes in multiple namespaces, these methods
will effectively be both case-sensitive and case-insensitive at
the same time.
3.4 Dynamic markup insertion
Status: Last call for comments
APIs for dynamically inserting markup into the
document interact with the parser, and thus their behavior varies
depending on whether they are used with HTML documents
(and the HTML parser) or XHTML in XML
documents (and the XML parser).
3.4.1 Opening the input stream
Status: Last call for comments
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.
Unless called from the body of a script element
while the document is being parsed, or called on a script-created
document, calling this method will clear the current page first,
as if document.open() had
been called.
Returns a fragment of HTML or XML that represents the element's
contents.
Can be set, to replace the contents of the element with nodes
parsed from the given string.
In the case of XML documents, will throw an
INVALID_STATE_ERR if the element cannot be serialized
to XML, and a SYNTAX_ERR if the given string is not
well-formed.
Returns a fragment of HTML or XML that represents the element
and its contents.
Can be set, to replace the element with nodes parsed from the
given string.
In the case of XML documents, will throw an
INVALID_STATE_ERR if the element cannot be serialized
to XML, and a SYNTAX_ERR if the given string is not
well-formed.
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 are links to resources that are to be
used to augment the current document, and hyperlink links are links to
other documents. The link types
section defines whether a particular link type is an external
resource or a hyperlink. One 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 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.
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
Status: Last call for comments
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. This value must
not be used on hand-authored pages.
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.
4.2.5.2 Other metadata names
Status: Last call for comments. ISSUE-27 (rel-ownership) blocks progress to Last Call
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
Status: Last call for comments
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 SEMICOLON character (;), followed by one or more space characters, followed by
either a U+0055 LATIN CAPITAL LETTER U character (U) or a U+0075
LATIN SMALL LETTER U character (u), a U+0052 LATIN CAPITAL LETTER
R character (R) or a U+0072 LATIN SMALL LETTER R character (r), a
U+004C LATIN CAPITAL LETTER L character (L) or a U+006C LATIN
SMALL LETTER L character (l), a U+003D EQUALS SIGN character (=),
and then a valid URL.
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
Status: Last call for comments
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.
Authors are encouraged to use UTF-8. Conformance checkers may
advise authors against using legacy encodings.
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][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, 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 set, 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.
The title attribute on
style elements defines alternative style sheet
sets. If the style element has no title attribute, then it has no
title; the title attribute of
ancestors does not apply to the style element. [CSSOM]
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 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
Status: Last call for comments
The link and style elements can provide
styling information for the user agent to use when rendering the
document. The DOM Styling specification specifies what styling
information is to be used by the user agent and how it is to be
used. [CSSOM]
The style and link elements implement
the LinkStyle interface. [CSSOM]
4.3 Scripting
Status: Last call for comments
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.
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, and
the src attribute must not be
specified.
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">
<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 onformchange="calculate(form)"></output></p>
</fieldset>
<script>
document.forms.pricecalc.dispatchFormChange();
</script>
</form>
4.3.1.1 Scripting languages
Status: Last call for comments
The following lists some MIME type strings and the
languages to which they refer:
4.3.1.2 Restrictions for contents of script elements
Status: Last call for comments
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 SOLIDUS 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 ; U+0009 CHARACTER TABULATION
tag-end =/ %x000A ; U+000A LINE FEED (LF)
tag-end =/ %x000C ; U+000C FORM FEED (FF)
tag-end =/ %x0020 ; U+0020 SPACE
tag-end =/ %x002F ; U+002F SOLIDUS (/)
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
Status: Last call for comments
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 ; U+0009 TAB
newline = %x000A ; U+000A LINE FEED (LF)
space = %x0020 ; U+0020 SPACE
star = %x002A ; U+002A ASTERISK (*)
slash = %x002F ; U+002F SOLIDUS (/)
not-newline = %x0000-0009 / %x000B-10FFFF
; a Unicode character other than U+000A LINE FEED (LF)
not-star = %x0000-0029 / %x002B-10FFFF
; a Unicode character other than U+002A ASTERISK (*)
not-slash = %x0000-002E / %x0030-10FFFF
; a Unicode character other than U+002F SOLIDUS (/)
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.
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, 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 for styling purposes or as a convenience for scripting,
authors are encouraged to use the div element
instead. A general rule is that the section element is
appropriate only if the element's contents would be listed
explicitly in the document's outline.
In the following example, we see an article (part of a larger
Web page) about apples, containing two short sections.
<article>
<hgroup>
<h1>Apples</h1>
<h2>Tasty, delicious fruit!</h2>
</hgroup>
<p>The apple is the pomaceous fruit of the apple tree.</p>
<section>
<h1>Red Delicious</h1>
<p>These bright red apples are the most common found in many
supermarkets.</p>
</section>
<section>
<h1>Granny Smith</h1>
<p>These juicy, green apples make a great filling for
apple pies.</p>
</section>
</article>
Notice how the use of section means that the author
can use h1 elements throughout, without having to
worry about whether a particular section is at the top level, the
second level, the third level, and so on.
Here is a graduation programme with two sections, one for the
list of people graduating, and one for the description of the
ceremony.
The 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 â only sections that consist of major
navigation blocks are appropriate for the nav
element. 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,
without a nav element.
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.
The article element represents a
self-contained composition in a document, page, application, or site
and that is intended to be independently distributable or reusable,
e.g. in syndication. This could be a forum post, a magazine or
newspaper article, a blog entry, a user-submitted comment, an
interactive widget or gadget, or any other independent item of
content.
When article elements are nested, the inner
article elements represent articles that are in
principle related to the contents of the outer article. For
instance, a blog entry on a site that accepts user-submitted
comments could represent the comments as article
elements nested within the article element for the blog
entry.
Author information associated with an article
element (q.v. the address element) does not apply to
nested article elements.
When used specifically with content to be
redistributed in syndication, the article element is
similar in purpose to the entry element in
Atom. [ATOM]
The time element's pubdate attribute can be used to
provide the publication date for an article
element.
This example shows a blog post using the article
element:
<article>
<header>
<h1>The Very First Rule of Life</h1>
<p><time pubdate datetime="2009-10-09T14:28-08:00"></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 pubdate datetime="2009-10-09T14:28-08:00"></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>
<footer>
<p>Posted by: George Washington</p>
<p><time pubdate datetime="2009-10-10T19:10-08:00"></time></p>
</footer>
<p>Yeah! Especially when talking about your lobbyist friends!</p>
</article>
<article>
<footer>
<p>Posted by: George Hammond</p>
<p><time pubdate datetime="2009-10-10T19:15-08:00"></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
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.
These two snippets are 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>
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.
For the purposes of document summaries, outlines, and the like,
the text of hgroup elements is defined to be the text
of the highest rankedh1âh6 element descendant of the
hgroup element, if there are any such elements, and the
first such element if there are multiple elements with that
rank. If there are no such elements, then the text of
the hgroup element is the empty string.
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).
Here are some examples of valid headings. In each case, the
emphasized text represents the text that would be used as the
heading in an application extracting heading data and ignoring
subheadings.
<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.
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.
Contact information for the author or editor of a
section belongs in an address element, possibly itself
inside a footer.
Footers don't necessarily have to appear at the end of a
section, though they usually do.
When the footer element contains entire sections,
they represent appendices, indexes,
long colophons, verbose license agreements, and other such
content.
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.
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:
Typically, the address element would be included
along with other information in a footer element.
4.4.11 Headings and sections
Status: Last call for comments
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.
4.4.11.1 Creating an outline
Status: Last call for comments
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.)
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.
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 Commonwearth 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>
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>
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 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.
The value
attribute, if present, must be a valid integer giving
the ordinal value of the list item.
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.
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, 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="#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, the figure has three images in it.
<figure>
<img src="castle1423.jpeg" title="Etching. Anonymous, ca. 1423."
alt="The castle has one tower, and a tall wall around it.">
<img src="castle1858.jpeg" title="Oil-based paint on canvas. Maria Towle, 1858."
alt="The castle now has two towers and two walls.">
<img src="castle1999.jpeg" title="Film photograph. Peter Jankle, 1999."
alt="The castle lies in ruins, the original tower all that remains in one piece.">
<figcaption>The castle through the ages: 1423, 1858, and 1999 respectively.</figcaption>
</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 the div element
instead of more appropriate elements leads to poor accessibility for
readers and poor 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 emphasis that a particular piece of content has is
given by its number of ancestor em elements.
The placement of emphasis changes the meaning of the sentence.
The element thus forms an integral part of the content. The precise
way in which emphasis is used in this way depends on the
language.
These examples show how changing the emphasis changes the
meaning. First, a general statement of fact, with no emphasis:
<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 emphasis 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
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 footer contains contact information and a
copyright notice.
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 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 "GDO" is first defined in
the first paragraph, then used in the second.
<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="#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 a 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 either a
time on a 24 hour clock, or a precise date in the proleptic
Gregorian calendar, optionally with a time and a time-zone
offset. [GREGORIAN]
This element is intended as a way to encode modern dates and
times in a machine-readable way so that, for example, user agents
can offer to add birthday reminders or scheduled events to the
user's calendar.
The time element is not intended for encoding times
for which a precise date or time cannot be established. For
example, it would be inappropriate for encoding times like "one
millisecond after the big bang", "the early part of the Jurassic
period", or "a winter around 250 BCE".
For dates before the introduction of the Gregorian calendar,
authors are encouraged to not use the time element, or
else to be very careful about converting dates and times from the
period to the Gregorian calendar. This is complicated by the manner
in which the Gregorian calendar was phased in, which occurred at
different times in different countries, ranging from partway
through the 16th century all the way to early in the 20th.
The pubdate
attribute is a boolean attribute. If specified, it
indicates that the date and time given by the element is the
publication date and time of the nearest ancestor
article element, or, if the element has no ancestor
article element, of the document as a whole. If the
element has a pubdate
attribute specified, then the element needs a date. For
each article element, there must no more than one
time element with a pubdate attribute whose nearest
ancestor is that article element. Furthermore, for each
Document, there must be no more than one
time element with a pubdate attribute that does not
have an ancestor article element.
The datetime
attribute, if present, gives the date or time being
specified. Otherwise, the date or time is given by the element's
contents.
The date, if any, must be expressed using the Gregorian
calendar.
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="2007-10-05">October 5</time> -
<time class="dtend" datetime="2007-10-20">19</time>,
at the <span class="location">Argent Hotel, San Francisco, CA</span>
</div>
(The end date is encoded as one day after the last date of the
event because in the iCalendar format, end dates are
exclusive, not inclusive.)
The time element is not necessary for encoding
dates or times. In the following snippet, the time is encoded using
time, so that it can be restyled (e.g. using XBL2) to
match local conventions, while the year is not marked up at all,
since marking it up would not be particularly useful.
<p>I usually have a snack at <time>16:00</time>.</p>
<p>I've liked model trains since at least 1983.</p>
Using a styling technology that supports restyling times, the
first paragraph from the above snippet could be rendered as follows:
Returns a Date object representing the specified date and time.
In the following snippet:
<p>Our first date was <time datetime="2006-09-23">a Saturday</time>.</p>
...the time element's valueAsDate attribute would
have the value 1,158,969,600,000ms.
In the following snippet:
<p>Many people get up at <time>08:00</time>.</p>
...the time element's valueAsDate attribute would
have the value 28,800,000ms.
In this example, an article's publication date is marked up
using time:
<article>
<h1>Small tasks</h1>
<footer>Published <time pubdate>2009-08-30</time>.</footer>
<p>I put a bike bell on his bike.</p>
</article>
Here is another way that could be marked up. In this example,
legacy user agents would say "today", while newer user agents would
render the time in a locale-specific manner based on the value of
the attribute.
<article>
<h1>Small tasks</h1>
<footer>Published <time pubdate datetime="2009-08-30">today</time>.</footer>
<p>I put a bike bell on his bike.</p>
</article>
Here is the same thing but with the time included only. Because
the element is empty, legacy user agents will not show anything
useful; user agents that implement this specification, on the other
hand, would show the date and time in a locale-specific manner.
<article>
<h1>Small tasks</h1>
<footer>Published <time pubdate datetime="2009-08-30T07:13Z"></time>.</footer>
<p>I put a bike bell on his bike.</p>
</article>
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, or it could 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>
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, such as a taxonomic designation, a technical term, an
idiomatic phrase from another language, a thought, a ship name, or
some other prose whose typical typographic presentation is
italicized.
<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 are encouraged to 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. Similarly, 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 be stylistically offset from the normal prose without conveying
any extra importance, such as key words in a document abstract,
product names in a review, or other spans of text whose typical
typographic presentation is boldened.
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 are encouraged to 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 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>
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.
A ruby element represents the spans of
phrasing content it contains, ignoring all the child rt
and rp elements and their descendants. Those spans of
phrasing content have associated annotations created using the
rt element.
In this example, each ideograph in the Japanese text æ¼¢å is annotated with its
reading in hiragana.
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.
4.6.20 The rp element
Status: Last call for comments
Categories
None.
Contexts in which this element may be used:
As a child of a ruby element, either immediately before or immediately after an rt element.
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 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.
The span element doesn't mean anything on its own,
but can be useful when used together with other attributes,
e.g. class, lang, or dir. It represents its
children.
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:
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>no<wbr>way<wbr>you<wbr>are<wbr>ever<wbr>going<wbr>to<wbr>catch<wbr>me"!</p>
The following example represents the addition of two paragraphs,
the second of which was inserted in two parts. The first
ins element in this example thus crosses a paragraph
boundary, which is considered poor form.
<aside>
<!-- don't do this -->
<ins datetime="2005-03-16T00:00Z">
<p> I like fruit. </p>
Apples are <em>tasty</em>.
</ins>
<ins datetime="2007-12-19T00:00Z">
So are pears.
</ins>
</aside>
Here is a better way of marking this up. It uses more elements,
but none of the elements cross implied paragraph boundaries.
<aside>
<ins datetime="2005-03-16T00:00Z">
<p> I like fruit. </p>
</ins>
<ins datetime="2005-03-16T00:00Z">
Apples are <em>tasty</em>.
</ins>
<ins datetime="2007-12-19T00:00Z">
So are pears.
</ins>
</aside>
The following shows a "to do" list where items that have been
done are crossed-off with the date and time of their
completion.
<h1>To Do</h1>
<ul>
<li>Empty the dishwasher</li>
<li><del datetime="2009-10-11T01:25-07:00">Watch Walter Lewin's lectures</del></li>
<li><del datetime="2009-10-10T23:38-07:00">Download more tracks</del></li>
<li>Buy a printer</li>
</ul>
The cite attribute
may be used to specify the address of a document that explains the
change. When that document is long, for instance the minutes of a
meeting, authors are encouraged to include a fragment identifier
pointing to the specific part of that document that discusses the
change.
Since the ins and del elements do not
affect paragraphing, it is possible,
in some cases where paragraphs are implied (without explicit p
elements), for an ins or del element to
span both an entire paragraph or other non-phrasing
content elements and part of another paragraph. For
example:
<section>
<ins>
<p>
This is a paragraph that was inserted.
</p>
This is another paragraph whose first sentence was inserted
at the same time as the paragraph above.
</ins>
This is a second sentence, which was there all along.
</section>
By only wrapping some paragraphs in p elements, one
can even get the end of one paragraph, a whole second paragraph,
and the start of a third paragraph to be covered by the same
ins or del element (though this is very
confusing, and not considered good practice):
<section>
This is the first paragraph. <ins>This sentence was
inserted.
<p>This second paragraph was inserted.</p>
This sentence was inserted too.</ins> This is the
third paragraph in this example.
<!-- (don't do this) -->
</section>
However, due to the way implied
paragraphs are defined, it is not possible to mark up the
end of one paragraph and the start of the very next one using the
same ins or del element. You instead have
to use one (or two) p element(s) and two
ins or del elements, as for example:
<section>
<p>This is the first paragraph. <del>This sentence was
deleted.</del></p>
<p><del>This sentence was deleted too.</del> That
sentence needed a separate <del> element.</p>
</section>
Partly because of the confusion described above, authors are
strongly encouraged to always mark up all paragraphs with the
p element, instead of having ins or
del elements that cross implied
paragraphs boundaries.
4.7.5 Edits and lists
Status: Last call for comments
This section is non-normative.
The content models of the ol and ul
elements do not allow ins and del elements
as children. Lists always represent all their items, including items
that would otherwise have been marked as deleted.
To indicate that an item is inserted or deleted, an
ins or del element can be wrapped around
the contents of the li element. To indicate that an
item has been replaced by another, a single li element
can have one or more del elements followed by one or
more ins elements.
In the following example, a list that started empty had items
added and removed from it over time. The bits in the example that
have been emphasized show the parts that are the "current" state of
the list. The list item numbers don't take into account the edits,
though.
<h1>Stop-ship bugs</h1>
<ol>
<li><ins datetime="2008-02-12T15:20Z">Bug 225:
Rain detector doesn't work in snow</ins></li>
<li><del datetime="2008-03-01T20:22Z"><ins datetime="2008-02-14T12:02Z">Bug 228:
Water buffer overflows in April</ins></del></li>
<li><ins datetime="2008-02-16T13:50Z">Bug 230:
Water heater doesn't use renewable fuels</ins></li>
<li><del datetime="2008-02-20T21:15Z"><ins datetime="2008-02-16T14:25Z">Bug 232:
Carbon dioxide emissions detected after startup</ins></del></li>
</ol>
In the following example, a list that started with just fruit
was replaced by a list with just colors.
Images can thus be static bitmaps (e.g. PNGs, GIFs,
JPEGs), single-page vector documents (single-page PDFs, XML files
with an SVG root element), animated bitmaps (APNGs, animated GIFs),
animated vector graphics (XML files with an SVG root element that
use declarative SMIL animation), and so forth. However, this also
precludes SVG files with script, multipage PDF files, interactive
MNG files, HTML documents, plain text documents, and so forth.
The img must not be used as a layout tool. In
particular, img elements should not be used to display
transparent images, as they rarely convey meaning and rarely add
anything useful to the document.
The usemap attribute,
if present, can indicate that the image has an associated
image map.
The ismap
attribute, when used on an element that is a descendant of an
a element with an href attribute, indicates by its
presence that the element provides access to a server-side image
map. This affects how events are handled on the corresponding
a element.
The ismap attribute is a
boolean attribute. The attribute must not be specified
on an element that does not have an ancestor a element
with an href attribute.
Returns a new img element, with the width and height attributes set to the values
passed in the relevant arguments, if applicable.
A single image can have different appropriate alternative text
depending on the context.
In each of the following cases, the same image is used, yet the
alt text is different each
time. The image is the coat of arms of the Carouge municipality in
the canton Geneva in Switzerland.
Here it is used as a supplementary icon:
<p>I lived in <img src="carouge.svg" alt=""> Carouge.</p>
<p>Carouge has a coat of arms.</p>
<p><img src="carouge.svg" alt="The coat of arms depicts a lion, sitting in front of a tree."></p>
<p>It is used as decoration all over the town.</p>
Here it is used as a way to support a similar text where the
description is given as well as, instead of as an alternative to,
the image:
<p>Carouge has a coat of arms.</p>
<p><img src="carouge.svg" alt=""></p>
<p>The coat of arms depicts a lion, sitting in front of a tree.
It is used as decoration all over the town.</p>
Here it is used as part of a story:
<p>He picked up the folder and a piece of paper fell out.</p>
<p><img src="carouge.svg" alt="Shaped like a shield, the paper had a
red background, a green tree, and a yellow lion with its tongue
hanging out and whose tail was shaped like an S."></p>
<p>He stared at the folder. S! The answer he had been looking for all
this time was simply the letter S! How had he not seen that before? It all
came together now. The phone call where Hector had referred to a lion's tail,
the time Marco had stuck his tongue out...</p>
Here it is not known at the time of publication what the image
will be, only that it will be a coat of arms of some kind, and thus
no replacement text can be provided, and instead only a brief
caption for the image is provided, in the title attribute:
<p>The last user to have uploaded a coat of arms uploaded this one:</p>
<p><img src="last-uploaded-coat-of-arms.cgi" title="User-uploaded coat of arms."></p>
Ideally, the author would find a way to provide real replacement
text even in this case, e.g. by asking the previous user. Not
providing replacement text makes the document more difficult to use
for people who are unable to view images, e.g. blind users, or
users or very low-bandwidth connections or who pay by the byte, or
users who are forced to use a text-only Web browser.
Here are some more examples showing the same picture used in
different contexts, with different appropriate alternate texts each
time.
<article>
<h1>My cats</h1>
<h2>Fluffy</h2>
<p>Fluffy is my favorite.</p>
<img src="fluffy.jpg" alt="She likes playing with a ball of yarn.">
<p>She's just too cute.</p>
<h2>Miles</h2>
<p>My other cat, Miles just eats and sleeps.</p>
</article>
<article>
<h1>Photography</h1>
<h2>Shooting moving targets indoors</h2>
<p>The trick here is to know how to anticipate; to know at what speed and
what distance the subject will pass by.</p>
<img src="fluffy.jpg" alt="A cat flying by, chasing a ball of yarn, can be
photographed quite nicely using this technique.">
<h2>Nature by night</h2>
<p>To achieve this, you'll need either an extremely sensitive film, or
immense flash lights.</p>
</article>
<article>
<h1>About me</h1>
<h2>My pets</h2>
<p>I've got a cat named Fluffy and a dog named Miles.</p>
<img src="fluffy.jpg" alt="Fluffy, my cat, tends to keep itself busy.">
<p>My dog Miles and I like go on long walks together.</p>
<h2>music</h2>
<p>After our walks, having emptied my mind, I like listening to Bach.</p>
</article>
<article>
<h1>Fluffy and the Yarn</h1>
<p>Fluffy was a cat who liked to play with yarn. He also liked to jump.</p>
<aside><img src="fluffy.jpg" alt="" title="Fluffy"></aside>
<p>He would play in the morning, he would play in the evening.</p>
</article>
4.8.1.1 Requirements for providing text to act as an alternative for images
Status: Last call for comments. ISSUE-31 (missing-alt) blocks progress to Last Call
Except where otherwise specified, the alt attribute must be specified and its
value must not be empty; the value must be an appropriate
replacement for the image. The specific requirements for the alt attribute depend on what the image
is intended to represent, as described in the following
sections.
4.8.1.1.1 A link or button containing nothing but the image
Status: Last call for comments
When an a element that is a hyperlink,
or a button element, has no textual content but
contains one or more images, the alt attributes must contain text that
together convey the purpose of the link or button.
In this example, a user is asked to pick his preferred color
from a list of three. Each color is given by an image, but for
users who have configured their user agent not to display images,
the color names are used instead:
In this example, each button has a set of images to indicate the
kind of color output desired by the user. The first image is used
in each case to give the alternative text.
4.8.1.1.2 A phrase or paragraph with an alternative graphical representation: charts, diagrams, graphs, maps, illustrations
Sometimes something can be more clearly stated in graphical
form, for example as a flowchart, a diagram, a graph, or a simple
map showing directions. In such cases, an image can be given using
the img element, but the lesser textual version must
still be given, so that users who are unable to view the image
(e.g. because they have a very slow connection, or because they
are using a text-only browser, or because they are listening to
the page being read out by a hands-free automobile voice Web
browser, or simply because they are blind) are still able to
understand the message being conveyed.
The text must be given in the alt attribute, and must convey the
same message as the image specified in the src attribute.
It is important to realize that the alternative text is a
replacement for the image, not a description of the
image.
In the following example we have a flowchart in image
form, with text in the alt
attribute rephrasing the flowchart in prose form:
<p>In the common case, the data handled by the tokenization stage
comes from the network, but it can also come from script.</p>
<p><img src="http://dev.w3.org/html5/spec/images/parsing-model-overview.png" alt="The network
passes data to the Tokenizer stage, which passes data to the Tree
Construction stage. From there, data goes to both the DOM and to
Script Execution. Script Execution is linked to the DOM, and, using
document.write(), passes data to the Tokenizer."></p>
Here's another example, showing a good solution and a bad
solution to the problem of including an image in a
description.
First, here's the good solution. This sample shows how the
alternative text should just be what you would have put in the
prose if the image had never existed.
<!-- This is the correct way to do things. -->
<p>
You are standing in an open field west of a house.
<img src="house.jpeg" alt="The house is white, with a boarded front door.">
There is a small mailbox here.
</p>
Second, here's the bad solution. In this incorrect way of
doing things, the alternative text is simply a description of the
image, instead of a textual replacement for the image. It's bad
because when the image isn't shown, the text doesn't flow as well
as in the first example.
<!-- This is the wrong way to do things. -->
<p>
You are standing in an open field west of a house.
<img src="house.jpeg" alt="A white house, with a boarded front door.">
There is a small mailbox here.
</p>
Text such as "Photo of white house with boarded door" would be
equally bad alternative text (though it could be suitable for the
title attribute or in the
figcaption element of a figure with this
image).
4.8.1.1.3 A short phrase or label with an alternative graphical representation: icons, logos
A document can contain information in iconic form. The icon is
intended to help users of visual browsers to recognize features at
a glance.
In some cases, the icon is supplemental to a text label
conveying the same meaning. In those cases, the alt attribute must be present but must
be empty.
Here the icons are next to text that conveys the same meaning,
so they have an empty alt
attribute:
In other cases, the icon has no text next to it describing what
it means; the icon is supposed to be self-explanatory. In those
cases, an equivalent textual label must be given in the alt attribute.
Here, posts on a news site are labeled with an icon
indicating their topic.
<body>
<article>
<header>
<h1>Ratatouille wins <i>Best Movie of the Year</i> award</h1>
<p><img src="movies.png" alt="Movies"></p>
</header>
<p>Pixar has won yet another <i>Best Movie of the Year</i> award,
making this its 8th win in the last 12 years.</p>
</article>
<article>
<header>
<h1>Latest TWiT episode is online</h1>
<p><img src="podcasts.png" alt="Podcasts"></p>
</header>
<p>The latest TWiT episode has been posted, in which we hear
several tech news stories as well as learning much more about the
iPhone. This week, the panelists compare how reflective their
iPhones' Apple logos are.</p>
</article>
</body>
Many pages include logos, insignia, flags, or emblems, which
stand for a particular entity such as a company, organization,
project, band, software package, country, or some such.
If the logo is being used to represent the entity, e.g. as a page
heading, the alt attribute must
contain the name of the entity being represented by the logo. The
alt attribute must not
contain text like the word "logo", as it is not the fact that it is
a logo that is being conveyed, it's the entity itself.
If the logo is being used next to the name of the entity that
it represents, then the logo is supplemental, and its alt attribute must instead be
empty.
If the logo is merely used as decorative material (as branding,
or, for example, as a side image in an article that mentions the
entity to which the logo belongs), then the entry below on purely
decorative images applies. If the logo is actually being
discussed, then it is being used as a phrase or paragraph (the
description of the logo) with an alternative graphical
representation (the logo itself), and the first entry above
applies.
In the following snippets, all four of the above cases are
present. First, we see a logo used to represent a company:
Next, we see a paragraph which uses a logo right next to the
company name, and so doesn't have any alternative text:
<article>
<h2>News</h2>
<p>We have recently been looking at buying the <img src="alpha.gif"
alt=""> ÎÎÎ company, a small Greek company
specializing in our type of product.</p>
In this third snippet, we have a logo being used in an aside,
as part of the larger article discussing the acquisition:
<aside><p><img src="alpha-large.gif" alt=""></p></aside>
<p>The ÎÎÎ company has had a good quarter, and our
pie chart studies of their accounts suggest a much bigger blue slice
than its green and orange slices, which is always a good sign.</p>
</article>
Finally, we have an opinion piece talking about a logo, and
the logo is therefore described in detail in the alternative
text.
<p>Consider for a moment their logo:</p>
<p><img src="/images/logo" alt="It consists of a green circle with a
green question mark centered inside it."></p>
<p>How unoriginal can you get? I mean, oooooh, a question mark, how
<em>revolutionary</em>, how utterly <em>ground-breaking</em>, I'm
sure everyone will rush to adopt those specifications now! They could
at least have tried for some sort of, I don't know, sequence of
rounded squares with varying shades of green and bold white outlines,
at least that would look good on the cover of a blue book.</p>
This example shows how the alternative text should be written
such that if the image isn't available, and the text is used instead,
the text flows seamlessly into the surrounding text, as if the
image had never been there in the first place.
4.8.1.1.4 Text that has been rendered to a graphic for typographical effect
Status: Last call for comments
Sometimes, an image just consists of text, and the purpose of the
image is not to highlight the actual typographic effects used to
render the text, but just to convey the text itself.
In such cases, the alt
attribute must be present but must consist of the same text as
written in the image itself.
Consider a graphic containing the text "Earth Day", but with the
letters all decorated with flowers and plants. If the text is
merely being used as a heading, to spice up the page for graphical
users, then the correct alternative text is just the same text
"Earth Day", and no mention need be made of the decorations:
4.8.1.1.5 A graphical representation of some of the surrounding text
Status: Last call for comments
In many cases, the image is actually just supplementary, and
its presence merely reinforces the surrounding text. In these
cases, the alt attribute must be
present but its value must be the empty string.
In general, an image falls into this category if removing the
image doesn't make the page any less useful, but including the
image makes it a lot easier for users of visual browsers to
understand the concept.
A flowchart that repeats the previous paragraph in graphical form:
<p>The network passes data to the Tokenizer stage, which
passes data to the Tree Construction stage. From there, data goes
to both the DOM and to Script Execution. Script Execution is
linked to the DOM, and, using document.write(), passes data to
the Tokenizer.</p>
<p><img src="http://dev.w3.org/html5/spec/images/parsing-model-overview.png" alt=""></p>
In these cases, it would be wrong to include alternative text
that consists of just a caption. If a caption is to be included,
then either the title attribute can
be used, or the figure and figcaption
elements can be used. In the latter case, the image would in fact
be a phrase or paragraph with an alternative graphical
representation, and would thus require alternative text.
<!-- Using the title="" attribute -->
<p>The network passes data to the Tokenizer stage, which
passes data to the Tree Construction stage. From there, data goes
to both the DOM and to Script Execution. Script Execution is
linked to the DOM, and, using document.write(), passes data to
the Tokenizer.</p>
<p><img src="http://dev.w3.org/html5/spec/images/parsing-model-overview.png" alt=""
title="Flowchart representation of the parsing model."></p>
<!-- Using <figure> and <figcaption> -->
<p>The network passes data to the Tokenizer stage, which
passes data to the Tree Construction stage. From there, data goes
to both the DOM and to Script Execution. Script Execution is
linked to the DOM, and, using document.write(), passes data to
the Tokenizer.</p>
<figure>
<img src="http://dev.w3.org/html5/spec/images/parsing-model-overview.png" alt="The Network leads
to the Tokenizer, which leads to the Tree Construction. The Tree
Construction leads to two items. The first is Script Execution, which
leads via document.write() back to the Tokenizer. The second item
from which Tree Construction leads is the DOM. The DOM is related to
the Script Execution.">
<figcaption>Flowchart representation of the parsing model.</figcaption>
</figure>
<!-- This is WRONG. Do not do this. Instead, do what the above examples do. -->
<p>The network passes data to the Tokenizer stage, which
passes data to the Tree Construction stage. From there, data goes
to both the DOM and to Script Execution. Script Execution is
linked to the DOM, and, using document.write(), passes data to
the Tokenizer.</p>
<p><img src="http://dev.w3.org/html5/spec/images/parsing-model-overview.png"
alt="Flowchart representation of the parsing model."></p>
<!-- Never put the image's caption in the alt="" attribute! -->
A graph that repeats the previous paragraph in graphical form:
<p>According to a study covering several billion pages,
about 62% of documents on the Web in 2007 triggered the Quirks
rendering mode of Web browsers, about 30% triggered the Almost
Standards mode, and about 9% triggered the Standards mode.</p>
<p><img src="rendering-mode-pie-chart.png" alt=""></p>
4.8.1.1.6 A purely decorative image that doesn't add any information
In general, if an image is decorative but isn't especially
page-specific, for example an image that forms part of a site-wide
design scheme, the image should be specified in the site's CSS,
not in the markup of the document.
However, a decorative image that isn't discussed by the
surrounding text but still has some relevance can be included in a page
using the img element. Such images are decorative, but
still form part of the content. In these cases, the alt attribute must be present but its
value must be the empty string.
Examples where the image is purely decorative despite being
relevant would include things like a photo of the Black Rock City
landscape in a blog post about an event at Burning Man, or an
image of a painting inspired by a poem, on a page reciting that
poem. The following snippet shows an example of the latter
case (only the first verse is included in this snippet):
<h1>The Lady of Shalott</h1>
<p><img src="shalott.jpeg" alt=""></p>
<p>On either side the river lie<br>
Long fields of barley and of rye,<br>
That clothe the wold and meet the sky;<br>
And through the field the road run by<br>
To many-tower'd Camelot;<br>
And up and down the people go,<br>
Gazing where the lilies blow<br>
Round an island there below,<br>
The island of Shalott.</p>
4.8.1.1.7 A group of images that form a single larger picture with no links
Status: Last call for comments
When a picture has been sliced into smaller image files that are
then displayed together to form the complete picture again, one of
the images must have its alt
attribute set as per the relevant rules that would be appropriate
for the picture as a whole, and then all the remaining images must
have their alt attribute set to
the empty string.
In the following example, a picture representing a company logo
for XYZ Corp has been split into two pieces,
the first containing the letters "XYZ" and the second with the word
"Corp". The alternative text ("XYZ Corp") is all in the first
image.
In the following example, a rating is shown as three filled
stars and two empty stars. While the alternative text could have
been "â â â ââ", the author has
instead decided to more helpfully give the rating in the form "3
out of 5". That is the alternative text of the first image, and the
rest have blank alternative text.
<p>Rating: <meter max=5 value=3><img src="1" alt="3 out of 5"
><img src="1" alt=""><img src="1" alt=""><img src="0" alt=""
><img src="0" alt=""></meter></p>
4.8.1.1.8 A group of images that form a single larger picture with links
Status: Last call for comments
Generally, image maps should be
used instead of slicing an image for links.
However, if an image is indeed sliced and any of the components
of the sliced picture are the sole contents of links, then one image
per link must have alternative text in its alt attribute representing the purpose
of the link.
In the following example, a picture representing the flying
spaghetti monster emblem, with each of the left noodly appendages
and the right noodly appendages in different images, so that the
user can pick the left side or the right side in an adventure.
<h1>The Church</h1>
<p>You come across a flying spaghetti monster. Which side of His
Noodliness do you wish to reach out for?</p>
<p><a href="?go=left" ><img src="fsm-left.png" alt="Left side. "></a
><img src="fsm-middle.png" alt=""
><a href="?go=right"><img src="fsm-right.png" alt="Right side."></a></p>
4.8.1.1.9 A key part of the content
Status: Last call for comments
In some cases, the image is a critical part of the
content. This could be the case, for instance, on a page that is
part of a photo gallery. The image is the whole point of
the page containing it.
How to provide alternative text for an image that is a key part
of the content depends on the image's provenance.
The general case
When it is possible for detailed alternative text to be
provided, for example if the image is part of a series of
screenshots in a magazine review, or part of a comic strip, or is
a photograph in a blog entry about that photograph, text that can
serve as a substitute for the image must be given as the contents
of the alt attribute.
A screenshot in a gallery of screenshots for a new OS, with
some alternative text:
<figure>
<img src="KDE%20Light%20desktop.png"
alt="The desktop is blue, with icons along the left hand side in
two columns, reading System, Home, K-Mail, etc. A window is
open showing that menus wrap to a second line if they
cannot fit in the window. The window has a list of icons
along the top, with an address bar below it, a list of
icons for tabs along the left edge, a status bar on the
bottom, and two panes in the middle. The desktop has a bar
at the bottom of the screen with a few buttons, a pager, a
list of open applications, and a clock.">
<figcaption>Screenshot of a KDE desktop.</figcaption>
</figure>
A graph in a financial report:
<img src="sales.gif"
title="Sales graph"
alt="From 1998 to 2005, sales increased by the following percentages
with each year: 624%, 75%, 138%, 40%, 35%, 9%, 21%">
Note that "sales graph" would be inadequate alternative text
for a sales graph. Text that would be a good caption is
not generally suitable as replacement text.
Images that defy a complete description
In certain cases, the nature of the image might be such that
providing thorough alternative text is impractical. For example,
the image could be indistinct, or could be a complex fractal, or
could be a detailed topographical map.
In these cases, the alt
attribute must contain some suitable alternative text, but it may
be somewhat brief.
Sometimes there simply is no text that can do justice to an
image. For example, there is little that can be said to usefully
describe a Rorschach inkblot test. However, a description, even
if brief, is still better than nothing:
<figure>
<img src="/commons/a/a7/Rorschach1.jpg" alt="A shape with left-right
symmetry with indistinct edges, with a small gap in the center, two
larger gaps offset slightly from the center, with two similar gaps
under them. The outline is wider in the top half than the bottom
half, with the sides extending upwards higher than the center, and
the center extending below the sides.">
<figcaption>A black outline of the first of the ten cards
in the Rorschach inkblot test.</figcaption>
</figure>
Note that the following would be a very bad use of alternative
text:
<!-- This example is wrong. Do not copy it. -->
<figure>
<img src="/commons/a/a7/Rorschach1.jpg" alt="A black outline
of the first of the ten cards in the Rorschach inkblot test.">
<figcaption>A black outline of the first of the ten cards
in the Rorschach inkblot test.</figcaption>
</figure>
Including the caption in the alternative text like this isn't
useful because it effectively duplicates the caption for users
who don't have images, taunting them twice yet not helping them
any more than if they had only read or heard the caption
once.
Another example of an image that defies full description is a
fractal, which, by definition, is infinite in detail.
The following example shows one possible way of providing
alternative text for the full view of an image of the Mandelbrot
set.
<img src="ms1.jpeg" alt="The Mandelbrot set appears as a cardioid with
its cusp on the real axis in the positive direction, with a smaller
bulb aligned along the same center line, touching it in the negative
direction, and with these two shapes being surrounded by smaller bulbs
of various sizes.">
Images whose contents are not known
In some unfortunate cases, there might be no alternative text
available at all, either because the image is obtained in some
automated fashion without any associated alternative text (e.g. a
Webcam), or because the page is being generated by a script using
user-provided images where the user did not provide suitable or
usable alternative text (e.g. photograph sharing sites), or
because the author does not himself know what the images represent
(e.g. a blind photographer sharing an image on his blog).
In such cases, the alt
attribute's value may be omitted, but one of the following
conditions must be met as well:
The title attribute is
present and has a non-empty value.
Such cases are to be kept to an absolute
minimum. If there is even the slightest possibility of the author
having the ability to provide real alternative text, then it would
not be acceptable to omit the alt
attribute.
A photo on a photo-sharing site, if the site received the
image with no metadata other than the caption, could be marked up
as follows:
<figure>
<img src="1100670787_6a7c664aef.jpg">
<figcaption>Bubbles traveled everywhere with us.</figcaption>
</figure>
It would be better, however, if a detailed description of the
important parts of the image obtained from the user and included
on the page.
A blind user's blog in which a photo taken by the user is
shown. Initially, the user might not have any idea what the photo
he took shows:
<article>
<h1>I took a photo</h1>
<p>I went out today and took a photo!</p>
<figure>
<img src="photo2.jpeg">
<figcaption>A photograph taken blindly from my front porch.</figcaption>
</figure>
</article>
Eventually though, the user might obtain a description of the
image from his friends and could then include alternative text:
<article>
<h1>I took a photo</h1>
<p>I went out today and took a photo!</p>
<figure>
<img src="photo2.jpeg" alt="The photograph shows my hummingbird
feeder hanging from the edge of my roof. It is half full, but there
are no birds around. In the background, out-of-focus trees fill the
shot. The feeder is made of wood with a metal grate, and it contains
peanuts. The edge of the roof is wooden too, and is painted white
with light blue streaks.">
<figcaption>A photograph taken blindly from my front porch.</figcaption>
</figure>
</article>
Sometimes the entire point of the image is that a textual
description is not available, and the user is to provide the
description. For instance, the point of a CAPTCHA image is to see
if the user can literally read the graphic. Here is one way to
mark up a CAPTCHA (note the title
attribute):
<p><label>What does this image say?
<img src="captcha.cgi?id=8934" title="CAPTCHA">
<input type=text name=captcha></label>
(If you cannot see the image, you can use an <a
href="?audio">audio</a> test instead.)</p>
Another example would be software that displays images and
asks for alternative text precisely for the purpose of then
writing a page with correct alternative text. Such a page could
have a table of images, like this:
Notice that even in this example, as much useful information
as possible is still included in the title attribute.
Since some users cannot use images at all
(e.g. because they have a very slow connection, or because they
are using a text-only browser, or because they are listening to
the page being read out by a hands-free automobile voice Web
browser, or simply because they are blind), the alt attribute is only allowed to be
omitted rather than being provided with replacement text when no
alternative text is available and none can be made available, as
in the above examples. Lack of effort from the part of the author
is not an acceptable reason for omitting the alt attribute.
4.8.1.1.10 An image not intended for the user
Status: Last call for comments
Generally authors should avoid using img elements
for purposes other than showing images.
If an img element is being used for purposes other
than showing an image, e.g. as part of a service to count page
views, then the alt attribute must
be the empty string.
In such cases, the width and
height attributes should both
be set to zero.
4.8.1.1.11 An image in an e-mail or private document intended for a specific person who is known to be able to view images
Status: Last call for comments
This section does not apply to documents that are publicly
accessible, or whose target audience is not necessarily personally
known to the author, such as documents on a Web site, e-mails sent
to public mailing lists, or software documentation.
When an image is included in a private communication (such as an
HTML e-mail) aimed at a specific person who is known to be able to
view images, the alt attribute may
be omitted. However, even in such cases it is strongly recommended
that alternative text be included (as appropriate according to the
kind of image involved, as described in the above entries), so that
the e-mail is still usable should the user use a mail client that
does not support images, or should the document be forwarded on to
other users whose abilities might not include easily seeing
images.
4.8.1.1.12 General guidelines
Status: Last call for comments
The most general rule to consider when writing alternative text
is the following: the intent is that replacing every image
with the text of its alt attribute
not change the meaning of the page.
So, in general, alternative text can be written by considering
what one would have written had one not been able to include the
image.
A corollary to this is that the alt attribute's value should never
contain text that could be considered the image's caption,
title, or legend. It is supposed to contain
replacement text that could be used by users instead of the
image; it is not meant to supplement the image. The title attribute can be used for
supplemental information.
One way to think of alternative text is to think
about how you would read the page containing the image to someone
over the phone, without mentioning that there is an image
present. Whatever you say instead of the image is typically a good
start for writing the alternative text.
4.8.2 The iframe element
Status: Last call for comments. ISSUE-100 (srcdoc) and ISSUE-103 (srcdoc-xml-escaping) block progress to Last Call
The srcdoc
attribute gives the content of the page that the nested
browsing context is to contain. The value of the attribute
in is an iframesrcdoc document.
For iframe elements in HTML documents,
the attribute, if present, must have a value using the HTML
syntax that consists of the following syntactic components,
in the given order:
For iframe elements in XML documents,
the attribute, if present, must have a value that matches the
production labeled document in the XML
specification. [XML]
If the src attribute and the
srcdoc attribute are both
specified together, the srcdoc
attribute takes priority. This allows authors to provide a fallback
URL for legacy user agents that do not support the
srcdoc attribute.
If, when the element is created, the srcdoc attribute is not set, and
the src attribute is either
also not set or set but its value cannot be resolved, the browsing context will remain at the
initial about:blank page.
If the user navigates
away from this page, the iframe's corresponding
WindowProxy object will proxy new Window
objects for new Document objects, but the src attribute will not change.
Here a blog uses the srcdoc attribute in conjunction
with the sandbox and seamless attributes described
below to provide users of user agents that support this feature
with an extra layer of protection from script injection in the blog
post comments:
<article>
<h1>I got my own magazine!</h1>
<p>After much effort, I've finally found a publisher, and so now I
have my own magazine! Isn't that awesome?! The first issue will come
out in September, and we have articles about getting food, and about
getting in boxes, it's going to be great!</p>
<footer>
<p>Written by <a href="/users/cap">cap</a>.
<time pubdate>2009-08-21T23:32Z</time></p>
</footer>
<article>
<footer> At <time pubdate>2009-08-21T23:35Z</time>, <a href="/users/ch">ch</a> writes: </footer>
<iframe seamless sandbox="allow-same-origin" srcdoc="<p>did you get a cover picture yet?"></iframe>
</article>
<article>
<footer> At <time pubdate>2009-08-21T23:44Z</time>, <a href="/users/cap">cap</a> writes: </footer>
<iframe seamless sandbox="allow-same-origin" srcdoc="<p>Yeah, you can see it <a href="/gallery?mode=cover&amp;page=1">in my gallery</a>."></iframe>
</article>
<article>
<footer> At <time pubdate>2009-08-21T23:58Z</time>, <a href="/users/ch">ch</a> writes: </footer>
<iframe seamless sandbox="allow-same-origin" srcdoc="<p>hey that's earl's table.
<p>you should get earl&amp;me on the next cover."></iframe>
</article>
Notice the way that quotes have to be escaped (otherwise the
sandbox attribute would
end prematurely), and the way raw ampersands (e.g. in URLs or in
prose) mentioned in the sandboxed content have to be
doubly escaped â once so that the ampersand is
preserved when originally parsing the sandbox attribute, and once more
to prevent the ampersand from being misinterpreted when parsing the
sandboxed content.
In the HTML syntax, authors need only
remember to use U+0022 QUOTATION MARK characters (") to wrap the
attribute contents and then to escape all U+0022 QUOTATION MARK (")
and U+0026 AMPERSAND (&) characters, and to specify the sandbox attribute, to ensure safe
embedding of content.
Due to restrictions of the XML syntax,
in XML a number of other characters need to be escaped also to
ensure correctness.
Sandboxing hostile content is of minimal help if
an attacker can convince the user to just visit the hostile content
directly, rather than in the iframe. To limit the
damage that can be caused by hostile HTML content, it should be
served using the text/html-sandboxed MIME type.
In this example, some completely-unknown, potentially hostile,
user-provided HTML content is embedded in a page. Because it is
sandboxed, it is treated by the user agent as being from a unique
origin, despite the content being served from the same site. Thus
it is affected by all the normal cross-site restrictions. In
addition, the embedded page has scripting disabled, plugins
disabled, forms disabled, and it cannot navigate any frames or
windows other than itself (or any frames or windows it itself
embeds).
<p>We're not scared of you! Here is your content, unedited:</p>
<iframe sandbox src="getusercontent.cgi?id=12193"></iframe>
Note that cookies are still sent to the server in the getusercontent.cgi request, though they are not
visible in the document.cookie IDL
attribute.
It is important that the server serve the
user-provided HTML using the text/html-sandboxed MIME
type so that if the attacker convinces the user to visit that page
directly, the page doesn't run in the context of the site's origin,
which would make the user vulnerable to any attack found in the
page.
In this example, a gadget from another site is embedded. The
gadget has scripting and forms enabled, and the origin sandbox
restrictions are lifted, allowing the gadget to communicate with
its originating server. The sandbox is still useful, however, as it
disables plugins and popups, thus reducing the risk of the user
being exposed to malware and other annoyances.
For this example, suppose all the files were served as
text/html.
Page C in this scenario has all the sandboxing flags
set. Scripts are disabled, because the iframe in A has
scripts disabled, and this overrides the allow-scripts
keyword set on the iframe in B. Forms are also
disabled, because the inner iframe (in B) does not
have the allow-forms keyword
set.
Suppose now that a script in A removes all the sandbox attributes in A and
B. This would change nothing immediately. If the user clicked the
link in C, loading page D into the iframe in B, page D
would now act as if the iframe in B had the allow-same-origin
and allow-forms keywords
set, because that was the state of the nested browsing
context in the iframe in A when page B was
loaded.
Generally speaking, dynamically removing or changing the sandbox attribute is
ill-advised, because it can make it quite hard to reason about what
will be allowed and what will not.
Potentially hostile files can be served from the
same server as the file containing the iframe element
by labeling them as text/html-sandboxed instead of
text/html. This ensures that scripts in the files are
unable to attack the site (as if they were actually served from
another server), even if the user is tricked into visiting those
pages directly, without the protection of the sandbox attribute.
If the allow-scripts
keyword is set along with allow-same-origin
keyword, and the file is from the same origin as the
iframe's Document, then a script in the
"sandboxed" iframe could just reach out, remove the sandbox attribute, and then
reload itself, effectively breaking out of the sandbox
altogether.
The seamless
attribute is a boolean attribute. When specified, it
indicates that the iframe element's browsing
context is to be rendered in a manner that makes it appear to
be part of the containing document (seamlessly included in the
parent document).
The attribute can be set or removed dynamically,
with the rendering updating in tandem.
In this example, the site's navigation is embedded using a
client-side include using an iframe. Any links in the
iframe will, in new user agents, be automatically
opened in the iframe's parent browsing context; for
legacy user agents, the site could also include a base
element with a target
attribute with the value _parent. Similarly,
in new user agents the styles of the parent page will be
automatically applied to the contents of the frame, but to support
legacy user agents authors might wish to include the styles
explicitly.
The iframe element supports dimension
attributes for cases where the embedded content has specific
dimensions (e.g. ad units have well-defined dimensions).
An iframe element never has fallback
content, as it will always create a nested browsing
context, regardless of whether the specified initial contents
are successfully used.
Descendants of iframe elements represent
nothing. (In legacy user agents that do not support
iframe elements, the contents would be parsed as markup
that could act as fallback content.)
When used in HTML documents, the allowed content
model of iframe elements is text, except that invoking
the HTML fragment parsing algorithm with the
iframe element as the context
element and the text contents as the input must
result in a list of nodes that are all phrasing
content, with no parse
errors having occurred, with no script elements
being anywhere in the list or as descendants of elements in the
list, and with all the elements in the list (including their
descendants) being themselves conforming.
The type
attribute, if present, gives the MIME type by which the
plugin to instantiate is selected. The value must be a valid
MIME type. If both the type attribute and the src attribute are present, then the
type attribute must specify the
same type as the explicit Content-Type
metadata of the resource given by the src attribute.
Any namespace-less attribute other than name, align, hspace, and vspace may be specified on the embed element,
so long as its name is XML-compatible and contains no
characters in the range U+0041 to U+005A (LATIN CAPITAL LETTER A to
LATIN CAPITAL LETTER Z). These attributes are then passed as
parameters to the plugin.
All attributes in HTML documents get
lowercased automatically, so the restriction on uppercase letters
doesn't affect such documents.
The four exceptions are to exclude legacy attributes
that have side-effects beyond just sending parameters to the
plugin.
Here's a way to embed a resource that requires a proprietary
plug-in, like Flash:
<embed src="catgame.swf">
If the user does not have the plug-in (for example if the
plug-in vendor doesn't support the user's platform), then the user
will be unable to use the resource.
To pass the plugin a parameter "quality" with the value "high",
an attribute can be specified:
<embed src="catgame.swf" quality="high">
This would be equivalent to the following, when using an
object element instead:
The object element can represent an external
resource, which, depending on the type of the resource, will either
be treated as an image, as a nested browsing context,
or as an external resource to be processed by a
plugin.
In the following example, a Java applet is embedded in a page
using the object element. (Generally speaking, it is
better to avoid using applets like these and instead use native
JavaScript and HTML to provide the functionality, since that way
the application will work on all Web browsers without requiring a
third-party plugin. Many devices, especially embedded devices, do
not support third-party technologies like Java.)
<figure>
<object type="application/x-java-applet">
<param name="code" value="MyJavaClass">
<p>You do not have Java available, or it is disabled.</p>
</object>
<figcaption>My Java Clock</figcaption>
</figure>
In this example, an HTML page is embedded in another using the
object element.
<figure>
<object data="clock.html"></object>
<figcaption>My HTML Clock</figcaption>
</figure>
The following example shows how a plugin can be used in HTML (in
this case the Flash plugin, to show a video file). Fallback is
provided for users who do not have Flash enabled, in this case
using the video element to show the video for those
using user agents that support video, and finally
providing a link to the video for those who have neither Flash nor
a video-capable browser.
The param element defines parameters for plugins
invoked by object elements. It does not represent anything on its own.
The name
attribute gives the name of the parameter.
The value
attribute gives the value of the parameter.
Both attributes must be present. They may have any value.
The following example shows how the param element
can be used to pass a parameter to a plugin, in this case the O3D
plugin.
<!DOCTYPE HTML>
<html lang="en">
<head>
<title>O3D Utah Teapot</title>
</head>
<body>
<p>
<object type="application/vnd.o3d.auto">
<param name="o3d_features" value="FloatingPointTextures">
<img src="o3d-teapot.png"
title="3D Utah Teapot illustration rendered using O3D."
alt="When O3D renders the Utah Teapot, it appears as a squat
teapot with a shiny metallic finish on which the
surroundings are reflected, with a faint shadow caused by
the lighting.">
<p>To see the teapot actually rendered by O3D on your
computer, please download and install the <a
href="http://code.google.com/apis/o3d/docs/gettingstarted.html#install">O3D plugin</a>.</p>
</object>
<script src="o3d-teapot.js"></script>
</p>
</body>
</html>
4.8.6 The video element
Status: Last call for comments. ISSUE-9 (video-accessibility) blocks progress to Last Call
A video element is used for playing videos or
movies.
Content may be provided inside the video
element; it is intended for older Web browsers which do
not support video, so that legacy video plugins can be
tried, or to show text to the users of these older browsers informing
them of how to access the video contents.
In particular, this content is not intended to
address accessibility concerns. To make video content accessible to
the blind, deaf, and those with other physical or cognitive
disabilities, authors are expected to provide alternative media
streams and/or to embed accessibility aids (such as caption or
subtitle tracks, audio description tracks, or sign-language
overlays) into their media streams.
The video element is a media element
whose media data is ostensibly video data, possibly
with associated audio data.
The poster
attribute gives the address of an image file that the user agent can
show while no video data is available. The attribute, if present,
must contain a valid non-empty URL potentially surrounded by
spaces.
The image given by the poster attribute, the poster
frame, is intended to be a representative frame of the video
(typically one of the first non-blank frames) that gives the user an
idea of what the video is like.
This example shows how to detect when a video has failed to play
correctly:
<script>
function failed(e) {
// video playback failed - show a message saying why
switch (e.target.error.code) {
case e.target.error.MEDIA_ERR_ABORTED:
alert('You aborted the video playback.');
break;
case e.target.error.MEDIA_ERR_NETWORK:
alert('A network error caused the video download to fail part-way.');
break;
case e.target.error.MEDIA_ERR_DECODE:
alert('The video playback was aborted due to a corruption problem or because the video used features your browser did not support.');
break;
case e.target.error.MEDIA_ERR_SRC_NOT_SUPPORTED:
alert('The video could not be loaded, either because the server or network failed or because the format is not supported.');
break;
default:
alert('An unknown error occurred.');
break;
}
}
</script>
<p><video src="tgif.vid" autoplay controls onerror="failed(event)"></video></p>
<p><a href="tgif.vid">Download the video file</a>.</p>
Content may be provided inside the audio
element; it is intended for older Web browsers which do
not support audio, so that legacy audio plugins can be
tried, or to show text to the users of these older browsers informing
them of how to access the audio contents.
In particular, this content is not intended to
address accessibility concerns. To make audio content accessible to
the deaf or to those with other physical or cognitive disabilities,
authors are expected to provide alternative media streams and/or to
embed accessibility aids (such as transcriptions) into their media
streams.
The type
attribute gives the type of the media resource, to help
the user agent determine if it can play this media
resource before fetching it. If specified, its value must be
a valid MIME type. The codecs
parameter may be specified and might be necessary to specify exactly
how the resource is encoded. [RFC4281]
The following list shows some examples of how to use the codecs= MIME parameter in the type attribute.
H.264 Simple baseline profile video (main and extended video compatible) level 3 and Low-Complexity AAC audio in MP4 container
The media
attribute gives the intended media type of the media
resource, to help the user agent determine if this
media resource is useful to the user before fetching
it. Its value must be a valid media query.
The default, if the media attribute is omitted, is
"all", meaning that by default the media
resource is suitable for all media.
If the author isn't sure if the user agents will all be able to
render the media resources provided, the author can listen to the
error event on the last
source element and trigger fallback behavior:
<script>
function fallback(video) {
// replace <video> with its contents
while (video.hasChildNodes()) {
if (video.firstChild instanceof HTMLSourceElement)
video.removeChild(video.firstChild);
else
video.parentNode.insertBefore(video.firstChild, video);
}
video.parentNode.removeChild(video);
}
</script>
<video controls autoplay>
<source src='video.mp4' type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"'>
<source src='video.ogv' type='video/ogg; codecs="theora, vorbis"'
onerror="fallback(parentNode)">
...
</video>
Media elements are used to
present audio data, or video and audio data, to the user. This is
referred to as media data in this section, since this
section applies equally to media
elements for audio or for video. The term media
resource is used to refer to the complete set of media data,
e.g. the complete video file, or complete audio file.
Types are usually somewhat incomplete descriptions; for example
"video/mpeg" doesn't say anything except what
the container type is, and even a type like "video/mp4; codecs="avc1.42E01E,
mp4a.40.2"" doesn't include information like the actual
bitrate (only the maximum bitrate). Thus, given a type, a user agent
can often only know whether it might be able to play
media of that type (with varying levels of confidence), or whether
it definitely cannot play media of that type.
A type that the user agent knows it cannot render is
one that describes a resource that the user agent definitely does
not support, for example because it doesn't recognize the container
type, or it doesn't support the listed codecs.
Returns the empty string (a negative response), "maybe", or
"probably" based on how confident the user agent is that it can
play media resources of the given type.
This script tests to see if the user agent supports a
(fictional) new format to dynamically decide whether to use a
video element or a plugin:
<section id="video">
<p><a href="playing-cats.nfv">Download video</a></p>
</section>
<script>
var videoSection = document.getElementById('video');
var videoElement = document.createElement('video');
var support = videoElement.canPlayType('video/x-new-fictional-format;codecs="kittens,bunnies"');
if (support != "probably" && "New Fictional Video Plug-in" in navigator.plugins) {
// not confident of browser support
// but we have a plugin
// so use plugin instead
videoElement = document.createElement("embed");
} else if (support == "") {
// no support from browser and no plugin
// do nothing
videoElement = null;
}
if (videoElement) {
while (videoSection.hasChildNodes())
videoSection.removeChild(videoSection.firstChild);
videoElement.setAttribute("src", "playing-cats.nfv");
videoSection.appendChild(videoElement);
}
</script>
The type
attribute of the source element allows the user agent
to avoid downloading resources that use formats it cannot
render.
Causes the element to reset and start selecting and loading a
new media resource from scratch.
The preload
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.
Keyword
State
Brief description
none
None
Hints to the user agent that either the author does not expect the user to need the media resource, or that the server wants to minimise unnecessary traffic.
metadata
Metadata
Hints to the user agent that the author does not expect the user to need the media resource, but that fetching the resource metadata (dimensions, first frame, track list, duration, etc) is reasonable.
auto
Automatic
Hints to the user agent that the user agent can put the user's needs first without risk to the server, up to and including optimistically downloading the entire resource.
The empty string is also a valid keyword, and maps to the Automatic state. The
attribute's missing value default is user-agent defined,
though the Metadata state is
suggested as a compromise between reducing server load and providing
an optimal user experience.
The autoplay attribute can overrride
the preload attribute (since
if the media plays, it naturally has to buffer first, regardless of
the hint given by the preload attribute). Including
both is not an error, however.
Will throw an INVALID_STATE_ERR exception if there
is no selected media resource. Will throw an
INDEX_SIZE_ERR exception if the given time is not
within the ranges to which the user agent can seek.
Returns the earliest possible position, in
seconds. This is the time for the start of the current clip. It
might not be zero if the clip's timeline is not zero-based, or if
the resource is a streaming resource (in which case it gives the
earliest time that the user agent is able to seek back to).
Returns a value that expresses the current state of the element
with respect to rendering the current playback
position, from the codes in the list below.
Enough of the resource has been obtained that the duration of
the resource is available. In the case of a video
element, the dimensions of the video are also available. The API
will no longer raise an exception when seeking. No media
data is available for the immediate current playback
position.
All the conditions described for the HAVE_FUTURE_DATA state
are met, and, in addition, the user agent estimates that data is
being fetched at a rate where the current playback
position, if it were to advance at the rate given by the
defaultPlaybackRate
attribute, would not overtake the available data before playback
reaches the end of the media resource.
It is possible for the ready state of a media
element to jump between these states discontinuously. For example,
the state of a media element can jump straight from HAVE_METADATA to HAVE_ENOUGH_DATA without
passing through the HAVE_CURRENT_DATA and
HAVE_FUTURE_DATA
states.
The autoplay
attribute is a boolean attribute. When present, the
user agent will automatically begin playback of the
media resource as soon as it can do so without
stopping.
Authors are urged to use the autoplay attribute rather than
using script to trigger automatic playback, as this allows the user
to override the automatic playback when it is not desired, e.g. when
using a screen reader. Authors are also encouraged to consider not
using the automatic playback behavior at all, and instead to let the
user agent wait for the user to start playback explicitly.
Returns the default rate of playback, for when the user is not
fast-forwarding or reversing through the media
resource.
Can be set, to change the default rate of playback.
The default rate has no direct effect on playback, but if the
user switches to a fast-forward mode, when they return to the
normal playback mode, it is expected that the rate of playback
will be returned to the default rate of playback.
Sets the paused attribute
to false, loading the media resource and beginning
playback if necessary. If the playback had ended, will restart it
from the start.
Returns a TimeRanges object that represents the
ranges of the media resource to which it is possible
for the user agent to seek.
4.8.9.10 User interface
Status: Last call for comments
The controls
attribute is a boolean attribute. If present, it
indicates that the author has not provided a scripted controller and
would like the user agent to provide its own set of controls.
A media element whose networkState was previously not in the NETWORK_EMPTY state has just switched to that state (either because of a fatal error during load that's about to be reported, or because the load() method was invoked while the resource selection algorithm was already running).
The user agent can resume playback of the media data, but estimates that if playback were to be started now, the media resource could not be rendered at the current playback rate up to its end without having to stop for further buffering of content.
The user agent estimates that if playback were to be started now, the media resource could be rendered at the current playback rate all the way to its end without having to stop for further buffering.
interface HTMLCanvasElement : HTMLElement {
attribute unsigned long width;
attribute unsigned long height;
DOMString toDataURL(in optional DOMString type, in any... args);
object getContext(in DOMString contextId);
};
The canvas element provides scripts with a
resolution-dependent bitmap canvas, which can be used for rendering
graphs, game graphics, or other visual images on the fly.
Authors should not use the canvas element in a
document when a more suitable element is available. For example, it
is inappropriate to use a canvas element to render a
page heading: if the desired presentation of the heading is
graphically intense, it should be marked up using appropriate
elements (typically h1) and then styled using CSS and
supporting technologies such as XBL.
When authors use the canvas element, they must also
provide content that, when presented to the user, conveys
essentially the same function or purpose as the bitmap canvas. This
content may be placed as content of the canvas
element. The contents of the canvas element, if any,
are the element's fallback content.
In non-interactive, static, visual media, if the
canvas element has been previously painted on (e.g. if
the page was viewed in an interactive visual medium and is now being
printed, or if some script that ran during the page layout process
painted on the element), then the canvas element
representsembedded content with the
current image and size. Otherwise, the element represents its
fallback content instead.
When a canvas element representsembedded content, the user can still focus descendants
of the canvas element (in the fallback
content). This allows authors to make an interactive canvas
keyboard-focusable: authors should have a one-to-one mapping of
interactive regions to focusable elements in the fallback
content.
The canvas element has two attributes to control the
size of the coordinate space: width and height. These
attributes, when specified, must have values that are valid non-negative
integers. The
width attribute defaults to
300, and the height
attribute defaults to 150.
The intrinsic dimensions of the canvas element equal
the size of the coordinate space, with the numbers interpreted in
CSS pixels. However, the element can be sized arbitrarily by a
style sheet. During rendering, the image is scaled to fit this layout
size.
Only one square appears to be drawn in the following example:
// canvas is a reference to a <canvas> element
var context = canvas.getContext('2d');
context.fillRect(0,0,50,50);
canvas.setAttribute('width', '300'); // clears the canvas
context.fillRect(0,100,50,50);
canvas.width = canvas.width; // clears the canvas
context.fillRect(100,0,50,50); // only this square remains
To draw on the canvas, authors must first obtain a reference to a
context using the getContext(contextId) method of the
canvas element.
The first argument, if provided, controls the type of the image
to be returned (e.g. PNG or JPEG). The default is image/png; that type is also used if the given
type isn't supported. The other arguments are specific to the
type, and control the way that the image is generated, as given in
the table below.
When trying to use types other than
image/png, authors can check if the image was really
returned in the requested format by checking to see if the returned
string starts with one the exact strings "data:image/png," or "data:image/png;". If it does, the image is PNG, and
thus the requested type was not supported. (The one exception to
this is if the canvas has either no height or no width, in which
case the result might simply be "data:,".)
Type
Other arguments
image/jpeg
The second argument is a
number in the range 0.0 to 1.0 inclusive treated as the desired quality level.
The map element, in conjunction with any
area element descendants, defines an image
map. The element represents its children.
The name attribute
gives the map a name so that it can be referenced. The attribute
must be present and must have a non-empty value with no space characters. The value of the
name attribute must not be a
compatibility-caseless
match for the value of the name
attribute of another map element in the same
document. If the id attribute is also
specified, both attributes must have the same value.
The area element represents either a
hyperlink with some text and a corresponding area on an image
map, or a dead area on an image map.
If the area element has an href attribute, then the
area element represents a hyperlink. In
this case, the alt
attribute must be present. It specifies the text of the
hyperlink. Its value must be text that, when presented with the
texts specified for the other hyperlinks of the image
map, and with the alternative text of the image, but without
the image itself, provides the user with the same kind of choice as
the hyperlink would when used without its text but with its shape
applied to the image. The alt
attribute may be left blank if there is another area
element in the same image map that points to the same
resource and has a non-blank alt
attribute.
If the area element has no href attribute, then the area
represented by the element cannot be selected, and the alt attribute must be omitted.
In both cases, the shape and
coords attributes specify the
area.
The shape
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.
The attribute may be omitted. The missing value default is
the rectangle state.
The coords
attribute must, if specified, contain a valid list of
integers. This attribute gives the coordinates for the shape
described by the shape
attribute.
In the circle state,
area elements must have a coords attribute present, with three
integers, the last of which must be non-negative. The first integer
must be the distance in CSS pixels from the left edge of the image
to the center of the circle, the second integer must be the distance
in CSS pixels from the top edge of the image to the center of the
circle, and the third integer must be the radius of the circle,
again in CSS pixels.
In the default state
state, area elements must not have a coords attribute. (The area is the
whole image.)
In the polygon state,
area elements must have a coords attribute with at least six
integers, and the number of integers must be even. Each pair of
integers must represent a coordinate given as the distances from the
left and the top of the image in CSS pixels respectively, and all
the coordinates together must represent the points of the polygon,
in order.
In the rectangle state,
area elements must have a coords attribute with exactly four
integers, the first of which must be less than the third, and the
second of which must be less than the fourth. The four points must
represent, respectively, the distance from the left edge of the
image to the left side of the rectangle, the distance from the
top edge to the top side, the distance from the left edge to the
right side, and the distance from the top edge to the bottom side,
all in CSS pixels.
An image map allows geometric areas on an image to be
associated with hyperlinks.
An image, in the form of an img element or an
object element representing an image, may be associated
with an image map (in the form of a map element) by
specifying a usemap attribute on
the img or object element. The usemap attribute, if specified,
must be a valid hash-name reference to a
map element.
Consider an image that looks as follows:
If we wanted just the colored areas to be clickable, we could
do it as follows:
<p>
Please select a shape:
<img src="shapes.png" usemap="#shapes"
alt="Four shapes are available: a red hollow box, a green circle, a blue triangle, and a yellow four-pointed star.">
<map name="shapes">
<area shape=rect coords="50,50,100,100"> <!-- the hole in the red box -->
<area shape=rect coords="25,25,125,125" href="red.html" alt="Red box.">
<area shape=circle coords="200,75,50" href="green.html" alt="Green circle.">
<area shape=poly coords="325,25,262,125,388,125" href="blue.html" alt="Blue triangle.">
<area shape=poly coords="450,25,435,60,400,75,435,90,450,125,465,90,500,75,465,60"
href="yellow.html" alt="Yellow star.">
</map>
</p>
The content model for title elements in the
SVG namespace inside HTML documents is
phrasing content. (This further constrains the
requirements given in the SVG specification.)
The semantics of SVG elements are defined by the SVG
specification and other relevant specifications. [SVG]
The SVG specification includes requirements regarding the
handling of elements in the DOM that are not in the SVG namespace,
that are in SVG fragments, and that are not included in a
foreignObject element. This specification does
not define any processing for elements in SVG fragments that are not
in the HTML namespace; they are considered neither conforming nor
non-conforming from the perspective of this specification.
4.8.16 Dimension attributes
Status: Last call for comments
The width and height attributes on
img, iframe, embed,
object, video, and, when their type attribute is in the Image Button state,
input elements may be specified to give the dimensions
of the visual content of the element (the width and height
respectively, relative to the nominal direction of the output
medium), in CSS pixels. The attributes, if specified, must have
values that are valid
non-negative integers.
The specified dimensions given may differ from the dimensions
specified in the resource itself, since the resource may have a
resolution that differs from the CSS pixel resolution. (On screens,
CSS pixels have a resolution of 96ppi, but in general the CSS pixel
resolution depends on the reading distance.) If both attributes are
specified, then one of the following statements must be true:
The target ratio is the ratio of the
intrinsic width to the intrinsic height in the resource. The specified width and specified
height are the values of the width and height attributes respectively.
The two attributes must be omitted if the resource in question
does not have both an intrinsic width and an intrinsic height.
If the two attributes are both zero, it indicates that the
element is not intended for the user (e.g. it might be a part of a
service to count page views).
The dimension attributes are not intended to be used
to stretch the image.
4.9 Tabular data
Status: Last call for comments. ISSUE-32 (table-summary) blocks progress to Last Call
4.9.1 The table element
Status: Last call for comments. ISSUE-92 (cleanuptable) blocks progress to Last Call
In this order: optionally a caption element,
followed by either zero or more colgroup elements,
followed optionally by a thead element, followed
optionally by a tfoot element, followed by either zero
or more tbody elements or one or more tr
elements, followed optionally by a tfoot element (but
there can only be one tfoot element child in
total).
The table element represents data with
more than one dimension, in the form of a table.
Tables must not be used as layout aids. Historically, some Web
authors have misused tables in HTML as a way to control their page
layout. This usage is non-conforming, because tools attempting to
extract tabular data from such documents would obtain very confusing
results. In particular, users of accessibility tools like screen
readers are likely to find it very difficult to navigate pages with
tables used for layout.
There are a variety of alternatives to using HTML
tables for layout, primarily using CSS positioning and the CSS table
model.
Tables have rows and columns given by their descendants. A table
must not have an empty row or column.
For tables that consist of more than just
a grid of cells with headers in the first row and headers in the
first column, and for any table in general where the reader might
have difficulty understanding the content, authors should include
explanatory information introducing the table. This information is
useful for all users, but is especially useful for users who cannot
see the table, e.g. users of screen readers.
Such explanatory information should introduce the purpose of the
table, outline its basic cell structure, highlight any trends or
patterns, and generally teach the user how to use the table.
For instance, the following table:
Characteristics with positive and negative sides
Negative
Characteristic
Positive
Sad
Mood
Happy
Failing
Grade
Passing
...might benefit from a description explaining the way the table
is laid out, something like "Characteristics are given in the
second column, with the negative side in the left column and the
positive side in the right column".
There are a variety of ways to include this information, such as:
In prose, surrounding the table
<p>In the following table, characteristics are given in the second
column, with the negative side in the left column and the positive
side in the right column.</p>
<table>
<caption>Characteristics with positive and negative sides</caption>
<thead>
<tr>
<th id="n"> Negative
<th> Characteristic
<th> Positive
<tbody>
<tr>
<td headers="n r1"> Sad
<th id="r1"> Mood
<td> Happy
<tr>
<td headers="n r2"> Failing
<th id="r2"> Grade
<td> Passing
</table>
<table>
<caption>
<strong>Characteristics with positive and negative sides.</strong>
<p>Characteristics are given in the second column, with the
negative side in the left column and the positive side in the right
column.</p>
</caption>
<thead>
<tr>
<th id="n"> Negative
<th> Characteristic
<th> Positive
<tbody>
<tr>
<td headers="n r1"> Sad
<th id="r1"> Mood
<td> Happy
<tr>
<td headers="n r2"> Failing
<th id="r2"> Grade
<td> Passing
</table>
<table>
<caption>
<strong>Characteristics with positive and negative sides.</strong>
<details>
<summary>Help</summary>
<p>Characteristics are given in the second column, with the
negative side in the left column and the positive side in the right
column.</p>
</details>
</caption>
<thead>
<tr>
<th id="n"> Negative
<th> Characteristic
<th> Positive
<tbody>
<tr>
<td headers="n r1"> Sad
<th id="r1"> Mood
<td> Happy
<tr>
<td headers="n r2"> Failing
<th id="r2"> Grade
<td> Passing
</table>
<figure>
<figcaption>Characteristics with positive and negative sides</figcaption>
<p>Characteristics are given in the second column, with the
negative side in the left column and the positive side in the right
column.</p>
<table>
<thead>
<tr>
<th id="n"> Negative
<th> Characteristic
<th> Positive
<tbody>
<tr>
<td headers="n r1"> Sad
<th id="r1"> Mood
<td> Happy
<tr>
<td headers="n r2"> Failing
<th id="r2"> Grade
<td> Passing
</table>
</figure>
<figure>
<figcaption>
<strong>Characteristics with positive and negative sides</strong>
<p>Characteristics are given in the second column, with the
negative side in the left column and the positive side in the right
column.</p>
</figcaption>
<table>
<thead>
<tr>
<th id="n"> Negative
<th> Characteristic
<th> Positive
<tbody>
<tr>
<td headers="n r1"> Sad
<th id="r1"> Mood
<td> Happy
<tr>
<td headers="n r2"> Failing
<th id="r2"> Grade
<td> Passing
</table>
</figure>
Authors may also use other techniques, or combinations of the
above techniques, as appropriate.
The best option, of course, rather than writing a description
explaining the way the table is laid out, is to adjust the table
such that no explanation is needed.
In the case of the table used in the examples above, a simple
rearrangement of the table so that the headers are on the top and
left sides removes the need for an explanation as well as removing
the need for the use of headers attributes:
The summary
attribute on table elements was suggested in earlier
versions of the language as a technique for providing explanatory
text for complex tables for users of screen readers. One of the techniques described above should be used
instead.
In particular, authors are encouraged to consider
whether their explanatory text for tables is likely to be useful to
the visually impaired: if their text would not be useful, then it is
best to not include a summary attribute. Similarly, if
their explanatory text could help someone who is not visually
impaired, e.g. someone who is seeing the table for the first time,
then the text would be more useful before the table or in the
caption. For example, describing the conclusions of the
data in a table is useful to everyone; explaining how to read the
table, if not obvious from the headers alone, is useful to everyone;
describing the structure of the table, if it is easy to grasp
visually, may not be useful to everyone, but it might also not be
useful to users who can quickly navigate the table with an
accessibility tool.
The caption element represents the title of the
table that is its parent, if it has a parent and that
is a table element.
When a table element is the only content in a
figure element other than the figcaption,
the caption element should be omitted in favor of the
figcaption.
A caption can introduce context for a table, making it
significantly easier to understand.
Consider, for instance, the following table:
1
2
3
4
5
6
1
2
3
4
5
6
7
2
3
4
5
6
7
8
3
4
5
6
7
8
9
4
5
6
7
8
9
10
5
6
7
8
9
10
11
6
7
8
9
10
11
12
In the abstract, this table is not clear. However, with a
caption giving the table's number (for reference in the main prose)
and explaining its use, it makes more sense:
<caption>
<p>Table 1.
<p>This table shows the total score obtained from rolling two
six-sided dice. The first row represents the value of the first die,
the first column the value of the second die. The total is given in
the cell that corresponds to the values of the two dice.
</caption>
If the colgroup element contains no col
elements, then the element may have a span content attribute
specified, whose value must be a valid non-negative
integer greater than zero.
4.9.4 The col element
Status: Last call for comments
Categories
None.
Contexts in which this element may be used:
As a child of a colgroup element that doesn't have
a span attribute.
The element may have a span content attribute
specified, whose value must be a valid non-negative
integer greater than zero.
4.9.5 The tbody element
Status: Last call for comments
Categories
None.
Contexts in which this element may be used:
As a child of a table element, after any
caption, colgroup, and
thead elements, but only if there are no
tr elements that are children of the
table element.
The tbody element represents a block of rows that consist of a body of data for
the parent table element, if the tbody
element has a parent and it is a table.
Creates a tr element, inserts it into the table section at the position given by the argument, and returns the tr.
The position is relative to the rows in the table section. The index â1, which is the default if the argument is omitted, is equivalent to inserting at the end of the table section.
If the given position is less than â1 or greater than the number of rows, throws an INDEX_SIZE_ERR exception.
Removes the tr element with the given position in the table section.
The position is relative to the rows in the table section. The index â1 is equivalent to deleting the last row of the table section.
If the given position is less than â1 or greater than the index of the last row, or if there are no rows, throws an INDEX_SIZE_ERR exception.
4.9.6 The thead element
Status: Last call for comments
Categories
None.
Contexts in which this element may be used:
As a child of a table element, after any
caption, and colgroup
elements and before any tbody, tfoot, and
tr elements, but only if there are no other
thead elements that are children of the
table element.
The thead element represents the block of rows that consist of the column labels
(headers) for the parent table element, if the
thead element has a parent and it is a
table.
4.9.7 The tfoot element
Status: Last call for comments
Categories
None.
Contexts in which this element may be used:
As a child of a table element, after any
caption, colgroup, and thead
elements and before any tbody and tr
elements, but only if there are no other tfoot
elements that are children of the table element.
As a child of a table element, after any
caption, colgroup, thead,
tbody, and tr elements, but only if there
are no other tfoot elements that are children of the
table element.
The tfoot element represents the block of rows that consist of the column summaries
(footers) for the parent table element, if the
tfoot element has a parent and it is a
table.
As a child of a table element, after any
caption, colgroup, and thead
elements, but only if there are no tbody elements that
are children of the table element.
Content model:
When the parent node is a thead element: Zero or more th elements
Creates a td element, inserts it into the table
row at the position given by the argument, and returns the
td.
The position is relative to the cells in the row. The
index â1, which is the default if the argument is omitted,
is equivalent to inserting at the end of the row.
If the given position is less than â1 or greater than
the number of cells, throws an INDEX_SIZE_ERR
exception.
The th element may have a scope content attribute
specified. The scope attribute is
an enumerated attribute with five states, four of which
have explicit keywords:
The row
keyword, which maps to the row state
The row state means the header cell applies to some of
the subsequent cells in the same row(s).
The col
keyword, which maps to the column state
The column state means the header cell applies to some
of the subsequent cells in the same column(s).
The rowgroup keyword,
which maps to the row group state
The row group state means the header cell applies to all
the remaining cells in the row group. A th element's
scope attribute must not be in
the row group state if
the element is not anchored in a row group.
The colgroup keyword,
which maps to the column group state
The column group state means the header cell applies to
all the remaining cells in the column group. A th
element's scope attribute must
not be in the column
group state if the element is not anchored in a column group.
The auto state
The auto state makes the header cell apply to a set of
cells selected based on context.
The scope attribute's
missing value default is the auto state.
The following example shows how the scope attribute's rowgroup value affects which
data cells a header cell applies to.
The td and th elements may have a colspan content
attribute specified, whose value must be a valid non-negative
integer greater than zero.
The td and th elements may also have a
rowspan content
attribute specified, whose value must be a valid non-negative
integer.
These attributes give the number of columns and rows respectively
that the cell is to span. These attributes must not be used to
overlap cells.
The td and th element may have a headers content
attribute specified. The headers attribute, if specified,
must contain a string consisting of an unordered set of unique
space-separated tokens, each of which must have the value of
an ID of a th element taking part in the same table as the td or
th element.
A th element with ID id is said
to be directly targeted by all td and
th elements in the same table that have headers attributes whose values
include as one of their tokens the ID id. A
th element A is said to be
targeted by a th or td element
B if either A is directly
targeted by B or if there exists an element
C that is itself targeted by the element
B and A is directly
targeted by C.
Returns the position of the cell in the row's cells list. This does not necessarily
correspond to the x-position of the cell in
the table, since earlier cells might cover multiple rows or
columns.
Returns 0 if the element isn't in a row.
4.9.12 Examples
Status: Last call for comments
This section is non-normative.
The following shows how might one mark up the bottom part of
table 45 of the Smithsonian physical tables, Volume
71:
The following shows how one might mark up the operating expenses
table from lower on the same page of that document:
<table>
<colgroup> <col>
<colgroup> <col> <col> <col>
<thead>
<tr> <th> <th>2008 <th>2007 <th>2006
<tbody>
<tr> <th scope=rowgroup> Research and development
<td> $ 1,109 <td> $ 782 <td> $ 712
<tr> <th scope=row> Percentage of net sales
<td> 3.4% <td> 3.3% <td> 3.7%
<tbody>
<tr> <th scope=rowgroup> Selling, general, and administrative
<td> $ 3,761 <td> $ 2,963 <td> $ 2,433
<tr> <th scope=row> Percentage of net sales
<td> 11.6% <td> 12.3% <td> 12.6%
</table>
This table could look like this:
2008
2007
2006
Research and development
$ 1,109
$ 782
$ 712
Percentage of net sales
3.4%
3.3%
3.7%
Selling, general, and administrative
$ 3,761
$ 2,963
$ 2,433
Percentage of net sales
11.6%
12.3%
12.6%
4.10 Forms
Status: Last call for comments
4.10.1 Introduction
Status: Last call for comments
This section is non-normative.
Forms allow unscripted client-server interaction: given a form, a
user can provide data, submit it to the server, and have the server
act on it accordingly (e.g. returning the results of a search or
calculation). The elements used in forms can also be used for user
interaction with no associated submission mechanism, in conjunction
with scripts.
Writing a form consists of several steps, which can be performed
in any order: writing the user interface, implementing the
server-side processing, and configuring the user interface to
communicate with the server.
4.10.1.1 Writing a form's user interface
This section is non-normative.
For the purposes of this brief introduction, we will create a
pizza ordering form.
Any form starts with a form element, inside which
are placed the controls. Most controls are represented by the
input element, which by default provides a one-line
text field. To label a control, the label element is
used; the label text and the control itself go inside the
label element. Each part of a form is considered a
paragraph, and is typically separated from other parts
using p elements. Putting this together, here is how
one might ask for the customer's name:
To let the user select the size of the pizza, we can use a set of
radio buttons. Radio buttons also use the input
element, this time with a type
attribute with the value radio. To make the radio
buttons work as a group, they are given a common name using the
name attribute. To group a batch
of controls together, such as, in this case, the radio buttons, one
can use the fieldset element. The title of such a group
of controls is given by the first element in the
fieldset, which has to be a legend
element.
<form>
<p><label>Customer name: <input></label></p>
<fieldset>
<legend> Pizza Size </legend>
<p><label> <input type=radio name=size> Small </label></p>
<p><label> <input type=radio name=size> Medium </label></p>
<p><label> <input type=radio name=size> Large </label></p>
</fieldset>
</form>
Changes from the previous step are highlighted.
To pick toppings, we can use checkboxes. These use the
input element with a type attribute with the value checkbox:
The pizzeria for which this form is being written is always
making mistakes, so it needs a way to contact the customer. For this
purpose, we can use form controls specifically for telephone numbers
(input elements with their type attribute set to tel) and e-mail addresses
(input elements with their type attribute set to email):
We can use an input element with its type attribute set to time to ask for a delivery
time. Many of these form controls have attributes to control exactly
what values can be specified; in this case, three attributes of
particular interest are min,
max, and step. These set the minimum time, the
maximum time, and the interval between allowed values (in
seconds). This pizzeria only delivers between 11am and 9pm, and
doesn't promise anything better than 15 minute increments, which we
can mark up as follows:
The textarea element can be used to provide a
free-form text field. In this instance, we are going to use it to
provide a space for the customer to give delivery instructions:
4.10.1.2 Implementing the server-side processing for a form
This section is non-normative.
The exact details for writing a server-side processor are out of
scope for this specification. For the purposes of this introduction,
we will assume that the script at https://pizza.example.com/order.cgi is configured to
accept submissions using the application/x-www-form-urlencoded
format, expecting the following parameters sent in an HTTP POST
body:
custname
Customer's name
custtel
Customer's telephone number
custemail
Customer's e-mail address
size
The pizza size, either small, medium, or large
toppings
The topping, specified once for each selected topping, with the allowed values being bacon, cheese, onion, and mushroom
delivery
The requested delivery time
comments
The delivery instructions
4.10.1.3 Configuring a form to communicate with a server
This section is non-normative.
Form submissions are exposed to servers in a variety of ways,
most commonly as HTTP GET or POST requests. To specify the exact
method used, the method
attribute is specified on the form element. This
doesn't specify how the form data is encoded, though; to specify
that, you use the enctype
attribute. You also have to specify the URL of the
service that will handle the submitted data, using the action attribute.
For each form control you want submitted, you then have to give a
name that will be used to refer to the data in the submission. We
already specified the name for the group of radio buttons; the same
attribute (name) also specifies
the submission name. Radio buttons can be distinguished from each
other in the submission by giving them different values, using the
value attribute.
Multiple controls can have the same name; for example, here we
give all the checkboxes the same name, and the server distinguishes
which checkbox was checked by seeing which values are submitted with
that name â like the radio buttons, they are also given unique
values with the value
attribute.
Given the settings in the previous section, this all becomes:
For example, if the customer entered "Denise Lawrence" as their
name, "555-321-8642" as their telephone number, did not specify an
e-mail address, asked for a medium-sized pizza, selected the Extra
Cheese and Mushroom toppings, entered a delivery time of 7pm, and
left the delivery instructions text field blank, the user agent
would submit the following to the online Web service:
Forms can be annotated in such a way that the user agent will
check the user's input before the form is submitted. The server
still has to verify the input is valid (since hostile users can
easily bypass the form validation), but it allows the user to avoid
the wait incurred by having the server be the sole checker of the
user's input.
The simplest annotation is the required attribute, which can be
specified on input elements to indicate that the form
is not to be submitted until a value is given. By adding this
attribute to the customer name and delivery time fields, we allow
the user agent to notify the user when the user submits the form
without filling in those fields:
It is also possible to limit the length of the input, using the
maxlength attribute. By
adding this to the textarea element, we can limit users
to 1000 characters, preventing them from writing huge essays to the
busy delivery drivers instead of staying focused and to the
point:
Mostly for historical reasons, elements in this section fall into
several overlapping (but subtly different) categories in addition to
the usual ones like flow content, phrasing
content, and interactive content.
A number of the elements are form-associated elements, which means they can have a
form owner and, to expose this, have a form content attribute with a matching
form IDL attribute.
In addition, some submittable
elements can be, depending on their attributes, buttons. The prose below defines when
an element is a button. Some buttons are specifically submit buttons.
The form element represents a
collection of form-associated
elements, some of which can represent editable values that
can be submitted to a server for processing.
The name attribute
represents the form's name within the forms collection. The value must
not be the empty string, and the value must be unique amongst the
form elements in the forms collection that it is in, if
any.
The autocomplete
attribute is an enumerated attribute. The attribute has
two states. The on
keyword maps to the on state, and the
off keyword maps to
the off
state. The attribute may also be omitted. The missing value
default is the on state. The off state indicates
that by default, input elements in the form will have
their resulting autocompletion state set to off; the on state indicates
that by default, input elements in the form will have
their resulting autocompletion state set to on.
Returns the form control in the form with the given ID or name (excluding image buttons for
historical reasons).
Once an element has been referenced using a particular name,
that name will continue being available as a way to reference that
element in this method, even if the element's actual ID or name changes, for as long as the
element remains in the Document.
If there are multiple matching items, then a
NodeList object containing all those elements is
returned.
Returns null if no element with that ID or name could be found.
The fieldset element represents a set
of form controls optionally grouped under a common name.
The name of the group is given by the first legend
element that is a child of the fieldset element, if
any. The remainder of the descendants form the group.
The disabled
attribute, when specified, causes all the form control descendants
of the fieldset element, excluding those that are
descendants of the fieldset element's first
legend element child, if any, to be disabled.
The form attribute is used to
explicitly associate the fieldset element with its
form owner. The name
attribute represents the element's name.
Returns an HTMLCollection of the form controls in
the element.
The following snippet shows a fieldset with a checkbox in the
legend that controls whether or not the fieldset is enabled. The
contents of the fieldset consist of two required text fields and an
optional year/month control.
The labelrepresents a caption in a
user interface. The caption can be associated with a specific form
control, either using for attribute, or by putting the form
control inside the label element itself.
The for attribute
may be specified to indicate a form control with which the caption
is to be associated. If the attribute is specified, the attribute's
value must be the ID of a labelable
form-associated element in the same Document as
the label element.
The input element represents a typed data field,
usually with a form control to allow the user to edit the data.
The type
attribute controls the data type (and associated control) of the
element. It 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 form attribute is used to
explicitly associate the input element with its
form owner. The name
attribute represents the element's name. The disabled attribute is used to make
the control non-interactive and to prevent its value from being
submitted. The autofocus
attribute controls focus.
The input element represents a value
that is not intended to be examined or manipulated by the user.
If the name attribute is
present and has a value that is a case-sensitive match
for the string "_charset_", then the element's
value attribute must be
omitted.
The
value
IDL attribute applies to this element and is
in mode default.
The input element represents a one line
plain text edit control for the element's value.
The difference between the Text state and the Search state is primarily
stylistic: on platforms where search fields are distinguished from
regular text fields, the Search state might result in
an appearance consistent with the platform's search fields rather
than appearing like a regular text field.
The value attribute, if
specified, must have a value that contains no U+000A LINE FEED (LF)
or U+000D CARRIAGE RETURN (CR) characters.
The input element represents a control
for editing a telephone number given in the element's value.
The value attribute, if
specified, must have a value that contains no U+000A LINE FEED (LF)
or U+000D CARRIAGE RETURN (CR) characters.
Unlike the URL and E-mail types, the Telephone type does not enforce a
particular syntax. This is intentional; in practice, telephone
number fields tend to be free-form fields, because there are a wide
variety of valid phone numbers. Systems that need to enforce a
particular format are encouraged to use the pattern attribute or the setCustomValidity() method
to hook into the client-side validation mechanism.
<input type="url" name="location" list="urls">
<datalist id="urls">
<option label="MIME: Format of Internet Message Bodies" value="http://www.ietf.org/rfc/rfc2045">
<option label="HTML 4.01 Specification" value="http://www.w3.org/TR/html4/">
<option label="Form Controls" value="http://www.w3.org/TR/xforms/slice8.html#ui-commonelems-hint">
<option label="Scalable Vector Graphics (SVG) 1.1 Specification" value="http://www.w3.org/TR/SVG/">
<option label="Feature Sets - SVG 1.1 - 20030114" value="http://www.w3.org/TR/SVG/feature.html">
<option label="The Single UNIX Specification, Version 3" value="http://www.unix-systems.org/version3/">
</datalist>
...and the user had typed "www.w3", and the user
agent had also found that the user had visited
http://www.w3.org/Consortium/#membership and
http://www.w3.org/TR/XForms/ in the recent past, then
the rendering might look like this:
The first four URIs in this sample consist of the four URIs in
the author-specified list that match the text the user has entered,
sorted lexically. Note how the UA is using the knowledge that the
values are URIs to allow the user to omit the scheme part and
perform intelligent matching on the domain name.
The last two URIs (and probably many more, given the scrollbar's
indications of more values being available) are the matches from
the user agent's session history data. This data is not made
available to the page DOM. In this particular case, the UA has no
titles to provide for those values.
4.10.7.1.5 E-mail state
Status: Last call for comments
The input element represents a control
for editing a list of e-mail addresses given in the element's value.
If the multiple
attribute is specified on the element, then the value attribute, if specified, must
have a value that is a valid e-mail address list;
otherwise, the value
attribute, if specified, must have a value that is a single
valid e-mail address.
A valid e-mail address is a string that matches the
ABNF production 1*( atext / "." ) "@" ldh-str 1*( "." ldh-str )
where atext is defined in RFC 5322 section
3.2.3, and ldh-str is defined in RFC 1034
section 3.5. [ABNF][RFC5322][RFC1034]
This requirement is a willful violation
of RFC 5322, which defines a syntax for e-mail addresses that is
simultaneously too strict (before the "@" character), too vague
(after the "@" character), and too lax (allowing comments, white
space characters, and quoted strings in manners unfamiliar to most
users) to be of practical use here.
The input element represents a one line
plain text edit control for the element's value. The user agent should obscure
the value so that people other than the user cannot see it.
The value attribute, if
specified, must have a value that contains no U+000A LINE FEED (LF)
or U+000D CARRIAGE RETURN (CR) characters.
The following fragment shows part of a calendar application. A
user can specify a date and time for a meeting (in his local time
zone, probably, though the user agent can allow the user to change
that), and since the submitted data includes the time-zone offset,
the application can ensure that the meeting is shown at the correct
time regardless of the time zones used by all the participants.
Had the application used the datetime-local type
instead, the calendar application would have also had to explicitly
determine which time zone the user intended.
4.10.7.1.8 Date state
Status: Last call for comments
The input element represents a control
for setting the element's value to a string representing a
specific date.
The input element represents a control
for setting the element's value to a string representing a
local date and time,
with no time-zone offset information.
The following example shows part of a flight booking
application. The application uses an input element
with its type attribute set to
datetime-local,
and it then interprets the given date and time in the time zone of
the selected airport.
If the application instead used the datetime type, then the
user would have to work out the time-zone conversions himself,
which is clearly not a good user experience!
4.10.7.1.13 Number state
Status: Last call for comments
The input element represents a control
for setting the element's value to a string representing a
number.
The input element represents a control
for setting the element's value to a string representing a
number, but with the caveat that the exact value is not important,
letting UAs provide a simpler interface than they do for the Number state.
Here is an example of a range control using an autocomplete list
with the list attribute. This
could be useful if there are values along the full range of the
control that are especially important, such as preconfigured light
levels or typical speed limits in a range control used as a speed
control. The following markup fragment:
Note how the UA determined the orientation of the control from
the ratio of the style-sheet-specified height and width properties.
The colors were similiarly derived from the style sheet. The tick
marks, however, were derived from the markup. In particular, the
step attribute has not
affected the placement of tick marks, the UA deciding to only use
the author-specified completion values and then adding longer tick
marks at the extremes.
Note also how the invalid value +50 was
completely ignored.
For another example, consider the following markup fragment:
A user agent could display in a variety of ways, for instance:
Or, alternatively, for instance:
The user agent could pick which one to display based on the
dimensions given in the style sheet. This would allow it to
maintain the same resolution for the tick marks, despite the
differences in width.
The following common input element content
attributes, IDL attributes, and methods apply to the element:
autocomplete and
list content attributes;
list,
value, and
selectedOption IDL attributes.
The input element represents a
two-state control that represents the element's checkedness state. If the
element's checkedness state
is true, the control represents a positive selection, and if it is
false, a negative selection. If the element's indeterminate IDL attribute
is set to true, then the control's selection should be obscured as
if the control was in a third, indeterminate, state.
The control is never a true tri-state control, even
if the element's indeterminate IDL attribute
is set to true. The indeterminate IDL attribute
only gives the appearance of a third state.
When set, overrides the rendering of checkbox controls so that
the current value is not visible.
The following common input element content
attributes and IDL attributes apply to the element:
checked, and
required content attributes;
checked and
value IDL attributes.
The input element represents a control
that, when used in conjunction with other input
elements, forms a radio button group in which only one
control can have its checkedness state set to true. If
the element's checkedness
state is true, the control represents the selected control in the
group, and if it is false, it indicates a control in the group that
is not selected.
The radio button group that contains an
input element a also contains all
the other input elements b that
fulfill all of the following conditions:
They both have a name
attribute, and the value of a's name attribute is a
compatibility caseless match for the value of b's name
attribute.
A document must not contain an input element whose
radio button group contains only that element.
If none of the radio buttons in a radio button
group are checked when they are inserted into the document,
then they will all be initially unchecked in the interface, until
such time as one of them is checked (either by the user or by
script).
The following common input element content
attributes and IDL attributes apply to the element:
checked and
required content attributes;
checked and
value IDL attributes.
Indicates that files of the specified type are accepted.
The tokens must not be ASCII case-insensitive
matches for any of the other tokens (i.e. duplicates are not
allowed).
For historical reasons, the value IDL attribute prefixes the
filename with the string "C:\fakepath\". Some
legacy user agents actually included the full path (which was a
security vulnerability). As a result of this, obtaining the
filename from the value IDL
attribute in a backwards-compatible way is non-trivial. The
following function extracts the filename in a suitably compatible
manner:
function extractFilename(path) {
var x;
x = path.lastIndexOf('\\');
if (x >= 0) // Windows-based path
return path.substr(x+1);
x = path.lastIndexOf('/');
if (x >= 0) // Unix-based path
return path.substr(x+1);
return path; // just the filename
}
This can be used as follows:
<p><input type=file name=image onchange="updateFilename(this.value)"></p>
<p>The name of the file you picked is: <span id="filename">(none)</span></p>
<script>
function updateFilename(path) {
var name = extractFilename(path);
document.getElementById('filename').textContent = name;
}
</script>
The following common input element content
attributes apply to the element:
The following common input element content
attributes and IDL attributes apply to the element:
accept,
multiple, and
required;
files and
value IDL attributes.
The input element represents either an
image from which a user can select a coordinate and submit the form,
or alternatively a button from which the user can submit the
form. The element is a button,
specifically a submit
button.
The image is given by the src attribute. The src attribute must be present, and
must contain a valid non-empty URL potentially surrounded by
spaces referencing a non-interactive, optionally animated,
image resource that is neither paged nor scripted.
The alt attribute
provides the textual label for the alternative button for users and
user agents who cannot use the image. The alt attribute must also be present,
and must contain a non-empty string.
Many aspects of this state's behavior are similar to
the behavior of the img element. Readers are encouraged
to read that section, where many of the same requirements are
described in more detail.
4.10.7.1.21 Reset Button state
Status: Last call for comments
The input element represents a button
that, when activated, resets the form. The element is a button.
The value IDL attribute
applies to this element and is in mode default.
User agents sometimes have features for helping users fill forms
in, for example prefilling the user's address based on earlier user
input.
The autocomplete
attribute is an enumerated attribute. The attribute has
three states. The on
keyword maps to the on state, and the
off keyword maps to
the off
state. The attribute may also be omitted. The missing value
default is the default
state.
The off
state indicates either that the control's input data is particularly
sensitive (for example the activation code for a nuclear weapon); or
that it is a value that will never be reused (for example a
one-time-key for a bank login) and the user will therefore have to
explicitly enter the data each time, instead of being able to rely
on the UA to prefill the value for him; or that the document
provides its own autocomplete mechanism and does not want the user
agent to provide autocompletion values.
Conversely, the on state indicates
that the value is not particularly sensitive and the user can expect
to be able to rely on his user agent to remember values he has
entered for that control.
The default state
indicates that the user agent is to use the autocomplete attribute on the
element's form owner instead. (By default, the autocomplete attribute of
form elements is in the on state.)
Banks frequently do not want UAs to prefill login
information:
Other URLs from the user's history might show also; this is up
to the user agent.
This example demonstrates how to design a form that uses the
autocompletion list feature while still degrading usefully in
legacy user agents.
If the autocompletion list is merely an aid, and is not
important to the content, then simply using a datalist
element with children option elements is enough. To
prevent the values from being rendered in legacy user agents, they
should be placed inside the value attribute instead of
inline.
However, if the values need to be shown in legacy UAs, then
fallback content can be placed inside the datalist
element, as follows:
<p>
<label>
Enter a breed:
<input type="text" name="breed" list="breeds">
</label>
<datalist id="breeds">
<label>
or select one from the list:
<select name="breed">
<option value=""> (none selected)
<option>Abyssinian
<option>Alpaca
<!-- ... -->
</select>
</label>
</datalist>
</p>
The fallback content will only be shown in UAs that don't
support datalist. The options, on the other hand, will
be detected by all UAs, even though they are not direct children of
the datalist element.
Note that if an option element used in a
datalist is selected, it will be selected
by default by legacy UAs (because it affects the
select), but it will not have any effect on the
input element in UAs that support
datalist.
The readonly
attribute is a boolean attribute that controls whether
or not the use can edit the form control.
In the following example, the existing product identifiers
cannot be modified, but they are still displayed as part of the
form, for consistency with the row representing a new product
(where the identifier is not yet filled in).
The size
attribute gives the number of characters that, in a visual
rendering, the user agent is to allow the user to see while editing
the element's value.
The required
attribute is a boolean attribute. When specified, the
element is required.
The following form has two required fields, one for an e-mail
address and one for a password. It also has a third field that is
only considerd valid if the user types the same password in the
password field and this third field.
If the user had, amongst many friends in his user contacts
database, two friends "Arthur Dent" (with address
"art@example.net") and "Adam Josh" (with address
"adamjosh@example.net"), then, after the user has typed "a", the
user agent might suggest these two e-mail addresses to the
user.
The page could also link in the user's contacts database from the site:
Suppose the user had entered "bob@example.net" into this text
field, and then started typing a second e-mail address starting
with "a". The user agent might show both the two friends mentioned
earlier, as well as the "astrophy" and "astronomy" values given in
the datalist element.
The following extract shows how an e-mail client's "Attachments"
field could accept multiple files for upload.
The following extract shows how a messaging client's text entry
could be arbitrarily restricted to a fixed number of characters,
thus forcing any conversion through this medium to be terse and
discouraging intelligent discourse.
What are you doing? <input name=status maxlength=140>
The pattern
attribute specifies a regular expression against which the control's
value is to be checked.
If specified, the attribute's value must match the JavaScript Pattern production. [ECMA262]
When an input element has a pattern attribute specified,
authors should include a title
attribute to give a description of the pattern. User agents may use
the contents of this attribute, if it is present, when informing the
user that the pattern is not matched, or at any other suitable time,
such as in a tooltip or read out by assistive technology when the
control gains focus.
For example, the following snippet:
<label> Part number:
<input pattern="[0-9][A-Z]{3}" name="part"
title="A part number is a digit followed by three uppercase letters."/>
</label>
...could cause the UA to display an alert such as:
A part number is a digit followed by three uppercase letters.
You cannot complete this form until the field is correct.
When a control has a pattern attribute, the title attribute, if used, must describe
the pattern. Additional information could also be included, so long
as it assists the user in filling in the control. Otherwise,
assistive technology would be impaired.
For instance, if the title attribute contained
the caption of the control, assistive technology could end up saying
something like The text you have entered does not match the
required pattern. Birthday, which is not useful.
UAs may still show the title in non-error situations
(for example, as a tooltip when hovering over the control), so
authors should be careful not to word titles as if an
error has necessarily occurred.
The placeholder
attribute represents a short hint (a word or short phrase)
intended to aid the user with data entry. A hint could be a sample
value or a brief description of the expected format. The attribute,
if specified, must have a value that contains no U+000A LINE FEED
(LF) or U+000D CARRIAGE RETURN (CR) characters.
For a longer hint or other advisory text, the title attribute is more appropriate.
The placeholder
attribute should not be used as an alternative to a
label.
Here is an example of a mail configuration user interface that
uses the placeholder
attribute:
Changes the form control's value by the value given in the
step attribute, multiplied by
n. The default is 1.
Throws INVALID_STATE_ERR exception if the control
is neither date- or time-based nor numeric, if the step attribute's value is "any", if the current value could not be parsed, or if
stepping in the given direction by the given amount would take the
value out of range.
The type
attribute controls the behavior of the button when it is activated.
It 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 value
attribute gives the element's value for the purposes of form
submission. The element's value is the value of the element's
value attribute, if there is
one, or the empty string otherwise.
A button (and its value) is only included in the
form submission if the button itself was used to initiate the form
submission.
The following button is labeled "Show hint" and pops up a dialog
box when activated:
<button type=button
onclick="alert('This 15-20 minute piece was composed by George Gershwin.')">
Show hint
</button>
The list of options
for a select element consists of all the
option element children of the select
element, and all the option element children of all the
optgroup element children of the select
element, in tree order.
The size
attribute gives the number of options to show to the user. The size attribute, if specified, must
have a value that is a valid non-negative integer
greater than zero. If the multiple attribute is present,
then the size attribute's
default value is 4. If the multiple attribute is absent,
then the size attribute's
default value is 1.
The form attribute is used to
explicitly associate the select element with its
form owner. The name
attribute represents the element's name. The disabled attribute is used to make
the control non-interactive and to prevent its value from being
submitted. The autofocus
attribute controls focus.
The before argument can be a number, in
which case element is inserted before the item
with that number, or an element from the list of options, 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 HIERARCHY_REQUEST_ERR
exception if element is an ancestor of the
element into which it is to be inserted. If element is not an option or
optgroup element, then the method does nothing.
Returns the value of the
first selected item, if any, or the empty string if there is no
selected item.
Can be set, to change the selection.
The following example shows how a select element
can be used to offer the user with a set of options from which the
user can select a single option. The default option is
preselected.
The datalist element represents a set of
option elements that represent predefined options for
other controls. The contents of the element represents fallback
content for legacy user agents, intermixed with option
elements that represent the predefined options. In the rendering,
the datalist element represents
nothing.
The datalist element is hooked up to an
input element using the list attribute on the
input element.
Each option element that is a descendant of the
datalist element, that is not disabled, and whose value is a string that isn't the
empty string, represents a suggestion. Each suggestion has a value and a label.
The disabled
attribute is a boolean attribute. An
option element is disabled if its disabled attribute is present or
if it is a child of an optgroup element whose disabled attribute is
present.
The label
attribute provides a label for element. The label of an option
element is the value of the label attribute, if there is one,
or the textContent of the element, if there isn't.
The value
attribute provides a value for element. The value of an option
element is the value of the value attribute, if there is one,
or the textContent of the element, if there isn't.
The selected
attribute represents the default selectedness of the
element.
A select element whose multiple attribute is not
specified must not have more than one descendant option
element with its selected
attribute set.
The defaultSelected argument sets the selected attribute.
The selected argument sets whether or not the element is selected. If it is omitted, even if the defaultSelected argument is true, the element is not selected.
The textarea element represents a
multiline plain text edit control. The contents of the control represent the
control's default value.
The readonly attribute
is a boolean attribute used to control whether the text
can be edited by the user or not.
The cols
attribute specifies the expected maximum number of characters per
line. If the cols attribute
is specified, its value must be a valid non-negative
integer greater than zero.
The rows
attribute specifies the number of lines to show. If the rows attribute is specified, its
value must be a valid non-negative integer greater than
zero.
The wrap
attribute is an enumerated attribute with two keywords
and states: the soft keyword
which maps to the Soft state, and the
hard keyword
which maps to the Hard state. The
missing value default is the Soft state.
If the element's wrap
attribute is in the Hard state, the cols attribute must be
specified.
The required attribute
is a boolean attribute. When specified, the user will
be required to enter a value before submitting the form.
The placeholder
attribute represents a hint (a word or short phrase) intended to aid
the user with data entry. A hint could be a sample value or a brief
description of the expected format. The attribute, if specified,
must have a value that contains no U+000A LINE FEED (LF) or U+000D
CARRIAGE RETURN (CR) characters.
For a longer hint or other advisory text, the title attribute is more appropriate.
The placeholder
attribute should not be used as an alternative to a
label.
The form attribute is used to
explicitly associate the textarea element with its
form owner. The name
attribute represents the element's name. The disabled attribute is used to make
the control non-interactive and to prevent its value from being
submitted. The autofocus
attribute controls focus.
textarea . type
Returns the string "textarea".
textarea . value
Returns the current value of the element.
Can be set, to change the value.
Here is an example of a textarea being used for
unrestricted free-form text input in a form:
<p>If you have any comments, please let us know: <textarea cols=80 name=comments></textarea></p>
The keygen element represents a key
pair generator control. When the control's form is submitted, the
private key is stored in the local keystore, and the public key is
packaged and sent to the server.
The challenge attribute
may be specified. Its value will be packaged with the submitted
key.
The keytype
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 listed in the cell in
the second column on the same row as the keyword. User agents are
not required to support these values, and must only recognize values
whose corresponding algorithms they support.
Keyword
State
rsa
RSA
The invalid value default state is the unknown state. The missing value default state
is the RSA state, if it is supported, or the unknown state otherwise.
This specification does not specify what key types
user agents are to support â it is possible for a user agent
to not support any key types at all.
The form attribute is used to
explicitly associate the keygen element with its
form owner. The name
attribute represents the element's name. The disabled attribute is used to make
the control non-interactive and to prevent its value from being
submitted. The autofocus
attribute controls focus.
keygen . type
Returns the string "keygen".
This specification does not specify how the private
key generated is to be used. It is expected that after receiving the
SignedPublicKeyAndChallenge (SPKAC) structure, the
server will generate a client certificate and offer it back to the
user for download; this certificate, once downloaded and stored in
the key store along with the private key, can then be used to
authenticate to services that use SSL and certificate
authentication.
To generate a key pair, add the private key to the user's key
store, and submit the public key to the server, markup such as the
following can be used:
The server will then receive a form submission with a packaged
RSA public key as the value of "key". This
can then be used for various purposes, such as generating a client
certificate, as mentioned above.
The for content
attribute allows an explicit relationship to be made between the
result of a calculation and the elements that represent the values
that went into the calculation or that otherwise influenced the
calculation. The for attribute,
if specified, must contain a string consisting of an unordered
set of unique space-separated tokens, each of which must have
the value of an ID of an element in the same
Document.
The form attribute is used to
explicitly associate the output element with its
form owner. The name
attribute represents the element's name.
The progress element represents the
completion progress of a task. The progress is either indeterminate,
indicating that progress is being made but that it is not clear how
much more work remains to be done before the task is complete
(e.g. because the task is waiting for a remote host to respond), or
the progress is a number in the range zero to a maximum, giving the
fraction of work that has so far been completed.
There are two attributes that determine the current task
completion represented by the element.
The value
attribute specifies how much of the task has been completed, and the
max attribute
specifies how much work the task requires in total. The units are
arbitrary and not specified.
Authors are encouraged to also include the current value and the
maximum value inline as text inside the element, so that the
progress is made available to users of legacy user agents.
Here is a snippet of a Web application that shows the progress
of some automated task:
(The updateProgress() method in this example would
be called by some other code on the page to update the actual
progress bar as the task progressed.)
The value and max attributes, when present, must
have values that are valid
floating point numbers. The value attribute, if present, must
have a value equal to or greater than zero, and less than or equal
to the value of the max
attribute, if present, or 1.0, otherwise. The max attribute, if present, must
have a value greater than zero.
The progress element is the wrong
element to use for something that is just a gauge, as opposed to
task progress. For instance, indicating disk space usage using
progress would be inappropriate. Instead, the
meter element is available for such use cases.
The meter element represents a scalar
measurement within a known range, or a fractional value; for example
disk usage, the relevance of a query result, or the fraction of a
voting population to have selected a particular candidate.
This is also known as a gauge.
The meter element should not be used to
indicate progress (as in a progress bar). For that role, HTML
provides a separate progress element.
The meter element also does not
represent a scalar value of arbitrary range â for example, it
would be wrong to use this to report a weight, or height, unless
there is a known maximum value.
There are six attributes that determine the semantics of the
gauge represented by the element.
The min attribute
specifies the lower bound of the range, and the max attribute specifies
the upper bound. The value attribute
specifies the value to have the gauge indicate as the "measured"
value.
The other three attributes can be used to segment the gauge's
range into "low", "medium", and "high" parts, and to indicate which
part of the gauge is the "optimum" part. The low attribute specifies
the range that is considered to be the "low" part, and the high attribute specifies
the range that is considered to be the "high" part. The optimum attribute
gives the position that is "optimum"; if that is higher than the
"high" value then this indicates that the higher the value, the
better; if it's lower than the "low" mark then it indicates that
lower values are better, and naturally if it is in between then it
indicates that neither high nor low values are good.
If no minimum or maximum is specified, then the
range is assumed to be 0..1, and the value thus has to be within
that range.
Authors are encouraged to include a textual representation of the
gauge's state in the element's contents, for users of user agents
that do not support the meter element.
The following examples show three gauges that would all be
three-quarters full:
Storage space usage: <meter value=6 max=8>6 blocks used (out of 8 total)</meter>
Voter turnout: <meter value=0.75><img alt="75%" src="graph75.png"></meter>
Tickets sold: <meter min="0" max="100" value="75"></meter>
The following example is incorrect use of the element, because
it doesn't give a range (and since the default maximum is 1, both
of the gauges would end up looking maxed out):
<p>The grapefruit pie had a radius of <meter value=12>12cm</meter>
and a height of <meter value=2>2cm</meter>.</p> <!-- BAD! -->
Instead, one would either not include the meter element, or use
the meter element with a defined range to give the dimensions in
context compared to other pies:
<p>The grapefruit pie had a radius of 12cm and a height of
2cm.</p>
<dl>
<dt>Radius: <dd> <meter min=0 max=20 value=12>12cm</meter>
<dt>Height: <dd> <meter min=0 max=10 value=2>2cm</meter>
</dl>
There is no explicit way to specify units in the
meter element, but the units may be specified in the
title attribute in free-form text.
The example above could be extended to mention the units:
User agents combine the value of
the title attribute and the other
attributes to provide context-sensitive help or inline text
detailing the actual values.
The name content
attribute gives the name of the form control, as used in form
submission and in the form element's elements object. If the attribute
is specified, its value must not be the empty string.
A form control is disabled
if its disabled attribute is
set, or if it is a descendant of a fieldset element
whose disabled attribute
is set and is not a descendant of that
fieldset element's first legend element
child, if any.
4.10.19.3 Autofocusing a form control
Status: Last call for comments
The autofocus
content attribute allows the user to indicate that a control is to
be focused as soon as the page is loaded, allowing the user to just
start typing without having to manually focus the main control.
Attributes for form submission can be specified both
on form elements and on submit buttons (elements that
represent buttons that submit forms, e.g. an input
element whose type attribute is
in the Submit Button
state).
The action of an element is
the value of the element's formaction attribute, if the
element is a submit
button and has such an attribute, or the value of its
form owner's action
attribute, if it has one, or else the empty string.
The method and
formmethod
content attributes are enumerated
attributes with the following keywords and states:
The keyword GET, mapping
to the state GET, indicating
the HTTP GET method.
The keyword POST, mapping
to the state POST, indicating
the HTTP POST method.
The keyword PUT, mapping
to the state PUT, indicating
the HTTP PUT method.
The keyword DELETE, mapping
to the state DELETE, indicating
the HTTP DELETE method.
The missing value default for these attributes is the
GET state.
The method of an element is
one of those four states. If the element is a submit button and has a formmethod attribute, then the
element's method is that
attribute's state; otherwise, it is the form owner's
method attribute's state.
The enctype and
formenctype
content attributes are enumerated
attributes with the following keywords and states:
The "application/x-www-form-urlencoded" keyword and corresponding state.
The "multipart/form-data" keyword and corresponding state.
The enctype of an element
is one of those three states. If the element is a submit button and has a formenctype attribute, then the
element's enctype is that
attribute's state; otherwise, it is the form owner's
enctype attribute's state.
The target of an element is
the value of the element's formtarget attribute, if the
element is a submit
button and has such an attribute; or the value of its
form owner's target
attribute, if it has such an attribute; or, if one of the
child nodes of the head element is a
base element with a target attribute, then the value of
the target attribute of the
first such base element; or, if there is no such
element, the empty string.
The novalidate
and formnovalidate
content attributes are boolean
attributes. If present, they indicate that the form is not to
be validated during submission.
The no-validate state of
an element is true if the element is a submit button and the element's
formnovalidate attribute
is present, or if the element's form owner's novalidate attribute is present,
and false otherwise.
This attribute is useful to include "save" buttons on forms that
have validation constraints, to allow users to save their progress
even though they haven't fully entered the data in the form. The
following example shows a simple form that has two required
fields. There are three buttons: one to submit the form, which
requires both fields to be filled in; one to save the form so that
the user can come back and fill it in later; and one to cancel the
form altogether.
Sets a custom error, so that the element would fail to
validate. The given message is the message to be shown to the user
when reporting the problem to the user.
If the argument is the empty string, clears the custom error.
Returns the error message that would be shown to the user if
the element was to be checked for validity.
In the following example, a script checks the value of a form
control each time it is edited, and whenever it is not a valid
value, uses the setCustomValidity() method
to set an appropriate message.
<label>Feeling: <input name=f type="text" oninput="check(this)"></label>
<script>
function check(input) {
if (input.value == "good" ||
input.value == "fine" ||
input.value == "tired") {
input.setCustomValidity('"' + input.value + '" is not a feeling.');
} else {
// input is fine -- reset the error message
input.setCustomValidity('');
}
}
</script>
4.10.20.3 Security
Servers should not rely on client-side
validation. Client-side validation can be intentionally bypassed by
hostile users, and unintentionally bypassed by users of older user
agents or automated tools that do not implement these features. The
constraint validation features are only intended to improve the user
experience, not to provide any kind of security mechanism.
4.10.21 Form submission
Status: Last call for comments
This section is non-normative.
When forms are submitted, the data in the form is converted into
the form specified by the enctype, and then sent to the
destination specified by the action using the given method.
If the user types in "cats" in the first field and "fur" in the
second, and then hits the submit button, then the user agent will
load /find.cgi?t=cats&q=fur.
Given the same user input, the result on submission is quite
different: the user agent instead does an HTTP POST to the given
URL, with as the entity body something like the following text:
The details element represents a
disclosure widget from which the user can obtain additional
information or controls.
The details element is not appropriate
for footnotes. Please see the section on
footnotes for details on how to mark up footnotes.
The summary element
child of the element, if any, represents the summary or
legend of the details.
The open
content attribute is a boolean attribute. If present,
it indicates that the details are to be shown to the user. If the
attribute is absent, the details are not to be shown.
The following example shows the details element
being used to hide technical details in a progress report.
One could use this in conjuction with other details
in a list to allow the user to collapse a set of fields down to a
small set of headings, with the ability to open each one.
In these examples, the summary really just summarises what the
controls can change, and not the actual values, which is less than
ideal.
The command element represents a command that the user
can invoke.
The type
attribute indicates the kind of command: either a normal command
with an associated action, or a state or option that can be toggled,
or a selection of one item from a list of items.
The attribute is an enumerated attribute with three
keywords and states. The "command"
keyword maps to the Command state, the
"checkbox"
keyword maps to the Checkbox state, and
the "radio"
keyword maps to the Radio state. The
missing value default is the Command state.
The Command state
The element represents a normal command with an associated action.
The Checkbox state
The element represents a state or option that can be toggled.
The Radio state
The element represents a selection of one item from a list of items.
The label
attribute gives the name of the command, as shown to the user. The
label attribute must be
specified and must have a value that is not the empty string.
The title
attribute gives a hint describing the command, which might be shown
to the user to help him.
The disabled attribute
is a boolean attribute that, if present, indicates that
the command is not available in the current state.
The distinction between disabled and hidden is subtle. A command would be
disabled if, in the same context, it could be enabled if only
certain aspects of the situation were changed. A command would be
marked as hidden if, in that situation, the command will never be
enabled. For example, in the context menu for a water faucet, the
command "open" might be disabled if the faucet is already open, but
the command "eat" would be marked hidden since the faucet could
never be eaten.
The checked
attribute is a boolean attribute that, if present,
indicates that the command is selected. The attribute must be
omitted unless the type
attribute is in either the Checkbox state or
the Radio
state.
The radiogroup
attribute gives the name of the group of commands that will be
toggled when the command itself is toggled, for commands whose type attribute has the value "radio". The scope of the name is the child list of
the parent element. The attribute must be omitted unless the type attribute is in the Radio state.
Here is an example of a toolbar with three buttons that let the
user toggle between left, center, and right alignment. One could
imagine such a toolbar as part of a text editor. The toolbar also
has a separator followed by another button labeled "Publish",
though that button is disabled.
The type attribute
is an enumerated attribute indicating the kind of menu
being declared. The attribute has three states. The context keyword maps to the
context menu state, in which
the element is declaring a context menu. The toolbar keyword maps to the
toolbar state, in which the
element is declaring a toolbar. The attribute may also be
omitted. The missing value default is the list state, which indicates that the element is merely
a list of commands that is neither declaring a context menu nor
defining a toolbar.
If a menu element's type attribute is in the context menu state, then the
element represents the commands of a context menu, and
the user can only interact with the commands if that context menu is
activated.
If a menu element's type attribute is in the toolbar state, then the element
represents a list of active commands that the user can
immediately interact with.
If a menu element's type attribute is in the list state, then the element either
represents an unordered list of items (each represented
by an li element), each of which represents a command
that the user can perform or activate, or, if the element has no
li element children, flow content
describing available commands.
The label
attribute gives the label of the menu. It is used by user agents to
display nested menus in the UI. For example, a context menu
containing another menu would use the nested menu's label attribute for the submenu's
menu label.
4.11.4.1 Introduction
Status: Last call for comments
This section is non-normative.
The menu element is used to define context menus and
toolbars.
For example, the following represents a toolbar with three menu
buttons on it, each of which has a dropdown menu with a series of
options:
In a supporting user agent, this might look like this:
In a legacy user agent, the above would look like a bulleted list
with three items, the first of which has four buttons, the second of
which has three, and the third of which has two nested bullet points
with two items consisting of links.
The following implements a similar toolbar, with a single button
whose values, when selected, redirect the user to Web sites.
The behavior in supporting user agents is similar to the example
above, but here the legacy behavior consists of a single
select element with a submit button. The submit button
doesn't appear in the toolbar, because it is not a direct child of
the menu element or of its li
children.
4.11.4.2 Context menus
Status: Last call for comments
The contextmenu
attribute gives the element's context
menu. The value must be the ID of a menu element
in the DOM.
Here is an example of a context menu for an input control:
<form name="npc">
<label>Character name: <input name=char type=text contextmenu=namemenu required></label>
<menu type=context id=namemenu>
<command label="Pick random name" onclick="document.forms.npc.elements.char.value = getRandomName()">
<command label="Prefill other fields based on name" onclick="prefillFields(document.forms.npc.elements.char.value)">
</menu>
</form>
This adds to items to the control's context menu, one called
"Pick random name", and one called "Prefill other fields based on
name". They invoke scripts that are not shown in the example
above.
4.11.5 Commands
Status: Last call for comments
A command is the abstraction
behind menu items, buttons, and links.
Commands are defined to have the following
facets:
Type
The kind of command: "command", meaning it is a normal command;
"radio", meaning that triggering the command will, amongst other
things, set the Checked
State to true (and probably uncheck some other commands); or
"checkbox", meaning that triggering the command will, amongst other
things, toggle the value of the Checked State.
ID
The name of the command, for referring to the command from the
markup or from script. If a command has no ID, it is an
anonymous command.
Label
The name of the command as seen by the user.
Hint
A helpful or descriptive string that can be shown to the
user.
Icon
An absolute URL identifying a graphical image that
represents the action. A command might not have an Icon.
Access Key
A key combination selected by the user agent that triggers the
command. A command might not have an Access Key.
Hidden State
Whether the command is hidden or not (basically, whether it
should be shown in menus).
Disabled State
Whether the command is relevant and can be triggered or not.
Checked State
Whether the command is checked or not.
Action
The actual effect that triggering the command will have. This
could be a scripted event handler, a URL to which to
navigate, or a form submission.
These facets are exposed on elements using the command
API:
Returns an HTMLCollection of the elements in the
Document that define commands and have IDs.
User agents may expose the commands whose Hidden State facet is false
(visible), e.g. in the user agent's menu bar. User agents are
encouraged to do this especially for commands that have Access Keys, as a way to
advertise those keys to the user.
4.12 Links
Status: Last call for comments
4.12.1 Hyperlink elements
Status: Last call for comments
The a, area, and link
elements can, in certain situations described in the definitions of
those elements, represent hyperlinks.
The href
attribute on a and area elements is not
required; when those elements do not have href attributes they do not
represent hyperlinks.
The href
attribute on the link element is required (and
has to be a valid non-empty URL), but whether
a link element represents a hyperlink or not depends on
the value of the rel attribute of
that element.
For a and area elements that represent
hyperlinks, the relationship between the document containing the
hyperlink and the destination resource indicated by the hyperlink is
given by the value of the element's rel attribute, which
must be a set of space-separated tokens. The allowed values and their meanings are defined
below. The rel attribute has
no default value. If the attribute is omitted or if none of the
values in the attribute are recognized by the user agent, then the
document has no particular relationship with the destination
resource other than there being a hyperlink between the two.
The media
attribute describes for which media the target document was
designed. It is purely advisory. The value must be a valid
media query. The default, if the media attribute is omitted, is
"all".
The hreflang
attribute on hyperlink elements, if present, gives the language of
the linked resource. It is purely advisory. The value must be a
valid BCP 47 language tag. [BCP47]
The type
attribute, if present, gives the MIME type of the
linked resource. It is purely advisory. The value must be a
valid MIME type.
4.12.2 Link types
Status: Last call for comments
The following table summarizes the link types that are defined by
this specification. This table is non-normative; the actual
definitions for the link types are given in the next few
sections.
In this section, the term referenced document refers to
the resource identified by the element representing the link, and
the term current document refers to the resource within
which the element representing the link finds itself.
Except where otherwise specified, a keyword must not be specified
more than once per rel
attribute.
The link types that contain no U+003A COLON characters (:),
including all those defined in this specification, are ASCII
case-insensitive values.
The meaning of this keyword depends on the values of the other
attributes.
If the element is a link element and the rel attribute also contains the
keyword stylesheet
The alternate keyword
modifies the meaning of the stylesheet keyword in the way
described for that keyword. The alternate keyword does not create a
link of its own.
The alternate keyword is
used with the type
attribute set to the value application/rss+xml or the value application/atom+xml
The link is a hyperlink
referencing a syndication feed (though not necessarily syndicating
exactly the same content as the current page).
Otherwise
The link is a hyperlink
referencing an alternate representation of the current
document.
The nature of the referenced document is given by the media, hreflang, and type attributes.
If the alternate keyword is
used with the media
attribute, it indicates that the referenced document is intended for
use with the media specified.
If the alternate keyword is
used with the hreflang
attribute, and that attribute's value differs from the root
element's language, it indicates that the
referenced document is a translation.
If the alternate keyword is
used with the type
attribute, it indicates that the referenced document is a
reformulation of the current document in the specified format.
This relationship is transitive â that is, if a document
links to two other documents with the link type "alternate", then, in addition to
implying that those documents are alternative representations of
the first document, it is also implying that those two documents
are alternative representations of each other.
For a and area elements, the author keyword indicates that the
referenced document provides further information about the author of
the nearest article element ancestor of the element
defining the hyperlink, if there is one, or of the page as a whole,
otherwise.
For link elements, the author keyword indicates that the
referenced document provides further information about the author
for the page as a whole.
The "referenced document" can be, and often is, a
mailto: URL giving the e-mail address of the
author. [MAILTO]
4.12.2.4 Link type "bookmark"
Status: Last call for comments
The bookmark keyword may be
used with a and area elements.
The following snippet has three permalinks. A user agent could
determine which permalink applies to which part of the spec by
looking at where the permalinks are given.
...
<body>
<h1>Example of permalinks</h1>
<div id="a">
<h2>First example</h2>
<p><a href="a.html" rel="bookmark">This</a> permalink applies to
only the content from the first H2 to the second H2. The DIV isn't
exactly that section, but it roughly corresponds to it.</p>
</div>
<h2>Second example</h2>
<article id="b">
<p><a href="b.html" rel="bookmark">This</a> permalink applies to
the outer ARTICLE element (which could be, e.g., a blog post).</p>
<article id="c">
<p><a href="c.html" rel="bookmark">This</a> permalink applies to
the inner ARTICLE element (which could be, e.g., a blog comment).</p>
</article>
</article>
</body>
...
4.12.2.5 Link type "external"
Status: Last call for comments
The external keyword may be
used with a and area elements.
The external keyword indicates
that the link is leading to a document that is not part of the site
that the current document forms a part of.
4.12.2.6 Link type "help"
Status: Last call for comments
The help keyword may be used with
link, a, and area
elements. For link elements, it creates a hyperlink.
For a and area elements, the help keyword indicates that the referenced
document provides further help information for the parent of the
element defining the hyperlink, and its children.
In the following example, the form control has associated
context-sensitive help. The user agent could use this information,
for example, displaying the referenced document if the user presses
the "Help" or "F1" key.
Icons could be auditory icons, visual icons, or other kinds of
icons.
The sizes
attribute gives the sizes of icons for visual media.
If specified, the attribute must have a value that is an
unordered set of unique space-separated tokens. The
values must all be either any or a value that consists of
two valid non-negative
integers that do not have a leading U+0030 DIGIT ZERO (0)
character and that are separated by a single U+0078 LATIN SMALL
LETTER X character (x).
The keywords represent icon sizes.
The any keyword
represents that the resource contains a scalable icon, e.g. as
provided by an SVG image.
The keywords specified on the sizes attribute must not represent
icon sizes that are not actually available in the linked
resource.
The following snippet shows the top part of an application with
several icons.
The license keyword indicates
that the referenced document provides the copyright license terms
under which the main content of the current document is
provided.
This specification does not specify how to distinguish between
the main content of a document and content that is not deemed to be
part of that main content. The distinction should be made clear to
the user.
Consider a photo sharing site. A page on that site might
describe and show a photograph, and the page might be marked up as
follows:
In this case the license
applies to just the photo (the main content of the document), not
the whole document. In particular not the design of the page
itself, which is covered by the copyright given at the bottom of
the document. This could be made clearer in the styling
(e.g. making the license link prominently positioned near the
photograph, while having the page copyright in light small text at
the foot of the page.
4.12.2.9 Link type "nofollow"
Status: Last call for comments
The nofollow keyword may be
used with a and area elements.
The nofollow keyword indicates
that the link is not endorsed by the original author or publisher of
the page, or that the link to the referenced document was included
primarily because of a commercial relationship between people
affiliated with the two pages.
4.12.2.10 Link type "noreferrer"
Status: Last call for comments
The noreferrer keyword may be
used with a and area elements.
It indicates that no referrer information is to be leaked when
following the link.
The prefetch keyword indicates
that preemptively fetching and caching the specified resource is
likely to be beneficial, as it is highly likely that the user will
require this resource.
There is no default type for resources given by the prefetch keyword.
The search keyword indicates that
the referenced document provides an interface specifically for
searching the document and its related resources.
OpenSearch description documents can be used with
link elements and the search link type to enable user agents to
autodiscover search interfaces. [OPENSEARCH]
The specified resource is a resource that describes how to
present the document. Exactly how the resource is to be processed
depends on the actual type of the resource.
If the alternate keyword is
also specified on the link element, then the link
is an alternative stylesheet; in this case, the title attribute must be specified on the
link element, with a non-empty value.
The default type for resources given by the stylesheet keyword is text/css.
The tag keyword may be used
with link, a, and area
elements. For link elements, it creates a hyperlink.
The tag keyword indicates that the
tag that the referenced document represents applies to the
current document.
Since it indicates that the tag applies to the
current document, it would be inappropriate to use this keyword
in the markup of a tag cloud, which lists
the popular tag across a set of pages.
4.12.2.17 Hierarchical link types
Status: Last call for comments
Some documents form part of a hierarchical structure of
documents.
A hierarchical structure of documents is one where each document
can have various subdocuments. The document of which a document is a
subdocument is said to be the document's parent. A document
with no parent forms the top of the hierarchy.
The index keyword indicates that
the document is part of a hierarchical structure, and that the link
is leading to the document that is the top of the hierarchy. It
conveys more information when used with the up keyword (q.v.).
4.12.2.17.2 Link type "up"
Status: Last call for comments
The up keyword may be used with
link, a, and area
elements. For link elements, it creates a hyperlink.
The up keyword indicates that the
document is part of a hierarchical structure, and that the link is
leading to a document that is an ancestor of the current
document.
The up keyword may be repeated within
a rel attribute to indicate
the hierarchical distance from the current document to the
referenced document. If it occurs only once, then the link is
leading to the current document's parent; each additional occurrence
of the keyword represents one further level. If the index keyword is also present, then the
number of up keywords is the depth of
the current page relative to the top of the hierarchy. Only one link
is created for the set of one or more up
keywords and, if present, the index
keyword.
If the page is part of multiple hierarchies, then they should be
described in different paragraphs.
This can be used to mark up a navigation style sometimes known
as bread crumbs. In the following example, the current page can be
reached via two paths.
The relList IDL
attribute (e.g. on the a element) does not currently
represent multiple up keywords (the
interface hides duplicates).
4.12.2.18 Sequential link types
Status: Last call for comments
Some documents form part of a sequence of documents.
A sequence of documents is one where each document can have a
previous sibling and a next sibling. A document
with no previous sibling is the start of its sequence, a document
with no next sibling is the end of its sequence.
The first keyword indicates that
the document is part of a sequence, and that the link is leading to
the document that is the first logical document in the sequence.
4.12.2.18.2 Link type "last"
Status: Last call for comments
The last keyword may be used with
link, a, and area
elements. For link elements, it creates a hyperlink.
The last keyword indicates that the
document is part of a sequence, and that the link is leading to the
document that is the last logical document in the sequence.
4.12.2.18.3 Link type "next"
Status: Last call for comments
The next keyword may be used with
link, a, and area
elements. For link elements, it creates a hyperlink.
The next keyword indicates that the
document is part of a sequence, and that the link is leading to the
document that is the next logical document in the sequence.
4.12.2.18.4 Link type "prev"
Status: Last call for comments
The prev keyword may be used with
link, a, and area
elements. For link elements, it creates a hyperlink.
The prev keyword indicates that the
document is part of a sequence, and that the link is leading to the
document that is the previous logical document in the sequence.
The keyword is not allowed to be specified on a
and area elements.
Hyperlink
The keyword may be specified on a and
area elements.
Brief description
A short non-normative description of what the keyword's
meaning is.
Specification
A link to a more detailed description of the keyword's
semantics and requirements. It could be another page on the Wiki,
or a link to an external page.
Synonyms
A list of other keyword values that have exactly the same
processing requirements. Authors should not use the values 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 keyword has not received wide peer review and
approval. Someone has proposed it and is, or soon will be, using
it.
Ratified
The keyword has received wide peer review and approval. It
has a specification that unambiguously defines how to handle
pages that use the keyword, including when they use it in
incorrect ways.
Discontinued
The keyword has received wide peer review and it has been
found wanting. Existing pages are using this keyword, 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 keyword is found to be redundant with existing values, it
should be removed and listed as a synonym for the existing
value.
If a keyword 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 keyword 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 keyword 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.
Types defined as extensions in the WHATWG Wiki
RelExtensions page with the status "proposed" or "ratified" may
be used with the rel attribute on
link, a, and area elements in
accordance to the "Effect on..." field. [WHATWGWIKI]
4.13 Common idioms without dedicated elements
Status: Last call for comments. ISSUE-89 (idioms) blocks progress to Last Call
4.13.1 Tag clouds
Status: Last call for comments
This specification does not define any markup
specifically for marking up lists of keywords that apply to a group
of pages (also known as tag clouds). In general, authors are
encouraged to either mark up such lists using ul
elements with explicit inline counts that are then hidden and turned
into a presentational effect using a style sheet, or to use SVG.
Here, three tags are included in a short tag cloud:
The actual frequency of each tag is given using the title attribute. A CSS style sheet is
provided to convert the markup into a cloud of differently-sized
words, but for user agents that do not support CSS or are not
visual, the markup contains annotations like "(popular)" or
"(rare)" to categorize the various tags by frequency, thus enabling
all users to benefit from the information.
The ul element is used (rather than
ol) because the order is not particularly important:
while the list is in fact ordered alphabetically, it would convey
the same information if ordered by, say, the length of the tag.
The tagrel-keyword is not used
on these a elements because they do not represent tags
that apply to the page itself; they are just part of an index
listing the tags themselves.
4.13.2 Conversations
Status: Last call for comments
This specification does not define a specific element for marking
up conversations, meeting minutes, chat transcripts, dialogues in
screenplays, instant message logs, and other situations where
different players take turns in discourse.
Instead, authors are encouraged to mark up conversations using
p elements and punctuation. Authors who need to mark
the speaker for styling purposes are encouraged to use
span or b. Paragraphs with their text
wrapped in the i element can be used for marking up
stage directions.
This example demonstrates this using an extract from Abbot and
Costello's famous sketch, Who's on first:
<p> Costello: Look, you gotta first baseman?
<p> Abbott: Certainly.
<p> Costello: Who's playing first?
<p> Abbott: That's right.
<p> Costello becomes exasperated.
<p> Costello: When you pay off the first baseman every month, who gets the money?
<p> Abbott: Every dollar of it.
The following extract shows how an IM conversation log could be
marked up.
<p> <time>14:22</time> <b>egof</b> I'm not that nerdy, I've only seen 30% of the star trek episodes
<p> <time>14:23</time> <b>kaj</b> if you know what percentage of the star trek episodes you have seen, you are inarguably nerdy
<p> <time>14:23</time> <b>egof</b> it's unarguably
<p> <time>14:23</time> <i>* kaj blinks</i>
<p> <time>14:24</time> <b>kaj</b> you are not helping your case
4.13.3 Footnotes
Status: Last call for comments
HTML does not have a dedicated mechanism for marking up
footnotes. Here are the recommended alternatives.
For short inline annotations, the title attribute should be used.
In this example, two parts of a dialogue are annotated with
footnote-like content using the title attribute.
<p> <b>Customer</b>: Hello! I wish to register a complaint. Hello. Miss?
<p> <b>Shopkeeper</b>: <span title="Colloquial pronunciation of 'What do you'"
>Watcha</span> mean, miss?
<p> <b>Customer</b>: Uh, I'm sorry, I have a cold. I wish to make a complaint.
<p> <b>Shopkeeper</b>: Sorry, <span title="This is, of course, a lie.">we're
closing for lunch</span>.
For longer annotations, the a element should be
used, pointing to an element later in the document. The convention
is that the contents of the link be a number in square brackets.
In this example, a footnote in the dialogue links to a paragraph
below the dialogue. The paragraph then reciprocally links back to the
dialogue, allowing the user to return to the location of the
footnote.
<p> Announcer: Number 16: The <i>hand</i>.
<p> Interviewer: Good evening. I have with me in the studio tonight
Mr Norman St John Polevaulter, who for the past few years has been
contradicting people. Mr Polevaulter, why <em>do</em> you
contradict people?
<p> Norman: I don't. <sup><a href="#fn1" id="r1">[1]</a></sup>
<p> Interviewer: You told me you did!
...
<section>
<p id="fn1"><a href="#r1">[1]</a> This is, naturally, a lie,
but paradoxically if it were true he could not say so without
contradicting the interviewer and thus making it false.</p>
</section>
For side notes, longer annotations that apply to entire sections
of the text rather than just specific words or sentences, the
aside element should be used.
In this example, a sidebar is given after a dialogue, giving it
some context.
<p> <span class="speaker">Customer</span>: I will not buy this record, it is scratched.
<p> <span class="speaker">Shopkeeper</span>: I'm sorry?
<p> <span class="speaker">Customer</span>: I will not buy this record, it is scratched.
<p> <span class="speaker">Shopkeeper</span>: No no no, this's'a tobacconist's.
<aside>
<p>In 1970, the British Empire lay in ruins, and foreign
nationalists frequented the streets â many of them Hungarians
(not the streets â the foreign nationals). Sadly, Alexander
Yalt has been publishing incompetently-written phrase books.
</aside>
For figures or tables, footnotes can be included in the relevant
figcaption or caption element, or in
surrounding prose.
In this example, a table has cells with footnotes
that are given in prose. A figure element is used to
give a single legend to the combination of the table and its
footnotes.
<figure>
<figcaption>Table 1. Alternative activities for knights.</figcaption>
<table>
<tr>
<th> Activity
<th> Location
<th> Cost
<tr>
<td> Dance
<td> Wherever possible
<td> £0<sup><a href="#fn1">1</a></sup>
<tr>
<td> Routines, chorus scenes<sup><a href="#fn2">2</a></sup>
<td> Undisclosed
<td> Undisclosed
<tr>
<td> Dining<sup><a href="#fn3">3</a></sup>
<td> Camelot
<td> Cost of ham, jam, and spam<sup><a href="#fn4">4</a></sup>
</table>
<p id="fn1">1. Assumed.</p>
<p id="fn2">2. Footwork impeccable.</p>
<p id="fn3">3. Quality described as "well".</p>
<p id="fn4">4. A lot.</p>
</figure>
5 Loading Web pages
Status: Last call for comments
5.1 Browsing contexts
Status: Last call for comments
A browsing context is an environment in which
Document objects are presented to the user.
A tab or window in a Web browser typically contains
a browsing context, as does an iframe.
A Document does not necessarily have a
browsing context associated with it. In particular,
data mining tools are likely to never instantiate browsing
contexts.
Certain elements (for example, iframe elements) can
instantiate further browsing
contexts. These are called nested browsing contexts. If a browsing context P has an element E in one of its
Documents D that nests another
browsing context C inside it, then P is said to be the parent browsing
context of C, C is
said to be a child browsing context of P, C is said to be nested through D, and E is said to be the
browsing context container of C.
A browsing context A is said to be an
ancestor of a browsing context B if there exists
a browsing context A' that is a child
browsing context of A and that is itself
an ancestor of B, or if there is a browsing
context P that is a child browsing
context of A and that is the parent
browsing context of B.
The browsing context with no parent browsing context
is the top-level browsing context of all the browsing
contexts nested within
it (either directly or indirectly through other nested browsing
contexts).
Throws a SECURITY_ERR exception in cross-origin situations.
5.1.2 Auxiliary browsing contexts
Status: Last call for comments
It is possible to create new browsing contexts that are related
to a top-level browsing context without being nested
through an element. Such browsing contexts are called auxiliary browsing
contexts. Auxiliary browsing contexts are always top-level browsing
contexts.
User agents may support secondary browsing contexts, which are browsing contexts that form part of
the user agent's interface, apart from the main content area.
5.1.4 Browsing context names
Status: Last call for comments
Browsing contexts can have a browsing context name. By
default, a browsing context has no name (its name is not set).
A valid browsing context name is any string with at
least one character that does not start with a U+005F LOW LINE
character. (Names starting with an underscore are reserved for
special keywords.)
Opens a window to show url (defaults to
about:blank), and returns it. The target argument gives the name of the new
window. If a window exists with that name already, it is
reused. The replace attribute, if true, means
that whatever page is currently open in that window will be
removed from the window's session history. The features argument is ignored.
Returns true if the toolbar is visible; otherwise, returns false.
5.3 Origin
Status: Last call for comments
The origin of a resource and the effective script
origin of a resource are both either opaque identifiers or
tuples consisting of a scheme component, a host component, a port
component, and optionally extra data.
The extra data could include the certificate of the
site when using encrypted connections, to ensure that if the site's
secure certificate changes, the origin is considered to change as
well.
Returns the current domain used for security checks.
Can be set to a value that removes subdomains, to change the
effective script origin to allow pages on other
subdomains of the same domain (if they do the same thing) to
access each other.
The domain
attribute is used to enable pages on different hosts of a domain to
access each others' DOMs.
Do not use the document.domain attribute when
using shared hosting. If an untrusted third party is able to host an
HTTP server at the same IP address but on a different port, then the
same-origin protection that normally protects two different sites on
the same host will fail, as the ports are ignored when comparing
origins after the document.domain attribute has
been used.
Titles associated with session history entries need not have any relation
with the current title of the
Document. The title of a session history
entry is intended to explain the state of the document at
that point, so that the user can navigate the document's
history.
URLs without associated state
objects are added to the session history as the user (or
script) navigates from page to page.
A state object is an object representing a user
interface state.
Pages can addstate objects between their entry in the
session history and the next ("forward") entry. These are then returned to the script when the user
(or script) goes back in the history, thus enabling authors to use
the "navigation" metaphor even in one-page applications.
State objects are intended to
be used for two main purposes: first, storing a preparsed
description of the state in the URL so that in the
simple case an author doesn't have to do the parsing (though one
would still need the parsing for handling URLs passed around by users, so it's only a minor
optimization), and second, so that the author can store state that
one wouldn't store in the URL because it only applies to the current
Document instance and it would have to be reconstructed
if a new Document were opened.
An example of the latter would be something like keeping track of
the precise coordinate from which a popup div was made
to animate, so that if the user goes back, it can be made to animate
to the same location. Or alternatively, it could be used to keep a
pointer into a cache of data that would be fetched from the server
based on the information in the URL, so that when going
back and forward, the information doesn't have to be fetched
again.
At any point, one of the entries in the session history is the
current entry. This is the entry representing the
active document of the browsing
context. The current entry is usually an entry
for the location of the
Document. However, it can also be one of the entries
for state objects added to the
history by that document.
Entries that consist of state
objects share the same Document as the entry for
the page that was active when they were added.
Contiguous entries that differ just by fragment identifier also
share the same Document.
All entries that share the same
Document (and that are therefore merely different
states of one particular document) are contiguous by definition.
interface History {
readonly attribute long length;
void go(in optional long delta);
void back();
void forward();
void pushState(in any data, in DOMString title, in optional DOMString url);
void replaceState(in any data, in DOMString title, in optional DOMString url);
};
The current entry of the joint session history is the
entry that most recently became a current entry in its
session history.
Entries in the joint session history are ordered
chronologically by the time they were added to their respective
session histories. (Since all
these browsing contexts by
definition share an event loop, there is always a
well-defined sequential order in which their session histories had their entries added.) Each
entry has an index; the earliest entry has index 0, and the
subsequent entries are numbered with consecutively increasing
integers (1, 2, 3, etc).
Consider a game where the user can navigate along a line, such
that the user is always at some coordinate, and such that the user
can bookmark the page corresponding to a particular coordinate, to
return to it later.
A static page implementing the x=5 position in such a game could
look like the following:
<!DOCTYPE HTML>
<!-- this is http://example.com/line?x=5 -->
<title>Line Game - 5</title>
<p>You are at coordinate 5 on the line.</p>
<p>
<a href="?x=6">Advance to 6</a> or
<a href="?x=4">retreat to 4</a>?
</p>
The problem with such a system is that each time the user
clicks, the whole page has to be reloaded. Here instead is another
way of doing it, using script:
<!DOCTYPE HTML>
<!-- this starts off as http://example.com/line?x=5 -->
<title>Line Game - 5</title>
<p>You are at coordinate <span id="coord">5</span> on the line.</p>
<p>
<a href="?x=6" onclick="go(1)">Advance to 6</a> or
<a href="?x=4" onclick="go(-1)">retreat to 4</a>?
</p>
<script>
var currentPage = 5; // prefilled by server
function go(d) {
history.pushState(currentPage, 'Line Game - ' + currentPage, '?x=' + currentPage);
setupPage(currentPage + d);
}
onpopstate = function(event) {
setupPage(event.state);
}
function setupPage(page) {
currentPage = page;
document.title = 'Line Game - ' + currentPage;
document.getElementById('coord').textContent = currentPage;
document.links[0].href = '?x=' + (currentPage+1);
document.links[0].textContent = 'Advance to ' + (currentPage+1);
document.links[1].href = '?x=' + (currentPage-1);
document.links[1].textContent = 'retreat to ' + (currentPage-1);
}
</script>
In systems without script, this still works like the previous
example. However, users that do have script support can
now navigate much faster, since there is no network access for the
same experience. Furthermore, contrary to the experience the user
would have with just a naïve script-based approach,
bookmarking and navigating the session history still work.
In the example above, the data argument to
the pushState() method
is the same information as would be sent to the server, but in a
more convenient form, so that the script doesn't have to parse the
URL each time the user navigates.
Applications might not use the same title for a session
history entry as the value of the document's
title element at that time. For example, here is a
simple page that shows a block in the title element.
Clearly, when navigating backwards to a previous state the user
does not go back in time, and therefore it would be inappropriate
to put the time in the session history title.
<!DOCTYPE HTML>
<TITLE>Line</TITLE>
<SCRIPT>
setInterval(function () { document.title = 'Line - ' + new Date(); }, 1000);
var i = 1;
function inc() {
set(i+1);
history.pushState(i, 'Line - ' + i);
}
function set(newI) {
i = newI;
document.forms.F.I.value = newI;
}
</SCRIPT>
<BODY ONPOPSTATE="recover(event.state)">
<FORM NAME=F>
State: <OUTPUT NAME=I>1</OUTPUT> <INPUT VALUE="Increment" TYPE=BUTTON ONCLICK="inc()">
</FORM>
The popstate event
is fired when navigating to a session history entry
that represents a state object.
interface PopStateEvent : Event {
readonly attribute any state;
void initPopStateEvent(in DOMString typeArg, in boolean canBubbleArg, in boolean cancelableArg, in any stateArg);
};
The hashchange
event is fired when navigating to a session history
entry whose URL differs from that of the
previous one only in the fragment identifier.
interface HashChangeEvent : Event {
readonly attribute any oldURL;
readonly attribute any newURL;
void initHashChangeEvent(in DOMString typeArg, in boolean canBubbleArg, in boolean cancelableArg, in DOMString oldURLArg, in DOMString newURLArg);
};
interface PageTransitionEvent : Event {
readonly attribute any persisted;
void initPageTransitionEvent(in DOMString typeArg, in boolean canBubbleArg, in boolean cancelableArg, in any persistedArg);
};
In order to enable users to continue interacting with Web
applications and documents even when their network connection is
unavailable â for instance, because they are traveling outside
of their ISP's coverage area â authors can provide a manifest
which lists the files that are needed for the Web application to
work offline and which causes the user's browser to keep a copy of
the files for use offline.
To illustrate this, consider a simple clock applet consisting of
an HTML page "clock.html", a CSS style sheet
"clock.css", and a JavaScript script "clock.js".
Before adding the manifest, these three files might look like
this:
If the user tries to open the "clock.html"
page while offline, though, the user agent (unless it happens to
have it still in the local cache) will fail with an error.
The author can instead provide a manifest of the three files:
CACHE MANIFEST
clock.html
clock.css
clock.js
With a small change to the HTML file, the manifest (served as
text/cache-manifest) is linked to the application:
Now, if the user goes to the page, the browser will cache the
files and make them available even when the user is offline.
Authors are encouraged to include the main page in
the manifest also, but in practice the page that referenced the
manifest is automatically cached even if it isn't explicitly
mentioned.
HTTP cache headers and restrictions on caching pages
served over TLS (encrypted, using https:) are
overridden by manifests. Thus, pages will not expire from an
application cache before the user agent has updated it, and even
applications served over TLS can be made to work offline.
5.6.1.1 Event summary
Status: Last call for comments
This section is non-normative.
When the user visits a page that declares a manifest, the browser
will try to update the cache. It does this by fetching a copy of the
manifest and, if the manifest has changed since the user agent last
saw it, redownloading all the resources it mentions and caching them
anew.
As this is going on, a number of events get fired on the
ApplicationCache object to keep the script updated as
to the state of the cache update, so that the user can be notified
appropriately. The events are as follows:
The manifest was a 404 or 410 page, so the attempt to cache the application has been aborted.
Last event in sequence.
The manifest hadn't changed, but the page referencing the manifest failed to download properly.
A fatal error occurred while fetching the resources listed in the manifest.
The manifest changed while the update was being run.
The user agent will try fetching the files again momentarily.
5.6.2 The cache manifest syntax
Status: Last call for comments
5.6.2.1 A sample manifest
Status: Last call for comments
This section is non-normative.
This example manifest requires two images and a style sheet to be
cached and whitelists a CGI script.
CACHE MANIFEST
# the above line is required
# this is a comment
# there can be as many of these anywhere in the file
# they are all ignored
# comments can have spaces before them
# but must be alone on the line
# blank lines are ignored too
# these are files that need to be cached they can either be listed
# first, or a "CACHE:" header could be put before them, as is done
# lower down.
images/sound-icon.png
images/background.png
# note that each file has to be put on its own line
# here is a file for the online whitelist -- it isn't cached, and
# references to this file will bypass the cache, always hitting the
# network (or trying to, if the user is offline).
NETWORK:
comm.cgi
# here is another set of files to cache, this time just the CSS file.
CACHE:
style/default.css
The following manifest defines a catch-all error page that is
displayed for any page on the site while the user is offline. It
also specifies that the online whitelist
wildcard flag is open, meaning that accesses
to resources on other sites will not be blocked. (Resources on the
same site are already not blocked because of the catch-all fallback
namespace.)
So long as all pages on the site reference this manifest, they
will get cached locally as they are fetched, so that subsequent hits
to the same page will load the page immediately from the
cache. Until the manifest is changed, those pages will not be
fetched from the server again. When the manifest changes, then all
the files will be redownloaded.
Subresources, such as style sheets, images, etc, would only be
cached using the regular HTTP caching semantics, however.
An application cache manifest is a text file, whose text is
encoded using UTF-8. Data in application cache manifests is
line-based. Newlines must be represented by U+000A LINE FEED (LF)
characters, U+000D CARRIAGE RETURN (CR) characters, or U+000D
CARRIAGE RETURN (CR) U+000A LINE FEED (LF) pairs.
This is a willful violation of two
aspects of RFC 2046, which requires all text/*
types to support an open-ended set of character encodings and only
allows CRLF line breaks. These requirements, however, are outdated;
UTF-8 is now widely used, such that supporting other encodings is no
longer necessary, and use of CR, LF, and CRLF line breaks is
commonly supported and indeed sometimes CRLF is not
supported by text editors. [RFC2046]
The first line of an application cache manifest must consist of
the string "CACHE", a single U+0020 SPACE character, the string
"MANIFEST", and either a U+0020 SPACE character, a U+0009 CHARACTER
TABULATION (tab) character, a U+000A LINE FEED (LF) character, or a
U+000D CARRIAGE RETURN (CR) character. The first line may optionally
be preceded by a U+FEFF BYTE ORDER MARK (BOM) character. If any
other text is found on the first line, it is ignored.
Subsequent lines, if any, must all be one of the following:
A blank line
Blank lines must consist of zero or more U+0020 SPACE and
U+0009 CHARACTER TABULATION (tab) characters only.
A comment
Comment lines must consist of zero or more U+0020 SPACE and
U+0009 CHARACTER TABULATION (tab) characters, followed by a single
U+0023 NUMBER SIGN character (#), followed by zero or more
characters other than U+000A LINE FEED (LF) and U+000D CARRIAGE
RETURN (CR) characters.
Comments must be on a line on their own. If they
were to be included on a line with a URL, the "#" would be
mistaken for part of a fragment identifier.
A section header
Section headers change the current section. There are three
possible section headers:
CACHE:
Switches to the explicit section.
FALLBACK:
Switches to the fallback section.
NETWORK:
Switches to the online whitelist section.
Section header lines must consist of zero or more U+0020 SPACE
and U+0009 CHARACTER TABULATION (tab) characters, followed by one
of the names above (including the U+003A COLON character (:))
followed by zero or more U+0020 SPACE and U+0009 CHARACTER
TABULATION (tab) characters.
Ironically, by default, the current section is the
explicit section.
Data for the current section
The format that data lines must take depends on the current
section.
When the current section is the explicit
section, data lines must consist of zero or more U+0020
SPACE and U+0009 CHARACTER TABULATION (tab) characters, a
valid URL identifying a resource other than the
manifest itself, and then zero or more U+0020 SPACE and U+0009
CHARACTER TABULATION (tab) characters.
When the current section is the fallback
section, data lines must consist of zero or more U+0020
SPACE and U+0009 CHARACTER TABULATION (tab) characters, a
valid URL identifying a resource other than the
manifest itself, one or more U+0020 SPACE and U+0009 CHARACTER
TABULATION (tab) characters, another valid URL
identifying a resource other than the manifest itself, and then
zero or more U+0020 SPACE and U+0009 CHARACTER TABULATION (tab)
characters.
When the current section is the online whitelist
section, data lines must consist of zero or more U+0020
SPACE and U+0009 CHARACTER TABULATION (tab) characters, either a
single U+002A ASTERISK character (*) or a valid
URL identifying a resource other than the manifest itself,
and then zero or more U+0020 SPACE and U+0009 CHARACTER TABULATION
(tab) characters.
Manifests may contain sections more than once. Sections may be
empty.
If the manifest's <scheme>
is https: or another scheme intended for
encrypted data transfer, then all URLs in explicit sections
must have the same origin as the manifest itself.
URLs that are to be fallback pages associated with fallback namespaces, and
those namespaces themselves, must be given in fallback sections,
with the namespace being the first URL of the data line, and the
corresponding fallback page being the second URL. All the other
pages to be cached must be listed in explicit
sections.
Namespaces that the user agent is to put into the online whitelist
must all be specified in online whitelist
sections. (This is needed for any URL that the page is
intending to use to communicate back to the server.) To specify that
all URLs are automatically whitelisted in this way, a U+002A
ASTERISK character character (*) may be specified as one of the
URLs.
Relative URLs must be given relative to the manifest's own
URL. All URLs in the manifest must have the same <scheme> as the manifest itself
(either explicitly or implicitly, through the use of relative
URLs).
URLs in manifests must not have fragment identifiers (i.e. the
U+0023 NUMBER SIGN character isn't allowed in URLs in
manifests).
As a general rule, user agents should not expire application
caches, except on request from the user, or after having been left
unused for an extended period of time.
Application caches and cookies have similar implications with
respect to privacy (e.g. if the site can identify the user when
providing the cache, it can store data in the cache that can be used
for cookie resurrection). Implementors are therefore encouraged to
expose application caches in a manner related to HTTP cookies,
allowing caches to be expunged together with cookies and other
origin-specific data.
For example, a user agent could have a "delete
site-specific data" feature that clears all cookies, application
caches, local storage, databases, etc, from an origin all at
once.
Switches to the most recent application cache, if there is a
newer one. If there isn't, throws an
INVALID_STATE_ERR exception.
This does not cause previously-loaded resources to be reloaded;
for example, images do not suddenly get reloaded and style sheets
and scripts do not get reparsed or reevaluated. The only change is
that subsequent requests for cached resources will obtain the
newer copies.
Returns false if the user agent is definitely offline
(disconnected from the network). Returns true if the user agent
might be online.
This attribute is inherently unreliable. A computer
can be connected to a network without having Internet access.
6 Web application APIs
6.1 Scripting
Status: Last call for comments
6.1.1 Introduction
Status: Last call for comments
Various mechanisms can cause author-provided executable code to
run in the context of a document. These mechanisms include, but are
probably not limited to:
Event handlers always fire before event listeners
attached using addEventListener().
The Function interface represents a function in the
scripting language being used. It is represented in IDL as
follows:
[Callback=FunctionOnly, NoInterfaceObject]
interface Function {
any call(in any... arguments);
};
The call(...)
method is the object's callback.
In JavaScript, any Function
object implements this interface.
If the Function object is a JavaScript Function, then when it is invoked by the user agent,
the user agent must set the thisArg (as defined
by ECMAScript edition 5 section 10.4.3 Entering Function Code) to
the event handler's object. [ECMA262]
For example, the following document fragment:
<body onload="alert(this)" onclick="alert(this)">
...leads to an alert saying "[object Window]" when the document is loaded,
and an alert saying "[object HTMLBodyElement]" whenever the user
clicks something in the page.
The return value of the function is affects whether the event is
canceled or not: if
the return value is false, the event is canceled (except for mouseover events, where the return
value has to be true to cancel the event). With beforeunload events, the value is
instead used to determine the message to show the user.
[Supplemental, NoInterfaceObject]
interface WindowTimers {
long setTimeout(in any handler, in optional any timeout, in any... args);
void clearTimeout(in long handle);
long setInterval(in any handler, in optional any timeout, in any... args);
void clearInterval(in long handle);
};
Window implements WindowTimers;
Displays a modal OK/Cancel prompt with the given message, waits
for the user to dismiss it, and returns true if the user clicks OK
and false if the user clicks Cancel.
Displays a modal text field prompt with the given message,
waits for the user to dismiss it, and returns the value that the
user entered. If the user cancels the prompt, then returns null
instead. If the second argument is present, then the given value
is used as a default.
In certain cases, despite the best efforts of the entire
industry, Web browsers have bugs and limitations that Web authors
are forced to work around.
This section defines a collection of attributes that can be used
to determine, from script, the kind of user agent in use, in order
to work around these issues.
Client detection should always be limited to detecting known
current versions; future versions and unknown versions should always
be assumed to be fully compliant.
The registerProtocolHandler()
method allows Web sites to register themselves as possible handlers
for particular schemes. For example, an online telephone messaging
service could register itself as a handler of the sms:
scheme ([RFC5724]), so that if the user
clicks on such a link, he is given the opportunity to use that Web
site. Analogously, the registerContentHandler()
method allows Web sites to register themselves as possible handlers
for content in a particular MIME type. For example, the
same online telephone messaging service could register itself as a
handler for text/directory files ([RFC2425]), so that if the user has no
native application capable of handling vCards ([RFC2426]), his Web browser can instead
suggest he use that site to view contact information stored on
vCards that he opens.
Registers a handler for the given scheme or content type, at
the given URL, with the given title.
The string "%s" in the URL is used as a
placeholder for where to put the URL of the content to be
handled.
Throws a SECURITY_ERR exception if the user agent
blocks the registration (this might happen if trying to register
as a handler for "http", for instance).
Throws a SYNTAX_ERR if the "%s" string is missing in the URL.
If a script uses the document.cookie API, or the
localStorage API, the
browser will block other scripts from accessing cookies or storage
until the first script finishes.
[WEBSTORAGE]
Calling the navigator.yieldForStorageUpdates()
method tells the user agent to unblock any other scripts that may
be blocked, even though the script hasn't returned.
Values of cookies and items in the Storage objects
of localStorage attributes
can change after calling this method, whence its name.
[WEBSTORAGE]
7 User interaction
7.1 The hidden attribute
Status: Last call for comments. ISSUE-95 (hidden) blocks progress to Last Call
All HTML elements may have the hidden content attribute set. The hidden attribute is a boolean
attribute. When specified on an element, it indicates that
the element is not yet, or is no longer, relevant.
In the following skeletal example, the attribute is used to hide
the Web game's main screen until the user logs in:
<h1>The Example Game</h1>
<section id="login">
<h2>Login</h2>
<form>
...
<!-- calls login() once the user's credentials have been checked -->
</form>
<script>
function login() {
// switch screens
document.getElementById('login').hidden = true;
document.getElementById('game').hidden = false;
}
</script>
</section>
<section id="game" hidden>
...
</section>
The hidden attribute must not be
used to hide content that could legitimately be shown in another
presentation. For example, it is incorrect to use hidden to hide panels in a tabbed dialog,
because the tabbed interface is merely a kind of overflow
presentation â one could equally well just show all the form
controls in one big page with a scrollbar. It is similarly incorrect
to use this attribute to hide content just from one presentation
â if something is marked hidden, it is hidden from all
presentations, including, for instance, screen readers.
Elements that are not hidden
should not link to or refer to elements that are hidden.
For example, it would be incorrect to use the href attribute to link to a
section marked with the hidden
attribute. If the content is not applicable or relevant, then there
is no reason to link to it.
It would similarly be incorrect to use the ARIA aria-describedby attribute to
refer to descriptions that are themselves hidden. Hiding a section means that it
is not applicable or relevant to anyone at the current time, so
clearly it cannot be a valid description of content the user can
interact with.
Elements in a section hidden by the hidden attribute are still active,
e.g. scripts and form controls in such sections still execute
and submit respectively. Only their presentation to the user
changes.
Scrolls the element into view. If the top
argument is true, then the element will be scrolled to the top of
the viewport, otherwise it'll be scrolled to the bottom. The
default is the top.
7.4 Focus
Status: Last call for comments
7.4.1 Sequential focus navigation
Status: Last call for comments
The tabindex
content attribute specifies whether the element is focusable,
whether it can be reached using sequential focus navigation, and the
relative order of the element for the purposes of sequential focus
navigation. The name "tab index" comes from the common use of the
"tab" key to navigate through the focusable elements. The term
"tabbing" refers to moving forward through the focusable elements
that can be reached using sequential focus navigation.
Unfocuses the element. Use of this method is discouraged. Focus
another element instead.
Do not use this method to hide the focus ring if you find the
focus ring unsightly. Instead, use a CSS rule to override the
'outline' property.
For example, to hide the outline from links, you could use:
:link:focus, :visited:focus { outline: none; }
7.5 The accesskey attribute
Status: Last call for comments
All HTML elements may have the accesskey content attribute set. The
accesskey attribute's value is
used by the user agent as a guide for creating a keyboard shortcut
that activates or focuses the element.
In the following example, a variety of links are given with
access keys so that keyboard users familiar with the site can
more quickly navigate to the relevant pages:
In the following example, the search field is given two possible
access keys, "s" and "0" (in that order). A user agent on a device
with a full keyboard might pick
Ctrl+Alt+S as the
shortcut key, while a user agent on a small device with just a
numeric keypad might pick just the plain unadorned key
0:
In the following example, a button has possible access keys
described. A script then tries to update the button's label to
advertise the key combination the user agent selected.
<input type=submit accesskey="N @ 1" value="Compose">
...
<script>
function labelButton(button) {
if (button.accessKeyLabel)
button.value += ' (' + button.accessKeyLabel + ')';
}
var inputs = document.getElementsByTagName('input');
for (var i = 0; i < inputs.length; i += 1) {
if (inputs[i].type == "submit")
labelButton(inputs[i]);
}
</script>
On one user agent, the button's label might become
"Compose (âN)". On another, it might become
"Compose (Alt+â§+1)". If the user agent doesn't
assign a key, it will be just "Compose". The exact
string depends on what the assigned access key is, and
on how the user agent represents that key combination.
7.6 The text selection APIs
Status: Last call for comments
Every browsing context has a selection. The selection can be empty, and the
selection can have more than one range (a disjointed selection). The
user agent should allow the user to change the selection. User
agents are not required to let the user select more than one range,
and may collapse multiple ranges in the selection to a single range
when the user interacts with the selection. (But, of course, the
user agent may let the user create selections with multiple
ranges.)
This one selection must be shared by all the content of the
browsing context (though not by nested browsing contexts), including any editing hosts in
the document. (Editing hosts that are not inside a document cannot
have a selection.)
Mostly for historical reasons, in addition to the browsing
context's selection, each
textarea and input element has an
independent selection. These are the text field selections.
The select element also has a selection, indicating
which items have been picked by the user. This is not discussed in
this section.
This specification does not specify how selections
are presented to the user.
The Selection interface represents a list of
Range objects. The first item in the list has index 0,
and the last item has index count-1, where count is the number of ranges in the list. [DOMRANGE]
All of the members of the Selection interface are
defined in terms of operations on the Range objects
represented by this object. These operations can raise exceptions,
as defined for the Range interface; this can therefore
result in the members of the Selection interface
raising exceptions as well, in addition to any explicitly called out
below.
Characters with no visible rendering, such as U+200D ZERO WIDTH
JOINER, still count as characters. Thus, for instance, the selection
can include just an invisible character, and the text insertion
cursor can be placed to one side or another of such a character.
The contenteditable
attribute is an enumerated attribute whose keywords are
the empty string, true, and false. The empty string and the true keyword map to the true state. The false keyword maps to the false state. In
addition, there is a third state, the inherit state, which is
the missing value default (and the invalid value
default).
The true state indicates that the element is editable. The
inherit state indicates that the element is editable if its
parent is. The false state indicates that the element is not
editable.
Returns "on" if the document is editable,
and "off" if it isn't.
Can be set, to change the document's current state.
7.8 Spelling and grammar checking
Status: Last call for comments
The spellcheck
attribute is an enumerated attribute whose keywords are
the empty string, true and false. The empty string and the true keyword map to the true state. The false keyword maps to the false state. In
addition, there is a third state, the default state, which is
the missing value default (and the invalid value
default).
The true state indicates that the element is to have its
spelling and grammar checked. The default state indicates
that the element is to act according to a default behavior, possibly
based on the parent element's own spellcheck state. The false
state indicates that the element is not to be checked.
Returns "true", "false", or "default", based
on the state of the spellcheck attribute.
Can be set, to change that state.
Throws a SYNTAX_ERR exception if the new value
isn't one of those strings.
This specification does not define the user
interface for spelling and grammar checkers. A user agent could
offer on-demand checking, could perform continuous checking while
the checking is enabled, or could use other interfaces.
7.9 Drag and drop
Status: Last call for comments
This section defines an event-based drag-and-drop mechanism.
This specification does not define exactly what a
drag-and-drop operation actually is.
On a visual medium with a pointing device, a drag operation could
be the default action of a mousedown event that is followed by a
series of mousemove events, and
the drop could be triggered by the mouse being released.
On media without a pointing device, the user would probably have
to explicitly indicate his intention to perform a drag-and-drop
operation, stating what he wishes to drag and what he wishes to
drop, respectively.
7.9.1 Introduction
Status: Last call for comments
This section is non-normative.
To make an element draggable is simple: give the element a draggable attribute, and set an event
listener for dragstart that
stores the data being dragged.
The event handler typically needs to check that it's not a text
selection that is being dragged, and then needs to store data into
the DataTransfer object and set the allowed effects
(copy, move, link, or some combination).
For example:
<p>What fruits do you like?</p>
<ol ondragstart="dragStartHandler(event)">
<li draggable data-value="fruit-apple">Apples</li>
<li draggable data-value="fruit-orange">Oranges</li>
<li draggable data-value="fruit-pear">Pears</li>
</ol>
<script>
var internalDNDType = 'text/x-example'; // set this to something specific to your site
function dragStartHandler(event) {
if (event.target instanceof HTMLLIElement) {
// use the element's data-value="" attribute as the value to be moving:
event.dataTransfer.setData(internalDNDType, event.target.dataset.value);
event.effectAllowed = 'move'; // only allow moves
} else {
event.preventDefault(); // don't allow selection to be dragged
}
}
</script>
To accept a drop, the drop target has to listen to at least three
events. First, the dragenter
event, which is used to determine whether or not the drop target is
to accept the drop. If the drop is to be accepted, then this event
has to be canceled. Second, the dragover event, which is used to
determine what feedback is to be shown to the user. If the event is
canceled, then the feedback (typically the cursor) is updated based
on the dropEffect
attribute's value, as set by the event handler; otherwise, the
default behavior (typically to do nothing) is used instead. Finally,
the drop event, which allows the
actual drop to be performed. This event also needs to be canceled,
so that the dropEffect attribute's
value can be used by the source (otherwise it's reset).
For example:
<p>Drop your favorite fruits below:</p>
<ol class="dropzone"
ondragenter="dragEnterHandler(event)"
ondragover="dragOverHandler(event)"
ondrop="dropHandler(event)">
</ol>
<script>
var internalDNDType = 'text/x-example'; // set this to something specific to your site
function dragEnterHandler(event) {
// cancel the event if the drag contains data of our type
if (event.dataTransfer.types.contains(internalDNDType))
event.preventDefault();
}
function dragOverHandler(event) {
event.dataTransfer.dropEffect = 'move';
event.preventDefault();
}
function dropHandler(event) {
// drop the data
var li = document.createElement('li');
var data = event.dataTransfer.getData(internalDNDType);
if (data == 'fruit-apple') {
li.textContent = 'Apples';
} else if (data == 'fruit-orange') {
li.textContent = 'Oranges';
} else if (data == 'fruit-pear') {
li.textContent = 'Pears';
} else {
li.textContent = 'Unknown Fruit';
}
event.target.appendChild(li);
}
</script>
To remove the original element (the one that was dragged) from
the display, the dragend event
can be used.
For our example here, that means updating the original markup to
handle that event:
<p>What fruits do you like?</p>
<ol ondragstart="dragStartHandler(event)" ondragend="dragEndHandler(event)">
...as before...
</ol>
<script>
function dragStartHandler(event) {
// ...as before...
}
function dragEndHandler(event) {
// remove the dragged element
event.target.parentNode.removeChild(event.target);
}
</script>
The drag-and-drop processing model involves several events. They
all use the DragEvent interface.
interface DragEvent : MouseEvent {
readonly attribute DataTransferdataTransfer;
void initDragEvent(in DOMString typeArg, in boolean canBubbleArg, in boolean cancelableArg, in any dummyArg, in long detailArg, in long screenXArg, in long screenYArg, in long clientXArg, in long clientYArg, in boolean ctrlKeyArg, in boolean altKeyArg, in boolean shiftKeyArg, in boolean metaKeyArg, in unsigned short buttonArg, in EventTarget relatedTargetArg, in DataTransfer dataTransferArg);
};
interface DataTransfer {
attribute DOMString dropEffect;
attribute DOMString effectAllowed;
readonly attribute DOMStringList types;
void clearData(in optional DOMString format);
void setData(in DOMString format, in DOMString data);
DOMString getData(in DOMString format);
readonly attribute FileListfiles;
void setDragImage(in Element image, in long x, in long y);
void addElement(in Element element);
};
DataTransfer objects can hold pieces of data, each
associated with a unique format. Formats are generally given by
MIME types, with some values
special-cased for legacy reasons. However, the API does not enforce
this; non-MIME-type values can be added as well. All formats are
identified by strings that are converted to ASCII
lowercase by the API.
Returns the kind of operation that is currently selected. If
the kind of operation isn't one of those that is allowed by the
effectAllowed
attribute, then the operation will fail.
Can be set, to change the selected operation.
The possible values are none, copy, link, and move.
Returns a DOMStringList listing the formats that
were set in the dragstart
event. In addition, if any files are being dragged, then one of
the types will be the string "Files".
"Empty" in the table above means that the getData() and files attributes act as if
there is no data being dragged.
7.9.4 The draggable attribute
Status: Last call for comments
All HTML elements may have the draggable content attribute set. The
draggable attribute is an
enumerated attribute. It has three states. The first
state is true and it has the keyword true. The second state is false and it has
the keyword false. The third state is
auto; it has no keywords but it is the missing value
default.
The true state means the element is draggable; the
false state means that it is not. The auto state
uses the default behavior of the user agent.
interface UndoManager {
readonly attribute unsigned long length;
getter any item(in unsigned long index);
readonly attribute unsigned long position;
unsigned long add(in any data, in DOMString title);
void remove(in unsigned long index);
void clearUndo();
void clearRedo();
};
interface UndoManagerEvent : Event {
readonly attribute any data;
void initUndoManagerEvent(in DOMString typeArg, in boolean canBubbleArg, in boolean cancelableArg, in any dataArg);
};
Returns the data that was passed to the add() method.
7.11 Editing APIs
Status: Last call for comments
document . execCommand(commandId [, showUI [, value ] ] )
Runs the action specified by the first argument, as described
in the list below. The second and third arguments sometimes affect
the action. (If they don't they are ignored.)
Returns the value of the command, as described in the list below.
A document is ready for editing host commands if it
has a selection that is entirely within an editing
host, or if it has no selection but its caret is inside an
editing host.
The possible values for commandId, and their
corresponding meanings, are as follows.
State: True if the selection, or the caret, if
there is no selection, is, or is contained within, a
b element. False otherwise.
Value: The string "true"
if the expression given for the "State" above is true, the string
"false" otherwise.
createLink
Summary: Toggles whether the selection is a
link or not. If the second argument is true, and a link is to be
added, the user agent will ask the user for the address. Otherwise,
the third argument will be used as the address.
Summary: Wraps the selection in the element
given by the second argument. If the second argument doesn't
specify an element that is a formatBlock
candidate, does nothing.
Summary: Toggles whether the selection is an
image or not. If the second argument is true, and an image is to be
added, the user agent will ask the user for the address. Otherwise,
the third argument will be used as the address.
Enabled When: The document has a selection
that is entirely within an editing host and that
contains (either partially or completely) at least one
a element that has an href attribute.
Indeterminate When: Never.
State: Always false.
Value: Always the string "false".
unselect
Summary: Unselects everything.
Enabled When: Always.
Indeterminate When: Never.
State: Always false.
Value: Always the string "false".
8 The HTML syntax
This section only describes the rules for resources
labeled with an HTML MIME type. Rules for XML resources
are discussed in the section below entitled "The XHTML
syntax".
8.1 Writing HTML documents
Status: Last call for comments
Documents must consist of the following parts, in the given
order:
Optionally, a single U+FEFF BYTE ORDER MARK (BOM) character.
The various types of content mentioned above are described in the
next few sections.
In addition, there are some restrictions on how character encoding
declarations are to be serialized, as discussed in the
section on that topic.
Space characters before the root html element, and
space characters at the start of the html element and
before the head element, will be dropped when the
document is parsed; space characters after the root
html element will be parsed as if they were at the end
of the body element. Thus, space characters around the
root element do not round-trip.
It is suggested that newlines be inserted after the DOCTYPE,
after any comments that are before the root element, after the
html element's start tag (if it is not omitted), and after any comments
that are inside the html element but before the
head element.
Many strings in the HTML syntax (e.g. the names of elements and
their attributes) are case-insensitive, but only for characters in
the ranges U+0041 to U+005A (LATIN CAPITAL LETTER A to LATIN CAPITAL
LETTER Z) and U+0061 to U+007A (LATIN SMALL LETTER A to LATIN SMALL
LETTER Z). For convenience, in this section this is just referred to
as "case-insensitive".
8.1.1 The DOCTYPE
Status: Last call for comments. ISSUE-4 (html-versioning) and ISSUE-84 (legacy-doctypes) block progress to Last Call
A DOCTYPE is a required preamble.
DOCTYPEs are required for legacy reasons. When
omitted, browsers tend to use a different rendering mode that is
incompatible with some specifications. Including the DOCTYPE in a
document ensures that the browser makes a best-effort attempt at
following the relevant specifications.
A DOCTYPE must consist of the following characters, in this
order:
In other words, <!DOCTYPE HTML>,
case-insensitively.
For the purposes of HTML generators that cannot output HTML
markup with the short DOCTYPE "<!DOCTYPE
HTML>", a DOCTYPE legacy string may be inserted
into the DOCTYPE (in the position defined above). This string must
consist of:
A matching U+0022 QUOTATION MARK or U+0027 APOSTROPHE character (i.e. the same character as in the earlier step labeled quote mark).
In other words, <!DOCTYPE HTML SYSTEM
"about:legacy-compat"> or <!DOCTYPE HTML SYSTEM
'about:legacy-compat'>, case-insensitively except for the bit
in single or double quotes.
The DOCTYPE legacy string should not be used unless
the document is generated from a system that cannot output the
shorter string.
To help authors transition from HTML4 and XHTML1, an
obsolete permitted DOCTYPE string can be inserted into
the DOCTYPE (in the position defined above). This string must
consist of:
A U+0022 QUOTATION MARK or U+0027 APOSTROPHE character (the first quote mark).
The string from one of the cells in the first column of the table below. The row to which this cell belongs is the selected row.
A matching U+0022 QUOTATION MARK or U+0027 APOSTROPHE character (i.e. the same character as in the earlier step labeled first quote mark).
If the cell in the second column of the selected row is not blank, one or more space characters.
If the cell in the second column of the selected row is not blank, a U+0022 QUOTATION MARK or U+0027 APOSTROPHE character (the third quote mark).
If the cell in the second column of the selected row is not blank, the string from the cell in the second column of the selected row.
If the cell in the second column of the selected row is not blank, a matching U+0022 QUOTATION MARK or U+0027 APOSTROPHE character (i.e. the same character as in the earlier step labeled third quote mark).
All other allowed HTML elements are normal
elements.
Tags are used to delimit the start
and end of elements in the markup. Raw text, RCDATA, and normal elements have a start tag to indicate where they
begin, and an end tag to
indicate where they end. The start and end tags of certain
normal elements can be omitted, as described
later. Those that cannot be omitted must not be omitted. Void
elements only have a start tag; end tags must not be
specified for void elements. Foreign
elements must either have a start tag and an end tag, or a
start tag that is marked as self-closing, in which case they must
not have an end tag.
The contents of the element must be placed between just after the
start tag (which might be implied,
in certain cases) and just before the end tag (which again,
might be implied in certain
cases). The exact allowed contents of each individual element
depends on the content model of that element, as described earlier
in this specification. Elements must not contain content that their
content model disallows. In addition to the restrictions placed on
the contents by those content models, however, the five types of
elements have additional syntactic requirements.
Void elements can't have any contents (since there's
no end tag, no content can be put between the start tag and the end
tag).
Foreign elements whose start tag is marked as
self-closing can't have any contents (since, again, as there's no
end tag, no content can be put between the start tag and the end
tag). Foreign elements whose start tag is not
marked as self-closing can have text, character references, CDATA sections, other elements, and comments, but the text must not
contain the character U+003C LESS-THAN SIGN (<) or an ambiguous ampersand.
The HTML syntax does not support namespace
declarations, even in foreign elements.
For instance, consider the following HTML fragment:
<p>
<svg>
<metadata>
<!-- this is invalid -->
<cdr:license xmlns:cdr="http://www.example.com/cdr/metadata" name="MIT"/>
</metadata>
</svg>
</p>
The innermost element, cdr:license, is
actually in the SVG namespace, as the "xmlns:cdr" attribute has no effect (unlike in
XML). In fact, as the comment in the fragment above says, the
fragment is actually non-conforming. This is because the SVG
specification does not define any elements called "cdr:license" in the SVG namespace.
Tags contain a tag name,
giving the element's name. HTML elements all have names that only
use characters in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT
NINE (9), U+0061 LATIN SMALL LETTER A to U+007A LATIN SMALL LETTER
Z, and U+0041 LATIN CAPITAL LETTER A to U+005A LATIN CAPITAL LETTER
Z. In the HTML syntax, tag names, even those for foreign
elements, may be written with any mix of lower- and uppercase
letters that, when converted to all-lowercase, matches the element's
tag name; tag names are case-insensitive.
8.1.2.1 Start tags
Status: Last call for comments
Start tags must have the
following format:
The first character of a start tag must be a U+003C LESS-THAN
SIGN character (<).
The next few characters of a start tag must be the element's
tag name.
If there are to be any attributes in the next step, there must
first be one or more space
characters.
Then, the start tag may have a number of attributes, the syntax for which is described
below. Attributes may be separated from each other by one or more
space characters.
After the attributes, or after the tag name if there are no attributes,
there may be one or more space
characters. (Some attributes are required to be followed by
a space. See the attributes
section below.)
Then, if the element is one of the void elements,
or if the element is a foreign
element, then there may be a single U+002F SOLIDUS character
(/). This character has no effect on void elements,
but on foreign elements it marks the start tag as
self-closing.
Finally, start tags must be closed by a U+003E GREATER-THAN
SIGN character (>).
8.1.2.2 End tags
Status: Last call for comments
End tags must have the
following format:
The first character of an end tag must be a U+003C LESS-THAN
SIGN character (<).
The second character of an end tag must be a U+002F SOLIDUS
character (/).
The next few characters of an end tag must be the element's
tag name.
Finally, end tags must be closed by a U+003E GREATER-THAN SIGN
character (>).
8.1.2.3 Attributes
Status: Last call for comments
Attributes for an element
are expressed inside the element's start tag.
Attributes have a name and a value. Attribute names must consist of
one or more characters other than the space characters, U+0000 NULL, U+0022 QUOTATION
MARK ("), U+0027 APOSTROPHE ('), U+003E GREATER-THAN SIGN
(>), U+002F SOLIDUS (/), and U+003D EQUALS SIGN (=) characters,
the control characters, and any characters that are not defined by
Unicode. In the HTML syntax, attribute names, even those for
foreign elements, may be written with any mix of lower-
and uppercase letters that are an ASCII
case-insensitive match for the attribute's name.
Attributes can be specified in four different ways:
Empty attribute syntax
Just the attribute
name. The value is implicitly the empty string.
In the following example, the disabled attribute is given with
the empty attribute syntax:
<input disabled>
If an attribute using the empty attribute syntax is to be
followed by another attribute, then there must be a space
character separating the two.
Unquoted attribute value syntax
The attribute name,
followed by zero or more space
characters, followed by a single U+003D EQUALS SIGN
character, followed by zero or more space characters, followed by the attribute value, which, in
addition to the requirements given above for attribute values,
must not contain any literal space
characters, any U+0022 QUOTATION MARK characters ("),
U+0027 APOSTROPHE characters ('), U+003D EQUALS SIGN
characters (=), U+003C LESS-THAN SIGN characters (<), U+003E
GREATER-THAN SIGN characters (>), or U+0060 GRAVE ACCENT
characters (`), and must not be the empty string.
In the following example, the value attribute is given
with the unquoted attribute value syntax:
<input value=yes>
If an attribute using the unquoted attribute syntax is to be
followed by another attribute or by the optional U+002F SOLIDUS
character (/) allowed in step 6 of the start tag syntax above, then there
must be a space character separating the two.
Single-quoted attribute value syntax
The attribute name,
followed by zero or more space
characters, followed by a single U+003D EQUALS SIGN
character, followed by zero or more space characters, followed by a single U+0027
APOSTROPHE character ('), followed by the attribute value, which, in
addition to the requirements given above for attribute values,
must not contain any literal U+0027 APOSTROPHE characters ('), and
finally followed by a second single U+0027 APOSTROPHE character
(').
In the following example, the type attribute is given with the
single-quoted attribute value syntax:
<input type='checkbox'>
If an attribute using the single-quoted attribute syntax is to
be followed by another attribute, then there must be a space
character separating the two.
Double-quoted attribute value syntax
The attribute name,
followed by zero or more space
characters, followed by a single U+003D EQUALS SIGN
character, followed by zero or more space characters, followed by a single U+0022
QUOTATION MARK character ("), followed by the attribute value, which, in
addition to the requirements given above for attribute values,
must not contain any literal U+0022 QUOTATION MARK characters ("),
and finally followed by a second single U+0022 QUOTATION MARK
character (").
In the following example, the name attribute is given with the
double-quoted attribute value syntax:
<input name="be evil">
If an attribute using the double-quoted attribute syntax is to
be followed by another attribute, then there must be a space
character separating the two.
There must never be two or more attributes on the same start tag
whose names are an ASCII case-insensitive match for
each other.
When a foreign element has
one of the namespaced attributes given by the local name and
namespace of the first and second cells of a row from the following
table, it must be written using the name given by the third cell
from the same row.
No other namespaced attribute can be expressed in the
HTML syntax.
8.1.2.4 Optional tags
Status: Last call for comments
Certain tags can be omitted.
Omitting an element's start tag does not mean the element
is not present; it is implied, but it is still there. An HTML
document always has a root html element, even if the
string <html> doesn't appear anywhere in
the markup.
An html element's start tag may be omitted if the
first thing inside the html element is not a comment.
An html element's end
tag may be omitted if the html element is not
immediately followed by a comment.
A head element's start tag may be omitted if the
element is empty, or if the first thing inside the
head element is an element.
A body element's start tag may be omitted if the
element is empty, or if the first thing inside the body
element is not a space character or a comment, except if the first thing
inside the body element is a script or
style element.
A body element's end
tag may be omitted if the body element is not
immediately followed by a comment.
A li element's end
tag may be omitted if the li element is
immediately followed by another li element or if there
is no more content in the parent element.
A dt element's end
tag may be omitted if the dt element is
immediately followed by another dt element or a
dd element.
A dd element's end
tag may be omitted if the dd element is
immediately followed by another dd element or a
dt element, or if there is no more content in the
parent element.
An rt element's end
tag may be omitted if the rt element is
immediately followed by an rt or rp
element, or if there is no more content in the parent element.
An rp element's end
tag may be omitted if the rp element is
immediately followed by an rt or rp
element, or if there is no more content in the parent element.
An optgroup element's end tag may be omitted if the
optgroup element is immediately followed by
another optgroup element, or if there is no
more content in the parent element.
An option element's end
tag may be omitted if the option element is
immediately followed by another option element, or if
it is immediately followed by an optgroup element, or
if there is no more content in the parent element.
A colgroup element's start tag may be omitted if the
first thing inside the colgroup element is a
col element, and if the element is not immediately
preceded by another colgroup element whose end tag has been omitted. (It can't be
omitted if the element is empty.)
A thead element's end
tag may be omitted if the thead element is
immediately followed by a tbody or tfoot
element.
A tbody element's start tag may be omitted if the
first thing inside the tbody element is a
tr element, and if the element is not immediately
preceded by a tbody, thead, or
tfoot element whose end
tag has been omitted. (It can't be omitted if the element is
empty.)
A tbody element's end
tag may be omitted if the tbody element is
immediately followed by a tbody or tfoot
element, or if there is no more content in the parent element.
A tfoot element's end
tag may be omitted if the tfoot element is
immediately followed by a tbody element, or if there is
no more content in the parent element.
A tr element's end
tag may be omitted if the tr element is
immediately followed by another tr element, or if there
is no more content in the parent element.
A td element's end
tag may be omitted if the td element is
immediately followed by a td or th
element, or if there is no more content in the parent element.
A th element's end
tag may be omitted if the th element is
immediately followed by a td or th
element, or if there is no more content in the parent element.
However, a start
tag must never be omitted if it has any attributes.
8.1.2.5 Restrictions on content models
Status: Last call for comments
For historical reasons, certain elements have extra restrictions
beyond even the restrictions given by their content model.
A table element must not contain tr
elements, even though these elements are technically allowed inside
table elements according to the content models
described in this specification. (If a tr element is
put inside a table in the markup, it will in fact imply
a tbody start tag before it.)
A single newline may be
placed immediately after the start
tag of pre and textarea
elements. This does not affect the processing of the element. The
otherwise optional newlinemust be included if the element's contents themselves start
with a newline (because
otherwise the leading newline in the contents would be treated like
the optional newline, and ignored).
8.1.2.6 Restrictions on the contents of raw text and RCDATA elements
Status: Last call for comments
The text in raw text and
RCDATA elements must not contain any occurrences of the
string "</" (U+003C LESS-THAN SIGN, U+002F
SOLIDUS) followed by characters that case-insensitively match the
tag name of the element followed by one of U+0009 CHARACTER
TABULATION, U+000A LINE FEED (LF), U+000C FORM FEED (FF), U+000D
CARRIAGE RETURN (CR), U+0020 SPACE, U+003E GREATER-THAN SIGN (>), or
U+002F SOLIDUS (/).
8.1.3 Text
Status: Last call for comments
Text is allowed inside elements,
attributes, and comments. Text must consist of Unicode characters.
Text must not contain U+0000 characters. Text must not contain
permanently undefined Unicode characters (noncharacters). Text must
not contain control characters other than space characters. Extra constraints are placed on
what is and what is not allowed in text based on where the text is
to be put, as described in the other sections.
8.1.3.1 Newlines
Status: Last call for comments
Newlines in HTML may be
represented either as U+000D CARRIAGE RETURN (CR) characters, U+000A
LINE FEED (LF) characters, or pairs of U+000D CARRIAGE RETURN (CR),
U+000A LINE FEED (LF) characters in that order.
Where character references
are allowed, a character reference of a U+000A LINE FEED (LF)
character (but not a U+000D CARRIAGE RETURN (CR) character) also
represents a newline.
8.1.4 Character references
Status: Last call for comments
In certain cases described in other sections, text may be mixed with character references. These can be used
to escape characters that couldn't otherwise legally be included in
text.
Character references must start with a U+0026 AMPERSAND character
(&). Following this, there are three possible kinds of character
references:
Named character references
The ampersand must be followed by one of the names given in the
named character references section, using the same
case.
Decimal numeric character reference
The ampersand must be followed by a U+0023 NUMBER SIGN
character (#), followed by one or more digits in the range U+0030
DIGIT ZERO (0) to U+0039 DIGIT NINE (9), representing a base-ten
integer that corresponds to a Unicode code point that is allowed
according to the definition below. The digits must then be followed
by a U+003B SEMICOLON character (;).
Hexadecimal numeric character reference
The ampersand must be followed by a U+0023 NUMBER SIGN
character (#), which must be followed by either a U+0078 LATIN
SMALL LETTER X character (x) or a U+0058 LATIN CAPITAL LETTER X
character (X), which must then be followed by one or more digits in
the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9), U+0061
LATIN SMALL LETTER A to U+0066 LATIN SMALL LETTER F, and U+0041
LATIN CAPITAL LETTER A to U+0046 LATIN CAPITAL LETTER F,
representing a base-sixteen integer that corresponds to a Unicode
code point that is allowed according to the definition below. The
digits must then be followed by a U+003B SEMICOLON character
(;).
The numeric character reference forms described above are allowed
to reference any Unicode code point other than U+0000, U+000D,
permanently undefined Unicode characters (noncharacters), and
control characters other than space
characters.
An ambiguous
ampersand is a U+0026 AMPERSAND character (&) that is
followed by one or more characters in the range U+0030 DIGIT ZERO
(0) to U+0039 DIGIT NINE (9), U+0061 LATIN SMALL LETTER A to U+007A
LATIN SMALL LETTER Z, and U+0041 LATIN CAPITAL LETTER A to U+005A
LATIN CAPITAL LETTER Z, followed by a U+003B SEMICOLON character
(;), where these characters do not match any of the names given in
the named character references section.
8.1.5 CDATA sections
Status: Last call for comments
CDATA sections must start with
the character sequence U+003C LESS-THAN SIGN, U+0021 EXCLAMATION
MARK, U+005B LEFT SQUARE BRACKET, U+0043 LATIN CAPITAL LETTER C,
U+0044 LATIN CAPITAL LETTER D, U+0041 LATIN CAPITAL LETTER A, U+0054
LATIN CAPITAL LETTER T, U+0041 LATIN CAPITAL LETTER A, U+005B LEFT
SQUARE BRACKET (<![CDATA[). Following this
sequence, the CDATA section may have text, with the additional restriction
that the text must not contain the three character sequence U+005D
RIGHT SQUARE BRACKET, U+005D RIGHT SQUARE BRACKET, U+003E
GREATER-THAN SIGN (]]>). Finally, the CDATA
section must be ended by the three character sequence U+005D RIGHT
SQUARE BRACKET, U+005D RIGHT SQUARE BRACKET, U+003E GREATER-THAN
SIGN (]]>).
CDATA sections can only be used in foreign content (MathML or
SVG). In this example, a CDATA section is used to escape the
contents of an ms element:
<p>You can add a string to a number, but this stringifies the number:</p>
<math>
<ms><![CDATA[x<y]]></ms>
<mo>+</mo>
<mn>3</mn>
<mo>=</mo>
<ms><![CDATA[x<y3]]></ms>
</math>
8.1.6 Comments
Status: Last call for comments
Comments must start with the
four character sequence U+003C LESS-THAN SIGN, U+0021 EXCLAMATION
MARK, U+002D HYPHEN-MINUS, U+002D HYPHEN-MINUS (<!--). Following this sequence, the comment may
have text, with the additional
restriction that the text must not start with a single U+003E
GREATER-THAN SIGN character (>), nor start with a U+002D
HYPHEN-MINUS character (-) followed by a U+003E GREATER-THAN SIGN
(>) character, nor contain two consecutive U+002D HYPHEN-MINUS
characters (--), nor end with a U+002D
HYPHEN-MINUS character (-). Finally, the comment must be ended by
the three character sequence U+002D HYPHEN-MINUS, U+002D
HYPHEN-MINUS, U+003E GREATER-THAN SIGN (-->).
8.2 Named character references
Status: Last call for comments
This table lists the character reference names that are supported
by HTML, and the code points to which they refer. It is referenced
by the previous sections.
The glyphs displayed above are non-normative. Refer to the
Unicode specifications for formal definitions of the characters
listed above.
9 The XHTML syntax
This section only describes the rules for XML
resources. Rules for text/html resources are discussed
in the section above entitled "The HTML syntax".
The syntax for using HTML with XML, whether in XHTML documents or
embedded in other XML documents, is defined in the XML and
Namespaces in XML specifications. [XML][XMLNS]
This specification does not define any syntax-level requirements
beyond those defined for XML proper.
XML documents may contain a DOCTYPE if desired, but
this is not required to conform to this specification. This
specification does not define a public or system identifier, nor
provide a format DTD.
According to the XML specification, XML processors
are not guaranteed to process the external DTD subset referenced in
the DOCTYPE. This means, for example, that using entity references
for characters in XHTML documents is unsafe if they are defined in
an external file (except for <, >, &, " and ').
10 Obsolete features
10.1 Obsolete but conforming features
Status: Last call for comments
Features listed in this section will trigger warnings in
conformance checkers.
Authors should not specify an http-equiv attribute in the
Content
Language state on a meta element. The lang attribute should be used instead.
Authors should not specify a border attribute on an
img element. If the attribute is present, its value
must be the string "0". CSS should be used
instead.
Authors should not specify a language attribute on a
script element. If the attribute is present, its value
must be an ASCII case-insensitive match for the string
"JavaScript" and either the type attribute must be omitted or
its value must be an ASCII case-insensitive match for
the string "text/javascript". The attribute
should be entirely omitted instead (with the value "JavaScript", it has no effect), or replaced with use
of the type attribute.
Authors should not specify the name attribute on a
elements. If the attribute is present, its value must not be the
empty string and must neither be equal to the value of any of the
IDs in the element's home
subtree other than the element's own ID, if any, nor be equal to the value of
any of the other name attributes on
a elements in the element's home
subtree. If this attribute is present and the element has an
ID, then the attribute's value must
be equal to the element's ID. In
earlier versions of the language, this attribute was intended as a
way to specify possible targets for fragment identifiers in URLs. The id
attribute should be used instead.
For the s and strike elements, if
they are marking up a removal from the element, consider using the
del element instead.
Where the tt element would have been used for
marking up keyboard input, consider the kbd element;
for variables, consider the var element; for computer
code, consider the code element; and for computer
output, consider the samp element.
Similarly, if the u element is being used to
indicate emphasis, consider using the em element; if
it is being used for marking up keywords, consider the
b element; and if it is being used for highlighting
text for reference purposes, consider the mark
element.
Use text that begins in an unambiguous and terse manner, and include any more elaborate text after that. The title attribute can also be useful in including more detailed text, so that the cell's contents can be made terse.
Entire novels have been written about the security
considerations that apply to HTML documents. Many are listed in
this document, to which the reader is referred for more
details. Some general concerns bear mentioning here, however:
HTML is scripted language, and has a large number of APIs (some
of which are described in this document). Script can expose the
user to potential risks of information leakage, credential
leakage, cross-site scripting attacks, cross-site request
forgeries, and a host of other problems. While the designs in this
specification are intended to be safe if implemented correctly, a
full implementation is a massive undertaking and, as with any
software, user agents are likely to have security bugs.
Even without scripting, there are specific features in HTML
which, for historical reasons, are required for broad
compatibility with legacy content but that expose the user to
unfortunate security problems. In particular, the img
element can be used in conjunction with some other features as a
way to effect a port scan from the user's location on the
Internet. This can expose local network topologies that the
attacker would otherwise not be able to determine.
HTML relies on a compartmentalization scheme sometimes known as
the same-origin policy. An origin in most
cases consists of all the pages served from the same host, on the
same port, using the same protocol.
It is critical, therefore, to ensure that any untrusted content
that forms part of a site be hosted on a different
origin than any sensitive content on that site.
Untrusted content can easily spoof any other page on the same
origin, read data from that origin, cause scripts in that origin
to execute, submit forms to and from that origin even if they are
protected from cross-site request forgery attacks by unique
tokens, and make use of any third-party resources exposed to or
rights granted to that origin.
Interoperability considerations:
Rules for processing both conforming and non-conforming content
are defined in this specification.
Published specification:
This document is the relevant specification. Labeling a resource
with the text/html type asserts that the resource is
an HTML document using
the HTML syntax.
Applications that use this media type:
Web browsers, tools for processing Web content, HTML authoring
tools, search engines, validators.
Additional information:
Magic number(s):
No sequence of bytes can uniquely identify an HTML
document. More information on detecting HTML documents is
available in the Content-Type Processing Model specification. [MIMESNIFF]
File extension(s):
"html" and "htm"
are commonly, but certainly not exclusively, used as the
extension for HTML documents.
Macintosh file type code(s):
TEXT
Person & email address to contact for further information:
The purpose of the text/html-sandboxed MIME type
is to provide a way for content providers to indicate that they
want the file to be interpreted in a manner that does not give the
file's contents access to the rest of the site. This is achieved
by assigning the Document objects generated from
resources labeled as text/html-sandboxed unique
origins.
To avoid having legacy user agents treating resources labeled
as text/html-sandboxed as regular
text/html files, authors should avoid using the .html or .htm extensions for
resources labeled as text/html-sandboxed.
Beyond this, the type is identical to text/html,
and the same considerations apply.
Labeling a resource with the application/xhtml+xml
type asserts that the resource is an XML document that likely has
a root element from the HTML namespace. As such, the
relevant specifications are the XML specification, the Namespaces
in XML specification, and this specification. [XML][XMLNS]
This registration is for community review and will be submitted
to the IESG for review, approval, and registration with IANA.
Type name:
text
Subtype name:
cache-manifest
Required parameters:
No parameters
Optional parameters:
No parameters
Encoding considerations:
Always UTF-8.
Security considerations:
Cache manifests themselves pose no immediate risk unless
sensitive information is included within the
manifest. Implementations, however, are required to follow
specific rules when populating a cache based on a cache manifest,
to ensure that certain origin-based restrictions are
honored. Failure to correctly implement these rules can result in
information leakage, cross-site scripting attacks, and the
like.
Interoperability considerations:
Rules for processing both conforming and non-conforming content
are defined in this specification.
Published specification:
This document is the relevant specification.
Applications that use this media type:
Web browsers.
Additional information:
Magic number(s):
Cache manifests begin with the string "CACHE
MANIFEST", followed by either a U+0020 SPACE character, a
U+0009 CHARACTER TABULATION (tab) character, a U+000A LINE FEED
(LF) character, or a U+000D CARRIAGE RETURN (CR) character.
File extension(s):
"manifest"
Macintosh file type code(s):
No specific Macintosh file type codes are recommended for this type.
Person & email address to contact for further information:
Fired at the Window when the document has finished loading; fired at an element containing a resource (e.g. img, embed) when its resource has finished loading
message
MessageEvent
Fired at an object when the object receives a message
Chinese Internal Code Specification. Chinese IT
Standardization Technical Committee.
[GRAPHICS]
(Non-normative) Computer Graphics: Principles and
Practice in C, Second Edition, J. Foley, A. van Dam,
S. Feiner, J. Hughes. Addison-Wesley. ISBN
0-201-84840-6.
[GREGORIAN]
(Non-normative) Inter Gravissimas, A. Lilius,
C. Clavius. Gregory XIII Papal Bulls, February 1582.
Scalable Vector
Graphics (SVG) Tiny 1.2 Specification, O. Andersson,
R. Berjon, E. Dahlström, A. Emmons, J. Ferraiolo, A. Grasso,
V. Hardy, S. Hayman, D. Jackson, C. Lilley, C. McCormack,
A. Neumann, C. Northway, A. Quint, N. Ramani, D. Schepers,
A. Shellshear. W3C.
[TIS620]
UDC
681.3.04:003.62. Thai Industrial Standards Institute,
Ministry of Industry, Royal Thai Government. ISBN
974-606-153-4.
Thanks also to everyone who has ever posted about HTML to their
blogs, public mailing lists, or forums, including all the
contributors to the various W3C HTML WG
lists and the various WHATWG lists.
Special thanks to Richard Williamson for creating the first
implementation of canvas in Safari, from which the
canvas feature was designed.
Special thanks also to the Microsoft employees who first
implemented the event-based drag-and-drop mechanism, contenteditable, and other
features first widely deployed by the Windows Internet Explorer
browser.
Thanks to the participants of the microdata usability study for
allowing us to use their mistakes as a guide for designing the
microdata feature.
Thanks to the many sources that provided inspiration for the
examples used in the specification.
Thanks also to the Microsoft blogging community for some ideas,
to the attendees of the W3C Workshop on Web Applications and
Compound Documents for inspiration, to the #mrt crew, the #mrt.no
crew, and the #whatwg crew, and to Pillar and Hedral for their ideas
and support.
