HTML

None.

As document's document element.

Wherever a subdocument fragment is allowed in a compound document.

A head element followed by a body element.

An html element's start tag can be omitted if the first thing inside the html element is not a comment.

An html element's end tag can be omitted if the html element is not immediately followed by a comment.

manifest — Application cache manifest

[Exposed=Window,
 HTMLConstructor]
interface HTMLHtmlElement : HTMLElement {};

The html element represents the root of an HTML document.

Authors are encouraged to specify a lang attribute on the root html element, giving the document's language. This aids speech synthesis tools to determine what pronunciations to use, translation tools to determine what rules to use, and so forth.

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 is part of the legacy "offline Web applications" feature, which is in the process of being removed from the Web platform. (This is a long process that takes many years.) Using the manifest attribute at this time is highly discouraged. Use service workers instead. [SW]

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

4.2 Document metadata

4.2.1 The `head` element

None.

As the first element in an html element.

If the document is an iframe srcdoc document or if title information is available from a higher-level protocol: Zero or more elements of metadata content, of which no more than one is a title element and no more than one is a base element.

Otherwise: One or more elements of metadata content, of which exactly one is a title element and no more than one is a base element.

A head element's start tag can be omitted if the element is empty, or if the first thing inside the head element is an element.

A head element's end tag can be omitted if the head element is not immediately followed by ASCII whitespace or a comment.

[Exposed=Window,
 HTMLConstructor]
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 lang=en>
 <head>
  <title>A document with a short head</title>
 </head>
 <body>
 ...

Here is an example of a longer one:

<!DOCTYPE HTML>
<HTML LANG="EN">
 <HEAD>
  <META CHARSET="UTF-8">
  <BASE HREF="https://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.

4.2.2 The `title` element

In a head element containing no other title elements.

Text that is not inter-element whitespace.

Neither tag is omissible.

[Exposed=Window,
 HTMLConstructor]
interface HTMLTitleElement : HTMLElement {
  [CEReactions] 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.

If it's reasonable for the Document to have no title, then the title element is probably not required. See the head element's content model for a description of when the element is required.

title . text [ = value ]

Returns the child text content of the element.

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

The IDL attribute text must return the child text content of the title element. 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.

4.2.3 The `base` element

In a head element containing no other base elements.

Nothing.

No end tag.

href — Document base URL

target — Default browsing context for hyperlink navigation and form submission

[Exposed=Window,
 HTMLConstructor]
interface HTMLBaseElement : HTMLElement {
  [CEReactions] attribute USVString href;
  [CEReactions] attribute DOMString target;
};

The base element allows authors to specify the document base URL for the purposes of parsing 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).

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

To get an element's target, given an a, area, or form element element, run these steps:

If element has a target attribute, then return that attribute's value.
If element's node document contains a base element with a target attribute, then return the value of the target attribute of the first such base element.
Return null.

A base element that is the first base element with an href content attribute in a document tree has a frozen base URL. The frozen base URL must be immediately set for an element whenever any of the following situations occur:

The base element becomes the first base element in tree order with an href content attribute in its Document.
The base element is the first base element in tree order with an href content attribute in its Document, and its href content attribute is changed.

To set the frozen base URL for an element element:

Let document be element's node document.
Let urlRecord be the result of parsing the value of element's href content attribute with document's fallback base URL, and document's character encoding. (Thus, the base element isn't affected by itself.)
Set element's frozen base URL to document's fallback base URL, if urlRecord is failure or running Is base allowed for Document? on the resulting URL record and document returns "Blocked", and to urlRecord otherwise.

The href IDL attribute, on getting, must return the result of running the following algorithm:

