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>

4.2 Document metadata

Status: Last call for comments

4.2.1 The head element

Status: Last call for comments. ISSUE-55 (head-profile) blocks progress to Last Call

The title element is a required child
in most situations, but when a higher-level protocol provides title
information, e.g. in the Subject line of an e-mail when HTML is used
as an e-mail authoring format, the title element can be
omitted.

The title element represents the
document's title or name. Authors should use titles that identify
their documents even when they are used out of context, for example
in a user's history or bookmarks, or in search results. The
document's title is often different from its first heading, since the
first heading does not have to stand alone when taken out of
context.

Returns the contents of the element, ignoring child nodes that
aren't text nodes.

Can be set, to replace the element's children with the given
value.

The IDL attribute text must return a
concatenation of the contents of all the text nodes that are direct children of the
title element (ignoring any other nodes such as
comments or elements), in tree order. On setting, it must act the
same way as the textContent IDL attribute.

Here are some examples of appropriate titles, contrasted with
the top-level headings that might be used on those same pages.

<title>Introduction to The Mating Rituals of Bees</title>
...
<h1>Introduction</h1>
<p>This companion guide to the highly successful
<cite>Introduction to Medieval Bee-Keeping</cite> book is...

The next page might be a part of the same site. Note how the
title describes the subject matter unambiguously, while the first
heading assumes the reader knows what the context is and therefore
won't wonder if the dances are Salsa or Waltz:

A base element, if it has an href attribute, must come before any
other elements in the tree that have attributes defined as taking
URLs, except the html element
(its manifest attribute
isn't affected by base elements).

If there are multiple base elements
with href attributes, all but the
first are ignored.

The types of link indicated (the relationships) are given by the
value of the rel
attribute, which, if present, must have a value that is a set
of space-separated tokens. The allowed
values and their meanings are defined in a later section. If the rel attribute
is absent, or if the values used are not allowed according to the
definitions in this specification, then the element does not define
a link.

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). For external
resources that are represented in the DOM (for example, style
sheets), the DOM representation must be made available even if the
resource is not applied. To obtain
the resource, the user agent must resolve the URL given by the href attribute, relative to the
element, and then fetch the resulting absolute
URL. User agents may opt to only try to obtain such resources
when they are needed, instead of pro-actively fetching all the external resources that are
not applied.

The semantics of the protocol used (e.g. HTTP) must be followed
when fetching external resources. (For example, redirects will be
followed and 404 responses will cause the external resource to not
be applied.)

Once the attempts to obtain the resource and its critical
subresources are complete, the user agent must, if the loads were
successful, queue a task to fire a simple
event named load at the
link element, or, if the resource or one of its
critical subresources failed to completely load for any reason
(e.g. DNS error, HTTP 404 response, a connection being prematurely
closed, unsupported Content-Type), queue a task to
fire a simple event named error at the link
element. Non-network errors in processing the resource or its
subresources (e.g. CSS parse errors, PNG decoding errors) are not
failures for the purposes of this paragraph.

The element must delay the load event of the
element's document until all the attempts to obtain the resource and
its critical subresources are complete. (Resources that the user
agent has not yet attempted to obtain, e.g. because it is waiting
for the resource to be needed, do not delay the load
event.)

Which resources are considered critical or not is defined by the
relevant specification. For CSS resources, only @import rules introduce critical subresources; other
resources, e.g. fonts or backgrounds, are not.

Interactive user agents may provide users with a
means to follow the
hyperlinks created using the link element,
somewhere within their user interface. The exact interface is not
defined by this specification, but it could include the following
information (obtained from the element's attributes, again as
defined below), in some form or another (possibly simplified), for
each hyperlink created with each link element in the
document:

The relationship between this document and the resource (given
by the rel attribute)

User agents could also include other information, such as the
type of the resource (as given by the type attribute).

Hyperlinks created with the link
element and its rel attribute
apply to the whole page. This contrasts with the rel attribute of a
and area elements, which indicates the type of a link
whose context is given by the link's location within the
document.

The media
attribute says which media the resource applies to. The value must
be a valid media query.

If the link is a hyperlink
then the media attribute is
purely advisory, and describes for which media the document in
question was designed.

The external resource might have further
restrictions defined within that limit its applicability. For
example, a CSS style sheet might have some @media blocks. This specification does not override
such further restrictions or requirements.

