HTML Metadata

interface HTMLMetaElement : HTMLElement {
  attribute DOMString name;
  attribute DOMString httpEquiv;
  attribute DOMString content;

  // also has obsolete members
};

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

Standard metadata names

This specification defines a few names for the name attribute of the meta element.

Names are case-insensitive, and must be compared in an ASCII case-insensitive manner.

application-name

The value must be a short free-form string giving the name of the Web application that the page represents. If the page is not a Web application, the application-name metadata name must not be used. Translations of the Web application's name may be given, using the lang attribute to specify the language of each name.

There must not be more than one meta element with a given language and with its name attribute set to the value application-name per document.

User agents may use the application name in UI in preference to the page's title, since the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.

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

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

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

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

author

The value must be a free-form string giving the name of one of the page's authors.

description

The value must be a free-form string that describes the page. The value must be appropriate for use in a directory of pages, e.g. in a search engine. There must not be more than one meta element with its name attribute set to the value description per document.

generator

The value must be a free-form string that identifies one of the software packages used to generate the document. This value must not be used on pages whose markup is not generated by software, e.g. pages whose markup was written by a user in a text editor.

Here is what a tool called "Frontweaver" could include in its output, in the page's head element, to identify itself as the tool used to generate the page:

<meta name=generator content="Frontweaver 8.2">

keywords

The value must be a set of comma-separated tokens, each of which is a keyword relevant to the page.

This page about typefaces on British motorways uses a meta element to specify some keywords that users might use to look for the page:

<!DOCTYPE HTML>
<html>
 <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.

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 rejected as invalid. Conformance checkers may cache this information (e.g. for performance reasons or to avoid the use of unreliable network connectivity).

When an author uses a new metadata name not defined by either this specification or the Wiki page, conformance checkers should offer to add the value to the Wiki, with the details described above, with the "proposed" status.

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

Pragma directives

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

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

State	Keyword	Notes
Content Language	`content-language`	Non-conforming
Encoding declaration	`content-type`
Default style	`default-style`
Refresh	`refresh`
Cookie setter	`set-cookie`	Non-conforming
X-UA-Compatible	`x-ua-compatible`

When a meta element is inserted into the document, if its http-equiv attribute is present and represents one of the above states, then the user agent must run the algorithm appropriate for that state, as described in the following list:

Content language state (http-equiv="content-language")

This feature is non-conforming. Authors are encouraged to use the lang attribute instead.

This pragma sets the pragma-set default language. Until such a pragma is successfully processed, there is no pragma-set default language.

If the meta element has no content attribute, then abort these steps.
If the element's content attribute contains a U+002C COMMA character (,) then abort these steps.
Let input be the value of the element's content attribute.
Let position point at the first character of input.
Skip whitespace.
Collect a sequence of characters that are not space characters.
Let candidate be the string that resulted from the previous step.
If candidate is the empty string, abort these steps.
Set the pragma-set default language to candidate.

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

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

Encoding declaration state (http-equiv="content-type")

The Encoding declaration state is just an alternative form of setting the charset attribute: it is a character encoding declaration. This state's user agent requirements are all handled by the parsing section of the specification.

For meta elements with an http-equiv attribute in the Encoding declaration state, the content attribute must have a value that is an ASCII case-insensitive match for a string that consists of: the literal string "text/html;", optionally followed by any number of space characters, followed by the literal string "charset=", followed by one of the labels of the character encoding of the character encoding declaration.

A document must not contain both a meta element with an http-equiv attribute in the Encoding declaration state and a meta element with the charset attribute present.

The Encoding declaration state may be used in HTML documents, but elements with an http-equiv attribute in that state must not be used in XML documents.

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