Let document be element's node document.
Let url be the value of the href attribute of this element, if it has one, and the empty string otherwise.
Let urlRecord be the result of parsing url with document's fallback base URL, and document's character encoding. (Thus, the base element isn't affected by other base elements or itself.)
If urlRecord is failure, return url.
Return the serialization of urlRecord.

The href IDL attribute, on setting, 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 lang="en">
    <head>
        <title>This is an example for the &lt;base&gt; element</title>
        <base href="https://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 "https://www.example.com/news/archives.html".

4.2.4 The `link` element

Spec bugs: 21622

If the element is allowed in the body: flow content.

If the element is allowed in the body: phrasing content.

Where metadata content is expected.

In a noscript element that is a child of a head element.

If the element is allowed in the body: where phrasing content is expected.

Nothing.

No end tag.

href — Address of the hyperlink

crossorigin — How the element handles crossorigin requests

rel — Relationship between the document containing the hyperlink and the destination resource

media — Applicable media

nonce — Cryptographic nonce used in Content Security Policy checks [CSP]

integrity — Integrity metadata used in Subresource Integrity checks [SRI]

hreflang — Language of the linked resource

type — Hint for the type of the referenced resource

referrerpolicy — Referrer policy for fetches initiated by the element

sizes — Sizes of the icons (for rel="icon")

as — Potential destination for a preload request (for rel="preload")

scope — Scope url for a service worker registration (for rel="serviceworker")

updateviacache — Update via cache mode for a service worker registration (for rel="serviceworker")

workertype — Service worker type for a service worker registration (for rel="serviceworker")

color — Color to use when customizing a site's icon (for rel="mask-icon")

Also, the title attribute has special semantics on this element: Title of the link; CSS style sheet set name.

[Exposed=Window,
 HTMLConstructor]
interface HTMLLinkElement : HTMLElement {
  [CEReactions] attribute USVString href;
  [CEReactions] attribute DOMString? crossOrigin;
  [CEReactions] attribute DOMString rel;
  [CEReactions] attribute DOMString as; // (default "")
  [SameObject, PutForwards=value] readonly attribute DOMTokenList relList;
  [CEReactions] attribute DOMString media;
  [CEReactions] attribute DOMString nonce;
  [CEReactions] attribute DOMString integrity;
  [CEReactions] attribute DOMString hreflang;
  [CEReactions] attribute DOMString type;
  [SameObject, PutForwards=value] readonly attribute DOMTokenList sizes;
  [CEReactions] attribute DOMString referrerPolicy;
  [CEReactions] attribute USVString scope;
  [CEReactions] attribute DOMString workerType;
  [CEReactions] attribute DOMString updateViaCache;
};
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.

The crossorigin attribute is a CORS settings attribute. It is intended for use with external resource links.

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.

rel's supported tokens are the keywords defined in HTML link types which are allowed on link elements, impact the processing model, and are supported by the user agent. The possible supported tokens are alternate, dns-prefetch, icon, next, pingback, preconnect, prefetch, preload, prerender, search, serviceworker, and stylesheet. rel's supported tokens must only include the tokens from this list that the user agent implements the processing model for.

Theoretically a user agent could support the processing model for the canonical keyword — if it were a search engine that executed JavaScript. But in practice that's quite unlikely. So in most cases, canonical ought not be included in rel's supported tokens.

A link element must have either a rel attribute or an itemprop attribute, but not both.

If a link element has an itemprop attribute, or has a rel attribute that contains only keywords that are body-ok, then the element is said to be allowed in the body. This means that the element can be used where phrasing content is expected.

If the rel attribute is used, the element can only sometimes be used in the body of the page. When used with the itemprop attribute, the element can be used both in the head element and in the body of the page, subject to the constraints of the microdata model.

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.

For example, the following link element creates two hyperlinks (to the same page):

<link rel="author license" href="/about">

The two links created by this element are one whose semantic is that the target page has information about the current page's author, and one whose semantic is that the target page has information regarding the license under which the current page is provided.

Hyperlinks created with the link element and its rel attribute apply to the whole document. 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 exact behavior for links to external resources depends on the exact relationship, as defined for the relevant link type.

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

The nonce attribute represents a cryptographic nonce ("number used once") which can be used by Content Security Policy to determine whether or not an external resource specified by the link will be loaded and applied to the document. The value is text. [CSP]

The integrity attribute represents the integrity metadata for requests which this element is responsible for. The value is text. The attribute must not be specified on link elements that do not have a rel attribute that contains the stylesheet keyword. [SRI]

The hreflang attribute on the link element has the same semantics as the hreflang attribute on the a element.

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

For external resource links, the type attribute is used as a hint to user agents so that they can avoid fetching resources they do not support.

The referrerpolicy attribute is a referrer policy attribute. It is intended for use with external resource links, where it helps set the referrer policy used when obtaining the external resource. [REFERRERPOLICY].

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 that are in a document tree, for which the title attribute defines CSS 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 gives the sizes of icons for visual media. Its value, if present, is merely advisory. User agents may use the value to decide which icon(s) to use if multiple icons are available. If specified, the attribute must have a value that is an unordered set of unique space-separated tokens which are ASCII case-insensitive. Each value must be either an ASCII case-insensitive match for the string "any", or a value that consists of two valid non-negative integers that do not have a leading U+0030 DIGIT ZERO (0) character and that are separated by a single U+0078 LATIN SMALL LETTER X or U+0058 LATIN CAPITAL LETTER X character. The attribute must not be specified on link elements that do not have a rel attribute that specifies the icon keyword or the apple-touch-icon keyword.

The apple-touch-icon keyword is a registered extension to the predefined set of link types, but user agents are not required to support it in any way.

The as attribute specifies the potential destination for a preload request for the resource given by the href attribute. It is an enumerated attribute. Each potential destination is a keyword for this attribute, mapping to a state of the same name. The attribute must be specified on link elements that have a rel attribute that contains the preload keyword, but must not be specified on link elements which do not. The processing model for how the as attribute is used is given in the steps to obtain the resource.

The attribute does not have a missing value default or invalid value default, meaning that invalid or missing values for the attribute map to no state. This is accounted for in the processing model.

The scope attribute specifies the scope url for a service worker registration. If the attribute is present, the value must be a valid URL potentially surrounded by spaces. The attribute must not be specified on link elements that do not have a rel attribute that contains the serviceworker keyword.

The updateviacache attribute specifies the update via cache mode for a service worker registration. It is an enumerated attribute. Each update via cache mode is a keyword for this attribute, mapping to a state of the same name. The missing value default is the imports state. The attribute must not be specified on link elements that do not have a rel attribute that contains the serviceworker keyword.

The workertype attribute is an enumerated attribute that specifies the service worker type for a service worker registration. The attribute's keywords are classic and module, which map to the respective states classic and module. The missing value default is the classic state. There is an additional state, not represented by a keyword: the invalid state. The invalid value default is the invalid state. The attribute must not be specified on link elements that do not have a rel attribute that contains the serviceworker keyword.

The color attribute is used with the mask-icon link type. The attribute must not be specified on link elements that do not have a rel attribute that contains the mask-icon keyword. The value must be a string that matches the CSS <color> production, defining a suggested color that user agents can use to customize the display of the icon that the user sees when they pin your site.

This specification does not have any user agent requirements for the color attribute.

The mask-icon keyword is a registered extension to the predefined set of link types, but user agents are not required to support it in any way.

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

There is no reflecting IDL attribute for the color attribute, but this might be added later.

The as IDL attribute must reflect the as content attribute, limited to only known values.

The crossOrigin IDL attribute must reflect the crossorigin content attribute, limited to only known values.

The referrerPolicy IDL attribute must reflect the referrerpolicy content attribute, limited to only known values.

The relList IDL attribute must reflect the rel content attribute.

The updateViaCache IDL attribute must reflect the updateviacache content attribute, limited to only known values.

The workerType IDL attribute must reflect the workertype content attribute, limited to only known values.

4.2.4.1 Processing the `media` attribute

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 default, if the media attribute is omitted, is "all", meaning that by default links apply to all media.

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.

4.2.4.2 Processing the `type` attribute

If type 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 computed 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.

4.2.4.3 Obtaining a resource from a `link` element

For external resources that are represented in the DOM (for example, style sheets), the DOM representation must be made available (modulo cross-origin restrictions) 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.
Parse the URL given by the href attribute, relative to the element's node document. If that fails, then abort these steps. Otherwise, let url be the resulting URL record.
Let corsAttributeState be the current state of the element's crossorigin content attribute.
Let request be the result of creating a potential-CORS request given url, the empty string, and corsAttributeState.
Set request's client to the link element's node document's Window object's environment settings object.
Set request's cryptographic nonce metadata to the current value of the link element's nonce content attribute.
Set request's integrity metadata to the current value of the link element's integrity content attribute.
Set request's referrer policy to the current state of the link element's referrerpolicy attribute.
If the rel attribute contains the preload keyword, then:
1. Let as be the current state of the as attribute.
2. If as is no state, then return.
3. Set request's destination to the result of translating as.
Fetch request.

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

Unless otherwise specified for a given rel keyword, the element must delay the load event of the element's node 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.)

4.2.4.4 Processing ``Link`` headers

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 message. These headers are to be processed according to the rules given in the relevant specifications. [HTTP] [WEBLINK]

Registration of relation types in HTTP `Link` headers is distinct from HTML link types, and thus their semantics can be different from same-named HTML types.

4.2.4.5 Providing users with a means to follow hyperlinks created using the `link` element

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

The relationship between this document and the resource (given by the rel attribute)
The title of the resource (given by the title attribute).
The address of the resource (given by the href attribute).
The language of the resource (given by the hreflang attribute).
The optimum media for the resource (given by the media attribute).

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

The activation behavior of link elements that create hyperlinks is to run the following steps:

If the link element's node document is not fully active, then abort these steps.
Follow the hyperlink created by the link element.

4.2.5 The `meta` element

If the itemprop attribute is present: flow content.

If the itemprop attribute is present: phrasing content.

If the charset attribute is present, or if the element's http-equiv attribute is in the Encoding declaration state: in a head element.

If the http-equiv attribute is present but not in the Encoding declaration state: in a head element.

If the http-equiv attribute is present but not in the Encoding declaration state: in a noscript element that is a child of a head element.

If the name attribute is present: where metadata content is expected.

If the itemprop attribute is present: where metadata content is expected.

If the itemprop attribute is present: where phrasing content is expected.

Nothing.

No end tag.

name — Metadata name

http-equiv — Pragma directive

content — Value of the element

charset — Character encoding declaration

[Exposed=Window,
 HTMLConstructor]
interface HTMLMetaElement : HTMLElement {
  [CEReactions] attribute DOMString name;
  [CEReactions] attribute DOMString httpEquiv;
  [CEReactions] 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, charset, and itemprop attributes must be specified.

If either name, http-equiv, or itemprop 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 XML.

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

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

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

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

4.2.5.1 Standard metadata names

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. Translations of the Web application's name may be given, using the lang attribute to specify the language of each name.

There must not be more than one meta element with a given language and 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.

To find the application name to use given an ordered list of languages (e.g. British English, American English, and English), user agents must run the following steps:

Let languages be the list of languages.
Let default language be the language of the Document's document element, if any, and if that language is not unknown.
If there is a default language, and if it is not the same language as any of the languages in languages, append it to languages.
Let winning language be the first language in languages for which there is a meta element in the Document that has its name attribute set to the value application-name and whose language is the language in question.

If none of the languages have such a meta element, then abort these steps; there's no given application name.
Return the value of the content attribute of the first meta element in the Document in tree order that has its name attribute set to the value application-name and whose language is winning language.

This algorithm would be used by a browser when it needs a name for the page, for instance, to label a bookmark. The languages it would provide to the algorithm would be the user's preferred languages.

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 pages whose markup is not generated by software, e.g. pages whose markup was written by a user in a text editor.

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 lang="en-GB">
 <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:
1. Split the value of the element's content attribute on commas.
2. 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.

referrer

The value must be a referrer policy, which defines the default referrer policy for the Document. [REFERRERPOLICY]

If any meta elements are inserted into the document or removed from the document, or existing meta elements have their name or content attributes changed, user agents must run the following algorithm:

Let candidate elements be the list of all meta elements that meet the following criteria, in tree order:
- The element is in a document tree
- The element has a name attribute, whose value is referrer
- The element has a content attribute, whose value is not the empty string
- The element is a child of the head element of the document

For each element in candidate elements:

Let value be the value of element's content attribute, converted to ASCII lowercase.

If value is one of the values given in the first column of the following table, then set value to the value given in the second column:

Legacy value	Referrer policy
`never`	`no-referrer`
`default`	`no-referrer-when-downgrade`
`always`	`unsafe-url`
`origin-when-crossorigin`	`origin-when-cross-origin`

If value is a referrer policy, then set element's node document's referrer policy to policy.

The fact that these steps are applied for each element enables deployment of fallback values for older user agents. [REFERRERPOLICY]

theme-color

The value must be a string that matches the CSS <color> production, defining a suggested color that user agents should use to customize the display of the page or of the surrounding user interface. For example, a browser might color the page's title bar with the specified value, or use it as a color highlight in a tab bar or task switcher.

There must not be more than one meta element with its name attribute set to the value theme-color per document.

This standard itself uses "WHATWG green" as its theme color:

<!DOCTYPE HTML>
<title>HTML Standard</title>
<meta name="theme-color" content="#3c790a">
...

To obtain a page's theme color, user agents must run the following steps:

Let candidate elements be the list of all meta elements that meet the following criteria, in tree order:
- The element is in a document tree
- The element has a name attribute, whose value is theme-color
- The element has a content attribute
For each element in candidate elements:
1. Let value be the result of stripping leading and trailing ASCII whitespace from the value of element's content attribute.
2. If value can be parsed as a CSS <color> value, return the parsed color.
If this step is reached, the page has no theme color.

When using the theme color in UI, user agents may adjust it in implementation-specific ways to make it more suitable for the UI in question. For example, if a user agent intends to use the theme color as a background and display white text over it, it might use a darker variant of the theme color in that part of the UI, to ensure adequate contrast.

4.2.5.2 Other metadata names

Anyone can create and use their own extensions to the predefined set of metadata names. There is no requirement to register such extensions.

However, a new metadata name should not be created in any of the following cases:

If either the name is a URL, or the value of its accompanying content attribute is a URL; in those cases, registering it as an extension to the predefined set of link types is encouraged (rather than creating a new metadata name).
If the name is for something expected to have processing requirements in user agents; in that case it ought to be standardized.

Also, before creating and using a new metadata name, consulting the WHATWG Wiki MetaExtensions page is encouraged — to avoid choosing a metadata name that's already in use, and to avoid duplicating the purpose of any metadata names that are already in use, and to avoid new standardized names clashing with your chosen name. [WHATWGWIKI]

Anyone is free to edit the WHATWG Wiki MetaExtensions page at any time to add a metadata name. New metadata names can be specified with the following information:

Keyword

The actual name being defined. The name should not be confusingly similar to any other defined name (e.g. differing only in case).

Brief description

A short non-normative description of what the metadata name's meaning is, including the format the value is required to be in.

Specification

A link to a more detailed description of the metadata name's semantics and requirements. It could be another page on the Wiki, or a link to an external page.

Synonyms

A list of other names that have exactly the same processing requirements. Authors should not use the names defined to be synonyms (they are only intended to allow user agents to support legacy content). Anyone may remove synonyms that are not used in practice; only names that need to be processed as synonyms for compatibility with legacy content are to be registered in this way.

Status

One of the following:

Proposed: The name has not received wide peer review and approval. Someone has proposed it and is, or soon will be, using it.
Ratified: The name has received wide peer review and approval. It has a specification that unambiguously defines how to handle pages that use the name, including when they use it in incorrect ways.
Discontinued: The metadata name has received wide peer review and it has been found wanting. Existing pages are using this metadata name, but new pages should avoid it. The "brief description" and "specification" entries will give details of what authors should use instead, if anything.

If a metadata name is found to be redundant with existing values, it should be removed and listed as a synonym for the existing value.

If a metadata name is added in the "proposed" state for a period of a month or more without being used or specified, then it may be removed from the WHATWG Wiki MetaExtensions page.

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.

4.2.5.3 Pragma directives

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
X-UA-Compatible	`x-ua-compatible`
Content security policy	`Content-Security-Policy`

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:

Content language state (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 such a pragma is successfully processed, there is no pragma-set default language.

If the meta element has no content attribute, 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.
Skip ASCII whitespace within input given position.
Collect a sequence of code points that are not ASCII whitespace from input given position.
Let candidate be the string that resulted from the previous step.
If candidate is the empty string, abort these steps.
Set the pragma-set default language to candidate.

If the value consists of multiple space-separated tokens, tokens after the first are ignored.

This pragma is almost, but not quite, entirely unlike the HTTP `Content-Language` header of the same name. [HTTP]

Encoding declaration state (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 ASCII whitespace, followed by the literal string "charset=", followed by one of the labels of the character encoding 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.

Default style state (http-equiv="default-style")

This pragma sets the name of the default CSS style sheet set.

If the meta element has no content attribute, or if that attribute's value is the empty string, then abort these steps.
Change the preferred CSS style sheet set name with the name being the value of the element's content attribute. [CSSOM]

Refresh state (http-equiv="refresh")

This pragma acts as timed redirect.

A Document object has an associated will declaratively refresh (a boolean). It is initially false.

If the meta element has no content attribute, or if that attribute's value is the empty string, then return.
Let input be the value of the element's content attribute.
Run the shared declarative refresh steps with the meta element's node document, input, and the meta element.

The shared declarative refresh steps, given a Document object document, string input, and optionally a meta element meta, are as follows:

If document's will declaratively refresh is true, then return.
Let position point at the first code point of input.
Skip ASCII whitespace within input given position.
Let time be 0.
Collect a sequence of code points that are ASCII digits from input given position, and let the result be timeString.
If timeString is the empty string, then:
1. If the code point in input pointed to by position is not U+002E (.), then return.
Otherwise, set time to the result of parsing timeString using the rules for parsing non-negative integers.
Collect a sequence of code points that are ASCII digits and U+002E FULL STOP characters (.) from input given position. Ignore any collected characters.
Let urlRecord be document's URL.
If position is not past the end of input, then:
1. If the code point in input pointed to by position is not U+003B (;), U+002C (,), or ASCII whitespace, then return.
2. Skip ASCII whitespace within input given position.
3. If the code point in input pointed to by position is U+003B (;) or U+002C (,), then advance position to the next code point.
4. Skip ASCII whitespace within input given position.
If position is not past the end of input, then:
1. Let urlString be the substring of input from the code point at position to the end of the string.
2. If the code point in input pointed to by position is U+0055 (U) or U+0075 (u), then advance position to the next code point. Otherwise, jump to the step labeled skip quotes.
3. If the code point in input pointed to by position is U+0052 (R) or U+0072 (r), then advance position to the next code point. Otherwise, jump to the step labeled parse.
4. If the code point in input pointed to by position is U+004C (L) or U+006C (l), then advance position to the next code point. Otherwise, jump to the step labeled parse.
5. Skip ASCII whitespace within input given position.
6. If the code point in input pointed to by position is U+003D (=), then advance position to the next code point. Otherwise, jump to the step labeled parse.
7. Skip ASCII whitespace within input given position.
8. Skip quotes: If the code point in input pointed to by position is U+0027 (') or U+0022 ("), then let quote be that code point, and advance position to the next code point. Otherwise, let quote be the empty string.
9. Set urlString to the substring of input from the code point at position to the end of the string.
10. If quote is not the empty string, and there is a code point in urlString equal to quote, then truncate urlString at that code point, so that it and all subsequent code points are removed.
11. Parse: Parse urlString relative to document. If that fails, return. Otherwise, set urlRecord to the resulting URL record.
Set document's will declaratively refresh to true.
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 meta is given, document's active sandboxing flag set does not have the sandboxed automatic features browsing context flag set, then navigate document's browsing context to urlRecord, with replacement enabled, and with 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:
  - At least time seconds have elapsed since document has completely loaded, adjusted to take into account user or user agent preferences.
  - If meta is given, at least time seconds have elapsed since meta was inserted into the document document, adjusted to take into account user or user agent preferences.
  It is important to use document here, and not meta's node document, as that might have changed between the initial set of steps and the refresh coming due and meta is not always given (in case of the HTTP `Refresh` header).
- Provide the user with an interface that, when selected, navigates a browsing context to urlRecord, with 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:

just a valid non-negative integer, or
a valid non-negative integer, followed by a U+003B SEMICOLON character (;), followed by one or more ASCII whitespace, followed by a substring that is an ASCII case-insensitive match for the string "URL", followed by a U+003D EQUALS SIGN character (=), followed by a valid URL string 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">

Cookie setter (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 URL via a "non-HTTP" API, consisting of the value of the element's content attribute encoded as UTF-8. [COOKIES] [ENCODING]

X-UA-Compatible state (http-equiv="x-ua-compatible")

In practice, this pragma encourages Internet Explorer to more closely follow the specifications.

For meta elements with an http-equiv attribute in the X-UA-Compatible state, the content attribute must have a value that is an ASCII case-insensitive match for the string "IE=edge".

User agents are required to ignore this pragma.

Content security policy state (http-equiv="content-security-policy")

This pragma enforces a Content Security Policy on a Document. [CSP]

If the meta element is not a child of a head element, 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 policy be the result of executing Content Security Policy's parse a serialized Content Security Policy algorithm on the meta element's content attribute's value.
Remove all occurrences of the report-uri, frame-ancestors, and sandbox directives from policy.
Enforce the policy policy.

For meta elements with an http-equiv attribute in the Content security policy state, the content attribute must have a value consisting of a valid Content Security Policy, but must not contain any report-uri, frame-ancestors, or sandbox directives. The Content Security Policy given in the content attribute will be enforced upon the current document. [CSP]

A page might choose to mitigate the risk of cross-site scripting attacks by preventing the execution of inline JavaScript, as well as blocking all plugin content, using a policy such as the following:

<meta http-equiv="Content-Security-Policy" content="script-src 'self'; object-src 'none'">

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

4.2.5.4 Other pragma directives

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:

Keyword: The actual name being defined. The name must match a previously-registered HTTP name with the same requirements.
Brief description: A short non-normative description of the purpose of the pragma directive.
Specification: A link to the specification defining the corresponding HTTP header.

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

4.2.5.5 Specifying the document's character encoding

A character encoding declaration is a mechanism by which the character encoding used to store or transmit a document is specified.

The following restrictions apply to character encoding declarations:

The character encoding name given must be an ASCII case-insensitive match for one of the labels of the character encoding used to serialize the file. [ENCODING]
The character encoding declaration must be serialized without the use of character references or character escapes of any kind.
The element containing the character encoding declaration must be serialized completely within the first 1024 bytes of the document.

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 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 encoding, and 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.

A character encoding declaration is required (either in the Content-Type metadata or explicitly in the file) even when all characters are in the ASCII range, because a character encoding is needed to process non-ASCII characters entered by the user in forms, in URLs generated by scripts, and so forth.

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

Authors should use UTF-8. Conformance checkers may advise authors against using legacy encodings. [ENCODING]

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

Authors must not use encodings that are not defined in the WHATWG Encoding standard. Additionally, authors should not use ISO-2022-JP. [ENCODING]

Some encodings that are not defined in the WHATWG Encoding standard use bytes in the range 0x20 to 0x7E, inclusive, to encode characters other than the corresponding characters in the range U+0020 to U+007E, inclusive, and represent a potential security vulnerability: a user agent might end up interpreting supposedly benign plain text content as HTML tags and JavaScript.

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 XML, 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"?>

4.2.6 The `style` element

Where metadata content is expected.

In a noscript element that is a child of a head element.

Depends on the value of the type attribute, but must match requirements described in prose below.

Neither tag is omissible.

media — Applicable media

nonce — Cryptographic nonce used in Content Security Policy checks [CSP]

type — Type of embedded resource

Also, the title attribute has special semantics on this element: CSS style sheet set name.