The default, if the media attribute is omitted, is "all", meaning that by default links apply to all
media.

The type attribute
gives the MIME type of the linked resource. It is
purely advisory. The value must be a valid MIME
type.

For external resource
links, the type attribute
is used as a hint to user agents so that they can avoid fetching
resources they do not support. If the attribute
is present, then the user agent must assume that the resource is of
the given type (even if that is not a valid MIME type,
e.g. the empty string). If the attribute is omitted, but the
external resource link type has a default type defined, then the
user agent must assume that the resource is of that type. If the UA
does not support the given MIME type for the given link
relationship, then the UA should not obtain the resource; if the UA
does support the given MIME type for the given link
relationship, then the UA should obtain the resource. If the
attribute is omitted, and the external resource link type does not
have a default type defined, but the user agent would obtain the resource if the type
was known and supported, then the user agent should obtain the resource under the
assumption that it will be supported.

User agents must not consider the type attribute authoritative —
upon fetching the resource, user agents must not use the type attribute to determine its actual
type. Only the actual type (as defined in the next paragraph) is
used to determine whether to apply the resource, not the
aforementioned assumed type.

If the external resource link
type defines rules for processing the resource's Content-Type metadata, then those rules
apply. Otherwise, if the resource is expected to be an image, user
agents may apply the image sniffing rules, with the official
type being the type determined from the resource's Content-Type metadata, and use the
resulting sniffed type of the resource as if it was the actual
type. Otherwise, if neither of these conditions apply or if the user
agent opts not to apply the image sniffing rules, then the user
agent must use the resource's Content-Type metadata to determine the
type of the resource. If there is no type metadata, but the external
resource link type has a default type defined, then the user agent
must assume that the resource is of that type.

Once the user agent has established the type of the resource, the
user agent must apply the resource if it is of a supported type and
the other relevant conditions apply, and must ignore the resource
otherwise.

...then a compliant UA that supported only CSS style sheets
would fetch the B and C files, and skip the A file (since
text/plain is not the MIME type for CSS style
sheets).

For files B and C, it would then check the actual types returned
by the server. For those that are sent as text/css, it
would apply the styles, but for those labeled as
text/plain, or any other type, it would not.

If one of the two files was returned without a
Content-Type metadata, or with a syntactically
incorrect type like Content-Type: "null", then the default type
for stylesheet links would kick
in. Since that default type is text/css, the
style sheet would nonetheless be applied.

The title
attribute gives the title of the link. With one exception, it is
purely advisory. The value is text. The exception is for style sheet
links, where the title
attribute defines alternative style sheet sets.

The title
attribute on link elements differs from the global
title attribute of most other
elements in that a link without a title does not inherit the title
of the parent element: it merely has no title.

The sizes attribute is used
with the icon link type. The attribute
must not be specified on link elements that do not have
a rel attribute that specifies
the icon keyword.

Some versions of HTTP defined a Link:
header, to be processed like a series of link elements.
If supported, for the purposes of ordering links defined by HTTP
headers must be assumed to come before any links in the document, in
the order that they were given in the HTTP entity header. (URIs in
these headers are to be processed and resolved according to the
rules given in HTTP; the rules of this specification don't
apply.) [HTTP][WEBLINK]

The IDL attributes href, rel, media, hreflang, and type, and sizes each must
reflect the respective content attributes of the same
name.

The IDL attribute disabled only applies
to style sheet links. When the link element defines a
style sheet link, then the disabled attribute behaves as
defined for the alternative
style sheets DOM. For all other link elements it
always return false and does nothing on setting.

The meta element can represent document-level
metadata with the name
attribute, pragma directives with the http-equiv attribute, and the
file's character encoding declaration when an HTML
document is serialized to string form (e.g. for transmission over
the network or for disk storage) with the charset attribute.

The charset
attribute on the meta element has no effect in XML
documents, and is only allowed in order to facilitate migration to
and from XHTML.

There must not be more than one meta element with a
charset attribute per
document.

The content
attribute gives the value of the document metadata or pragma
directive when the element is used for those purposes. The allowed
values depend on the exact context, as described in subsequent
sections of this specification.