This pragma sets the name of the default 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 FULL STOP 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 SEMICOLON character (;) or a U+002C COMMA 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+0055 LATIN CAPITAL LETTER U character (U) or a U+0075 LATIN SMALL LETTER U character (u), then advance position to the next character. Otherwise, jump to the last step.
If the character in input pointed to by position is a U+0052 LATIN CAPITAL LETTER R character (R) or a U+0072 LATIN SMALL LETTER R character (r), then advance position to the next character. Otherwise, jump to the last step.
If the character in input pointed to by position is s U+004C LATIN CAPITAL LETTER L character (L) or a U+006C LATIN SMALL LETTER L character (l), then advance position to the next character. Otherwise, jump to the last step.
Skip whitespace.
If the character in input pointed to by position is a U+003D EQUALS SIGN (=), then advance position to the next character. Otherwise, jump to the last step.
Skip whitespace.
If the character in input pointed to by position is either a U+0027 APOSTROPHE character (') or U+0022 QUOTATION MARK character ("), then let quote be that character, and advance position to the next character. Otherwise, let quote be the empty string.
Let url be equal to the substring of input from the character at position to the end of the string.
If quote is not the empty string, and there is a character in url equal to quote, then truncate url at that character, so that it and all subsequent characters are removed.
Strip any trailing space characters from the end of url.
Strip any U+0009 CHARACTER TABULATION (tab), U+000A LINE FEED (LF), and U+000D CARRIAGE RETURN (CR) characters from url.
Resolve the url value to an absolute URL, relative to the meta element. If this fails, abort these steps.
Perform one or more of the following steps:
- After the refresh has come due (as defined below), if the user has not canceled the redirect and if the meta element's node 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 EQUALS SIGN character (=), followed by a valid URL that does not start with a literal U+0027 APOSTROPHE (') or U+0022 QUOTATION MARK (") character.

In the former case, the integer represents a number of seconds before the page is to be reloaded; in the latter case the integer represents a number of seconds before the page is to be replaced by the page at the given URL.

A news organization's front page could include the following markup in the page's head element, to ensure that the page automatically reloads from the server every five minutes:

<meta http-equiv="Refresh" content="300">

A sequence of pages could be used as an automated slide show by making each page refresh to the next page in the sequence, using markup such as the following:

<meta http-equiv="Refresh" content="20; URL=page4.html">

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]] [[!ENCODING]]

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

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

For meta elements with an http-equiv attribute in the X-UA-Compatible state, the content attribute must have the value "IE=edge".

User agents are required to ignore this pragma.

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

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 behaviour 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 behaviour being different for user agents that implement HTML than for user agents that do not.

Anyone is free to edit the WHATWG Wiki PragmaExtensions page at any time to add a pragma directive satisfying these conditions. Such registrations must specify the following information:

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

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

Specifying the document's character encoding

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

The following restrictions apply to character encoding declarations:

The character encoding name given must be an ASCII case-insensitive match for one of the labels of the character encoding used to serialise the file. [[!ENCODING]]
The character encoding declaration must be serialised without the use of character references or character escapes of any kind.
The element containing the character encoding declaration must be serialised 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. [[!ENCODING]]

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

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

The `link` element

Categories:

Metadata content.

If the itemprop attribute is present: flow content.

If the itemprop attribute is present: phrasing content.

Contexts in which this element can be used:

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.

Content model:

Nothing.

Tag omission in text/html:

No end tag.

Content attributes:

Global attributes

href — Address of the hyperlink

crossorigin — How the element handles crossorigin requests

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

media — Applicable media

hreflang — Language of the linked resource

type — Hint for the type of the referenced resource

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

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

Allowed ARIA role attribute values:

link (default - do not set).

Allowed ARIA State and Property Attributes:

Global aria-* attributes

Any aria-* attributes applicable to the allowed roles.

For role value

DOM interface:

interface HTMLLinkElement : HTMLElement {
  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;

  // also has obsolete members
};
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 behaviour 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 current state of the element's crossorigin content attribute, the origin being the origin of the link element's node 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 node document until all the attempts to obtain the resource and its critical subresources are complete. (Resources that the user agent has not yet attempted to obtain, e.g. because it is waiting for the resource to be needed, do not delay the load event.)

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

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.

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

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

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

The IDL attribute relList must reflect the rel content attribute.

The LinkStyle interface is also implemented by this element. [[!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">

The meta element