html elementhead element followed by a body element.manifestHTMLElement.The html element represents the root of
an HTML document.
The manifest
attribute gives the address of the document's application
cache manifest, if there is
one. If the attribute is present, the attribute's value must be a
valid URL.
The manifest attribute
only has an effect during
the early stages of document load. Changing the attribute
dynamically thus has no effect (and thus, no DOM API is provided for
this attribute).
For the purposes of application cache selection,
later base elements cannot affect the resolving of relative URLs in manifest attributes, as the
attributes are processed before those elements are seen.
head elementhtml element.title element.HTMLElement.The head element represents a
collection of metadata for the Document.
title elementhead element containing no other title elements.HTMLElement.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 header, since the
first header does not have to stand alone when taken out of
context.
There must be no more than one title element per
document.
The title element must not contain any
elements.
Here are some examples of appropriate titles, contrasted with the top-level headers 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 header assumes the reader knowns what the context is and therefore won't wonder if the dances are Salsa or Waltz:
<title>Dances used during bee mating rituals</title>
...
<h1>The Dances</h1>
The string to use as the document's title is given by the document.title DOM attribute. User
agents should use the document's title when referring to the
document in their user interface.
base elementhead element containing no other base elements.hreftargetinterface HTMLBaseElement : HTMLElement {
attribute DOMString href;
attribute DOMString target;
};
The base element allows authors to specify the
document base URL for the purposes of resolving relative URLs, and the name
of the default browsing context for the purposes of
following hyperlinks. The element does not represent any content beyond this
information.
There must be no more than one base element per
document.
A base element must have either an href attribute, a target attribute, or both.
The href content
attribute, if specified, must contain a valid URL.
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 target
attribute, if specified, must contain a valid browsing context
name or keyword. User agents use this name when
following hyperlinks.
A base element, if it has a target attribute, must come before
any elements in the tree that represent hyperlinks.
If there are multiple base elements
with target attributes, all but
the first are ignored.
The href and target DOM attributes
must reflect the respective content attributes of the
same name.
link elementnoscript element that is a child of a head element.hrefrelmediahreflangtypesizestitle attribute has special semantics on this element.interface HTMLLinkElement : HTMLElement {
attribute boolean disabled;
attribute DOMString href;
attribute DOMString rel;
readonly attribute DOMTokenList relList;
attribute DOMString media;
attribute DOMString hreflang;
attribute DOMString type;
attribute DOMString sizes;
};
The LinkStyle interface must also be implemented
by this element, the styling processing model defines
how. [CSSOM]
The link element allows authors to link their
document to other resources.
The destination of the link(s) is given by the href attribute, which must
be present and must contain a valid URL. If the href attribute is absent, then the
element does not define a link.
The types of link indicated (the relationships) are given by the
value of the rel
attribute, which must be present, and 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
fetch 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 must be followed and 404 responses must cause the external resource to not be applied.)
Interactive user agents should 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 should 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:
rel attribute)title attribute).href attribute).hreflang attribute).media attribute).User agents may 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. [MQ]
If the link is a hyperlink
then the media attribute is
purely advisory, and describes for which media the document in
question was designed.
However, if the link is an external resource link,
then the media attribute is
prescriptive. The user agent must apply the external resource to
views while their state match the listed
media and the other relevant conditions apply, and must not apply
them otherwise.
The external resource might have further
restrictions defined within that limit its applicability. For
example, a CSS style sheet might have some @media blocks. This specification does not override
such further restrictions or requirements.
The default, if the media attribute is omitted, is
all, meaning that by default links apply to all
media.
The hreflang
attribute on the link element has the same semantics as
the hreflang
attribute on hyperlink elements.
The type attribute
gives the MIME type of the linked resource. It is purely advisory.
The value must be a valid MIME type, optionally with parameters. [RFC2046]
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. 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 fetch
the resource; if the UA does support the given MIME type for the
given link relationship, then the UA should fetch 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 fetch the resource if the type was known and supported, then
the user agent should fetch 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 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 the resource is not expected to be an image, or if the user agent opts not to apply those rules, then the user agent must use the resource's Content-Type metadata to determine the type of the resource. If there is no type metadata, but the external resource link type has a default type defined, then the user agent must assume that the resource is of that type.
Once the user agent has established the type of the resource, the user agent must apply the resource if it is of a supported type and the other relevant conditions apply, and must ignore the resource otherwise.
If a document contains style sheet links labeled as follows:
<link rel="stylesheet" href="A" type="text/plain"> <link rel="stylesheet" href="B" type="text/css"> <link rel="stylesheet" href="C">
...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 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.) [RFC2616] [RFC2068]
The DOM attributes href, rel, media, hreflang, and type, and sizes each must
reflect the respective content attributes of the same
name.
The DOM attribute relList must
reflect the rel
content attribute.
The DOM 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.
meta elementcharset attribute is present, or if the element is in the Encoding declaration state: in a head element.http-equiv attribute is present, and the element is not in the Encoding declaration state: in a head element.http-equiv attribute is present, and the element is not in the Encoding declaration state: in a noscript element that is a child of a head element.name attribute is present: where metadata content is expected.namehttp-equivcontentcharset (HTML only)interface HTMLMetaElement : HTMLElement {
attribute DOMString content;
attribute DOMString name;
attribute DOMString httpEquiv;
};
The meta element represents various
kinds of metadata that cannot be expressed using the
title, base, link,
style, and script elements.
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.
Exactly one of the name,
http-equiv, and charset attributes must be
specified.
If either name or http-equiv is specified, then
the content attribute must
also be specified. Otherwise, it must be omitted.
The charset
attribute specifies the character encoding used by the
document. This is called a character encoding
declaration.
The charset attribute may
be specified in HTML documents only, it
must not be used in XML documents. There
must not be more than one 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.
If a meta element has the http-equiv attribute specified,
it must be either in a head element or in a
noscript element that itself is in a head
element. If a meta element does not have the http-equiv attribute specified,
it must be in a head element.
The DOM attributes name and content must
reflect the respective content attributes of the same
name. The DOM attribute httpEquiv must
reflect the content attribute http-equiv.
This specification defines a few names for the name attribute of the
meta element.
The value must be a short free-form string that 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. 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.
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.
The value must be a free-form string that identifies the software used to generate the document. This value must not be used on hand-authored pages.
Extensions to the predefined set of metadata names may be registered in the WHATWG Wiki MetaExtensions page.
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:
The actual name being defined. The name should not be confusingly similar to any other defined name (e.g. differing only in case).
A short description of what the metadata name's meaning is, including the format the value is required to be in.
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.
One of the following:
If a metadata name is added with the "proposal" status and found to be redundant with existing values, it should be removed and listed as a synonym for the existing value.
Conformance checkers must use the information given on the WHATWG Wiki MetaExtensions page to establish if a value not explicitly defined in this specification is allowed or not. When an author uses a new type 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 "proposal" status.
This specification does not define how new values will get approved. It is expected that the Wiki will have a community that addresses this.
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.
When the http-equiv attribute
is specified on a meta element, the element is a pragma
directive.
The http-equiv attribute
is an enumerated attribute. The following table lists
the keywords defined for this attribute. The states given in the
first cell of the rows with keywords give the states to which
those keywords map. Some of the keywords are non-conforming, as
noted in the last column.
| State | Keywords | Notes |
|---|---|---|
| Content Language | content-language
| Non-conforming |
| Encoding declaration | content-type
| |
| Default style | default-style
| |
| Refresh | refresh
|
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:
This non-conforming pragma sets the document-wide default language. Until the pragma is successfully processed, there is no document-wide default language.
If another meta element 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.
Let input be the value of the
element's content
attribute.
Let position point at the first character of input.
Collect a sequence of characters that are neither space characters nor a U+002C COMMA character (",").
Let the document-wide default language be the string that resulted from the previous step.
For meta elements in the Content Language
state, the content
attribute must have a value consisting of a valid RFC 3066
language code. [RFC3066]
This pragma is not exactly equivalent to the HTTP
Content-Language header, for instance it only
supports one language. [RFC2616]
The Encoding
declaration state's user agent requirements are all handled
by the parsing section of the specification. The state is just an
alternative form of setting the charset attribute: it is a
character encoding declaration.
For meta elements in the Encoding declaration
state, the content
attribute must have a value that is an ASCII
case-insensitive match for a string that consists of: the
literal string "text/html;", optionally
followed by any number of space
characters, followed by the literal string "charset=", followed by the character encoding name
of the character encoding declaration.
If the document contains a meta element in the
Encoding
declaration state, then the document must not contain a
meta element with the charset attribute present.
The Encoding declaration state may be used in HTML documents only, elements in that state must not be used in XML documents.
If another meta element in the Refresh state has
already been successfully processed (i.e. when it was inserted
the user agent processed it and reached the last step of this
list of steps), then abort these steps.
If the meta element has no content attribute, or if that
attribute's value is the empty string, then abort these
steps.
Let input be the value of the
element's content
attribute.
Let position point at the first character of input.
Collect a sequence of characters in the range U+0030 DIGIT ZERO to U+0039 DIGIT NINE, and parse the resulting string using the rules for parsing non-negative integers. If the sequence of characters collected is the empty string, then no number will have been parsed; abort these steps. Otherwise, let time be the parsed number.
Collect a
sequence of characters in the range U+0030 DIGIT ZERO to
U+0039 DIGIT NINE and U+002E FULL STOP ("."). Ignore any collected characters.
Let url be the address of the current page.
If the character in input pointed to
by position is a U+003B SEMICOLON (";"), then advance position to
the next character. Otherwise, jump to the last step.
If the character in input pointed to by position is one of U+0055 LATIN CAPITAL LETTER U or U+0075 LATIN SMALL LETTER U, then advance position to the next character. Otherwise, jump to the last step.
If the character in input pointed to by position is one of U+0052 LATIN CAPITAL LETTER R or U+0072 LATIN SMALL LETTER R, then advance position to the next character. Otherwise, jump to the last step.
If the character in input pointed to by position is one of U+004C LATIN CAPITAL LETTER L or U+006C LATIN SMALL LETTER L, 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+003D EQUALS SIGN ("="), then advance position to
the next character. Otherwise, jump to the last step.
Let url be equal to the substring of input from the character at position to the end of the string.
Strip any trailing space characters from the end of url.
Strip any U+0009 CHARACTER TABULATION, U+000A LINE FEED (LF), and U+000D CARRIAGE RETURN (CR) characters from url.
Resolve the url value to an absolute URL,
relative to the meta element. If this fails, abort
these steps.
Perform one or more of the following steps:
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.
Provide the user with an interface that, when selected, navigates a browsing context to url, with the document's browsing context as the source browsing context.
Do nothing.
In addition, the user agent may, as with anything, inform the user of any and all aspects of its operation, including the state of any timers, the destinations of any timed redirects, and so forth.
For meta elements in the Refresh state, the
content attribute must have
a value consisting either of:
;), followed by one or
more space characters,
followed by either a U+0055 LATIN CAPITAL LETTER U or a U+0075
LATIN SMALL LETTER U, a U+0052 LATIN CAPITAL LETTER R or a U+0072
LATIN SMALL LETTER R, a U+004C LATIN CAPITAL LETTER L or a U+006C
LATIN SMALL LETTER L, a U+003D EQUALS SIGN (=), 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.
There must not be more than one meta element with
any particular state in the document at a time.
Extensions to the predefined set of pragma directives may, under certain conditions, be registered in the WHATWG Wiki PragmaExtensions page.
Such extensions must use a name that is identical to a previously-registered HTTP header defined in an RFC, and must have behavior identical to that described for the HTTP header. Pragma directions corresponding to headers describing metadata, or not requiring specific user agent processing, must not be registered; instead, use metadata names. Pragma directions 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:
The actual name being defined.
A short description of the purpose of the pragma directive.
Conformance checkers must use the information given on the WHATWG Wiki PragmaExtensions page to establish if a value not explicitly defined in this specification is allowed or not.
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:
If the document does not start with a BOM, and if its encoding is
not explicitly given by Content-Type
metadata, then the character encoding used must be an
ASCII-compatible character encoding, and, in addition,
if that encoding isn't US-ASCII itself, then the encoding must be
specified using a meta element with a charset attribute or a
meta element in the Encoding declaration
state.
If the document contains a meta element with a charset attribute or a
meta element in the Encoding declaration
state, then the character encoding used must be an
ASCII-compatible character encoding.
Authors should not use JIS_X0212-1990, x-JIS0208, and encodings based on EBCDIC. Authors should not use UTF-32. Authors must not use the CESU-8, UTF-7, BOCU-1 and SCSU encodings. [CESU8] [UTF7] [BOCU1] [SCSU]
Authors are encouraged to use UTF-8. Conformance checkers may advise against authors using legacy encodings.
In XHTML, the XML declaration should be used for inline character encoding information, if necessary.
style elementscoped attribute is present: flow content.scoped attribute is absent: where metadata content is expected.scoped attribute is absent: in a noscript element that is a child of a head element.scoped attribute is present: where flow content is expected, but before any other flow content other than other style elements and inter-element whitespace.type attribute.mediatypescopedtitle attribute has special semantics on this element.interface HTMLStyleElement : HTMLElement {
attribute boolean disabled;
attribute DOMString media;
attribute DOMString type;
attribute boolean scoped;
};
The LinkStyle interface must also be implemented
by this element, the styling processing model defines
how. [CSSOM]
The style element allows authors to embed style
information in their documents. The style element is
one of several inputs to the styling processing
model. The element does not represent content for the user.
If the type
attribute is given, it must contain a valid MIME type, optionally
with parameters, that designates a styling language. [RFC2046] If the attribute is absent, the
type defaults to text/css. [RFC2138]
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 media
attribute says which media the styles apply to. The value must be a
valid media query. [MQ] User
agents must apply the styles to views
while their state match the listed media, 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 the 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.
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.
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.
This specification does not specify a style system, but CSS is expected to be supported by most Web browsers. [CSS21]
The media, type and scoped DOM attributes
must reflect the respective content attributes of the
same name.
The DOM disabled attribute
behaves as defined for the
alternative style sheets DOM.
The link and style elements can provide
styling information for the user agent to use when rendering the
document. The DOM Styling specification specifies what styling
information is to be used by the user agent and how it is to be
used. [CSSOM]
The style and link elements implement
the LinkStyle interface. [CSSOM]
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 attributes implemented as
follows: [CSSOM]
type DOM attribute)The content type must be the same as the style's specified
type. For style elements, this is the same as the
type content attribute's
value, or text/css if that is omitted. For
link elements, this is the Content-Type metadata of the specified
resource.
href DOM attribute)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.
media DOM attribute)The media must be the same as the value of the element's
media content attribute.
title DOM attribute)The title must be the same as the value of the element's
title content attribute. If the attribute is
absent, then the style sheet does not have a title. The title is
used for defining alternative style sheet sets.
The disabled DOM
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.
Scripts allow authors to add interactivity to their documents.
Authors are encouraged to use declarative alternatives to scripting where possible, as declarative mechanisms are often more maintainable, and many users disable scripting.
For example, instead of using script to show or hide a section
to show more details, the details element could be
used.
Authors are also encouraged to make their applications degrade gracefully in the absence of scripting support.
For example, if an author provides a link in a table header to dynamically resort the table, the link could also be made to function without scripts by requesting the sorted table from the server.
script elementsrc
attribute, depends on the value of the type attribute.src
attribute, the element must be either empty or contain only
script documentation.srcasyncdefertypecharsetinterface HTMLScriptElement : HTMLElement {
attribute DOMString src;
attribute boolean async;
attribute boolean defer;
attribute DOMString type;
attribute DOMString charset;
attribute DOMString text;
};
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. If the type
attribute is present, its value must be the type of the script's
language.
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,
optionally with parameters. The charset
parameter must not be specified. (The default, which is used if the
attribute is absent, is "text/javascript".) [RFC2046]
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.
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 the preferred 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
is 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.
Changing the src, type, charset, async, and defer attributes dynamically has no
direct effect; these attribute are only used at specific times
described below (namely, when the element is inserted into the document).
script elements have four associated pieces of
metadata. The first is a flag indicating whether or not the script
block has been "already executed". Initially,
script elements must have this flag unset (script
blocks, when created, are not "already executed"). When a
script element is cloned, the "already executed" 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". This flag is set by the HTML
parser and is used to handle document.write() calls. The third
and fourth pieces of metadata 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.
When a script element that is neither marked as
having "already executed" nor marked as being
"parser-inserted" experiences one of the events listed
in the following list, the user agent must run the script element:
script element gets inserted into a document.script element's child nodes are changed.script element has a src attribute set where previously
the elment had no such attribute.Running a script: When a
script element is to be run, the user agent must act as
follows:
If either:
script element has a type attribute and its value is
the empty string, orscript element has no type attribute but it has a language attribute and
that attribute's value is the empty string, orscript element has neither a type attribute nor a language attribute, then...let the script block's type for this
script element be "text/javascript".
Otherwise, if the script element has a type attribute, let the
script block's type for this script element be
the value of that attribute.
Otherwise, the element has a non-empty language attribute; let
the script block's type for this script
element be the concatenation of the string "text/" followed by the value of the language attribute.
The language attribute is never
conforming, and is always ignored if there is a type attribute present.
If the script element has a charset attribute, then let
the script block's character encoding for this
script element be the encoding given by the charset attribute.
Otherwise, let the script block's character encoding
for this script element be the same as the encoding of the document
itself.
If scripting is
disabled for the script element, or if the
user agent does not support the scripting language
given by the script block's type for this
script element, then the user agent must abort these
steps at this point. The script is not executed.
If the element has no src
attribute, and its child nodes consist only of comment nodes and
empty text nodes, then the user
agent must abort these steps at this point. The script is not
executed.
The user agent must set the element's "already executed" flag.
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.
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 given script; instead the user
agent must act as if it had received an empty HTTP 400
response.
Once the resource's Content Type metadata is available, if it ever is, apply the algorithm for extracting an encoding from a Content-Type to it. If this returns an encoding, and the user agent supports that encoding, then let the script block's character encoding be that encoding.
Once the fetching process has completed, and the script has completed loading, the user agent will have to complete the steps described below. (If the parser is still active at that time, those steps defer to the parser to handle the execution of pending scripts.)
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:
defer attribute, and the
element does not have an async attributeThis isn't compatible with IE for inline deferred scripts, but then what IE does is pretty hard to pin down exactly. Do we want to keep this like it is? Be more compatible?
async attribute and a src attributeasync attribute but no src attribute, and the list
of scripts that will execute asynchronously is not
emptysrc
attribute and has been flagged as
"parser-inserted"src
attributeWhen a script completes loading: If the
script element was added to one of the lists mentioned
above and the document is still being parsed, then the parser
handles it. Otherwise, the UA must run the following steps as the
task that the networking
task source places on the task queue:
script element was added to the list
of scripts that will execute when the document has finished
parsing:If the script element is not the first element
in the list, then do nothing yet. Stop going through these
steps.
Otherwise, execute the script block (the first element in the list).
Remove the script element from the list
(i.e. shift out the first entry in the list).
If there are any more entries in the list, and if the script associated with the element that is now the first in the list is already loaded, then jump back to step two to execute it.
script element was added to the list
of scripts that will execute asynchronously:If the script is not the first element in the list, then do nothing yet. Stop going through these steps.
Execute the script block (the first element in the list).
Remove the script element from the list
(i.e. shift out the first entry in the list).
If there are any more scripts in the list, and the element
now at the head of the list had no src attribute when it was added
to the list, or had one, but its associated script has finished
loading, then jump back to step two to execute the script
associated with this element.
script element was added to the list
of scripts that will execute as soon as possible:Remove the script element from the list.
Fetching an external script must delay the load event.
Executing a script block: When the steps above require that the script block be executed, the user agent must act as follows:
Executing the script block must just consist of firing an error event at the
element.
Initialize the script block's source as follows:
The contents of that file, interpreted as string of Unicode characters, are the script source.
The file must be converted to Unicode using the character encoding given by the script block's character encoding.
The value of the DOM text attribute at the time the
"running a script" algorithm was first invoked is
the script source.
The child nodes of the script element at the
time the "running a script" algorithm was first
invoked are the script source.
Create a
script from the script element node, using
the the script block's source and the the script
block's type.
This is where the script is compiled and actually executed.
Fire a load
event at the script element.
The DOM attributes src, type, charset, async, and defer, each must
reflect the respective content attributes of the same
name.
The DOM 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 DOM attribute.
In this example, two script elements are used. One
embeds an external script, and the other includes some data.
<script src="game-engine.js"></script> <script type="text/x-game-map"> ........U.........e o............A....e .....A.....AAA....e .A..AAA...AAAAA...e </script>
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.
When inserted using the document.write() method,
script elements execute (typically synchronously), but
when inserted using innerHTML and outerHTML attributes, they do not
execute at all.
A user agent is said to support the scripting language if the script block's type matches the MIME type of a scripting language that the user agent implements.
The following lists some MIME types and the languages to which they refer:
text/javascripttext/javascript1.1text/javascript1.2text/javascript1.3text/javascript;e4x=1User agents may support other MIME types and other languages.
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.
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 DOM text
attribute, which is derived from the element's contents, matches the
documentation production in the following
ABNF, the character set for which is Unicode. [ABNF]
documentation = *( *( space / tab / comment ) [ line-comment ] newline )
comment = slash star *( not-star / star not-slash ) 1*star slash
line-comment = slash slash *not-newline
; characters
tab = %x0009 ; U+0009 TAB
newline = %x000A ; U+000A LINE FEED
space = %x0020 ; U+0020 SPACE
star = %x002A ; U+002A ASTERISK
slash = %x002F ; U+002F SOLIDUS
not-newline = %x0000-0009 / %x000B-%10FFFF
; a Unicode character other than U+000A LINE FEED
not-star = %x0000-0029 / %x002B-%10FFFF
; a Unicode character other than U+002A ASTERISK
not-slash = %x0000-002E / %x0030-%10FFFF
; a Unicode character other than U+002F SOLIDUSThis allows authors to include documentation, such as license
information or API information, inside their documents while still
referring to external script files. The syntax is constrained so
that authors don't accidentally include what looks like valid
script while also providing a src attribute.
<script src="cool-effects.js"> // create new instances using: // var e = new Effect(); // start the effect using .play, stop using .stop: // e.play(); // e.stop(); </script>
noscript elementhead element of an HTML document, if there are no ancestor noscript elements.noscript elements.head element: in any order, zero or more link elements, zero or more style elements, and zero or more meta elements.head element: transparent, but there must be no noscript element descendants.HTMLElement.The noscript element represents nothing
if scripting is enabled, and
represents its children if scripting is disabled. It is used
to present different markup to user agents that support scripting
and those that don't support scripting, by affecting how the
document is parsed.
When used in HTML documents, the allowed content model is as follows:
head element, if scripting is disabled for the
noscript elementThe noscript element must contain only
link, style, and meta
elements.
head element, if scripting is enabled for the
noscript elementThe noscript element must contain only text,
except that invoking the HTML fragment parsing
algorithm with the noscript element as the context element and the text contents as the input must result in a list of nodes that consists
only of link, style, and
meta elements, and no parse
errors.
head elements, if scripting is disabled for the
noscript elementThe noscript element's content model is
transparent, with the additional restriction that a
noscript element must not have a noscript
element as an ancestor (that is, noscript can't be
nested).
head elements, if scripting is enabled for the
noscript elementThe 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:
script element from the
document.noscript element in the
document. For every noscript element in that list,
perform the following steps:
noscript element.noscript element, and call these
elements the before children.noscript element, and
call these elements the after children.noscript
element.innerHTML
attribute of the parent element to the value
of s. (This, as a side-effect, causes the
noscript element to be removed from the
document.)All these contortions are required because, for
historical reasons, the noscript element is handled
differently by the HTML parser based on whether scripting was enabled or not when the
parser was invoked. The element is not allowed in XML, because in
XML the parser is not affected by such state, and thus the element
would not have the desired effect.
The noscript element must not be used in XML
documents.
The noscript element is only
effective in the HTML serialization,
it has no effect in the XML serialization.
The noscript element has no other requirements. In
particular, children of the noscript element are not
exempt from form submission, scripting, and so forth,
even when scripting is enabled
for the element.
eventsource elementsrcinterface HTMLEventSourceElement : HTMLElement {
attribute DOMString src;
};
The eventsource element represents a
target for events generated by a remote server.
The src
attribute, if specified, must give a valid URL
identifying a resource that uses the text/event-stream
format.
When an eventsource element with a src attribute specified is inserted into the
document, and when an eventsource element that
is already in the document has a src attribute added, the user
agent must run the add declared event source
algorithm.
While an eventsource element is in a document, if its src
attribute is mutated, the user agent must must run the remove
declared event source algorithm followed by the add
declared event source algorithm.
When an eventsource element with a src attribute specified is
removed from a document, and when an
eventsource element that is in a document with a src
attribute specified has its src attribute removed, the user
agent must run the remove declared event source
algorithm.
When it is created, an eventsource element must
have its current declared event source set to
"undefined".
The add declared event source algorithm is as follows:
eventsource element's src attribute, relative to the
element.The remove declared event source algorithm is as follows:
There can be more than one eventsource element per
document, but authors should take care to avoid opening multiple
connections to the same server as HTTP recommends a limit to the
number of simultaneous connections that a user agent can open per
server.
The src DOM
attribute must reflect the content attribute of the
same name.
Some elements, for example
address elements, are scoped to their nearest ancestor
sectioning content. For such elements x, the elements that apply to a sectioning
content element e are all the x elements whose nearest sectioning
content ancestor is e.
body elementhtml element.onbeforeunloadonerroronhashchangeonloadonmessageonofflineononlineonpopstateonresizeonstorageonunloadinterface HTMLBodyElement : HTMLElement {
attribute Function onbeforeunload;
attribute any onerror;
attribute Function onhashchange;
attribute Function onload;
attribute Function onmessage;
attribute Function onoffline;
attribute Function ononline;
attribute Function onpopstate;
attribute Function onresize;
attribute Function onstorage;
attribute Function onunload;
};
The body element represents the main
content of the document.
In conforming documents, there is only one body
element. The document.body
DOM 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 body element exposes as event handler
content attributes a number of the event handler
attributes of the Window object. It also mirrors
their event handler DOM attributes.
The onerror and onmessage event
handler attributes of the Window object, exposed
on the body element, shadow the generic onerror and onmessage event handler
attributes normally supported by HTML
elements.
Thus, for example, a bubbling message event fired on a child of
the body element of a Document would first
trigger the onmessage
event handler content attributes of that element, then
that of the root html element, and only then
would it trigger the onmessage event handler content attribute
on the body element. This is because the event would
bubble from the target, to the body, to the
html, to the Document, to the
Window, and the event handler attribute on the
body is watching the Window not the
body. A regular event listener attached to the
body using addEventListener(),
however, would fire when the event bubbled through the
body and not when it reaches the Window
object.
section elementHTMLElement.The section element represents a
generic document or application section. A section, in this context,
is a thematic grouping of content, typically with a header, possibly
with a footer.
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.
In the following example, we see an article (part of a larger Web page) about apples, containing two short sections.
<article> <header> <h1>Apples</h1> <p>Tasty, delicious fruit!</p> </header> <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 and make a great filling for apple pies.</p> </section> </article>
nav elementHTMLElement.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 primary navigation blocks are appropriate for the
nav element. In particular, it is common for footers to
have a list of links to various key parts of a site, but the
footer element is more appropriate in such cases.
In the following example, the page has several places where links are present, but only one of those places is considered a navigation section.
<body>
<header>
<h1>Wake up sheeple!</h1>
<p><a href="news.html">News</a> -
<a href="blog.html">Blog</a> -
<a href="forums.html">Forums</a></p>
</header>
<nav>
<h1>Navigation</h1>
<ul>
<li><a href="articles.html">Index of all articles</a><li>
<li><a href="today.html">Things sheeple need to wake up for today</a><li>
<li><a href="successes.html">Sheeple we have managed to wake</a><li>
</ul>
</nav>
<article>
<p>...page content would be here...</p>
</article>
<footer>
<p>Copyright © 2006 The Example Company</p>
<p><a href="about.html">About</a> -
<a href="policy.html">Privacy Policy</a> -
<a href="contact.html">Contact Us</a></p>
</footer>
</body>
article elementHTMLElement.The article element represents a
section of a page that consists of a composition that forms an
independent part of a document, page, or site. This could be a forum
post, a magazine or newspaper article, a Web log entry, a
user-submitted comment, or any other independent item of
content.
An article element is "independent" in
that its contents could stand alone, for example in syndication.
However, the element is still associated with its ancestors; for
instance, contact information that applies to a parent body
element still covers the article as well.
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 Web log entry on a site that accepts user-submitted
comments could represent the comments as article
elements nested within the article element for the Web
log entry.
Author information associated with an article
element (q.v. the address element) does not apply to
nested article elements.
aside elementHTMLElement.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 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> ...
h1, h2,
h3, h4,
h5, and h6
elementsHTMLElement.These elements define headers for their sections.
The semantics and meaning of these elements are defined in the section on headings and sections.
These elements have a rank given by the number in
their name. The h1 element is said to have the highest
rank, the h6 element has the lowest rank, and two
elements with the same name have equal rank.
header elementheader element
descendants, and no footer element descendants.HTMLElement.The header element represents the
header of a section. The element is typically used to group a set of
h1–h6 elements to mark up a page's
title with its subtitle or tagline. However, header
elements may contain more than just the section's headings and
subheadings — for example it would be reasonable for the
header to include version history information.
For the purposes of document summaries, outlines, and the like,
the text of header elements is defined to be the text
of the highest ranked
h1–h6 element descendant of the
header 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 header element is the empty string.
Other heading elements in the header element
indicate subheadings or subtitles.
The rank of a header element is the
same as for an h1 element (the highest rank).
The section on headings and sections
defines how header elements are assigned to individual
sections.
Here are some examples of valid headers. In each case, the emphasised text represents the text that would be used as the header in an application extracting header data and ignoring subheadings.
<header> <h1>The reality dysfunction</h1> <h2>Space is not the only void</h2> </header>
<header> <h1>Dr. Strangelove</h1> <h2>Or: How I Learned to Stop Worrying and Love the Bomb</h2> </header>
<header> <p>Welcome to...</p> <h1>Voidwars!</h1> </header>
<header> <h1>Scalable Vector Graphics (SVG) 1.2</h1> <h2>W3C Working Draft 27 October 2004</h2> <dl> <dt>This version:</dt> <dd><a href="http://www.w3.org/TR/2004/WD-SVG12-20041027/">http://www.w3.org/TR/2004/WD-SVG12-20041027/</a></dd> <dt>Previous version:</dt> <dd><a href="http://www.w3.org/TR/2004/WD-SVG12-20040510/">http://www.w3.org/TR/2004/WD-SVG12-20040510/</a></dd> <dt>Latest version of SVG 1.2:</dt> <dd><a href="http://www.w3.org/TR/SVG12/">http://www.w3.org/TR/SVG12/</a></dd> <dt>Latest SVG Recommendation:</dt> <dd><a href="http://www.w3.org/TR/SVG/">http://www.w3.org/TR/SVG/</a></dd> <dt>Editor:</dt> <dd>Dean Jackson, W3C, <a href="mailto:dean@w3.org">dean@w3.org</a></dd> <dt>Authors:</dt> <dd>See <a href="#authors">Author List</a></dd> </dl> <p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notic ... </header>
footer elementfooter element descendants.HTMLElement.The footer element represents a footer
for the section it applies to. 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 section given in a
footer should be marked up using the
address element.
Footers don't necessarily have to appear at the end of a section, though they usually do.
Here is a page with two footers, one at the top and one at the bottom, with the same content:
<body> <footer><a href="../">Back to index...</a></footer> <header> <h1>Lorem ipsum</h1> <h2>The ipsum of all lorems</h2> </header> <p>A dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</p> <footer><a href="../">Back to index...</a></footer> </body>
address elementfooter element descendants, and no
address element descendants.HTMLElement.The address element represents the
contact information for the section it applies to. If it applies to the
body element, then it instead applies to the document as a
whole.
For example, a page at the W3C Web site related to HTML might include the following contact information:
<ADDRESS> <A href="../People/Raggett/">Dave Raggett</A>, <A href="../People/Arnaud/">Arnaud Le Hors</A>, contact persons for the <A href="Activity">W3C HTML Activity</A> </ADDRESS>
The address element must not be used to represent
arbitrary addresses (e.g. postal addresses), unless those addresses
are contact information for the section. (The p element
is the appropriate element for marking up such addresses.)
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
with other information in a footer element.
To determine the contact information for a sectioning
content element (such as a document's body
element, which would give the contact information for the page), UAs
must collect all the address elements that apply to that sectioning
content element and its ancestor sectioning
content elements. The contact information is the collection
of all the information given by those elements.
Contact information for one sectioning
content element, e.g. an aside element, does
not apply to its ancestor elements, e.g. the page's
body.
The h1–h6 elements and the
header element are headings.
The first element of heading content in an element of sectioning content represents the header for that section. Subsequent headers of equal or higher rank start new (implied) sections, headers of lower rank start implied subsections that are part of the previous one. In both cases, the element represents the header 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 headers inside these elements do not
contribute to the outlines of their ancestors.
For the following fragment:
<body> <h1>Foo</h1> <h2>Bar</h2> <blockquote> <h3>Bla</h3> </blockquote> <p>Baz</p> <h2>Quux</h2> <section> <h3>Thud</h3> </section> <p>Grunt</p> </body>
...the structure would be:
body section, containing the "Grunt" paragraph)
section section)
Notice how the section ends the earlier implicit
section so that a later paragraph ("Grunt") is back at the top
level.
Sections may contain headers 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 heading in one element of sectioning content.
For example, the following is correct:
<body> <h4>Apples</h4> <p>Apples are fruit.</p> <section> <h2>Taste</h2> <p>They taste lovely.</p> <h6>Sweet</h6> <p>Red apples are sweeter than green ones.</p> <h1>Color</h1> <p>Apples come in various colors.</p> </section> </body>
However, the same document would be more clearly expressed as:
<body> <h1>Apples</h1> <p>Apples are fruit.</p> <section> <h2>Taste</h2> <p>They taste lovely.</p> <section> <h3>Sweet</h3> <p>Red apples are sweeter than green ones.</p> </section> </section> <section> <h2>Color</h2> <p>Apples come in various colors.</p> </section> </body>
Both of the documents above are semantically identical and would produce the same outline in compliant user agents.
This 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.)
The following markup fragment:
<body> <h1>A</h1> <p>B</p> <h2>C</h2> <p>D</p> <h2>E</h2> <p>F</p> </body>
...results in the following outline being created for the
body node (and thus the entire document):
Section created for body node.
Associated with heading "A".
Also associated with paragraph "B".
Nested sections:
The algorithm that must be followed during a walk of a DOM subtree rooted at a sectioning content element or a sectioning root element to determine that element's outline is as follows:
Let current outlinee be null. (It holds the element whose outline is being created.)
Let current section be null. (It holds a pointer to a section, so that elements in the DOM can all be associated with a section.)
Create a stack to hold elements, which is used to handle nesting. Initialize this stack to empty.
As you walk over the DOM in tree order, trigger the first relevant step below for each element as you enter and exit it.
The element being exited is a heading content element.
Pop that element from the stack.
Do nothing.
If current outlinee is not null, push current outlinee onto the stack.
Let current outlinee be the element that is being entered.
Let current section be a newly created section for the current outlinee element.
Let there be a new outline for the new current outlinee, initialized with just the new current section as the only section in the outline.
Pop the top element from the stack, and let the current outlinee be that element.
Let current section be the last section in the outline of the current outlinee element.
Append the outline of the sectioning content element being exited to the current section. (This does not change which section is the last section in the outline.)
Run these steps:
Pop the top element from the stack, and let the current outlinee be that element.
Let current section be the last section in the outline of the current outlinee element.
Finding the deepest child: If current section has no child sections, stop these steps.
Let current section be the last child section of the current current section.
Go back to the substep labeled finding the deepest child.
The current outlinee is the element being exited.
Let current section be the first section in the outline of the current outlinee element.
Skip to the next step in the overall set of steps. (The walk is over.)
Do nothing.
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.)
Recall that h1 has the
highest rank, and h6 has the lowest
rank.
Do nothing.
In addition, whenever you exit a node, after doing the steps above, if current section is not null, associate the node with the section current section.
If the current outlinee is null, then there was no sectioning content element or sectioning root element in the DOM. There is no outline. Abort these steps.
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 header in the body is to be found.
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]
function (root, enter, exit) {
var node = root;
start: while (node) {
enter(node);
if (node.firstChild) {
node = node.firstChild;
continue start;
}
while (node) {
exit(node);
if (node.nextSibling) {
node = node.nextSibling;
continue start;
}
if (node == root)
node = null;
else
node = node.parentNode;
}
}
}
Given the outline of a document, but ignoring any
sections created for nav and aside
elements, and any of their descendants, if the only root of the tree
is the body element's section, and it has only a single
subsection which is created by an article element, then
the heading of the body element should be assumed to be
a site-wide heading, and the heading of the article
element should be assumed to be the page's heading.
If a page starts with a heading that is common to the whole site,
the document must be authored such that, in the document's
outline, ignoring any sections created for
nav and aside elements and any of their
descendants, the tree has only one root section, the body
element's section, its heading is the site-wide heading,
the body element has just one subsection, that
subsection is created by an article element, and that
article's heading is the page heading.
If a page does not contain a site-wide heading, then the page
must be authored such that, in the document's outline,
ignoring any sections created for nav and
aside elements and any of their descendants, either
the body element has no subsections, or it has more
than one subsection, or it has a single subsection but that
subsection is not created by an article element, or
there is more than one section
at the root of the outline.
Conceptually, a site is thus a document with many articles — when those articles are split into many pages, the heading of the original single page becomes the heading of the site, repeated on every page.
p elementHTMLElement.The p element represents a
paragraph.
The following examples are conforming HTML fragments:
<p>The little kitten gently seated himself on a piece of carpet. Later in his life, this would be referred to as the time the cat sat on the mat.</p>
<fieldset> <legend>Personal information</legend> <p> <label>Name: <input name="n"></label> <label><input name="anon" type="checkbox"> Hide from other users</label> </p> <p><label>Address: <textarea name="a"></textarea></label></p> </fieldset>
<p>There was once an example from Femley,<br> Whose markup was of dubious quality.<br> The validator complained,<br> So the author was pained,<br> To move the error from the markup to the rhyming.</p>
The p element should not be used when a more
specific element is more appropriate.
The following example is technically correct:
<section> <!-- ... --> <p>Last modified: 2001-04-23</p> <p>Author: fred@example.com</p> </section>
However, it would be better marked-up as:
<section> <!-- ... --> <footer>Last modified: 2001-04-23</footer> <address>Author: fred@example.com</address> </section>
Or:
<section> <!-- ... --> <footer> <p>Last modified: 2001-04-23</p> <address>Author: fred@example.com</address> </footer> </section>
hr elementHTMLElement.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.
br elementHTMLElement.The br element represents a line
break.
br elements must be empty. Any content inside
br elements must not be considered part of the
surrounding text.
br elements must be used only for line breaks that
are actually part of the content, as in poems or addresses.
The following example is correct usage of the br
element:
<p>P. Sherman<br> 42 Wallaby Way<br> Sydney</p>
br elements must not be used for separating thematic
groups in a paragraph.
The following examples are non-conforming, as they abuse the
br element:
<p><a ...>34 comments.</a><br> <a ...>Add a comment.<a></p>
<p>Name: <input name="name"><br> Address: <input name="address"></p>
Here are alternatives to the above, which are correct:
<p><a ...>34 comments.</a></p> <p><a ...>Add a comment.<a></p>
<p>Name: <input name="name"></p> <p>Address: <input name="address"></p>
If a paragraph consists of nothing but a single
br element, it represents a placeholder blank line
(e.g. as in a template). Such blank lines must not be used for
presentation purposes.
pre elementHTMLElement.The pre element represents a block of
preformatted text, in which structure is represented by typographic
conventions rather than by elements.
In the HTML
serialization, a leading newline character
immediately following the pre element start tag is
stripped.
Some examples of cases where the pre element could
be used:
To represent a block of computer code, the pre
element can be used with a code element; to represent a
block of computer output the pre element can be used
with a samp element. Similarly, the kbd
element can be used within a pre element to indicate
text that the user is to enter.
In the following snippet, a sample of computer code is presented.
<p>This is the <code>Panel</code> constructor:</p>
<pre><code>function Panel(element, canClose, closeHandler) {
this.element = element;
this.canClose = canClose;
this.closeHandler = function () { if (closeHandler) closeHandler() };
}</code></pre>
In the following snippet, samp and kbd
elements are mixed in the contents of a pre element to
show a session of Zork I.
<pre><samp>You are in an open field west of a big white house with a boarded front door. There is a small mailbox here. ></samp> <kbd>open mailbox</kbd> <samp>Opening the mailbox reveals: A leaflet. ></samp></pre>
The following shows a contemporary poem that uses the
pre element to preserve its unusual formatting, which
forms an intrinsic part of the poem itself.
<pre> maxling
it is with a heart
heavy
that i admit loss of a feline
so loved
a friend lost to the
unknown
(night)
~cdr 11dec07</pre>
dialog elementdt element followed by
one dd element.HTMLElement.The dialog element represents a
conversation, meeting minutes, a chat transcript, a dialog in a
screenplay, an instant message log, or some other construct in which
different players take turns in discourse.
Each part of the conversation must have an explicit talker (or
speaker) given by a dt element, and a discourse (or
quote) given by a dd element.
This example demonstrates this using an extract from Abbot and Costello's famous sketch, Who's on first:
<dialog> <dt> Costello <dd> Look, you gotta first baseman? <dt> Abbott <dd> Certainly. <dt> Costello <dd> Who's playing first? <dt> Abbott <dd> That's right. <dt> Costello <dd> When you pay off the first baseman every month, who gets the money? <dt> Abbott <dd> Every dollar of it. </dialog>
Text in a dt element in a
dialog element is implicitly the source of the text
given in the following dd element, and the contents of
the dd element are implicitly a quote from that
speaker. There is thus no need to include cite,
q, or blockquote elements in this
markup. Indeed, a q element inside a dd
element in a conversation would actually imply the people talking
were themselves quoting another work. See the cite,
q, and blockquote elements for other ways
to cite or quote.
blockquote elementciteinterface HTMLQuoteElement : HTMLElement {
attribute DOMString cite;
};
The HTMLQuoteElement interface is
also used by the q element.
The blockquote element represents a
section that is quoted from another source.
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.
The cite DOM
attribute must reflect the element's cite content attribute.
The best way to represent a conversation is not with
the cite and blockquote elements, but with
the dialog element.
This next example shows the use of cite alongside
blockquote:
<p>His next piece was the aptly named <cite>Sonnet 130</cite>:</p> <blockquote cite="http://quotes.example.org/s/sonnet130.html"> <p>My mistress' eyes are nothing like the sun,<br> Coral is far more red, than her lips red,<br> ...
ol elementli elements.reversedstartinterface HTMLOListElement : HTMLElement {
attribute boolean reversed;
attribute long start;
};
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 DOM
attribute must reflect the value of the reversed content attribute.
The start DOM
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>
ul elementli elements.HTMLElement.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>
li elementol elements.ul elements.menu elements.ol element: valueinterface HTMLLIElement : HTMLElement {
attribute long value;
};
The li element represents a list
item. If its parent element is an ol, ul,
or menu element, then the element is an item of the
parent element's list, as defined for those elements. Otherwise, the
list item has no defined list-related relationship to any other
li element.
The value
attribute, if present, must be a valid integer giving
the ordinal value of the list item.
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 DOM
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 legend.
<figure> <legend>The top 10 movies of all time</legend> <ol> <li value="10"><cite>Josie and the Pussycats</cite>, 2001</li> <li value="9"><cite lang="sh">Црна мачка, бели мачор</cite>, 1998</li> <li value="8"><cite>A Bug's Life</cite>, 1998</li> <li value="7"><cite>Toy Story</cite>, 1995</li> <li value="6"><cite>Monsters, Inc</cite>, 2001</li> <li value="5"><cite>Cars</cite>, 2006</li> <li value="4"><cite>Toy Story 2</cite>, 1999</li> <li value="3"><cite>Finding Nemo</cite>, 2003</li> <li value="2"><cite>The Incredibles</cite>, 2004</li> <li value="1"><cite>Ratatouille</cite>, 2007</li> </ol> </figure>
The markup could also be written as follows, using the reversed attribute on the
ol element:
<figure> <legend>The top 10 movies of all time</legend> <ol reversed> <li><cite>Josie and the Pussycats</cite>, 2001</li> <li><cite lang="sh">Црна мачка, бели мачор</cite>, 1998</li> <li><cite>A Bug's Life</cite>, 1998</li> <li><cite>Toy Story</cite>, 1995</li> <li><cite>Monsters, Inc</cite>, 2001</li> <li><cite>Cars</cite>, 2006</li> <li><cite>Toy Story 2</cite>, 1999</li> <li><cite>Finding Nemo</cite>, 2003</li> <li><cite>The Incredibles</cite>, 2004</li> <li><cite>Ratatouille</cite>, 2007</li> </ol> </figure>
If the li element is the child of a
menu element and itself has a child that defines a
command, then the
li element will match the :enabled and :disabled pseudo-classes in the
same way as the first such child element does.
dl elementdt elements followed by one or more dd
elements.HTMLElement.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).
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 is empty, it contains no groups.
If a dl element contains non-whitespace text nodes, or elements other than dt and
dd, then those elements or text
nodes do not form part of any groups in that
dl.
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").
<dl> <dt> Last modified time </dt> <dd> 2004-12-23T23:33Z </dd> <dt> Recommended update interval </dt> <dd> 60s </dd> <dt> Authors </dt> <dt> Editors </dt> <dd> Robert Rothman </dd> <dd> Daniel Jackson </dd> </dl>
The following example shows the dl element used to
give a set of instructions. The order of the instructions here is
important (in the other examples, the order of the blocks was not
important).
<p>Determine the victory points as follows (use the first matching case):</p> <dl> <dt> If you have exactly five gold coins </dt> <dd> You get five victory points </dd> <dt> If you have one or more gold coins, and you have one or more silver coins </dt> <dd> You get two victory points </dd> <dt> If you have one or more silver coins </dt> <dd> You get one victory point </dd> <dt> Otherwise </dt> <dd> You get no victory points </dd> </dl>
The following snippet shows a dl element being used
as a glossary. Note the use of dfn to indicate the
word being defined.
<dl> <dt><dfn>Apartment</dfn>, n.</dt> <dd>An execution context grouping one or more threads with one or more COM objects.</dd> <dt><dfn>Flat</dfn>, n.</dt> <dd>A deflated tire.</dd> <dt><dfn>Home</dfn>, n.</dt> <dd>The user's login directory.</dd> </dl>
The dl element is inappropriate for
marking up dialogue, since dialogue is ordered (each speaker/line
pair comes after the next). For an example of how to mark up
dialogue, see the dialog element.
dt elementdd or dt elements inside dl elements.dd element inside a dialog element.HTMLElement.The dt element represents the term, or
name, part of a term-description group in a description list
(dl element), and the talker, or speaker, part of a
talker-discourse pair in a conversation (dialog
element).
The dt element itself, when used in a
dl element, does not indicate that its contents are a
term being defined, but this can be indicated using the
dfn element.
If the dt element is the child of a
dialog element, and it further contains a
time element, then that time element
represents a timestamp for when the associated discourse
(dd element) was said, and is not part of the name of
the talker.
The following extract shows how an IM conversation log could be marked up.
<dialog> <dt> <time>14:22</time> egof <dd> I'm not that nerdy, I've only seen 30% of the star trek episodes <dt> <time>14:23</time> kaj <dd> if you know what percentage of the star trek episodes you have seen, you are inarguably nerdy <dt> <time>14:23</time> egof <dd> it's unarguably <dt> <time>14:24</time> kaj <dd> you are not helping your case </dialog>
dd elementdt or dd elements inside dl elements.dt element inside a dialog element.HTMLElement.The dd element represents the
description, definition, or value, part of a term-description group
in a description list (dl element), and the discourse,
or quote, part in a conversation (dialog element).
A dl can be used to define a vocabulary list, like
in a dictionary. In the following example, each entry, given by a
dt with a dfn, has several
dds, showing the various parts of the definition.
<dl> <dt><dfn>happiness</dfn></dt> <dd class="pronunciation">/'hæ p. nes/</dd> <dd class="part-of-speech"><i><abbr>n.</abbr></i></dd> <dd>The state of being happy.</dd> <dd>Good fortune; success. <q>Oh <b>happiness</b>! It worked!</q></dd> <dt><dfn>rejoice</dfn></dt> <dd class="pronunciation">/ri jois'/</dd> <dd><i class="part-of-speech"><abbr>v.intr.</abbr></i> To be delighted oneself.</dd> <dd><i class="part-of-speech"><abbr>v.tr.</abbr></i> To cause one to be delighted.</dd> </dl>
This specification does not define any markup
specifically for marking up lists of keywords that apply to a group
of pages (also known as tag clouds). In general, authors are
encouraged to either mark up such lists using ul
elements with explicit inline counts that are then hidden and turned
into a presentational effect using a style sheet, or to use SVG.
Here, three tags are included in a short tag cloud:
<style>
@media screen, print, handheld, tv {
/* should be ignored by non-visual browsers */
.tag-cloud > li > span { display: none; }
.tag-cloud > li { display: inline; }
.tag-cloud-1 { font-size: 0.7em; }
.tag-cloud-2 { font-size: 0.9em; }
.tag-cloud-3 { font-size: 1.1em; }
.tag-cloud-4 { font-size: 1.3em; }
.tag-cloud-5 { font-size: 1.5em; }
}
</style>
...
<ul class="tag-cloud">
<li class="tag-cloud-4"><a title="28 instances" href="/t/apple">apple</a> <span>(popular)</span>
<li class="tag-cloud-2"><a title="6 instances" href="/t/kiwi">kiwi</a> <span>(rare)</span>
<li class="tag-cloud-5"><a title="41 instances" href="/t/pear">pear</a> <span>(very popular)</span>
</ul>
The actual frequency of each tag is given using the title attribute. A CSS style sheet is
provided to convert the markup into a cloud of differently-sized
words, but for user agents that do not support CSS or are not
visual, the markup contains annotations like "(popular)" or
"(rare)" to categorise the various tags by frequency, thus enabling
all users to benefit from the information.
The ul element is used (rather than
ol) because the order is not particular important:
while the list is in fact ordered alphabetically, it would convey
the same information if ordered by, say, the length of the tag.
The tag rel-keyword is not used
on these a elements because they do not represent tags
that apply to the page itself; they are just part of an index
listing the tags themselves.