If a meta element has a name attribute, it sets
document metadata. Document metadata is expressed in terms of
name/value pairs, the name
attribute on the meta element giving the name, and the
content attribute on the same
element giving the value. The name specifies what aspect of metadata
is being set; valid names and the meaning of their values are
described in the following sections. If a meta element
has no content attribute,
then the value part of the metadata name/value pair is the empty
string.

The name and content IDL attributes
must reflect the respective content attributes of the
same name. The IDL attribute httpEquiv must
reflect the content attribute http-equiv.

4.2.5.1 Standard metadata names

Status: Last call for comments. ISSUE-79 (meta-keywords) blocks progress to Last Call

This specification defines a few names for the name attribute of the
meta element.

The value must be a short free-form string giving the name
of the Web application that the page represents. If the page is not
a Web application, the application-name metadata name
must not be used. There must not be more than one meta
element with its name attribute
set to the value application-name per
document. User agents may use the application
name in UI in preference to the page's title, since
the title might include status messages and the like relevant to
the status of the page at a particular moment in time instead of
just being the name of the application.

author

The value must be a free-form string giving the name of one
of the page's authors.

description

The value must be a free-form string that describes the
page. The value must be appropriate for use in a directory of
pages, e.g. in a search engine. There must not be more than one
meta element with its name attribute set to the value description per document.

generator

The value must be a free-form string that identifies one of the
software packages used to generate the document. 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:

<meta name=generator content="Frontweaver 8.2">

4.2.5.2 Other metadata names

Status: Last call for comments. ISSUE-27 (rel-ownership) and ISSUE-102 (meta-name-registry) block 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.

Conformance checkers must use the information given on the WHATWG
Wiki MetaExtensions page to establish if a value is allowed or not:
values defined in this specification or marked as "proposed" or
"ratified" must be accepted, whereas values marked as "discontinued"
or not listed in either this specification or on the aforementioned
page must be rejected as invalid. Conformance checkers may cache
this information (e.g. for performance reasons or to avoid the use
of unreliable network connectivity).

When an author uses a new metadata name not defined by either
this specification or the Wiki page, conformance checkers should
offer to add the value to the Wiki, with the details described
above, with the "proposed" status.

Metadata names whose values are to be URLs must not be proposed or accepted. Links must
be represented using the link element, not the
meta element.

4.2.5.3 Pragma directives

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.

When a meta element is inserted into the document, if its
http-equiv attribute is
present and represents one of the above states, then the user agent
must run the algorithm appropriate for that state, as described in
the following list:

Conformance checkers will include a warning if
this pragma is used. Authors are encouraged to use the lang attribute instead.

If another meta element with an http-equiv attribute in the
Content
Language state has already been successfully processed
(i.e. when it was inserted the user agent processed it and
reached the last step of this list of steps), then abort these
steps.

If the meta element has no content attribute, or if that
attribute's value is the empty string, then abort these
steps.

If the element's content attribute contains a
U+002C COMMA character (,) then abort these steps.

If the meta element has no content attribute, or if that
attribute's value is the empty string, then abort these
steps.

Set the preferred style sheet set to the
value of the element's content attribute. [CSSOM]

Refresh state (http-equiv="refresh")

This pragma acts as timed redirect.

If another meta element with an http-equiv attribute in the
Refresh state
has already been successfully processed (i.e. when it was
inserted the user agent processed it and reached the last step of
this list of steps), then abort these steps.

If the meta element has no content attribute, or if that
attribute's value is the empty string, then abort these
steps.

If the character in input pointed to
by position is a U+0055 LATIN CAPITAL LETTER
U character (U) or a U+0075 LATIN SMALL LETTER U character (u),
then advance position to the next
character. Otherwise, jump to the last step.

If the character in input pointed to
by position is a U+0052 LATIN CAPITAL LETTER
R character (R) or a U+0072 LATIN SMALL LETTER R character (r),
then advance position to the next
character. Otherwise, jump to the last step.

If the character in input pointed to
by position is s U+004C LATIN CAPITAL LETTER
L character (L) or a U+006C LATIN SMALL LETTER L character (l),
then advance position to the next
character. Otherwise, jump to the last step.

