HTML5

A vocabulary and associated APIs for HTML and XHTML

1 Introduction

Status: Last call for comments

1.1 Background

Status: Last call for comments

This section is non-normative.

The World Wide Web's markup language has always been HTML. HTML
was primarily designed as a language for semantically describing
scientific documents, although its general design and adaptations
over the years have enabled it to be used to describe a number of
other types of documents.

The main area that has not been adequately addressed by HTML is a
vague subject referred to as Web Applications. This specification
attempts to rectify this, while at the same time updating the HTML
specifications to address issues raised in the past few years.

1.2 Audience

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, implementors of tools that operate on pages that use
the features defined in this specification, and individuals wishing
to establish the correctness of documents or implementations with
respect to the requirements of this specification.

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

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

1.3 Scope

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.

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.

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.

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

Each element has a predefined meaning, which is explained in
this section. Rules for authors on how to use the element, along with user agent requirements for how to handle
each element, are also given.

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

1.7.1 How to read this specification

Status: Last call for comments

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
};

variable = object . method( [ optionalArgument ] )

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

/* this is a CSS fragment */

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

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

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.

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.

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 Recommended reading

Status: Last call for comments

This section is non-normative.

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

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

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

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

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

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