HTML Living Standard — Last Updated

4 The elements of HTML

4.1 The document element

4.1.1 The html element

✔ MDN Element/html Support in all current engines. Firefox Yes Safari Yes Chrome Yes Opera Yes Edge Yes Edge (Legacy) 12+ Internet Explorer Yes Firefox Android Yes Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android Yes

✔ MDN HTMLHtmlElement Support in all current engines. Firefox 1+ Safari Yes Chrome Yes Opera Yes Edge Yes Edge (Legacy) 12+ Internet Explorer Yes Firefox Android 4+ Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android Yes

The html element represents the root of an HTML document.

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

The manifest attribute gives the address of the document's application cache manifest, if there is one. If the attribute is present, the attribute's value must be a valid non-empty URL potentially surrounded by spaces.

The manifest attribute is part of the legacy "offline web applications" feature, which is in the process of being removed from the web platform. (This is a long process that takes many years.) Using the manifest attribute at this time is highly discouraged. Use service workers instead. [SW]

The manifest attribute only has an effect during the early stages of document load. Changing the attribute dynamically thus has no effect (and thus, no DOM API is provided for this attribute).

For the purposes of application cache selection, later base elements cannot affect the parsing of URLs in manifest attributes, as the attributes are processed before those elements are seen.

The window.applicationCache IDL attribute provides scripted access to the offline application cache mechanism.

The html element in the following example declares that the document's language is English. <!DOCTYPE html> < html lang = "en" > < head > < title > Swapping Songs </ title > </ head > < body > < h1 > Swapping Songs </ h1 > < p > Tonight I swapped some of the songs I wrote with some friends, who gave me some of the songs they wrote. I love sharing my music. </ p > </ body > </ html >

4.2 Document metadata

4.2.1 The head element

✔ MDN Element/head Support in all current engines. Firefox 1+ Safari Yes Chrome 1+ Opera Yes Edge 79+ Edge (Legacy) 12+ Internet Explorer Yes Firefox Android 4+ Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android Yes

✔ MDN HTMLHeadElement Support in all current engines. Firefox 1+ Safari Yes Chrome Yes Opera Yes Edge Yes Edge (Legacy) 12+ Internet Explorer Yes Firefox Android 4+ Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android Yes

The head element represents a collection of metadata for the Document .

The collection of metadata in a head element can be large or small. Here is an example of a very short one: <!doctype html> < html lang = en > < head > < title > A document with a short head </ title > </ head > < body > ... Here is an example of a longer one: <!DOCTYPE HTML> < HTML LANG = "EN" > < HEAD > < META CHARSET = "UTF-8" > < BASE HREF = "https://www.example.com/" > < TITLE > An application with a long head </ TITLE > < LINK REL = "STYLESHEET" HREF = "default.css" > < LINK REL = "STYLESHEET ALTERNATE" HREF = "big.css" TITLE = "Big Text" > < SCRIPT SRC = "support.js" ></ SCRIPT > < META NAME = "APPLICATION-NAME" CONTENT = "Long headed application" > </ HEAD > < BODY > ...

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

4.2.2 The title element

✔ MDN Element/title Support in all current engines. Firefox 1+ Safari 1+ Chrome 1+ Opera Yes Edge 79+ Edge (Legacy) 12+ Internet Explorer 1+ Firefox Android 4+ Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android Yes

✔ MDN HTMLTitleElement Support in all current engines. Firefox 1+ Safari Yes Chrome Yes Opera Yes Edge Yes Edge (Legacy) 12+ Internet Explorer Yes Firefox Android 4+ Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android Yes

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

There must be no more than one title element per document.

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

title . text [ = value ] Returns the child text content of the element. Can be set, to replace the element's children with the given value.

The text attribute's getter must return this title element's child text content.

The text attribute's setter must string replace all with the given value within this title element.

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

✔ MDN Element/base Support in all current engines. Firefox 1+ Safari Yes Chrome Yes Opera Yes Edge Yes Edge (Legacy) 12+ Internet Explorer Yes Firefox Android 4+ Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android Yes

✔ MDN HTMLBaseElement Support in all current engines. Firefox 1+ Safari Yes Chrome Yes Opera Yes Edge Yes Edge (Legacy) 12+ Internet Explorer Yes Firefox Android 4+ Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android Yes

The base element allows authors to specify the document base URL for the purposes of parsing URLs, and the name of the default browsing context for the purposes of . The element does not represent any content beyond this information.

There must be no more than one base element per document.