If the character in input pointed to
by position is either a U+0027 APOSTROPHE
character (') or U+0022 QUOTATION MARK character ("), then let
quote be that character, and advance position to the next character. Otherwise, let
quote be the empty string.

Let url be equal to the substring of
input from the character at position to the end of the string.

If quote is not the empty string, and
there is a character in url equal to quote, then truncate url at
that character, so that it and all subsequent characters are
removed.

Set a timer so that in time seconds,
adjusted to take into account user or user agent preferences,
if the user has not canceled the redirect, the user agent navigates the document's browsing
context to url, with replacement
enabled, and with the document's browsing context as the
source browsing context.

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:

<meta http-equiv="Refresh" content="20; URL=page4.html">

There must not be more than one meta element with
any particular state in the document at a time.

4.2.5.4 Other pragma directives

Such extensions must use a name that is identical to an HTTP
header registered in the Permanent Message Header Field Registry,
and must have behavior identical to that described for the HTTP
header. [IANAPERMHEADERS]

Pragma directives corresponding to headers describing metadata,
or not requiring specific user agent processing, must not be
registered; instead, use metadata names. Pragma
directives corresponding to headers that affect the HTTP processing
model (e.g. caching) must not be registered, as they would result in
HTTP-level behavior being different for user agents that implement
HTML than for user agents that do not.

Anyone is free to edit the WHATWG Wiki PragmaExtensions page at
any time to add a pragma directive satisfying these conditions. Such
registrations must specify the following information:

Keyword

The actual name being defined. The name must match a
previously-registered HTTP name with the same
requirements.

Brief description

A short non-normative description of the purpose of the
pragma directive.

Specification

A link to the specification defining the corresponding HTTP
header.

Conformance checkers must use the information given on the WHATWG
Wiki PragmaExtensions page to establish if a value is allowed or
not: values defined in this specification or listed on the
aforementioned page must be accepted, whereas values not listed in
either this specification or on the aforementioned page must be
rejected as invalid. Conformance checkers may cache this information
(e.g. for performance reasons or to avoid the use of unreliable
network connectivity).

4.2.5.5 Specifying the document's character encoding

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.

Authoring tools should default to using UTF-8 for newly-created
documents.

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

When examining types to determine if they support the language,
user agents must not ignore unknown MIME parameters — types
with unknown parameters must be assumed to be unsupported. The charset parameter must be treated as an unknown
parameter for the purpose of comparing MIME
types here.

The media
attribute says which media the styles apply to. The value must be a
valid media query. The user agent
must apply the styles to a view when the media attribute's value
matches the environment of that view and the other
relevant conditions apply, and must not apply them
otherwise.

The styles might be further limited in scope,
e.g. in CSS with the use of @media
blocks. This specification does not override such further
restrictions or requirements.

The default, if the media attribute is omitted, is
"all", meaning that by default styles apply to
all media.

The scoped
attribute is a boolean attribute. If 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.

If the scoped attribute is
present, then the user agent must apply the specified style
information only to the style element's parent element
(if any), and that element's child nodes. Otherwise, the specified
styles must, if applied, be applied to the entire 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]

All descendant elements must be processed, according to their
semantics, before the style element itself is
evaluated. For styling languages that consist of pure text, user
agents must evaluate style elements by passing the
concatenation of the contents of all the text nodes that are direct children of the
style element (not any other nodes such as comments or
elements), in tree order, to the style system. For
XML-based styling languages, user agents must pass all the child
nodes of the style element to the style system.

All URLs found by the styling language's
processor must be resolved,
relative to the element (or as defined by the styling language),
when the processor is invoked.

Once the attempts to obtain the style sheet's critical
subresources, if any, are complete, or, if the style sheet has no
critical subresources, once the style sheet has been parsed and
processed, the user agent must, if the loads were successful or
there were none, queue a task to fire a simple
event named load at the
style element, or, if one of the style sheet's critical
subresources failed to completely load for any reason (e.g. DNS
error, HTTP 404 response, a connection being prematurely closed,
unsupported Content-Type), queue a task to fire a
simple event named error at
the style element. Non-network errors in processing the
style sheet or its subresources (e.g. CSS parse errors, PNG decoding
errors) are not failures for the purposes of this paragraph.

The element must delay the load event of the
element's document until all the attempts to obtain the style
sheet's critical subresources, if any, are complete.

Which resources are considered critical or not is defined by the
relevant specification. For CSS resources, only @import rules introduce critical subresources; other
resources, e.g. fonts or backgrounds, are not.

