HTML 5.1 Nightly

None.

As the root element of a document.

Wherever a subdocument fragment is allowed in a compound document.

A head element followed by a body element.

manifest

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

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.

Otherwise: One or more elements of metadata content, of which exactly one is a 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.

4.2.2 The `title` element

In a head element containing no other title elements.

Text.

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.

The title element must not be empty.

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

4.2.3 The `base` element

In a head element containing no other base elements.

Empty.

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

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.

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

If the base element has no href content attribute, then return the document base URL and abort these steps.
Let fallback base url be the Document's fallback base URL.
Let url be the value of the href attribute of the base element.
Resolve url relative to fallback base url (thus, the base href attribute isn't affected by xml:base attributes or base elements).
If the previous step was successful, return the resulting absolute URL and abort these steps.
Otherwise, return the empty string.

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>
    <head>
        <title>This is an example for the &lt;base&gt; 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".

4.2.4 The `link` element

If the itemprop attribute is present: flow content.

If the itemprop attribute is present: phrasing content.

Where metadata content is expected.

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

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

Empty.

href

crossorigin

rel

media

hreflang

type

sizes

Also, the title attribute has special semantics on this element.

interface HTMLLinkElement : HTMLElement {
           attribute boolean disabled;
           attribute DOMString href;
           attribute DOMString crossOrigin;
           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 either a rel attribute or an itemprop attribute, but not both.

If the rel attribute is used, the element is restricted to the head element. 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.

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.

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.

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

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 (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.
Resolve the URL given by the href attribute, relative to the element.
If the previous step fails, then abort these steps.
Do a potentially CORS-enabled fetch of the resulting absolute URL, with the mode being the state of the element's crossorigin content attribute, the origin being the origin of the link element's Document, and the default origin behaviour set to taint.

The resource obtained in this fashion can be either CORS-same-origin or CORS-cross-origin.

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:

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

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: header fields, 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 header fields are to be processed according to the rules given in the relevant specifications. [HTTP] [WEBLINK]

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

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

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

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

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.

Empty.

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

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

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

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

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

4.2.5.1 Standard metadata names

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.

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

4.2.5.2 Other metadata names

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:

Keyword

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

Brief description

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

Specification

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

Synonyms

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

Status

One of the following:

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

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

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

If a metadata name is added with the "proposed" status and found to be redundant with existing values, it should be removed and listed as a synonym for the existing value. If a metadata name is added with the "proposed" status and found to be harmful, then it should be changed to "discontinued" status.

Anyone can change the status at any time, but should only do so in accordance with the definitions above.

Conformance checkers may 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 reported 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 may offer to add the value to the Wiki, with the details described above, with the "proposed" status.

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

4.2.5.3 Pragma directives

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:

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, or if that attribute's value is the empty string, then abort these steps.
If the element's content attribute contains a "," (U+002C) 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 whitespace.
Collect a sequence of characters that are not space characters.
Set the pragma-set default language to the string that resulted from the previous step.

This pragma is not exactly equivalent to the HTTP Content-Language header. [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 space characters, followed by the literal string "charset=", followed by the name 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 alternative 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.
Set the preferred style sheet set to the value of the element's content attribute. [CSSOM]

Refresh state (http-equiv="refresh")

This pragma acts as timed redirect.

If another meta element with an http-equiv attribute in the Refresh state has already been successfully processed (i.e. when it was inserted the user agent processed it and reached the last step of this list of steps), then abort these steps.
If the meta element has no content attribute, or if that attribute's value is the empty string, then abort these steps.
Let input be the value of the element's content attribute.
Let position point at the first character of input.
Skip whitespace.
Collect a sequence of characters that are ASCII digits, 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 that are ASCII digits and "." (U+002E) characters. Ignore any collected characters.
Skip whitespace.
Let url be the address of the current page.
If the character in input pointed to by position is a ";" (U+003B) character or a "," (U+002C) character, then advance position to the next character. Otherwise, jump to the last step.
Skip whitespace.
If the character in input pointed to by position is a "U" (U+0055) character 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 "R" (U+0052) character 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 "L" (U+004C) character or a U+006C LATIN SMALL LETTER L character (l), then advance position to the next character. Otherwise, jump to the last step.
Skip whitespace.
If the character in input pointed to by position is a "=" (U+003D), then advance position to the next character. Otherwise, jump to the last step.
Skip whitespace.
If the character in input pointed to by position is either a "'" (U+0027) character or """ (U+0022) 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 "tab" (U+0009), "LF" (U+000A), and "CR" (U+000D) 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 active sandboxing flag set does not have the sandboxed automatic features browsing context flag set, 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:
  - At least time seconds have elapsed since the document has completely loaded, adjusted to take into account user or user agent preferences.
  - At least time seconds have elapsed since the 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:

just a valid non-negative integer, or
a valid non-negative integer, followed by a U+003B SEMICOLON character (;), followed by one or more space characters, followed by a substring that is an ASCII case-insensitive match for the string "URL", followed by a "=" (U+003D) character, followed by a valid URL that does not start with a literal "'" (U+0027) or """ (U+0022) 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.
Obtain the storage mutex.
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.

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 may 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 reported 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 the name 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 character 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 if the encoding is US-ASCII, 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 character encoding.

Authors should 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 unlabeled content as another user agent) might end up interpreting technically benign plain text content as HTML tags and JavaScript. Authors should therefore not use these encodings. 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; these encodings were never intended for use for Web content. [RFC1345] [RFC1842] [RFC1468] [RFC2237] [RFC1554] [CP50220] [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"?>

4.2.6 The `style` element

If the scoped attribute is present: flow content.

If the scoped attribute is absent: where metadata content is expected.

If the scoped attribute is absent: in a noscript element that is a child of a head element.

If the scoped attribute is present: where flow content is expected, but before any other flow content other than inter-element whitespace, and not as the child of an element whose content model is transparent.

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

media

type

scoped

Also, the 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 present, 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 and the element has a parent element, then the style element must be the first node of flow content in its parent element other than inter-element whitespace, and the parent element's content model must not have a transparent component.

This implies that only one scoped style element is allowed at a time, and that such elements cannot be children of, e.g., a or ins elements, even when those are used as flow content containers.

A style element without a scoped attribute is restricted to appearing in the head of the 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 descendants. Otherwise, the specified styles must, if applied, be applied to the entire document.

The following will eventually be moved to a CSS specification; it is specified here only on an interim basis until an editor can be found to own this.

Within scoped CSS resources, authors may use an @global @-rule. The syntax of this rule is defined as follows.

The following production is added to the grammar:

global
  : GLOBAL_SYM S* ruleset
  ;

The following rules are added to the Flex tokenizer:

B                     b|\\0{0,4}(42|62)(\r\n|[ \t\r\n\f])?
@{G}{L}{O}{B}{A}{L}   {return GLOBAL_SYM;}

Simple selectors in rule sets prefixed by the @global @-rule in scoped CSS resources must be processed in the same way as normal rule sets in non-scoped CSS resources.

Simple selectors in scoped CSS resources that are not prefixed by an @global @-rule must only match the style element's parent element (if any), and that element's descendants.

For scoped CSS resources, the effect of other @-rules must be scoped to either the scoped sheet and its subresources or to the subtree rooted at the style element's parent (if any), even if the @-rule in question would ordinarily apply to all style sheets that affect the Document, or to all nodes in 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 elements in the scoped section; the font would not be used for elements outside the subtree. However, rules outside the subtree that refer to font family names declared in '@font-face' rules in a scoped section, when those rules are inherited by nodes in the scoped section, would end up referring to the fonts declared in that section.

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

4.2.7 Styling

The link and style elements can provide styling information for the user agent to use when rendering the document. The CSS and CSSOM specifications specify what styling information is to be used by the user agent and how it is to be used. [CSS] [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), for which the link is an alternative stylesheet but whose title content attribute is absent or empty, or whose resource is CORS-cross-origin, must have their LinkStyle interface's sheet attribute return null.

Otherwise, the LinkStyle interface's sheet attribute must return null if the corresponding element is not in a Document, and otherwise must return a StyleSheet object with the following properties: [CSSOM]

The style sheet type: 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.
The style sheet location: For link elements, the location must be the result of resolving the URL given by the element's href content attribute, relative to the element, or the empty string if that fails. For style elements, there is no location.
The style sheet media: The media must be the same as the value of the element's media content attribute, or the empty string, if the attribute is omitted.
The style sheet title: The title must be the same as the value of the element's title content attribute, if the attribute is present and has a non-empty value. If the attribute is absent or its value is the empty string, then the style sheet does not have a title (it is the empty string). The title is used for defining alternative style sheet sets.
The style sheet alternate flag: 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.

Giving up on a style sheet before the style sheet loads, if the style sheet eventually does still load, means that the script might end up operating with incorrect information. For example, if a style sheet sets the color of an element to green, but a script that inspects the resulting style is executed before the sheet is loaded, the script will find that the element is black (or whatever the default color is), and might thus make poor choices (e.g. deciding to use black as the color elsewhere on the page, instead of green). Implementors have to balance the likelihood of a script using incorrect information with the performance impact of doing nothing while waiting for a slow network request to finish.

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.

4.3 Scripting

Scripts allow authors to add interactivity to their documents.

Authors are encouraged to use declarative alternatives to scripting where possible, as declarative mechanisms are often more maintainable, and many users disable scripting.

For example, instead of using script to show or hide a section to show more details, the details element could be used.

Authors are also encouraged to make their applications degrade gracefully in the absence of scripting support.

For example, if an author provides a link in a table header to dynamically resort the table, the link could also be made to function without scripts by requesting the sorted table from the server.

4.3.1 The `script` element

Where metadata content is expected.

Where phrasing content is expected.

If there is no src attribute, depends on the value of the type attribute, but must match script content restrictions.

If there is a src attribute, the element must be either empty or contain only script documentation that also matches script content restrictions.

src

type

charset

async

defer

crossorigin

interface HTMLScriptElement : HTMLElement {
           attribute DOMString src;
           attribute DOMString type;
           attribute DOMString charset;
           attribute boolean async;
           attribute boolean defer;
           attribute DOMString crossOrigin;
           attribute DOMString text;
};

The script element allows authors to include dynamic script and data blocks in their documents. The element does not represent content for the user.

When used to include dynamic scripts, the scripts may either be embedded inline or may be imported from an external file using the src attribute. If the language is not that described by "text/javascript", then the type attribute must be present, as described below. Whatever language is used, the contents of the script element must conform with the requirements of that language's specification.

When used to include data blocks (as opposed to scripts), the data must be embedded inline, the format of the data must be given using the type attribute, the src attribute must not be specified, and the contents of the script element must conform to the requirements defined for the format used.

The type attribute gives the language of the script or format of the data. If the attribute is present, its value must be a valid MIME type. The charset parameter must not be specified. The default, which is used if the attribute is absent, is "text/javascript".

The src attribute, if specified, gives the address of the external script resource to use. The value of the attribute must be a valid non-empty URL potentially surrounded by spaces identifying a script resource of the type given by the type attribute, if the attribute is present, or of the type "text/javascript", if the attribute is absent. A resource is a script resource of a given type if that type identifies a scripting language and the resource conforms with the requirements of that language's specification.

The charset attribute gives the character encoding of the external script resource. The attribute must not be specified if the src attribute is not present. If the attribute is set, its value must be an ASCII case-insensitive match for the name of an encoding, and must specify the same encoding as the charset parameter of the Content-Type metadata of the external file, if any. [ENCODING]

The async and defer attributes are boolean attributes that indicate how the script should be executed. The defer and async attributes must not be specified if the src attribute is not present.

There are three possible modes that can be selected using these attributes. If the async attribute is present, then the script will be executed asynchronously, as soon as it is available. If the async attribute is not present but the defer attribute is present, then the script is executed when the page has finished parsing. If neither attribute is present, then the script is fetched and executed immediately, before the user agent continues parsing the page.

The exact processing details for these attributes are, for mostly historical reasons, somewhat non-trivial, involving a number of aspects of HTML. The implementation requirements are therefore by necessity scattered throughout the specification. The algorithms below (in this section) describe the core of this processing, but these algorithms reference and are referenced by the parsing rules for script start and end tags in HTML, in foreign content, and in XML, the rules for the document.write() method, the handling of scripting, etc.

The defer attribute may be specified even if the async attribute is specified, to cause legacy Web browsers that only support defer (and not async) to fall back to the defer behavior instead of the synchronous blocking behavior that is the default.

The crossorigin attribute is a CORS settings attribute. It controls, for scripts that are obtained from other origins, whether error information will be exposed.

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

A script element has several associated pieces of state.

The first is a flag indicating whether or not the script block has been "already started". Initially, script elements must have this flag unset (script blocks, when created, are not "already started"). The cloning steps for script elements must set the "already started" flag on the copy if it is set on the element being cloned.

The second is a flag indicating whether the element was "parser-inserted". Initially, script elements must have this flag unset. It is set by the HTML parser and the XML parser on script elements they insert and affects the processing of those elements.

The third is a flag indicating whether the element will "force-async". Initially, script elements must have this flag set. It is unset by the HTML parser and the XML parser on script elements they insert. In addition, whenever a script element whose "force-async" flag is set has a async content attribute added, the element's "force-async" flag must be unset.

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

The last few pieces of state are the script block's type, the script block's character encoding, and the script block's fallback character encoding. They are determined when the script is prepared, based on the attributes on the element at that time, and the Document of the script element.

When a script element that is not marked as being "parser-inserted" experiences one of the events listed in the following list, the user agent must synchronously prepare the script element:

The script element gets inserted into a document, at the time the node is inserted according to the DOM, after any other script elements inserted at the same time that are earlier in the Document in tree order.
The script element is in a Document and a node or document fragment is inserted into the script element, after any script elements inserted at that time.
The script element is in a Document and has a src attribute set where previously the element had no such attribute.

To prepare a script, the user agent must act as follows:

If the script element is marked as having "already started", then the user agent must abort these steps at this point. The script is not executed.
If the element has its "parser-inserted" flag set, then set was-parser-inserted to true and unset the element's "parser-inserted" flag. Otherwise, set was-parser-inserted to false.

This is done so that if parser-inserted script elements fail to run when the parser tries to run them, e.g. because they are empty or specify an unsupported scripting language, another script can later mutate them and cause them to run again.
If was-parser-inserted is true and the element does not have an async attribute, then set the element's "force-async" flag to true.

This is done so that if a parser-inserted script element fails to run when the parser tries to run it, but it is later executed after a script dynamically updates it, it will execute asynchronously even if the async attribute isn't set.
If the element has no src attribute, and its child nodes, if any, consist only of comment nodes and empty Text nodes, then the user agent must abort these steps at this point. The script is not executed.
If the element is not in a Document, then the user agent must abort these steps at this point. The script is not executed.
If either:
- the script element has a type attribute and its value is the empty string, or
- the script element has no type attribute but it has a language attribute and that attribute's value is the empty string, or
- the script element has neither a type attribute nor a language attribute, then
...let the script block's type for this script element be "text/javascript".

Otherwise, if the script element has a type attribute, let the script block's type for this script element be the value of that attribute with any leading or trailing sequences of space characters removed.

Otherwise, the element has a non-empty language attribute; let the script block's type for this script element be the concatenation of the string "text/" followed by the value of the language attribute.

The language attribute is never conforming, and is always ignored if there is a type attribute present.
If the user agent does not support the scripting language given by the script block's type for this script element, then the user agent must abort these steps at this point. The script is not executed.
If was-parser-inserted is true, then flag the element as "parser-inserted" again, and set the element's "force-async" flag to false.
The user agent must set the element's "already started" flag.

The state of the element at this moment is later used to determine the script source.
If the element is flagged as "parser-inserted", but the element's Document is not the Document of the parser that created the element, then abort these steps.
If scripting is disabled for the script element, then the user agent must abort these steps at this point. The script is not executed.

The definition of scripting is disabled means that, amongst others, the following scripts will not execute: scripts in XMLHttpRequest's responseXML documents, scripts in DOMParser-created documents, scripts in documents created by XSLTProcessor's transformToDocument feature, and scripts that are first inserted by a script into a Document that was created using the createDocument() API. [XHR] [DOMPARSING] [DOM]
If the script element has an event attribute and a for attribute, then run these substeps:
1. Let for be the value of the for attribute.
2. Let event be the value of the event attribute.
3. Strip leading and trailing whitespace from event and for.
4. If for is not an ASCII case-insensitive match for the string "window", then the user agent must abort these steps at this point. The script is not executed.
5. If event is not an ASCII case-insensitive match for either the string "onload" or the string "onload()", then the user agent must abort these steps at this point. The script is not executed.
If the script element has a charset attribute, then let the script block's character encoding for this script element be the result of getting an encoding from the value of the charset attribute.

Otherwise, let the script block's fallback character encoding for this script element be the same as the encoding of the document itself.

Only one of these two pieces of state is set.
If the element has a src content attribute, run these substeps:
1. Let src be the value of the element's src attribute.
2. If src is the empty string, queue a task to fire a simple event named error at the element, and abort these steps.
3. Resolve src relative to the element.
4. If the previous step failed, queue a task to fire a simple event named error at the element, and abort these steps.
5. Do a potentially CORS-enabled fetch of the resulting absolute URL, with the mode being the state of the element's crossorigin content attribute, the origin being the origin of the script element's Document, and the default origin behaviour set to taint.
  
  The resource obtained in this fashion can be either CORS-same-origin or CORS-cross-origin. This only affects how error reporting happens.
  
  For historical reasons, if the URL is a javascript: URL, then the user agent must not, despite the requirements in the definition of the fetching algorithm, actually execute the script in the URL; instead the user agent must act as if it had received an empty HTTP 400 response.
  
  For performance reasons, user agents may start fetching the script (as defined above) as soon as the src attribute is set, instead, in the hope that the element will be inserted into the document (and that the crossorigin attribute won't change value in the meantime). Either way, once the element is inserted into the document, the load must have started as described in this step. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, or the crossorigin attribute is dynamically changed, then the user agent will not execute the script so obtained, and the fetching process will have been effectively wasted.
Then, the first of the following options that describes the situation must be followed:
If the element has a src attribute, and the element has a defer attribute, and the element has been flagged as "parser-inserted", and the element does not have an async attribute

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

The task that the networking task source places on the task queue once the fetching algorithm has completed must set the element's "ready to be parser-executed" flag. The parser will handle executing the script.

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

The element is the pending parsing-blocking script of the Document of the parser that created the element. (There can only be one such script per Document at a time.)

The task that the networking task source places on the task queue once the fetching algorithm has completed must set the element's "ready to be parser-executed" flag. The parser will handle executing the script.

If the element does not have a src attribute, and the element has been flagged as "parser-inserted", and either the parser that created the script is an XML parser or it's an HTML parser whose script nesting level is not greater than one, and the Document of the HTML parser or XML parser that created the script element has a style sheet that is blocking scripts

The element is the pending parsing-blocking script of the Document of the parser that created the element. (There can only be one such script per Document at a time.)

Set the element's "ready to be parser-executed" flag. The parser will handle executing the script.

If the element has a src attribute, does not have an async attribute, and does not have the "force-async" flag set
The element must be added to the end of the list of scripts that will execute in order as soon as possible associated with the Document of the script element at the time the prepare a script algorithm started.

The task that the networking task source places on the task queue once the fetching algorithm has completed must run the following steps:
1. If the element is not now the first element in the list of scripts that will execute in order as soon as possible to which it was added above, then mark the element as ready but abort these steps without executing the script yet.
2. Execution: Execute the script block corresponding to the first script element in this list of scripts that will execute in order as soon as possible.
3. Remove the first element from this list of scripts that will execute in order as soon as possible.
4. If this list of scripts that will execute in order as soon as possible is still not empty and the first entry has already been marked as ready, then jump back to the step labeled execution.
If the element has a src attribute

The element must be added to the set of scripts that will execute as soon as possible of the Document of the script element at the time the prepare a script algorithm started.

The task that the networking task source places on the task queue once the fetching algorithm has completed must execute the script block and then remove the element from the set of scripts that will execute as soon as possible.

Otherwise

The user agent must immediately execute the script block, even if other scripts are already executing.

Fetching an external script must delay the load event of the element's document until the task that is queued by the networking task source once the resource has been fetched (defined above) has been run.

The pending parsing-blocking script of a Document is used by the Document's parser(s).

If a script element that blocks a parser gets moved to another Document before it would normally have stopped blocking that parser, it nonetheless continues blocking that parser until the condition that causes it to be blocking the parser no longer applies (e.g. if the script is a pending parsing-blocking script because there was a style sheet that is blocking scripts when it was parsed, but then the script is moved to another Document before the style sheet loads, the script still blocks the parser until the style sheets are all loaded, at which time the script executes and the parser is unblocked).

When the user agent is required to execute a script block, it must run the following steps:

If the element is flagged as "parser-inserted", but the element's Document is not the Document of the parser that created the element, then abort these steps.
Jump to the appropriate set of steps from the list below:
If the load resulted in an error (for example a DNS error, or an HTTP 404 error)

Executing the script block must just consist of firing a simple event named error at the element.

If the load was successful
Executing the script block must consist of running the following steps. For the purposes of these steps, the script is considered to be from an external file if, while the prepare a script algorithm above was running for this script, the script element had a src attribute specified.
1. Initialize the script block's source as follows:
  If the script is from an external file and the script block's type is a text-based language
  
  The contents of that file, interpreted as a Unicode string, are the script source.
  
  To obtain the Unicode string, the user agent run the following steps:
  
  If the resource's Content Type metadata, if any, specifies a character encoding, and the user agent supports that encoding, then let character encoding be that encoding, and jump to the bottom step in this series of steps.
  
  If the algorithm above set the script block's character encoding, then let character encoding be that encoding, and jump to the bottom step in this series of steps.
  
  Let character encoding be the script block's fallback character encoding.
  
  If the specification for the script block's type gives specific rules for decoding files in that format to Unicode, follow them, using character encoding as the character encoding specified by higher-level protocols, if necessary.
  
  Otherwise, decode the file to Unicode, using character encoding as the fallback encoding.
  
  The decode algorithm overrides character encoding if the file contains a BOM.
  
  If the script is from an external file and the script block's type is an XML-based language
  
  The external file is the script source. When it is later executed, it must be interpreted in a manner consistent with the specification defining the language given by the script block's type.
  
  If the script is inline and the script block's type is a text-based language
  
  The value of the text IDL attribute at the time the element's "already started" flag was last set is the script source.
  
  If the script is inline and the script block's type is an XML-based language
  
  The child nodes of the script element at the time the element's "already started" flag was last set are the script source.
2. Fire a simple event named beforescriptexecute that bubbles and is cancelable at the script element.
  
  If the event is canceled, then abort these steps.
3. If the script is from an external file, then increment the ignore-destructive-writes counter of the script element's Document. Let neutralized doc be that Document.
4. Let old script element be the value to which the Document element's currentScript object was most recently initialized.
5. Initialize the Document element's currentScript object to the script element.
6. Create a script from the script element node, using the script block's source, the URL from which the script was obtained, and the script block's type.
  
  If the script came from a resource that was fetched in the steps above, and the resource was CORS-cross-origin, then pass the muted errors flag to the create a script from a node algorithm.
  
  This is where the script is compiled and actually executed.
7. Initialize the Document element's currentScript object to old script element.
8. Decrement the ignore-destructive-writes counter of neutralized doc, if it was incremented in the earlier step.
9. Fire a simple event named afterscriptexecute that bubbles (but is not cancelable) at the script element.
10. If the script is from an external file, fire a simple event named load at the script element.
  
  Otherwise, the script is internal; queue a task to fire a simple event named load at the script element.

The IDL attributes src, type, charset, defer, each must reflect the respective content attributes of the same name.

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

The async IDL attribute controls whether the element will execute asynchronously or not. If the element's "force-async" flag is set, then, on getting, the async IDL attribute must return true, and on setting, the "force-async" flag must first be unset, and then the content attribute must be removed if the IDL attribute's new value is false, and must be set to the empty string if the IDL attribute's new value is true. If the element's "force-async" flag is not set, the IDL attribute must reflect the async content attribute.

script . 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 children of the script element (ignoring any other nodes such as comments or elements), in tree order. On setting, it must act the same way as the textContent IDL attribute.

When inserted using the document.write() method, script elements execute (typically synchronously), but when inserted using innerHTML and outerHTML attributes, they do not execute at all.

In this example, two script elements are used. One embeds an external script, and the other includes some data.

<script src="game-engine.js"></script>
<script type="text/x-game-map">
........U.........e
o............A....e
.....A.....AAA....e
.A..AAA...AAAAA...e
</script>

The data in this case might be used by the script to generate the map of a video game. The data doesn't have to be used that way, though; maybe the map data is actually embedded in other parts of the page's markup, and the data block here is just used by the site's search engine to help users who are looking for particular features in their game maps.

The following sample shows how a script element can be used to define a function that is then used by other parts of the document. It also shows how a script element can be used to invoke script while the document is being parsed, in this case to initialize the form's output.

<script>
 function calculate(form) {
   var price = 52000;
   if (form.elements.brakes.checked)
     price += 1000;
   if (form.elements.radio.checked)
     price += 2500;
   if (form.elements.turbo.checked)
     price += 5000;
   if (form.elements.sticker.checked)
     price += 250;
   form.elements.result.value = price;
 }
</script>
<form name="pricecalc" onsubmit="return false" onchange="calculate(this)">
 <fieldset>
  <legend>Work out the price of your car</legend>
  <p>Base cost: £52000.</p>
  <p>Select additional options:</p>
  <ul>
   <li><label><input type=checkbox name=brakes> Ceramic brakes (£1000)</label></li>
   <li><label><input type=checkbox name=radio> Satellite radio (£2500)</label></li>
   <li><label><input type=checkbox name=turbo> Turbo charger (£5000)</label></li>
   <li><label><input type=checkbox name=sticker> "XZ" sticker (£250)</label></li>
  </ul>
  <p>Total: £<output name=result></output></p>
 </fieldset>
 <script>
  calculate(document.forms.pricecalc);
 </script>
</form>

4.3.1.1 Scripting languages

A user agent is said to support the scripting language if each component of the script block's type is an ASCII case-insensitive match for the corresponding component in the MIME type string of a scripting language that the user agent implements.

The following lists the MIME type strings that user agents must recognize, and the languages to which they refer:

"application/ecmascript"
"application/javascript"
"application/x-ecmascript"
"application/x-javascript"
"text/ecmascript"
"text/javascript"
"text/javascript1.0"
"text/javascript1.1"
"text/javascript1.2"
"text/javascript1.3"
"text/javascript1.4"
"text/javascript1.5"
"text/jscript"
"text/livescript"
"text/x-ecmascript"
"text/x-javascript": JavaScript. [ECMA262]

User agents may support other MIME types for other languages, but must not support other MIME types for the languages in the list above. User agents are not required to support the languages listed above.

The following MIME types (with or without parameters) must not be interpreted as scripting languages:

"text/plain"
"text/xml"
"application/octet-stream"
"application/xml"

These types are explicitly listed here because they are poorly-defined types that are nonetheless likely to be used as formats for data blocks, and it would be problematic if they were suddenly to be interpreted as script by a user agent.

When examining types to determine if they represent supported languages, user agents must not ignore MIME parameters. Types are to be compared including all parameters.

For example, types that include the charset parameter will not be recognized as referencing any of the scripting languages listed above.

4.3.1.2 Restrictions for contents of `script` elements

The textContent of a script element must match the script production in the following ABNF, the character set for which is Unicode. [ABNF]

script        = data1 *( escape [ script-start data3 ] "-->" data1 ) [ escape ]
escape        = "<!--" data2 *( script-start data3 script-end data2 )

data1         = < any string that doesn't contain a substring that matches not-data1 >
not-data1     = "<!--"             

data2         = < any string that doesn't contain a substring that matches not-data2 >
not-data2     = script-start / "-->"  

data3         = < any string that doesn't contain a substring that matches not-data3 >
not-data3     = script-end / "-->"

script-start  = lt       s c r i p t tag-end
script-end    = lt slash s c r i p t tag-end

lt            =  %x003C ; "<" (U+003C) character
slash         =  %x002F ; "/" (U+002F) character

s             =  %x0053 ; U+0053 LATIN CAPITAL LETTER S
s             =/ %x0073 ; U+0073 LATIN SMALL LETTER S
c             =  %x0043 ; U+0043 LATIN CAPITAL LETTER C
c             =/ %x0063 ; U+0063 LATIN SMALL LETTER C
r             =  %x0052 ; U+0052 LATIN CAPITAL LETTER R
r             =/ %x0072 ; U+0072 LATIN SMALL LETTER R
i             =  %x0049 ; U+0049 LATIN CAPITAL LETTER I
i             =/ %x0069 ; U+0069 LATIN SMALL LETTER I
p             =  %x0050 ; U+0050 LATIN CAPITAL LETTER P
p             =/ %x0070 ; U+0070 LATIN SMALL LETTER P
t             =  %x0054 ; U+0054 LATIN CAPITAL LETTER T
t             =/ %x0074 ; U+0074 LATIN SMALL LETTER T

tag-end       =  %x0009 ; "tab" (U+0009)
tag-end       =/ %x000A ; "LF" (U+000A)
tag-end       =/ %x000C ; "FF" (U+000C)
tag-end       =/ %x0020 ; U+0020 SPACE
tag-end       =/ %x002F ; "/" (U+002F)
tag-end       =/ %x003E ; ">" (U+003E)

When a script element contains script documentation, there are further restrictions on the contents of the element, as described in the section below.

4.3.1.3 Inline documentation for external scripts

If a script element's src attribute is specified, then the contents of the script element, if any, must be such that the value of the text IDL attribute, which is derived from the element's contents, matches the documentation production in the following ABNF, the character set for which is Unicode. [ABNF]

documentation = *( *( space / tab / comment ) [ line-comment ] newline )
comment       = slash star *( not-star / star not-slash ) 1*star slash
line-comment  = slash slash *not-newline

; characters
tab           = %x0009 ; "tab" (U+0009)
newline       = %x000A ; "LF" (U+000A)
space         = %x0020 ; U+0020 SPACE
star          = %x002A ; "*" (U+002A)
slash         = %x002F ; "/" (U+002F)
not-newline   = %x0000-0009 / %x000B-10FFFF
                ; a Unicode character other than "LF" (U+000A)
not-star      = %x0000-0029 / %x002B-10FFFF
                ; a Unicode character other than "*" (U+002A)
not-slash     = %x0000-002E / %x0030-10FFFF
                ; a Unicode character other than "/" (U+002F)

This corresponds to putting the contents of the element in JavaScript comments.

This requirement is in addition to the earlier restrictions on the syntax of contents of script elements.

This allows authors to include documentation, such as license information or API information, inside their documents while still referring to external script files. The syntax is constrained so that authors don't accidentally include what looks like valid script while also providing a src attribute.

<script src="cool-effects.js">
 // create new instances using:
 //    var e = new Effect();
 // start the effect using .play, stop using .stop:
 //    e.play();
 //    e.stop();
</script>

4.3.1.4 Interaction of `script` elements and XSLT

This section is non-normative.

This specification does not define how XSLT interacts with the script element. However, in the absence of another specification actually defining this, here are some guidelines for implementors, based on existing implementations:

When an XSLT transformation program is triggered by an <?xml-stylesheet?> processing instruction and the browser implements a direct-to-DOM transformation, script elements created by the XSLT processor need to be marked "parser-inserted" and run in document order (modulo scripts marked defer or async), asynchronously while the transformation is occurring.
The XSLTProcessor.transformToDocument() method adds elements to a Document that is not in a browsing context, and, accordingly, any script elements they create need to have their "already started" flag set in the prepare a script algorithm and never get executed (scripting is disabled). Such script elements still need to be marked "parser-inserted", though, such that their async IDL attribute will return false in the absence of an async content attribute.
The XSLTProcessor.transformToFragment() method needs to create a fragment that is equivalent to one built manually by creating the elements using document.createElementNS(). For instance, it needs to create script elements that aren't "parser-inserted" and that don't have their "already started" flag set, so that they will execute when the fragment is inserted into a document.

The main distinction between the first two cases and the last case is that the first two operate on Documents and the last operates on a fragment.

4.3.2 The `noscript` element

Categories:: Metadata content.; Flow content.; Phrasing content.
Contexts in which this element can be used:: In a head element of an HTML document, if there are no ancestor noscript elements.; Where phrasing content is expected in HTML documents, if there are no ancestor noscript elements.
Content model:: When scripting is disabled, in a head element: in any order, zero or more link elements, zero or more style elements, and zero or more meta elements.; When scripting is disabled, not in a head element: transparent, but there must be no noscript element descendants.; Otherwise: text that conforms to the requirements given in the prose.
Content attributes:: Global attributes
DOM interface:: Uses HTMLElement.

The noscript element represents nothing if scripting is enabled, and represents its children if scripting is disabled. It is used to present different markup to user agents that support scripting and those that don't support scripting, by affecting how the document is parsed.

When used in HTML documents, the allowed content model is as follows:

In a head element, if scripting is disabled for the noscript element

The noscript element must contain only link, style, and meta elements.

In a head element, if scripting is enabled for the noscript element

The noscript element must contain only text, except that invoking the HTML fragment parsing algorithm with the noscript element as the context element and the text contents as the input must result in a list of nodes that consists only of link, style, and meta elements that would be conforming if they were children of the noscript element, and no parse errors.

Outside of head elements, if scripting is disabled for the noscript element

The noscript element's content model is transparent, with the additional restriction that a noscript element must not have a noscript element as an ancestor (that is, noscript can't be nested).

Outside of head elements, if scripting is enabled for the noscript element

The noscript element must contain only text, except that the text must be such that running the following algorithm results in a conforming document with no noscript elements and no script elements, and such that no step in the algorithm causes an HTML parser to flag a parse error:

Remove every script element from the document.
Make a list of every noscript element in the document. For every noscript element in that list, perform the following steps:
1. Let the parent element be the parent element of the noscript element.
2. Take all the children of the parent element that come before the noscript element, and call these elements the before children.
3. Take all the children of the parent element that come after the noscript element, and call these elements the after children.
4. Let s be the concatenation of all the Text node children of the noscript element.
5. Set the innerHTML attribute of the parent element to the value of s. (This, as a side-effect, causes the noscript element to be removed from the document.)
6. Insert the before children at the start of the parent element, preserving their original relative order.
7. Insert the after children at the end of the parent element, preserving their original relative order.

All these contortions are required because, for historical reasons, the noscript element is handled differently by the HTML parser based on whether scripting was enabled or not when the parser was invoked.

The noscript element must not be used in XML documents.

The noscript element is only effective in the HTML syntax, it has no effect in the XHTML syntax. This is because the way it works is by essentially "turning off" the parser when scripts are enabled, so that the contents of the element are treated as pure text and not as real elements. XML does not define a mechanism by which to do this.

The noscript element has no other requirements. In particular, children of the noscript element are not exempt from form submission, scripting, and so forth, even when scripting is enabled for the element.

In the following example, a noscript element is used to provide fallback for a script.

<form action="calcSquare.php">
 <p>
  <label for=x>Number</label>:
  <input id="x" name="x" type="number">
 </p>
 <script>
  var x = document.getElementById('x');
  var output = document.createElement('p');
  output.textContent = 'Type a number; it will be squared right then!';
  x.form.appendChild(output);
  x.form.onsubmit = function () { return false; }
  x.oninput = function () {
    var v = x.valueAsNumber;
    output.textContent = v + ' squared is ' + v * v;
  };
 </script>
 <noscript>
  <input type=submit value="Calculate Square">
 </noscript>
</form>

When script is disabled, a button appears to do the calculation on the server side. When script is enabled, the value is computed on-the-fly instead.

The noscript element is a blunt instrument. Sometimes, scripts might be enabled, but for some reason the page's script might fail. For this reason, it's generally better to avoid using noscript, and to instead design the script to change the page from being a scriptless page to a scripted page on the fly, as in the next example:

<form action="calcSquare.php">
 <p>
  <label for=x>Number</label>:
  <input id="x" name="x" type="number">
 </p>
 <input id="submit" type=submit value="Calculate Square">
 <script>
  var x = document.getElementById('x');
  var output = document.createElement('p');
  output.textContent = 'Type a number; it will be squared right then!';
  x.form.appendChild(output);
  x.form.onsubmit = function () { return false; }
  x.oninput = function () {
    var v = x.valueAsNumber;
    output.textContent = v + ' squared is ' + v * v;
  };
  var submit = document.getElementById('submit');
  submit.parentNode.removeChild(submit);
 </script>
</form>

The above technique is also useful in XHTML, since noscript is not supported in the XHTML syntax.

4.4 Sections

4.4.1 The `body` element

Sectioning root.

As the second element in an html element.

Flow content.

onafterprint

onbeforeprint

onbeforeunload

onfullscreenchange

onfullscreenerror

onhashchange

onmessage

onoffline

ononline

onpagehide

onpageshow

onpopstate

onresize

onstorage

onunload