A base element must have either an href attribute, a target attribute, or both.

The href content attribute, if specified, must contain a valid URL potentially surrounded by spaces.

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

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

The target attribute, if specified, must contain a valid browsing context name or keyword, which specifies which browsing context is to be used as the default when hyperlinks and forms in the Document cause navigation.

A base element, if it has a target attribute, must come before any elements in the tree that represent hyperlinks.

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

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

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

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

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

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

To set the frozen base URL for an element element :

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

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

The href IDL attribute, on setting, must set the href content attribute to the given new value.

The target IDL attribute must reflect the content attribute of the same name.

In this example, a base element is used to set the document base URL: <!DOCTYPE html> < html lang = "en" > < head > < title > This is an example for the < base > element </ title > < base href = "https://www.example.com/news/index.html" > </ head > < body > < p > Visit the < a href = "archives.html" > archives </ a > . </ p > </ body > </ html > The link in the above example would be a link to " https://www.example.com/news/archives.html ".

4.2.4 The link element

✔ MDN Element/link Support in all current engines. Firefox 1+ Safari Yes Chrome 1+ Opera Yes Edge 79+ Edge (Legacy) 12+ Internet Explorer Yes Firefox Android 4+ Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android Yes

✔ MDN HTMLLinkElement Support in all current engines. Firefox 1+ Safari Yes Chrome Yes Opera Yes Edge Yes Edge (Legacy) 12+ Internet Explorer Yes Firefox Android 4+ Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android Yes

The link element allows authors to link their document to other resources.

The address of the link(s) is given by the href attribute. If the href attribute is present, then its value must be a valid non-empty URL potentially surrounded by spaces. One or both of the href or imagesrcset attributes must be present.

If both the href and imagesrcset attributes are absent, then the element does not define a link.

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

✔ MDN HTMLLinkElement/rel Support in all current engines. Firefox Yes Safari Yes Chrome Yes Opera Yes Edge Yes Edge (Legacy) 12+ Internet Explorer Yes Firefox Android Yes Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android Yes

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 unordered set of unique space-separated tokens. The allowed keywords and their meanings are defined in a later section. If the rel attribute is absent, has no keywords, or if none of the keywords used are allowed according to the definitions in this specification, then the element does not create any links.

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

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

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

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

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

Two categories of links can be created using the link element: links to external resources and hyperlinks. The link types section defines whether a particular link type is an external resource or a hyperlink. One link element can create multiple links (of which some might be external resource links and some might be hyperlinks); exactly which and how many links are created depends on the keywords given in the rel attribute. User agents must process the links on a per-link basis, not a per-element basis.

Each link created for a link element is handled separately. For instance, if there are two link elements with rel="stylesheet" , they each count as a separate external resource, and each is affected by its own attributes independently. Similarly, if a single link element has a rel attribute with the value next stylesheet , it creates both a hyperlink (for the next keyword) and an external resource link (for the stylesheet keyword), and they are affected by other attributes (such as media or title ) differently.

For example, the following link element creates two hyperlinks (to the same page): < link rel = "author license" href = "/about" > The two links created by this element are one whose semantic is that the target page has information about the current page's author, and one whose semantic is that the target page has information regarding the license under which the current page is provided.

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

The exact behavior for links to external resources depends on the exact relationship, as defined for the relevant link type.

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

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

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

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

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

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

The title attribute gives the title of the link. With one exception, it is purely advisory. The value is text. The exception is for style sheet links that are in a document tree, for which the title attribute defines CSS style sheet sets.

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

The imagesrcset attribute may be present, and is a srcset attribute.

The imagesrcset and href attributes (if width descriptors are not used) together contribute the image sources to the source set.

If the imagesrcset attribute is present and has any using a width descriptor, the imagesizes attribute must also be present, and is a sizes attribute. The imagesizes attribute contributes the source size to the source set.

The imagesrcset and imagesizes attributes must only be specified on link elements that have both a rel attribute that specifies the preload keyword, as well as an as attribute in the " image " state.

These attributes allow preloading the appropriate resource that is later used by an img element that has the corresponding values for its srcset and sizes attributes: < link rel = "preload" as = "image" imagesrcset = "wolf_400px.jpg 400w, wolf_800px.jpg 800w, wolf_1600px.jpg 1600w" imagesizes = "50vw" > <!-- ... later, or perhaps inserted dynamically ... --> < img src = "wolf.jpg" alt = "A rad wolf" srcset = "wolf_400px.jpg 400w, wolf_800px.jpg 800w, wolf_1600px.jpg 1600w" sizes = "50vw" > Note how we omit the href attribute, as it would only be relevant for browsers that do not support imagesrcset , and in those cases it would likely cause the incorrect image to be preloaded.