This specification does not specify a style system,
but CSS is expected to be supported by most Web browsers. [CSS]

The media, type and scoped IDL attributes
must reflect the respective content attributes of the
same name.

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.

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]

For style elements, if the user agent does not
support the specified styling language, then the sheet attribute of the element's
LinkStyle interface must return null. Similarly,
link elements that do not represent external resource links that contribute to
the styling processing model (i.e. that do not have a stylesheet keyword in their rel attribute), and link
elements whose specified resource has not yet been fetched, or is
not in a supported styling language, must have their
LinkStyle interface's sheet attribute return null.

Otherwise, the LinkStyle interface's sheet attribute must return a
StyleSheet object with the following properties: [CSSOM]

For link elements, the location must be the
result of resolving the
URL given by the element's href content attribute, relative to
the element, or the empty string if that fails. For
style elements, there is no location.

The style sheet media

The media must be the same as the value of the element's
media content attribute, or the empty string,
if the attribute is omitted.

The style sheet title

The title must be the same as the value of the element's
title content attribute, if the
attribute is present and has a non-empty value. If the attribute is
absent or its value is the empty string, then the style sheet does
not have a title (it is the empty string). The title is used for
defining alternative style sheet sets.

The disabled IDL
attribute on link and style elements must
return false and do nothing on setting, if the sheet attribute of their
LinkStyle interface is null. Otherwise, it must return
the value of the StyleSheet interface's disabled attribute on
getting, and forward the new value to that same attribute on
setting.

The rules for handling alternative
style sheets are defined in the CSS object model specification. [CSSOM]

Style sheets, whether added by a link element, a
style element, an <?xml-stylesheet> PI,
an HTTP Link: header, or some other
mechanism, have a style sheet ready flag, which is
initially unset.

When a style sheet is ready to be applied, its style sheet
ready flag must be set. If the style sheet referenced no
other resources (e.g. it was an internal style sheet given by a
style element with no @import
rules), then the style rules must be synchronously made available to
script; otherwise, the style rules must only be made available to
script once the event loop reaches its "update the
rendering" step.

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

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

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.

If one or both of the defer and async attributes are specified, the
src attribute must also be
specified.

Changing the src, type, charset, async, and defer attributes dynamically has no
direct effect; these attribute are only used at specific times
described below.

The first is a flag indicating whether or not the script block
has been "already started". Initially,
script elements must have this flag unset (script
blocks, when created, are not "already started"). When a
script element is cloned, the "already started" flag,
if set, must be propagated to the clone when it is created.

The second is a flag indicating whether the element was
"parser-inserted". Initially, script
elements must have this flag unset. It is set by the HTML
parser and is used to handle document.write() calls.

The third is a flag indicating whether or not the script block is
"ready to be parser-executed". Initially,
script elements must have this flag unset (script
blocks, when created, are not "ready to be parser-executed"). This
flag is used only for elements that are also
"parser-inserted", to let the parser know when to
execute the script.

The fourth and fifth pieces of state are the script
block's type and the script block's character
encoding. They are determined when the script is run,
based on the attributes on the element at that time.

If the element has a src
attribute, then the value of that attribute must be resolved relative to the element, and
if that is successful, the specified resource must then be fetched, from the origin of the
element's Document.

For historical reasons, if the URL is a javascript:
URL, then the user agent must not, despite the requirements
in the definition of the fetching
algorithm, actually execute the script in the URL; instead the
user agent must act as if it had received an empty HTTP 400
response.

For performance reasons, user agents may start fetching the
script as soon as the attribute is set, instead, in the hope that
the element will be inserted into the document. Either way, once
the element is inserted into the document, the load must have
started. If the UA performs such prefetching, but the element is
never inserted in the document, or the src attribute is dynamically
changed, then the
user agent will not execute the script, and the fetching process
will have been effectively wasted.

Then, the first of the following options that describes the
situation must be followed:

If the element has a src
attribute, and the element has a defer attribute, and the element
has been flagged as "parser-inserted", and the
element does not have an async attribute

The element must be added to the end of the list of
scripts that will execute when the document has finished
parsing.

The contents of that file, interpreted as string of
Unicode characters, are the script source.

