html
elementhead
element followed by a body
element.manifest
interface HTMLHtmlElement : HTMLElement {};
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 non-empty URL potentially surrounded by
spaces.
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.
The window.applicationCache
IDL
attribute provides scripted access to the offline application
cache mechanism.
The html
element in the following example declares
that the document's language is English.
<!DOCTYPE html> <html lang="en"> <head> <title>Swapping Songs</title> </head> <body> <h1>Swapping Songs</h1> <p>Tonight I swapped some of the songs I wrote with some friends, who gave me some of the songs they wrote. I love sharing my music.</p> </body> </html>
head
elementhtml
element.iframe
srcdoc
document or if title information is available from a higher-level protocol: Zero or more elements of metadata content.title
element.interface HTMLHeadElement : HTMLElement {};
The head
element represents a
collection of metadata for the Document
.
The collection of metadata in a head
element can be
large or small. Here is an example of a very short one:
<!doctype html> <html> <head> <title>A document with a short head</title> </head> <body> ...
Here is an example of a longer one:
<!DOCTYPE HTML> <HTML> <HEAD> <META CHARSET="UTF-8"> <BASE HREF="http://www.example.com/"> <TITLE>An application with a long head</TITLE> <LINK REL="STYLESHEET" HREF="default.css"> <LINK REL="STYLESHEET ALTERNATE" HREF="big.css" TITLE="Big Text"> <SCRIPT SRC="support.js"></SCRIPT> <META NAME="APPLICATION-NAME" CONTENT="Long headed application"> </HEAD> <BODY> ...
The title
element is a required child
in most situations, but when a higher-level protocol provides title
information, e.g. in the Subject line of an e-mail when HTML is used
as an e-mail authoring format, the title
element can be
omitted.
title
elementhead
element containing no other title
elements.interface HTMLTitleElement : HTMLElement { attribute DOMString text; };
The title
element represents the
document's title or name. Authors should use titles that identify
their documents even when they are used out of context, for example
in a user's history or bookmarks, or in search results. The
document's title is often different from its first heading, since the
first heading does not have to stand alone when taken out of
context.
There must be no more than one title
element per
document.
text
[ = value ]Returns the contents of the element, ignoring child nodes that aren't text nodes.
Can be set, to replace the element's children with the given value.
The IDL attribute text
must return a
concatenation of the contents of all the text nodes that are direct children of the
title
element (ignoring any other nodes such as
comments or elements), in tree order. On setting, it must act the
same way as the textContent
IDL attribute.
Here are some examples of appropriate titles, contrasted with the top-level headings that might be used on those same pages.
<title>Introduction to The Mating Rituals of Bees</title> ... <h1>Introduction</h1> <p>This companion guide to the highly successful <cite>Introduction to Medieval Bee-Keeping</cite> book is...
The next page might be a part of the same site. Note how the title describes the subject matter unambiguously, while the first heading assumes the reader knows what the context is and therefore won't wonder if the dances are Salsa or Waltz:
<title>Dances used during bee mating rituals</title> ... <h1>The Dances</h1>
The string to use as the document's title is given by the document.title
IDL attribute.
User agents should use the document's title when referring to the
document in their user interface. When the contents of a
title
element are used in this way, the
directionality of that title
element should be
used to set the directionality of the document's title in the user
interface.
base
elementhead
element containing no other base
elements.href
target
interface 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 potentially
surrounded by spaces.
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).
The target
attribute, if specified, must contain a valid browsing context
name or keyword, which specifies which browsing
context is to be used as the default when hyperlinks and forms in the Document
cause navigation.
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
IDL
attribute, on getting, must return the page's document base
URL, and on setting, it must set the href
content attribute to the given
new value.
The target
IDL
attribute must reflect the content attribute of the
same name.
In this example, a base
element is used to set the
document base URL:
<!DOCTYPE html> <html> <head> <title>This is an example for the <base> element</title> <base href="http://www.example.com/news/index.html"> </head> <body> <p>Visit the <a href="archives.html">archives</a>.</p> </body> </html>
The link in the above example would be a link to "http://www.example.com/news/archives.html
".
link
elementnoscript
element that is a child of a head
element.href
rel
media
hreflang
type
sizes
title
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;
[PutForwards=value] readonly attribute DOMSettableTokenList sizes;
};
HTMLLinkElement implements LinkStyle;
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 non-empty URL potentially
surrounded by spaces. If the href
attribute is absent, then the
element does not define a link.
A link
element must have rel
attribute.
The types of link indicated (the relationships) are given by the
value of the rel
attribute, which, if present, must have a value that is a set
of space-separated tokens. The allowed
keywords and their meanings are defined in a later
section. If the rel
attribute is absent, has no
keywords, or if none of the keywords used are allowed according to
the definitions in this specification, then the element does not
create any links.
Two categories of links can be created using the
link
element: Links to external resources and hyperlinks. The link
types section defines whether a particular link type is an
external resource or a hyperlink. One link
element can
create multiple links (of which some might be external resource
links and some might be hyperlinks); exactly which and how many
links are created depends on the keywords given in the rel
attribute. User agents must process
the links on a per-link basis, not a per-element basis.
Each link created for a link
element is
handled separately. For instance, if there are two link
elements with rel="stylesheet"
, they each
count as a separate external resource, and each is affected by its
own attributes independently. Similarly, if a single
link
element has a rel
attribute with the value next stylesheet
, it creates both a
hyperlink (for the next
keyword) and an external resource link (for the stylesheet
keyword), and they are
affected by other attributes (such as media
or title
) differently.
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 run the following steps:
If the href
attribute's
value is the empty string, then abort these steps.
Resolve the
URL given by the href
attribute, relative to the
element.
If the previous step fails, then abort these steps.
Fetch the resulting absolute URL.
User agents may opt to only try to obtain such resources when they are needed, instead of pro-actively fetching all the external resources that are not applied.
The semantics of the protocol used (e.g. HTTP) must be followed when fetching external resources. (For example, redirects will be followed and 404 responses will cause the external resource to not be applied.)
Once the attempts to obtain the resource and its critical
subresources are complete, the user agent must, if the loads
were successful, queue a task to fire a simple
event named load
at the
link
element, or, if the resource or one of its
critical subresources failed to completely load for any
reason (e.g. DNS error, HTTP 404 response, a connection being
prematurely closed, unsupported Content-Type), queue a
task to fire a simple event named error
at the link
element. Non-network errors in processing the resource or its
subresources (e.g. CSS parse errors, PNG decoding errors) are not
failures for the purposes of this paragraph.
The task source for these tasks is the DOM manipulation task source.
The element must delay the load event of the element's document until all the attempts to obtain the resource and its critical subresources are complete. (Resources that the user agent has not yet attempted to obtain, e.g. because it is waiting for the resource to be needed, do not delay the load event.)
Interactive user agents may provide users with a
means to follow the
hyperlinks created using the link
element,
somewhere within their user interface. The exact interface is not
defined by this specification, but it could include the following
information (obtained from the element's attributes, again as
defined below), in some form or another (possibly simplified), for
each hyperlink created with each link
element in the
document:
rel
attribute)title
attribute).href
attribute).hreflang
attribute).media
attribute).User agents could also include other information, such as the
type of the resource (as given by the type
attribute).
Hyperlinks created with the link
element and its rel
attribute
apply to the whole page. This contrasts with the rel
attribute of a
and area
elements, which indicates the type of a link
whose context is given by the link's location within the
document.
The media
attribute says which media the resource applies to. The value must
be a valid media query.
If the link is a hyperlink then the media
attribute is purely advisory,
and describes for which media the document in question was
designed.
However, if the link is an external resource link,
then the media
attribute is
prescriptive. The user agent must apply the external resource when
the media
attribute's value
matches the environment and the other relevant
conditions apply, and must not apply it 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 a
and area
elements.
The type
attribute
gives the MIME type of the linked resource. It is
purely advisory. The value must be a valid MIME
type.
For external resource
links, the type
attribute
is used as a hint to user agents so that they can avoid fetching
resources they do not support. If the attribute
is present, then the user agent must assume that the resource is of
the given type (even if that is not a valid MIME type,
e.g. the empty string). If the attribute is omitted, but the
external resource link type has a default type defined, then the
user agent must assume that the resource is of that type. If the UA
does not support the given MIME type for the given link
relationship, then the UA should not obtain the resource; if the UA
does support the given MIME type for the given link
relationship, then the UA should obtain the resource at the
appropriate time as specified for the external resource
link's particular type. If the attribute is omitted, and the
external resource link type does not have a default type defined,
but the user agent would obtain the resource if the type
was known and supported, then the user agent should obtain the resource under the
assumption that it will be supported.
User agents must not consider the type
attribute authoritative —
upon fetching the resource, user agents must not use the type
attribute to determine its actual
type. Only the actual type (as defined in the next paragraph) is
used to determine whether to apply the resource, not the
aforementioned assumed type.
If the external resource link type defines rules for processing the resource's Content-Type metadata, then those rules apply. Otherwise, if the resource is expected to be an image, user agents may apply the image sniffing rules, with the official type being the type determined from the resource's Content-Type metadata, and use the resulting sniffed type of the resource as if it was the actual type. Otherwise, if neither of these conditions apply or if the user agent opts not to apply the image sniffing rules, then the user agent must use the resource's Content-Type metadata to determine the type of the resource. If there is no type metadata, but the external resource link type has a default type defined, then the user agent must assume that the resource is of that type.
The stylesheet
link type defines rules for processing the resource's Content-Type metadata.
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 of the two files was returned without a
Content-Type metadata, or with a syntactically
incorrect type like Content-Type: "null"
, then the default type
for stylesheet
links would kick
in. Since that default type is text/css
, the
style sheet would nonetheless be applied.
The title
attribute gives the title of the link. With one exception, it is
purely advisory. The value is text. The exception is for style sheet
links, where the title
attribute defines alternative style sheet sets.
The title
attribute on link
elements differs from the global
title
attribute of most other
elements in that a link without a title does not inherit the title
of the parent element: it merely has no title.
The sizes
attribute is used
with the icon
link type. The attribute
must not be specified on link
elements that do not have
a rel
attribute that specifies
the icon
keyword.
HTTP Link:
headers, if supported, must be
assumed to come before any links in the document, in the order that
they were given in the HTTP entity header. (URLs in these headers
are to be processed and resolved according to the rules given in the
relevant specification; the rules of this specification
don't apply.) [HTTP] [WEBLINK]
The IDL attributes href
, rel
, media
, hreflang
, and type
, and sizes
each must
reflect the respective content attributes of the same
name.
The IDL attribute relList
must reflect the rel
content attribute.
The IDL attribute disabled
only applies
to style sheet links. When the link
element defines a
style sheet link, then the disabled
attribute behaves as
defined for the alternative
style sheets DOM. For all other link
elements it
always return false and does nothing on setting.
The LinkStyle
interface is also implemented by
this element; the styling processing model defines
how. [CSSOM]
Here, a set of link
elements provide some style
sheets:
<!-- a persistent style sheet --> <link rel="stylesheet" href="default.css"> <!-- the preferred alternate style sheet --> <link rel="stylesheet" href="green.css" title="Green styles"> <!-- some alternate style sheets --> <link rel="alternate stylesheet" href="contrast.css" title="High contrast"> <link rel="alternate stylesheet" href="big.css" title="Big fonts"> <link rel="alternate stylesheet" href="wide.css" title="Wide screen">
The following example shows how you can specify versions of the page that use alternative formats, are aimed at other languages, and that are intended for other media:
<link rel=alternate href="/en/html" hreflang=en type=text/html title="English HTML"> <link rel=alternate href="/fr/html" hreflang=fr type=text/html title="French HTML"> <link rel=alternate href="/en/html/print" hreflang=en type=text/html media=print title="English HTML (for printing)"> <link rel=alternate href="/fr/html/print" hreflang=fr type=text/html media=print title="French HTML (for printing)"> <link rel=alternate href="/en/pdf" hreflang=en type=application/pdf title="English PDF"> <link rel=alternate href="/fr/pdf" hreflang=fr type=application/pdf title="French PDF">
meta
elementcharset
attribute is present, or if the element's http-equiv
attribute is in the Encoding declaration state: in a head
element.http-equiv
attribute is present but not in the Encoding declaration state: in a head
element.http-equiv
attribute is present but 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.name
http-equiv
content
charset
interface HTMLMetaElement : HTMLElement { attribute DOMString name; attribute DOMString httpEquiv; attribute DOMString content; };
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 a character encoding declaration. If
the attribute is present in an XML
document, its value must be an ASCII
case-insensitive match for the string "UTF-8
" (and the document is therefore forced to use
UTF-8 as its encoding).
The charset
attribute on the meta
element has no effect in XML
documents, and is only allowed in order to facilitate migration to
and from XHTML.
There must not be more than one meta
element with a
charset
attribute per
document.
The content
attribute gives the value of the document metadata or pragma
directive when the element is used for those purposes. The allowed
values depend on the exact context, as described in subsequent
sections of this specification.
If a meta
element has a name
attribute, it sets
document metadata. Document metadata is expressed in terms of
name/value pairs, the name
attribute on the meta
element giving the name, and the
content
attribute on the same
element giving the value. The name specifies what aspect of metadata
is being set; valid names and the meaning of their values are
described in the following sections. If a meta
element
has no content
attribute,
then the value part of the metadata name/value pair is the empty
string.
The name
and content
IDL attributes
must reflect the respective content attributes of the
same name. The IDL attribute httpEquiv
must
reflect the content attribute http-equiv
.
This specification defines a few names for the name
attribute of the
meta
element.
Names are case-insensitive, and must be compared in an ASCII case-insensitive manner.
application-name
The value must be a short free-form string giving the name
of the Web application that the page represents. If the page is not
a Web application, the application-name
metadata name
must not be used. There must not be more than one meta
element with its name
attribute
set to the value application-name
per
document. User agents may use the application
name in UI in preference to the page's title
, since
the title might include status messages and the like relevant to
the status of the page at a particular moment in time instead of
just being the name of the application.
author
The value must be a free-form string giving the name of one of the page's authors.
description
The value must be a free-form string that describes the
page. The value must be appropriate for use in a directory of
pages, e.g. in a search engine. There must not be more than one
meta
element with its name
attribute set to the value description
per document.
generator
The value must be a free-form string that identifies one of the software packages used to generate the document. This value must not be used on hand-authored pages.
Here is what a tool called "Frontweaver" could include in its
output, in the page's head
element, to identify
itself as the tool used to generate the page:
<meta name=generator content="Frontweaver 8.2">
keywords
The value must be a set of comma-separated tokens, each of which is a keyword relevant to the page.
This page about typefaces on British motorways uses a
meta
element to specify some keywords that users
might use to look for the page:
<!DOCTYPE HTML> <html> <head> <title>Typefaces on UK motorways</title> <meta name="keywords" content="british,type face,font,fonts,highway,highways"> </head> <body> ...
Many search engines do not consider such keywords, because this feature has historically been used unreliably and even misleadingly as a way to spam search engine results in a way that is not helpful for users.
To obtain the list of keywords that the author has specified as applicable to the page, the user agent must run the following steps:
Let keywords be an empty list.
For each meta
element with a name
attribute and a content
attribute and whose
name
attribute's value is
keywords
, run the following
substeps:
Split the value
of the element's content
attribute on commas.
Add the resulting tokens, if any, to keywords.
Remove any duplicates from keywords.
Return keywords. This is the list of keywords that the author has specified as applicable to the page.
User agents should not use this information when there is insufficient confidence in the reliability of the value.
For instance, it would be reasonable for a content management system to use the keyword information of pages within the system to populate the index of a site-specific search engine, but a large-scale content aggregator that used this information would likely find that certain users would try to game its ranking mechanism through the use of inappropriate keywords.
Extensions to the predefined set of metadata names may be registered in the WHATWG Wiki MetaExtensions page. [WHATWGWIKI]
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 non-normative 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. Anyone may remove synonyms that are not used in practice; only names that need to be processed as synonyms for compatibility with legacy content are to be registered in this way.
One of the following:
If a metadata name is found to be redundant with existing values, it should be removed and listed as a synonym for the existing value.
If a metadata name is registered in the "proposed" state for a period of a month or more without being used or specified, then it may be removed from the registry.
If a metadata name is added with the "proposed" status and found to be redundant with existing values, it should be removed and listed as a synonym for the existing value. If a metadata name is added with the "proposed" status and found to be harmful, then it should be changed to "discontinued" status.
Anyone can change the status at any time, but should only do so in accordance with the definitions above.
Conformance checkers must use the information given on the WHATWG Wiki MetaExtensions page to establish if a value is allowed or not: values defined in this specification or marked as "proposed" or "ratified" must be accepted, whereas values marked as "discontinued" or not listed in either this specification or on the aforementioned page must be rejected as invalid. Conformance checkers may cache this information (e.g. for performance reasons or to avoid the use of unreliable network connectivity).
When an author uses a new metadata name not defined by either this specification or the Wiki page, conformance checkers should offer to add the value to the Wiki, with the details described above, with the "proposed" status.
Metadata names whose values are to be URLs must not be proposed or accepted. Links must
be represented using the link
element, not the
meta
element.
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 | Keyword | Notes |
---|---|---|
Content Language | content-language
| Non-conforming |
Encoding declaration | content-type
| |
Default style | default-style
| |
Refresh | refresh
| |
Cookie setter | set-cookie
| Non-conforming |
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:
http-equiv="content-language"
)
This feature is non-conforming. Authors are
encouraged to use the lang
attribute instead.
This pragma sets the pragma-set default language. Until the pragma is successfully processed, there is no pragma-set default language.
If another meta
element with an http-equiv
attribute in the
Content
Language state has already been successfully processed
(i.e. when it was inserted the user agent processed it and
reached the last step of this list of steps), then abort these
steps.
If the meta
element has no content
attribute, or if that
attribute's value is the empty string, then abort these
steps.
If the element's content
attribute contains a
U+002C COMMA character (,) then abort these steps.
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 not space characters.
Let the pragma-set default language be the string that resulted from the previous step.
This pragma is not exactly equivalent to the HTTP
Content-Language
header. [HTTP]
http-equiv="content-type"
)
The Encoding
declaration state is just an alternative form of setting
the charset
attribute: it is a
character encoding declaration. This state's user agent requirements are all handled
by the parsing section of the specification.
For meta
elements with an http-equiv
attribute 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.
A document must not contain both a meta
element
with an http-equiv
attribute in the Encoding declaration
state and a meta
element with the charset
attribute present.
The Encoding
declaration state may be used in HTML
documents, but elements with an http-equiv
attribute in that
state must not be used in XML documents.
http-equiv="default-style"
)
This pragma sets the name of the default alternative style sheet set.
http-equiv="refresh"
)
This pragma acts as timed redirect.
If another meta
element with an http-equiv
attribute in the
Refresh state
has already been successfully processed (i.e. when it was
inserted the user agent processed it and reached the last step of
this list of steps), then abort these steps.
If the meta
element has no content
attribute, or if that
attribute's value is the empty string, then abort these
steps.
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 (0) to U+0039 DIGIT NINE (9), 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 (0) to U+0039 DIGIT NINE (9) 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 a U+0055 LATIN CAPITAL LETTER U character (U) or a U+0075 LATIN SMALL LETTER U character (u), then advance position to the next character. Otherwise, jump to the last step.
If the character in input pointed to by position is a U+0052 LATIN CAPITAL LETTER R character (R) or a U+0072 LATIN SMALL LETTER R character (r), then advance position to the next character. Otherwise, jump to the last step.
If the character in input pointed to by position is s U+004C LATIN CAPITAL LETTER L character (L) or a U+006C LATIN SMALL LETTER L character (l), then advance position to the next character. Otherwise, jump to the last step.
If the character in input pointed to
by position is a U+003D EQUALS SIGN ("=
"), then advance position to
the next character. Otherwise, jump to the last step.
If the character in input pointed to by position is either a U+0027 APOSTROPHE character (') or U+0022 QUOTATION MARK character ("), then let quote be that character, and advance position to the next character. Otherwise, let quote be the empty string.
Let url be equal to the substring of input from the character at position to the end of the string.
If quote is not the empty string, and there is a character in url equal to quote, then truncate url at that character, so that it and all subsequent characters are removed.
Strip any trailing space characters from the end of url.
Strip any U+0009 CHARACTER TABULATION (tab), 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:
After the refresh has come due (as defined below), if the
user has not canceled the redirect and if the
meta
element's Document
's
browsing context did not have the sandboxed
automatic features browsing context flag set when the
Document
was created, navigate the
Document
's browsing context to url, with replacement enabled, and
with the Document
's browsing context
as the source browsing context.
For the purposes of the previous paragraph, a refresh is said to have come due as soon as the later of the following two conditions occurs:
meta
element was inserted into the
Document
, adjusted to take into account
user or user agent preferences.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 with an http-equiv
attribute in the
Refresh state,
the content
attribute must
have a value consisting either of:
URL
", followed by a U+003D
EQUALS SIGN character (=), followed by a valid URL
that does not start with a literal U+0027 APOSTROPHE (') or
U+0022 QUOTATION MARK (") character.In the former case, the integer represents a number of seconds before the page is to be reloaded; in the latter case the integer represents a number of seconds before the page is to be replaced by the page at the given URL.
A news organization's front page could include the following
markup in the page's head
element, to ensure that
the page automatically reloads from the server every five
minutes:
<meta http-equiv="Refresh" content="300">
A sequence of pages could be used as an automated slide show by making each page refresh to the next page in the sequence, using markup such as the following:
<meta http-equiv="Refresh" content="20; URL=page4.html">
http-equiv="set-cookie"
)
This pragma sets an HTTP cookie. [COOKIES]
It is non-conforming. Real HTTP headers should be used instead.
If the meta
element has no content
attribute, or if that
attribute's value is the empty string, then abort these
steps.
Act as if receiving a set-cookie-string for
the document's address via a "non-HTTP" API,
consisting of the value of the element's content
attribute encoded as
UTF-8. [COOKIES] [RFC3629]
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. [WHATWGWIKI]
Such extensions must use a name that is identical to an HTTP header registered in the Permanent Message Header Field Registry, and must have behavior identical to that described for the HTTP header. [IANAPERMHEADERS]
Pragma directives corresponding to headers describing metadata, or not requiring specific user agent processing, must not be registered; instead, use metadata names. Pragma directives corresponding to headers that affect the HTTP processing model (e.g. caching) must not be registered, as they would result in HTTP-level behavior being different for user agents that implement HTML than for user agents that do not.
Anyone is free to edit the WHATWG Wiki PragmaExtensions page at any time to add a pragma directive satisfying these conditions. Such registrations must specify the following information:
The actual name being defined. The name must match a previously-registered HTTP name with the same requirements.
A short non-normative 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 is allowed or not: values defined in this specification or listed on the aforementioned page must be accepted, whereas values not listed in either this specification or on the aforementioned page must be rejected as invalid. Conformance checkers may cache this information (e.g. for performance reasons or to avoid the use of unreliable network connectivity).
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:
In addition, due to a number of restrictions on meta
elements, there can only be one meta
-based character
encoding declaration per document.
If an HTML document does not
start with a BOM, and if its encoding is not explicitly given by
Content-Type metadata, and the
document is not an iframe
srcdoc
document, 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 with an http-equiv
attribute in the
Encoding declaration
state.
If the document is an iframe
srcdoc
document, the
document must not have a character encoding
declaration. (In this case, the source is already decoded,
since it is part of the document that contained the
iframe
.)
If an HTML document contains
a meta
element with a charset
attribute or a
meta
element with an http-equiv
attribute in the
Encoding declaration
state, then the character encoding used must be an
ASCII-compatible character encoding.
Authors are encouraged to use UTF-8. Conformance checkers may advise authors against using legacy encodings. [RFC3629]
Authoring tools should default to using UTF-8 for newly-created documents. [RFC3629]
Encodings in which a series of bytes in the range 0x20 to 0x7E
can encode characters other than the corresponding characters in the
range U+0020 to U+007E represent a potential security vulnerability:
a user agent that does not support the encoding (or does not support
the label used to declare the encoding, or does not use the same
mechanism to detect the encoding of unlabelled content as another
user agent) might end up interpreting technically benign plain text
content as HTML tags and JavaScript. For example, this applies to
encodings in which the bytes corresponding to "<script>
" in ASCII can encode a different
string. Authors should not use such encodings, which are known to
include JIS_C6226-1983,
JIS_X0212-1990, HZ-GB-2312, JOHAB (Windows code
page 1361), encodings based on ISO-2022, and encodings based on EBCDIC. Furthermore, authors must not
use the CESU-8, UTF-7, BOCU-1 and SCSU encodings, which also fall
into this category, because these encodings were never intended for
use for Web content.
[RFC1345]
[RFC1842]
[RFC1468]
[RFC2237]
[RFC1554]
[RFC1922]
[RFC1557]
[CESU8]
[UTF7]
[BOCU1]
[SCSU]
Authors should not use UTF-32, as the encoding detection algorithms described in this specification intentionally do not distinguish it from UTF-16. [UNICODE]
Using non-UTF-8 encodings can have unexpected results on form submission and URL encodings, which use the document's character encoding by default.
In XHTML, the XML declaration should be used for inline character encoding information, if necessary.
In HTML, to declare that the character encoding is UTF-8, the
author could include the following markup near the top of the
document (in the head
element):
<meta charset="utf-8">
In XML, the XML declaration would be used instead, at the very top of the markup:
<?xml version="1.0" encoding="utf-8"?>
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, but must match requirements described in prose below.media
type
scoped
title
attribute has special semantics on this element.interface HTMLStyleElement : HTMLElement {
attribute boolean disabled;
attribute DOMString media;
attribute DOMString type;
attribute boolean scoped;
};
HTMLStyleElement implements LinkStyle;
The style
element allows authors to embed style
information in their documents. The style
element is
one of several inputs to the styling processing
model. The element does not represent content for the user.
The type
attribute gives the styling language. If the attribute is present,
its value must be a valid MIME type that designates a
styling language. The charset
parameter must
not be specified. The default value for the type
attribute, which is used if the
attribute is absent, is "text/css
". [RFC2318]
When examining types to determine if they support the language,
user agents must not ignore unknown MIME parameters — types
with unknown parameters must be assumed to be unsupported. The charset
parameter must be treated as an unknown
parameter for the purpose of comparing MIME
types here.
The media
attribute says which media the styles apply to. The value must be a
valid media query. The user agent
must apply the styles when the media
attribute's value
matches the environment and the other relevant
conditions apply, and must not apply them otherwise.
The styles might be further limited in scope,
e.g. in CSS with the use of @media
blocks. This specification does not override such further
restrictions or requirements.
The default, if the media
attribute is omitted, is
"all
", meaning that by default styles apply to
all media.
The scoped
attribute is a boolean attribute. If set, it indicates
that the styles are intended just for the subtree rooted at the
style
element's parent element, as opposed to the whole
Document
.
If the scoped
attribute is
present, then the user agent must apply the specified style
information only to the style
element's parent element
(if any), and that element's child nodes. Otherwise, the specified
styles must, if applied, be applied to the entire document.
For scoped CSS resources, the effect of @-rules must be scoped to
the scoped sheet and its subresources, even if the @-rule in
question would ordinarily apply to all style sheets that affect the
Document
. Any '@page' rules in scoped CSS resources
must be ignored.
For example, an '@font-face' rule defined in a scoped style sheet would only define the font for the purposes of font rules in the scoped section; style sheets outside the scoped section using the same font name would not end up using that embedded font.
The title
attribute on
style
elements defines alternative style sheet
sets. If the style
element has no title
attribute, then it has no
title; the title
attribute of
ancestors does not apply to the style
element. [CSSOM]
The title
attribute on style
elements, like the title
attribute on link
elements, differs from the global title
attribute in that a
style
block without a title does not inherit the title
of the parent element: it merely has no title.
The textContent
of a style
element must
match the style
production in the following
ABNF, the character set for which is Unicode. [ABNF]
style = no-c-start *( c-start no-c-end c-end no-c-start ) no-c-start = <any string that doesn't contain a substring that matches c-start > c-start = "<!--" no-c-end = <any string that doesn't contain a substring that matches c-end > c-end = "-->"
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 (as
opposed to XML), user agents must evaluate style
elements by passing the concatenation of the contents of all the
text nodes that are direct children
of the style
element (not any other nodes such as
comments or elements), in tree order, to the style
system. For XML-based styling languages, user agents must pass all
the child nodes of the style
element to the style
system.
All URLs found by the styling language's processor must be resolved, relative to the element (or as defined by the styling language), when the processor is invoked.
Once the attempts to obtain the style sheet's critical
subresources, if any, are complete, or, if the style sheet
has no critical subresources, once the style sheet has
been parsed and processed, the user agent must, if the loads were
successful or there were none, queue a task to
fire a simple event named load
at the style
element,
or, if one of the style sheet's critical subresources
failed to completely load for any reason (e.g. DNS error, HTTP 404
response, a connection being prematurely closed, unsupported
Content-Type), queue a task to fire a simple
event named error
at the
style
element. Non-network errors in processing the
style sheet or its subresources (e.g. CSS parse errors, PNG decoding
errors) are not failures for the purposes of this paragraph.
The task source for these tasks is the DOM manipulation task source.
The element must delay the load event of the element's document until all the attempts to obtain the style sheet's critical subresources, if any, are complete.
This specification does not specify a style system, but CSS is expected to be supported by most Web browsers. [CSS]
The media
, type
and scoped
IDL attributes
must reflect the respective content attributes of the
same name.
The disabled
IDL attribute behaves as defined for the alternative style sheets
DOM.
The LinkStyle
interface is also implemented by
this element; the styling processing model defines
how. [CSSOM]
The following document has its emphasis styled as bright red text rather than italics text, while leaving titles of works and Latin words in their default italics. It shows how using appropriate elements enables easier restyling of documents.
<!DOCTYPE html> <html lang="en-US"> <head> <title>My favorite book</title> <style> body { color: black; background: white; } em { font-style: normal; color: red; } </style> </head> <body> <p>My <em>favorite</em> book of all time has <em>got</em> to be <cite>A Cat's Life</cite>. It is a book by P. Rahmel that talks about the <i lang="la">Felis Catus</i> in modern human society.</p> </body> </html>
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 following properties: [CSSOM]
The style sheet 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.
For link
elements, the location must be the
result of resolving the
URL given by the element's href
content attribute, relative to
the element, or the empty string if that fails. For
style
elements, there is no location.
The media must be the same as the value of the element's
media
content attribute, or the empty string,
if the attribute is omitted.
The title must be the same as the value of the element's
title
content attribute, if the
attribute is present and has a non-empty value. If the attribute is
absent or its value is the empty string, then the style sheet does
not have a title (it is the empty string). The title is used for
defining alternative style sheet sets.
For link
elements, true if the link is an
alternative stylesheet. In all other cases, false.
The same object must be returned each time.
The disabled
IDL
attribute on link
and style
elements must
return false and do nothing on setting, if the sheet
attribute of their
LinkStyle
interface is null. Otherwise, it must return
the value of the StyleSheet
interface's disabled
attribute on
getting, and forward the new value to that same attribute on
setting.
The rules for handling alternative style sheets are defined in the CSS object model specification. [CSSOM]
Style sheets, whether added by a link
element, a
style
element, an <?xml-stylesheet>
PI,
an HTTP Link:
header, or some other
mechanism, have a style sheet ready flag, which is
initially unset.
When a style sheet is ready to be applied, its style sheet
ready flag must be set. If the style sheet referenced no
other resources (e.g. it was an internal style sheet given by a
style
element with no @import
rules), then the style rules must be synchronously made available to
script; otherwise, the style rules must only be made available to
script once the event loop reaches its "update the
rendering" step.
A style sheet in the context of the Document
of an
HTML parser or XML parser is said to be
a style sheet that is blocking scripts if the element was
created by that Document
's parser, and the element is
either a style
element or a link
element
that was an external resource link that
contributes to the styling processing model when the element
was created by the parser, and the element's style sheet was enabled
when the element was created by the parser, and the element's
style sheet ready flag is not yet set, and, the last
time the event loop reached step 1, the element was
in that Document
,
and the user agent hasn't given up on that particular style sheet
yet. A user agent may give up on a style sheet at any time.
A Document
has a style sheet that is blocking
scripts if there is either a style sheet that is
blocking scripts in the context of that
Document
, or if that Document
is in a
browsing context that has a parent browsing
context, and the active document of that
parent browsing context itself has a style sheet
that is blocking scripts.
A Document
has no style sheet that is blocking
scripts if it does not have a style sheet that is blocking scripts
as defined in the previous paragraph.