The imagesrcset attribute can be combined with the media attribute to preload the appropriate resource selected from a picture element's sources, for art direction: < link rel = "preload" as = "image" imagesrcset = "dog-cropped-1x.jpg, dog-cropped-2x.jpg 2x" media = "(max-width: 800px)" > < link rel = "preload" as = "image" imagesrcset = "dog-wide-1x.jpg, dog-wide-2x.jpg 2x" media = "(min-width: 801px)" > <!-- ... later, or perhaps inserted dynamically ... --> < picture > < source srcset = "dog-cropped-1x.jpg, dog-cropped-2x.jpg 2x" media = "(max-width: 800px)" > < img src = "dog-wide-1x.jpg" srcset = "dog-wide-2x.jpg 2x" alt = "An awesome dog" > </ picture >

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

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

The as attribute specifies the potential destination for a preload request for the resource given by the href attribute. It is an enumerated attribute. Each potential destination is a keyword for this attribute, mapping to a state of the same name. The attribute must be specified on link elements that have a rel attribute that contains the preload keyword. It may be specified on link elements that have a rel attribute that contains the modulepreload keyword; in such cases it must have a value which is a script-like destination. For other link elements, it must not be specified.

The processing model for how the as attribute is used is given in an individual link type's fetch and process the linked resource algorithm.

The attribute does not have a missing value default or invalid value default, meaning that invalid or missing values for the attribute map to no state. This is accounted for in the processing model. For preload links, both conditions are an error; for modulepreload links, a missing value will be treated as " script ".

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

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

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

link elements have an associated explicitly enabled boolean. It is initially false.

The disabled attribute is a boolean attribute that is used with the stylesheet link type. The attribute must only be specified on link elements that have a rel attribute that contains the stylesheet keyword.

Whenever the disabled attribute is removed, set the link element's explicitly enabled attribute to true.

Removing the disabled attribute dynamically, e.g., using document.querySelector("link").removeAttribute("disabled") , will fetch and apply the style sheet: < link disabled rel = "alternate stylesheet" href = "css/pooh" >

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

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

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

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

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

The imageSrcset IDL attribute must reflect the imagesrcset content attribute.

The imageSizes IDL attribute must reflect the imagesizes content attribute.

✔ MDN HTMLLinkElement/relList Support in all current engines. Firefox 30+ Safari Yes Chrome 54+ Opera Yes Edge 79+ Edge (Legacy) 17+ Internet Explorer No Firefox Android 30+ Safari iOS Yes Chrome Android 54+ WebView Android 54+ Samsung Internet 6.0+ Opera Android Yes

The relList IDL attribute must reflect the rel content attribute.

4.2.4.1 Processing the media attribute

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

However, if the link is an external resource link, then the media attribute is prescriptive. The user agent must apply the external resource when the media attribute's value matches the environment and the other relevant conditions apply, and must not apply it otherwise.

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

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

4.2.4.2 Processing the type attribute