For each of the rows in the following table, starting with
the first one and going down, if the file has as many or more
bytes available than the number of bytes in the first column,
and the first bytes of the file match the bytes given in the
first column, then set the script block's character
encoding to the encoding given in the cell in the second
column of that row, irrespective of any previous value:

Returns the contents of the element, ignoring child nodes that
aren't text nodes.

Can be set, to replace the element's children with the given
value.

The IDL attribute text must return a
concatenation of the contents of all the text nodes that are direct children of the
script element (ignoring any other nodes such as
comments or elements), in tree order. On setting, it must act the
same way as the textContent IDL attribute.

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.

When examining types to determine if they support the language,
user agents must not ignore unknown MIME parameters — types
with unknown parameters must be assumed to be unsupported. The charset parameter must be treated as an unknown
parameter for the purpose of comparing MIME
types here.

4.3.1.2 Restrictions for contents of script elements

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]

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]

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.

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:

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:

In conforming documents, there is only one body
element. The document.body
IDL attribute provides scripts with easy access to a document's
body element.

Some DOM operations (for example, parts of the
drag and drop model) are defined in terms of "the
body element". This refers to a particular element in the
DOM, as per the definition of the term, and not any arbitrary
body element.

The section element represents a
generic document or application section. 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.

The article element represents a
component of a page that consists of 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.

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

4.4.5 The aside element

Status: Last call for comments. ISSUE-91 (aside) blocks progress to Last Call

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:

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.

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

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:

<header>
<p>Welcome to...</p>
<h1>Voidwars!</h1>
</header>

The following snippet shows how the element can be used to mark
up a specification's header:

In this example, the page has a page heading given by the
h1 element, and two subsections whose headings are
given by h2 elements. The content after the
header element is still part of the last subsection
started in the header element, because the
header element doesn't take part in the
outline algorithm.

<body>
<header>
<h1>Little Green Guys With Guns</h1>
<nav>
<ul>
<li><a href="/games">Games</a>
<li><a href="/forum">Forum</a>
<li><a href="/download">Download</a>
</ul>
</nav>
<h2>Important News</h2> <!-- this starts a second subsection -->
<!-- this is part of the subsection entitled "Important News" -->
<p>To play today's games you will need to update your client.</p>
<h2>Games</h2> <!-- this starts a third subsection -->
</header>
<p>You have three active games:</p>
<!-- this is still part of the subsection entitled "Games" -->
...

The footer element represents a footer
for its nearest ancestor sectioning content or
sectioning root element. A footer typically contains
information about its section such as who wrote it, links to related
documents, copyright data, and the like.

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.

The address element must not be used to represent
arbitrary addresses (e.g. postal addresses), unless those addresses
are in fact the relevant contact information. (The p
element is the appropriate element for marking up postal addresses
in general.)

The address element must not contain information
other than contact information.

For example, the following is non-conforming use of the
address element:

<ADDRESS>Last Modified: 1999/12/24 23:37:50</ADDRESS>

Typically, the address element would be included
along with other information in a footer element.

The contact information for a node node is a
collection of address elements defined by the first
applicable entry from the following list:

4.4.11 Headings and sections

The first element of heading content in an element
of sectioning contentrepresents the
heading for that section. Subsequent headings of equal or higher
rank start new (implied) sections, headings of lower
rank start implied subsections that are part of the
previous one. In both cases, the element represents the
heading of the implied section.

Sectioning content elements are always considered
subsections of their nearest ancestor element of sectioning
content, regardless of what implied sections other headings
may have created.

Certain elements are said to be sectioning roots, including blockquote and
td elements. These elements can have their own
outlines, but the sections and headings inside these elements do not
contribute to the outlines of their ancestors.

Notice how the section ends the earlier implicit
section so that a later paragraph ("Grunt") is back at the top
level.

Sections may contain headings of any rank, 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.

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

This section defines an algorithm for creating an outline for a
sectioning content element or a sectioning
root element. It is defined in terms of a walk over the nodes
of a DOM tree, in tree order, with each node being visited when it
is entered and when it is exited during the walk.

The outline for a sectioning content
element or a sectioning root element consists of a list
of one or more potentially nested sections. A section is a container that
corresponds to some nodes in the original DOM tree. Each section can
have one heading associated with it, and can contain any number of
further nested sections. The algorithm for the
outline also associates each node in the DOM tree with a particular
section and potentially a heading. (The sections in the
outline aren't section elements, though some may
correspond to such elements — they are merely conceptual
sections.)

If the current section has no heading,
let the element being entered be the heading for the current section.

Otherwise, if the element being entered has a
rank equal to or greater than the heading of the
last section of the outline of the current outlinee, then create a new section and append it to the
outline of the current outlinee
element, so that this new section is the new last section of
that outline. Let current section be that
new section. Let the element being entered be the new heading
for the current section.

Otherwise, run these substeps:

Let candidate section be current section.

If the element being entered has a rank
lower than the rank of the heading of the candidate section, then create a new section, and append it to candidate section. (This does not change which
section is the last section in the outline.) Let current section be this new section. Let the
element being entered be the new heading for the current section. Abort these substeps.

Let new candidate section be the
section that contains candidate section in the outline of
current outlinee.

Let candidate section be new candidate section.

Return to step 2.

Push the element being entered onto the stack. (This causes
the algorithm to skip any descendants of the element.)

Associate any nodes that were not associated with a section in the steps above with current outlinee as their section.

Associate all nodes with the heading of the section with which they are
associated, if any.

If current outlinee is the body
element, then the outline created for that element is the
outline of the entire document.

The tree of sections created by the algorithm above, or a proper
subset thereof, must be used when generating document outlines, for
example when generating tables of contents.

When creating an interactive table of contents, entries should
jump the user to the relevant sectioning content
element, if the section was
created for a real element in the original document, or to the
relevant heading content element, if the section in the tree was generated for
a heading in the above process.

Selecting the first section of the document therefore
always takes the user to the top of the document, regardless of
where the first heading in the body is to be found.

Although it contains no headings, this snippet has three
sections: a document (the body) with two subsections
(a nav and an aside). A user agent could
present the outline as follows:

Untitled document

Navigation

Sidebar

These default headings ("Untitled document", "Navigation",
"Sidebar") are not specified by this specification, and might vary
with the user's language, the page's language, the user's
preferences, the user agent implementor's preferences, etc.

The following JavaScript function shows how the tree walk could
be implemented. The root argument is the root
of the tree to walk, and the enter and exit arguments are callbacks that are called with
the nodes as they are entered and exited. [ECMA262]

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

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

Content inside a blockquote must be quoted from
another source, whose address, if it has one, should be cited in the
cite
attribute.

If the cite attribute
is present, it must be a valid URL. To obtain the corresponding citation link, the value of
the attribute must be resolved
relative to the element. User agents should allow users to follow
such citation links.

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

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.

If the start attribute is
present, user agents must parse it as an integer, in order to determine the
attribute's value. The default value, used if the attribute is
missing or if the value cannot be converted to a number according to
the referenced algorithm, is 1 if the element has no reversed attribute, and is the
number of child li elements otherwise.

The first item in the list has the ordinal value given by the
ol element's start
attribute, unless that li element has a value attribute with a value that can
be successfully parsed, in which case it has the ordinal value given
by that value attribute.

Each subsequent item in the list has the ordinal value given by
its value attribute, if it has
one, or, if it doesn't, the ordinal value of the previous item, plus
one if the reversed is absent,
or minus one if it is present.

The reversed IDL
attribute must reflect the value of the reversed content attribute.

The start IDL
attribute must reflect the value of the start content attribute.

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>

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.

If the value attribute is
present, user agents must parse it as an integer, in order to determine the
attribute's value. If the attribute's value cannot be converted to a
number, the attribute must be treated as if it was absent. The
attribute has no default value.

The value attribute is
processed relative to the element's parent ol element
(q.v.), if there is one. If there is not, the attribute has no
effect.

The value IDL
attribute must reflect the value of the value content attribute.

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.

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.

If a dl element contains only dt
elements, then it consists of one group with names but no
values.

If a dl element contains only dd
elements, then it consists of one group with values but no
names.

If a dl element starts with one or more
dd elements, then the first group has no associated
name.

If a dl element ends with one or more
dt elements, then the last group has no associated
value.

When a dl element doesn't match its
content model, it is often due to accidentally using dd
elements in the place of dt elements and vice
versa. Conformance checkers can spot such mistakes and might be able
to advise authors how to correctly use the markup.

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

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.

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

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