If the type attribute is present, then the user agent must assume that the resource is of the given type (even if that is not a valid MIME type string, 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 fetch and process the linked resource; if the UA does support the given MIME type for the given link relationship, then the UA should fetch and process the linked 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 fetch and process the linked resource if the type was known and supported, then the user agent should fetch and process the linked resource under the assumption that it will be supported.

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

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

The stylesheet link type defines rules for processing the resource's Content-Type metadata.

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

If a document contains style sheet links labeled as follows: < link rel = "stylesheet" href = "A" type = "text/plain" > < link rel = "stylesheet" href = "B" type = "text/css" > < link rel = "stylesheet" href = "C" > ...then a compliant UA that supported only CSS style sheets would fetch the B and C files, and skip the A file (since text/plain is not the MIME type for CSS style sheets). For files B and C, it would then check the actual types returned by the server. For those that are sent as text/css , it would apply the styles, but for those labeled as text/plain , or any other type, it would not. If one of the two files was returned without a Content-Type metadata, or with a syntactically incorrect type like Content-Type: "null" , then the default type for stylesheet links would kick in. Since that default type is text/css , the style sheet would nonetheless be applied.

4.2.4.3 Fetching and processing a resource from a link element

All external resource links have a fetch and process the linked resource algorithm, which takes a link element el . They also have linked resource fetch setup steps which take a link element el and request request . Individual link types may provide their own fetch and process the linked resource algorithm, but unless explicitly stated, they use the default fetch and process the linked resource algorithm. Similarly, individual link types may provide their own linked resource fetch setup steps, but unless explicitly stated, these steps just return true.

The default fetch and process the linked resource , given a link element el , is as follows:

User agents may opt to only try to fetch and process such resources when they are needed, instead of pro-actively fetching all the external resources that are not applied.

Similar to the fetch and process the linked resource algorithm, all external resource links have a process the linked resource algorithm which takes a link element el , boolean success , and response response . Unless an individual link type provides its own process the linked resource algorithm, the default process the linked resource algorithm, given a link element el , and boolean success (ignoring response ) is used:

Unless otherwise specified for a given rel keyword, the element must delay the load event of the element's node document until all the attempts to fetch and process the linked resource and its critical subresources are complete. (Resources that the user agent has not yet attempted to fetch and process, e.g., because it is waiting for the resource to be needed, do not delay the load event.)

4.2.4.4 Processing ` Link ` headers

HTTP ` Link ` headers, if supported, must be assumed to come before any links in the document, in the order that they were given in the HTTP message. These headers are to be processed according to the rules given in the relevant specifications. [HTTP] [WEBLINK]

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

The processing of ` Link ` headers, in particular their influence on a Document 's script-blocking style sheet counter, is not defined. See issue #4224 for discussion on integrating this into the spec.

Interactive user agents may provide users with a means to created using the 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 created with each element in the document:

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

The title of the resource (given by the attribute).

The address of the resource (given by the attribute).

The language of the resource (given by the attribute).

The optimum media for the resource (given by the attribute).

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

The of elements that create is to created by the element.

4.2.5 The element

✔ MDN Element/meta Support in all current engines. Firefox 1+ Safari Yes Chrome Yes Opera Yes Edge Yes Edge (Legacy) 12+ Internet Explorer Yes Firefox Android 4+ Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android Yes

✔ MDN HTMLMetaElement Support in all current engines. Firefox 1+ Safari Yes Chrome Yes Opera Yes Edge Yes Edge (Legacy) 12+ Internet Explorer Yes Firefox Android Yes Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android Yes

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, its value must be an ASCII case-insensitive match for the string " utf-8 ".

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

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

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

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

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

4.2.5.1 Standard metadata names

✔ MDN Element/meta/name Support in all current engines. Firefox 1+ Safari Yes Chrome Yes Opera Yes Edge Yes Edge (Legacy) 12+ Internet Explorer Yes Firefox Android 4+ Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android Yes

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.

4.2.5.2 Other metadata names

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

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

If either the name is a URL, or the value of its accompanying content attribute is a URL; in those cases, registering it as an extension to the predefined set of link types is encouraged (rather than creating a new metadata name).

If the name is for something expected to have processing requirements in user agents; in that case it ought to be standardized.

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

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

Keyword The actual name being defined. The name should not be confusingly similar to any other defined name (e.g. differing only in case). Brief description A short non-normative description of what the metadata name's meaning is, including the format the value is required to be in. Specification A link to a more detailed description of the metadata name's semantics and requirements. It could be another page on the Wiki, or a link to an external page. Synonyms A list of other names that have exactly the same processing requirements. Authors should not use the names defined to be synonyms (they are only intended to allow user agents to support legacy content). Anyone may remove synonyms that are not used in practice; only names that need to be processed as synonyms for compatibility with legacy content are to be registered in this way. Status One of the following: Proposed The name has not received wide peer review and approval. Someone has proposed it and is, or soon will be, using it. Ratified The name has received wide peer review and approval. It has a specification that unambiguously defines how to handle pages that use the name, including when they use it in incorrect ways. Discontinued The metadata name has received wide peer review and it has been found wanting. Existing pages are using this metadata name, but new pages should avoid it. The "brief description" and "specification" entries will give details of what authors should use instead, if anything. If a metadata name is found to be redundant with existing values, it should be removed and listed as a synonym for the existing value. If a metadata name is added in the "proposed" state for a period of a month or more without being used or specified, then it may be removed from the WHATWG Wiki MetaExtensions page. If a metadata name is added with the "proposed" status and found to be redundant with existing values, it should be removed and listed as a synonym for the existing value. If a metadata name is added with the "proposed" status and found to be harmful, then it should be changed to "discontinued" status. Anyone can change the status at any time, but should only do so in accordance with the definitions above.

4.2.5.3 Pragma directives

When the http-equiv attribute is specified on a meta element, the element is a pragma directive.

The http-equiv attribute is an enumerated attribute. The following table lists the keywords defined for this attribute. The states given in the first cell of the rows with keywords give the states to which those keywords map. Some of the keywords are non-conforming, as noted in the last column.

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:

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

4.2.5.4 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 Encoding standard requires use of the UTF-8 character encoding and requires use of the " utf-8 " encoding label to identify it. Those requirements necessitate that the document's character encoding declaration, if it exists, specifies an encoding label using an ASCII case-insensitive match for " utf-8 ". Regardless of whether a character encoding declaration is present or not, the actual character encoding used to encode the document must be UTF-8. [ENCODING]

To enforce the above rules, authoring tools must default to using UTF-8 for newly-created documents.

The following restrictions also apply:

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 encoding must be specified using a meta element with a charset attribute or a meta element with an http-equiv attribute in the Encoding declaration state.

A character encoding declaration is required (either in the Content-Type metadata or explicitly in the file) even when all characters are in the ASCII range, because a character encoding is needed to process non-ASCII characters entered by the user in forms, in URLs generated by scripts, and so forth. Using non-UTF-8 encodings can have unexpected results on form submission and URL encodings, which use the document's character encoding by default.

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

In XML, the XML declaration should be used for inline character encoding information, if necessary.

In HTML, to declare that the character encoding is UTF-8, the author could include the following markup near the top of the document (in the head element): < meta charset = "utf-8" > In XML, the XML declaration would be used instead, at the very top of the markup: <?xml version="1.0" encoding="utf-8"?>

4.2.6 The style element

✔ MDN Element/style Support in all current engines. Firefox 1+ Safari 1+ Chrome 1+ Opera 3.5+ Edge 79+ Edge (Legacy) 12+ Internet Explorer 3+ Firefox Android 4+ Safari iOS 1+ Chrome Android 18+ WebView Android 1+ Samsung Internet 1.0+ Opera Android 10.1+

✔ MDN HTMLStyleElement Support in all current engines. Firefox Yes Safari Yes Chrome Yes Opera Yes Edge Yes Edge (Legacy) 12+ Internet Explorer Yes Firefox Android Yes Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android Yes

The style element allows authors to embed CSS style sheets 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.

✔ MDN HTMLStyleElement/media Support in all current engines. Firefox Yes Safari Yes Chrome Yes Opera Yes Edge Yes Edge (Legacy) 12+ Internet Explorer Yes Firefox Android Yes Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android Yes

The media attribute says which media the styles apply to. The value must be a valid media query list. 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.

⚠ MDN Alternative_style_sheets Support in one engine only. Firefox 3+ Safari ? Chrome 1–48 Opera Yes Edge No Edge (Legacy) ? Internet Explorer 8+ Firefox Android 4+ Safari iOS ? Chrome Android ? WebView Android ? Samsung Internet ? Opera Android ?

The title attribute on style elements defines CSS 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. If the style element is not in a document tree, then the title attribute is ignored. [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 child text content of a style element must be that of a conformant style sheet.

The user agent must run the algorithm whenever one of the following conditions occur:

The algorithm is as follows:

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 run these steps:

The element must delay the load event of the element's node 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 IDL attribute must reflect the content attribute of the same name.

The interface is also implemented by this element. [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 Interactions of styling and scripting

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 immediately made available to script; otherwise, the style rules must only be made available to script once the event loop reaches its step.

An element el in the context of a Document of an HTML parser or XML parser contributes a script-blocking style sheet if all of the following conditions are true:

el was created by that Document 's parser.

el is either a style element or a link element that was an external resource link that contributes to the styling processing model when the el was created by the parser.

If the el is a link element, it's media attribute's value matches the environment.

el 's style sheet was enabled when the element was created by the parser.

The last time the event loop reached step 1, el 's root was that Document .

The user agent hasn't given up on loading that particular style sheet yet. A user agent may give up on loading 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). Implementers 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.

It is expected that counterparts to the above rules also apply to <?xml-stylesheet?> PIs and HTTP ` Link ` headers. However, this has not yet been thoroughly investigated.

A Document has a script-blocking style sheet counter , which is a number, initially 0.

A Document has a style sheet that is blocking scripts if its script-blocking style sheet counter is greater than 0, or if that Document has a non-null browsing context whose container document is non-null and has a script-blocking style sheet counter greater than 0.