GeezerVison

The activation behavior of an a or area element element given an event event is:

1. If element has no href attribute, then return.

2. Let hyperlinkSuffix be null.

3. If element is an a element, and event's target is an img with an ismap attribute specified:

   1. Let x and y be 0.

   2. If event's isTrusted attribute is initialized to true, then set x to the distance in CSS pixels from the left edge of the image to the location of the click, and set y to the distance in CSS pixels from the top edge of the image to the location of the click.

   3. If x is negative, set x to 0.

   4. If y is negative, set y to 0.

   5. Set hyperlinkSuffix to the concatenation of U+003F (?), the value of x expressed as a base-ten integer using ASCII digits, U+002C (,), and the value of y expressed as a base-ten integer using ASCII digits.

4. Let userInvolvement be event's user navigation involvement.

5. If the user has expressed a preference to download the hyperlink, then set userInvolvement to "browser UI".

   That is, if the user has expressed a specific preference for downloading, this no longer counts as merely "activation".

6. If element has a download attribute, or if the user has expressed a preference to download the hyperlink, then download the hyperlink created by element with hyperlinkSuffix set to hyperlinkSuffix and userInvolvement set to userInvolvement.

7. Otherwise, follow the hyperlink created by element with hyperlinkSuffix set to hyperlinkSuffix and userInvolvement set to userInvolvement.

A hyperlink element has the following extract an origin steps:

1. If this's url is null, then return null.

2. Return this's url's origin.

When hyperlink elements are created, the user agent must set the url.

A hyperlink element has an associated reinitialize url algorithm, which runs these steps:

1. If the element's url is non-null, its scheme is "blob", and it has an opaque path, then terminate these steps.

2. Set the url.

The origin getter steps are:

1. Reinitialize url.

2. If this's url is null, return the empty string.

3. Return the serialization of this's url's origin.

The protocol getter steps are:

1. Reinitialize url.

2. If this's url is null, return ":".

3. Return this's url's scheme, followed by ":".

The protocol setter steps are:

1. Reinitialize url.

2. If this's url is null, then return.

3. Basic URL parse the given value, followed by ":", with this's url as url and scheme start state as state override.

   Because the URL parser ignores multiple consecutive colons, providing a value of "https:" (or even "https::::") is the same as providing a value of "https".

4. Update href.

The username getter steps are:

1. Reinitialize url.

2. If this's url is null, return the empty string.

3. Return this's url's username.

The username setter steps are:

1. Reinitialize url.

2. Let url be this's url.

3. If url is null or url cannot have a username/password/port, then return.

4. Set the username, given url and the given value.

5. Update href.

The password getter steps are:

1. Reinitialize url.

2. Let url be this's url.

3. If url is null, then return the empty string.

4. Return url's password.

The password setter steps are:

1. Reinitialize url.

2. Let url be this's url.

3. If url is null or url cannot have a username/password/port, then return.

4. Set the password, given url and the given value.

5. Update href.

The host getter steps are:

1. Reinitialize url.

2. Let url be this's url.

3. If url or url's host is null, return the empty string.

4. If url's port is null, return url's host, serialized.

5. Return url's host, serialized, followed by ":" and url's port, serialized.

The host setter steps are:

1. Reinitialize url.

2. Let url be this's url.

3. If url is null or url has an opaque path, then return.

4. Basic URL parse the given value, with url as url and host state as state override.

5. Update href.

The hostname getter steps are:

1. Reinitialize url.

2. Let url be this's url.

3. If url or url's host is null, return the empty string.

4. Return url's host, serialized.

The hostname setter steps are:

1. Reinitialize url.

2. Let url be this's url.

3. If url is null or url has an opaque path, then return.

4. Basic URL parse the given value, with url as url and hostname state as state override.

5. Update href.

The port getter steps are:

1. Reinitialize url.

2. Let url be this's url.

3. If url or url's port is null, return the empty string.

4. Return url's port, serialized.

The port setter steps are:

1. Reinitialize url.

2. Let url be this's url.

3. If url is null or url cannot have a username/password/port, then return.

4. If the given value is the empty string, then set url's port to null.

5. Otherwise, basic URL parse the given value, with url as url and port state as state override.

6. Update href.

The pathname getter steps are:

1. Reinitialize url.

2. Let url be this's url.

3. If url is null, then return the empty string.

4. Return the result of URL path serializing url.

The pathname setter steps are:

1. Reinitialize url.

2. Let url be this's url.

3. If url is null or url has an opaque path, then return.

4. Set url's path to the empty list.

5. Basic URL parse the given value, with url as url and path start state as state override.

6. Update href.

The search getter steps are:

1. Reinitialize url.

2. Let url be this's url.

3. If url is null, or url's query is either null or the empty string, return the empty string.

4. Return "?", followed by url's query.

The search setter steps are:

1. Reinitialize url.

2. Let url be this's url.

3. If url is null, terminate these steps.

4. If the given value is the empty string, set url's query to null.

5. Otherwise:

   1. Let input be the given value with a single leading "?" removed, if any.

   2. Set url's query to the empty string.

   3. Basic URL parse input, with url as url and query state as state override.

6. Update href.

The hash getter steps are:

1. Reinitialize url.

2. Let url be this's url.

3. If url is null, or url's fragment is either null or the empty string, return the empty string.

4. Return "#", followed by url's fragment.

The hash setter steps are:

1. Reinitialize url.

2. Let url be this's url.

3. If url is null, then return.

4. If the given value is the empty string, set url's fragment to null.

5. Otherwise:

   1. Let input be the given value with a single leading "#" removed, if any.

   2. Set url's fragment to the empty string.

   3. Basic URL parse input, with url as url and fragment state as state override.

6. Update href.

The href getter steps are:

1. Reinitialize url.

2. Let url be this's url.

3. If url is null and this has no href content attribute, return the empty string.

4. Otherwise, if url is null, return this's href content attribute's value.

5. Return url, serialized.

The HTML element insertion steps for a and area elements, given insertedNode, are:

1. If insertedNode is not connected, then return.

2. Consider speculative loads given insertedNode's node document.

The HTML element removing steps for a and area elements, given removedNode, isSubtreeRoot, and oldAncestor are:

1. If oldAncestor is not connected, then return.

2. Consider speculative loads given oldAncestor's node document.

The HTML element moving steps for a and area elements, given movedNode, are:

1. Consider speculative loads given movedNode's node document.

The following attribute change steps, given element, localName, oldValue, value, and namespace, are used for all a and area elements:

1. If namespace is not null, then return.

2. If oldValue equals value, then return.

3. If localName is href, then set the url given element.

   This is only observable for blob: URLs as parsing them involves a Blob URL Store lookup.

4. If localName is href, referrerpolicy, or rel, then consider speculative loads given element's node document.

To update href for an HTMLAnchorElement or HTMLAreaElement element, set the element's href content attribute's value to the element's url, serialized.

The set the url algorithm for HTMLAnchorElement and HTMLAreaElement elements is as follows:

1. Set this element's url to null.

2. If this element's href content attribute is absent, then return.

3. Let url be the result of encoding-parsing a URL given this element's href content attribute's value, relative to this element's node document.

4. If url is not failure, then set this element's url to url.

An element element cannot navigate if any of the following are true:

• element's node document is not fully active; or

• element is not an a element and is not connected.

To get an element's noopener, given an a, area, or form element element, a URL record url, and a string target, perform the following steps. They return a boolean.

1. If element's link types include the noopener or noreferrer keyword, then return true.

2. If element's link types do not include the opener keyword and target is an ASCII case-insensitive match for "_blank", then return true.

3. If url's blob URL entry is not null:

   1. Let blobOrigin be url's blob URL entry's environment's origin.

   2. Let topLevelOrigin be element's relevant settings object's top-level origin.

   3. If blobOrigin is not same site with topLevelOrigin, then return true.

4. Return false.

To follow the hyperlink created by an element subject, given an optional hyperlinkSuffix (default null) and an optional userInvolvement (default "none"):

1. If subject cannot navigate, then return.

2. Let targetAttributeValue be the empty string.

3. If subject is an a or area element, then set targetAttributeValue to the result of getting an element's target given subject.

4. Let urlRecord be the result of encoding-parsing a URL given subject's href attribute value, relative to subject's node document.

5. If urlRecord is failure, then return.

6. Let noopener be the result of getting an element's noopener with subject, urlRecord, and targetAttributeValue.

7. Let targetNavigable be the first return value of applying the rules for choosing a navigable given targetAttributeValue, subject's node navigable, and noopener.

8. If targetNavigable is null, then return.

9. Let urlString be the result of applying the URL serializer to urlRecord.

10. If hyperlinkSuffix is non-null, then append it to urlString.

11. Navigate targetNavigable to urlString using subject's node document, with referrerPolicy set to subject's hyperlink referrer policy, userInvolvement set to userInvolvement, and sourceElement set to subject.

    Unlike many other types of navigations, following hyperlinks does not have special "replace" behavior for when documents are not completely loaded. This is true for both user-initiated instances of following hyperlinks, as well as script-triggered ones via, e.g., aElement.click().

The hyperlink referrer policy for an element subject is the value returned by the following steps:

1. If subject's link types includes the noreferrer keyword, then return "no-referrer".

2. Return the current state of subject's referrerpolicy content attribute.

To download the hyperlink created by an element subject, given an optional hyperlinkSuffix (default null) and an optional userInvolvement (default "none"):

1. If subject cannot navigate, then return.

2. If subject's node document's active sandboxing flag set has the sandboxed downloads browsing context flag set, then return.

3. Let urlString be the result of encoding-parsing-and-serializing a URL given subject's href attribute value, relative to subject's node document.

4. If urlString is failure, then return.

5. If hyperlinkSuffix is non-null, then append it to urlString.

6. If userInvolvement is not "browser UI":

   1. Assert: subject has a download attribute.

   2. Let navigation be subject's relevant global object's navigation API.

   3. Let filename be the value of subject's download attribute.

   4. Let continue be the result of firing a download request navigate event at navigation with destinationURL set to urlString, userInvolvement set to userInvolvement, sourceElement set to subject, and filename set to filename.

   5. If continue is false, then return.

   6. Inform the navigation API about aborting navigation given subject's node navigable.

7. Optionally, the user agent may return, if it believes doing so would safeguard the user from a potentially hostile download.

8. Let request be a new request whose URL is urlString, client is entry settings object, initiator is "download", destination is the empty string, and whose use-URL-credentials flag is set.

9. Fetch request, with processResponse set to the following steps given response response:

   1. Handle as a download response with subject's node navigable and null.

To handle as a download a response response with a navigable navigable and a navigation ID or null navigationId:

1. Let suggestedFilename be the result of getting the suggested filename for response.

2. Let download behavior be the result of WebDriver BiDi download will begin with navigable and a new WebDriver BiDi navigation status whose id is navigationId, status is "pending", url is response's URL, suggestedFilename is suggestedFilename, and downloadResponse is response.

3. If download behavior is not null and download behavior's allowed is false:

   1. Invoke WebDriver BiDi download end with navigable and a new WebDriver BiDi navigation status whose id is navigationId, status is "canceled", url is response's URL, and downloadResponse is response.

   2. Return.

4. If download behavior is not null, let destinationFolder be download behavior's destinationFolder.

5. Run these steps in parallel:

   1. Run implementation-defined steps to save response for later use. If destinationFolder is not null, the user agent should save the file to that path. If the user agent needs a filename, the user agent should use the suggestedFilename.

   2. If any of the following are true:

      • the download is canceled by the user;

      • the download is canceled by the user agent;

      • an error occurs (for example, a network error, not enough storage, an unavailable destination folder);

      then:

      1. Invoke WebDriver BiDi download end with navigable and a new WebDriver BiDi navigation status whose id is navigationId, status is "canceled", url is response's URL.

      2. Return.

   3. When the download completes successfully, invoke WebDriver BiDi download end with navigable and a new WebDriver BiDi navigation status whose id is navigationId, status is "complete", downloadedFilepath is an absolute path of the downloaded file if available, otherwise null, url is response's URL, and downloadResponse is response.

To get the suggested filename for a response response:

This algorithm is intended to mitigate security dangers involved in downloading files from untrusted sites, and user agents are strongly urged to follow it.

1. Let filename be the undefined value.

2. If response has a `Content-Disposition` header, that header specifies the attachment disposition type, and the header includes filename information, then let filename have the value specified by the header, and jump to the step labeled sanitize below. [RFC6266]

3. Let interface origin be the origin of the Document in which the download or navigate action resulting in the download was initiated, if any.

4. Let response origin be the origin of the URL of response, unless that URL's scheme component is data, in which case let response origin be the same as the interface origin, if any.

5. If there is no interface origin, then let trusted operation be true. Otherwise, let trusted operation be true if response origin is the same origin as interface origin, and false otherwise.

6. If trusted operation is true and response has a `Content-Disposition` header and that header includes filename information, then let filename have the value specified by the header, and jump to the step labeled sanitize below. [RFC6266]

7. If the download was not initiated from a hyperlink created by an a or area element, or if the element of the hyperlink from which it was initiated did not have a download attribute when the download was initiated, or if there was such an attribute but its value when the download was initiated was the empty string, then jump to the step labeled no proposed filename.

8. Let proposed filename have the value of the download attribute of the element of the hyperlink that initiated the download at the time the download was initiated.

9. If trusted operation is true, let filename have the value of proposed filename, and jump to the step labeled sanitize below.

10. If response has a `Content-Disposition` header and that header specifies the attachment disposition type, let filename have the value of proposed filename, and jump to the step labeled sanitize below. [RFC6266]

11. No proposed filename: If trusted operation is true, or if the user indicated a preference for having the response in question downloaded, let filename have a value derived from the URL of response in an implementation-defined manner, and jump to the step labeled sanitize below.

12. Let filename be set to the user's preferred filename or to a filename selected by the user agent, and jump to the step labeled sanitize below.

    If the algorithm reaches this step, then a download was begun from a different origin than response, and the origin did not mark the file as suitable for downloading, and the download was not initiated by the user. This could be because a download attribute was used to trigger the download, or because response is not of a type that the user agent supports.

    This could be dangerous, because, for instance, a hostile server could be trying to get a user to unknowingly download private information and then re-upload it to the hostile server, by tricking the user into thinking the data is from the hostile server.

    Thus, it is in the user's interests that the user be somehow notified that response comes from quite a different source, and to prevent confusion, any suggested filename from the potentially hostile interface origin should be ignored.

13. Sanitize: Optionally, allow the user to influence filename. For example, a user agent could prompt the user for a filename, potentially providing the value of filename as determined above as a default value.

14. Adjust filename to be suitable for the local file system.

    For example, this could involve removing characters that are not legal in filenames, or trimming leading and trailing whitespace.

15. If the platform conventions do not in any way use extensions to determine the types of file on the file system, then return filename as the filename.

16. Let claimed type be the type given by response's Content-Type metadata, if any is known. Let named type be the type given by filename's extension, if any is known. For the purposes of this step, a type is a mapping of a MIME type to an extension.

17. If named type is consistent with the user's preferences (e.g., because the value of filename was determined by prompting the user), then return filename as the filename.

18. If claimed type and named type are the same type (i.e., the type given by response's Content-Type metadata is consistent with the type given by filename's extension), then return filename as the filename.

19. If the claimed type is known, then alter filename to add an extension corresponding to claimed type.

    Otherwise, if named type is known to be potentially dangerous (e.g. it will be treated by the platform conventions as a native executable, shell script, HTML application, or executable-macro-capable document), then optionally alter filename to add a known-safe extension (e.g. ".txt").

    This last step would make it impossible to download executables, which might not be desirable. As always, implementers are forced to balance security and usability in this matter.

20. Return filename as the filename.

If a hyperlink created by an a or area element has a ping attribute, and the user follows the hyperlink, and the value of the element's href attribute can be parsed, relative to the element's node document, without failure, then the user agent must take the ping attribute's value, split that string on ASCII whitespace, parse each resulting token, relative to the element's node document, and then run these steps for each resulting URL ping URL, ignoring when parsing returns failure:

1. If ping URL's scheme is not an HTTP(S) scheme, then return.

2. Optionally, return. (For example, the user agent might wish to ignore any or all ping URLs in accordance with the user's expressed preferences.)

3. Let settingsObject be the element's node document's relevant settings object.

4. Let request be a new request whose URL is ping URL, method is `POST`, header list is « (`Content-Type`, `text/ping`) », body is `PING`, client is settingsObject, destination is the empty string, credentials mode is "include", referrer is "no-referrer", and whose use-URL-credentials flag is set, and whose initiator type is "ping".

5. Let target URL be the result of encoding-parsing-and-serializing a URL given the element's href attribute's value, relative to the element's node document, and then:

   If the URL of the Document object containing the hyperlink being audited and ping URL have the same origin

   If the origins are different, but the scheme of the URL of the Document containing the hyperlink being audited is not "https"

   request must include a `Ping-From` header with, as its value, the URL of the document containing the hyperlink, and a `Ping-To` HTTP header with, as its value, the target URL.

   Otherwise

   request must include a `Ping-To` HTTP header with, as its value, target URL. request does not include a `Ping-From` header.

6. Fetch request.

The ping attribute is redundant with pre-existing technologies like HTTP redirects and JavaScript in allowing web pages to track which off-site links are most popular or allowing advertisers to track click-through rates.

However, the ping attribute provides these advantages to the user over those alternatives:

• It allows the user to see the final target URL unobscured.
• It allows the UA to inform the user about the out-of-band notifications.
• It allows the UA to optimize the use of available network bandwidth so that the target page loads faster.

The following snippet has three permalinks. A user agent could determine which permalink applies to which part of the spec by looking at where the permalinks are given.

 ...
 <body>
  <h1>Example of permalinks</h1>
  <div id="a">
   <h2>First example</h2>
   <p><a href="a.html" rel="bookmark">This permalink applies to
   only the content from the first H2 to the second H2</a>. The DIV isn't
   exactly that section, but it roughly corresponds to it.</p>
  </div>
  <h2>Second example</h2>
  <article id="b">
   <p><a href="b.html" rel="bookmark">This permalink applies to
   the outer ARTICLE element</a> (which could be, e.g., a blog post).</p>
   <article id="c">
    <p><a href="c.html" rel="bookmark">This permalink applies to
    the inner ARTICLE element</a> (which could be, e.g., a blog comment).</p>
   </article>
  </article>
 </body>
 ...

The appropriate times to fetch and process this type of link are:

• When the external resource link is created on a link element that is already browsing-context connected.

• When the external resource link's link element becomes browsing-context connected.

• When the href attribute of the link element of an external resource link that is already browsing-context connected is changed.

The fetch and process the linked resource steps for this type of linked resource, given a link element el, are:

1. Let url be the result of encoding-parsing a URL given el's href attribute's value, relative to el's node document.

2. If url is failure, then return.

3. Let partitionKey be the result of determining the network partition key given el's node document's relevant settings object.

4. The user agent should resolve an origin given partitionKey and url's origin.

   As the results of this algorithm can be cached, future fetches could be faster.

Whenever any of the following conditions occur for a link element el:

• the expect internal resource link is created on el that is already browsing-context connected;

• an expect internal resource link has been created on el and el becomes browsing-context connected;

• an expect internal resource link has been created on el, el is already browsing-context connected, and el's href attribute is set, changed, or removed; or

• an expect internal resource link has been created on el, el is already browsing-context connected, and el's media attribute is set, changed, or removed,

then process el.

To process internal resource link given a link element el, run these steps:

1. Let doc be el's node document.

2. Let url be the result of encoding-parsing a URL given el's href attribute's value, relative to doc.

3. If this fails, or if url does not equal doc's URL with exclude fragments set to true, then unblock rendering on el and return.

4. Let indicatedElement be the result of selecting the indicated part given doc and url.

5. If all of the following are true:

   • doc's current document readiness is "loading";

   • el creates an internal resource link;

   • el is browsing-context connected;

   • el's rel attribute contains expect;

   • el is potentially render-blocking;

   • el's media attribute matches the environment; and

   • indicatedElement is not an element, or is on a stack of open elements of an HTML parser whose associated Document is doc,

   then block rendering on el.

6. Otherwise, unblock rendering on el.

To process internal resource links given a Document doc:

1. For each expect link element link in doc's render-blocking element set, process link.

The following attribute change steps, given element, localName, oldValue, value, and namespace, are used to ensure expect link elements respond to dynamic id and name changes:

1. If namespace is not null, then return.

2. If element is in a stack of open elements of an HTML parser, then return.

3. If any of the following is true:

   • localName is id; or

   • localName is name and element is an a element,

   then process internal resource links given element's node document.

In the following example, the form control has associated context-sensitive help. The user agent could use this information, for example, displaying the referenced document if the user presses the "Help" or "F1" key.

 <p><label> Topic: <input name=topic> <a href="help/topic.html" rel="help">(Help)</a></label></p>

Other keywords must be further parsed as follows to determine what they represent:

1. If the keyword doesn't contain exactly one U+0078 LATIN SMALL LETTER X or U+0058 LATIN CAPITAL LETTER X character, then this keyword doesn't represent anything. Return for that keyword.

2. Let width string be the string before the "x" or "X".

3. Let height string be the string after the "x" or "X".

4. If either width string or height string start with a U+0030 DIGIT ZERO (0) character or contain any characters other than ASCII digits, then this keyword doesn't represent anything. Return for that keyword.

5. Apply the rules for parsing non-negative integers to width string to obtain width.

6. Apply the rules for parsing non-negative integers to height string to obtain height.

7. The keyword represents that the resource contains a bitmap icon with a width of width device pixels and a height of height device pixels.

The linked resource fetch setup steps for this type of linked resource, given a link element el and request request, are:

1. Set request's destination to "image".

2. Return true.

The process a link header steps for this type of linked resource are to do nothing.

In the absence of a link with the icon keyword, for Document objects whose URL's scheme is an HTTP(S) scheme, user agents may instead run these steps:

1. Let request be a new request whose URL is the URL record obtained by resolving the URL "/favicon.ico" against the Document object's URL, client is the Document object's relevant settings object, destination is "image", credentials mode is "include", and whose use-URL-credentials flag is set.

2. Fetch request, with processResponse set to the following steps given response response:

   1. Use response's unsafe response as an icon as if it had been declared using the icon keyword.

The following snippet shows the top part of an application with several icons.

<!DOCTYPE HTML>
<html lang="en">
 <head>
  <title>lsForums — Inbox</title>
  <link rel=icon href=favicon.png sizes="16x16" type="image/png">
  <link rel=icon href=windows.ico sizes="32x32 48x48" type="image/vnd.microsoft.icon">
  <link rel=icon href=mac.icns sizes="128x128 512x512 8192x8192 32768x32768">
  <link rel=icon href=iphone.png sizes="57x57" type="image/png">
  <link rel=icon href=gnome.svg sizes="any" type="image/svg+xml">
  <link rel=stylesheet href=lsforums.css>
  <script src=lsforums.js></script>
  <meta name=application-name content="lsForums">
 </head>
 <body>
  ...

Consider a photo sharing site. A page on that site might describe and show a photograph, and the page might be marked up as follows:

<!DOCTYPE HTML>
<html lang="en">
 <head>
  <title>Exampl Pictures: Kissat</title>
  <link rel="stylesheet" href="/style/default">
 </head>
 <body>
  <h1>Kissat</h1>
  <nav>
   <a href="../">Return to photo index</a>
  </nav>
  <figure>
   <img src="/pix/39627052_fd8dcd98b5.jpg">
   <figcaption>Kissat</figcaption>
  </figure>
  <p>One of them has six toes!</p>
  <p><small><a rel="license" href="http://www.opensource.org/licenses/mit-license.php">MIT Licensed</a></small></p>
  <footer>
   <a href="/">Home</a> | <a href="../">Photo index</a>
   <p><small>© copyright 2009 Exampl Pictures. All Rights Reserved.</small></p>
  </footer>
 </body>
</html>

In this case the license applies to just the photo (the main content of the document), not the whole document. In particular not the design of the page itself, which is covered by the copyright given at the bottom of the document. This could be made clearer in the styling (e.g. making the license link prominently positioned near the photograph, while having the page copyright in light small text at the foot of the page).

For an installed web application, the appropriate times to fetch and process the linked resource for this link type are:

• When the external resource link is created on a link element that is already browsing-context connected.

• When the external resource link's link element becomes browsing-context connected.

• When the href attribute of the link element of an external resource link that is already browsing-context connected is changed.

The linked resource fetch setup steps for this type of linked resource, given a link element el and request request, are:

1. Let navigable be el's node document's node navigable.

2. If navigable is null, then return false.

3. If navigable is not a top-level traversable, then return false.

4. Set request's initiator to "manifest".

5. Set request's destination to "manifest".

6. Set request's mode to "cors".

7. Set request's credentials mode to the CORS settings attribute credentials mode for el's crossorigin content attribute.

8. Return true.

To process this type of linked resource given a link element el, boolean success, response response, and byte sequence bodyBytes:

1. If response's Content-Type metadata is not a JSON MIME type, then set success to false.

2. If success is true:

   1. Let document URL be el's node document's URL.

   2. Let manifest URL be response's URL.

   3. Let client be el's node document's relevant settings object.

   4. Process the manifest given document URL, manifest URL, bodyBytes, and client. [MANIFEST]

The process a link header steps for this type of linked resource are to do nothing.

The appropriate times to fetch and process the linked resource for such a link are:

• When the external resource link is created on a link element that is already browsing-context connected.

• When the external resource link's link element becomes browsing-context connected.

• When the href attribute of the link element of an external resource link that is already browsing-context connected is changed.

The fetch and process the linked resource algorithm for modulepreload links, given a link element el, is as follows:

1. If el's href attribute's value is the empty string, then return.

2. Let destination be the current state of el's as attribute (a destination), or "script" if it is in no state.

3. If destination is not a module preload destination, then queue an element task on the networking task source given el to fire an event named error at el, and return.

4. Let url be the result of encoding-parsing a URL given el's href attribute's value, relative to el's node document.

5. If url is failure, then return.

6. Let settings object be el's node document's relevant settings object.

7. Let credentials mode be the CORS settings attribute credentials mode for el's crossorigin attribute.

8. Let cryptographic nonce be el.[[CryptographicNonce]].

9. Let integrity metadata be the value of el's integrity attribute, if it is specified, or the empty string otherwise.

10. If el does not have an integrity attribute, then set integrity metadata to the result of resolving a module integrity metadata with url and settings object.

11. Let referrer policy be the current state of el's referrerpolicy attribute.

12. Let fetch priority be the current state of el's fetchpriority attribute.

13. Let options be a script fetch options whose cryptographic nonce is cryptographic nonce, integrity metadata is integrity metadata, parser metadata is "not-parser-inserted", credentials mode is credentials mode, referrer policy is referrer policy, and fetch priority is fetch priority.

14. Fetch a modulepreload module script graph given url, destination, settings object, options, and with the following steps given result:

    1. If result is null, then fire an event named error at el, and return.

    2. Fire an event named load at el.

The process a link header steps for this type of linked resource are to do nothing.

The following snippet shows the top part of an application with several modules preloaded:

<!DOCTYPE html>
<html lang="en">
<title>IRCFog</title>

<link rel="modulepreload" href="app.mjs">
<link rel="modulepreload" href="helpers.mjs">
<link rel="modulepreload" href="irc.mjs">
<link rel="modulepreload" href="fog-machine.mjs">

<script type="module" src="app.mjs">
...

Assume that the module graph for the application is as follows:

Here we see the application developer has used modulepreload to declare all of the modules in their module graph, ensuring that the user agent initiates fetches for them all. Without such preloading, the user agent might need to go through multiple network roundtrips before discovering helpers.mjs, if technologies such as HTTP/2 Server Push are not in play. In this way, modulepreload link elements can be used as a sort of "manifest" of the application's modules.

The following code shows how modulepreload links can be used in conjunction with import() to ensure network fetching is done ahead of time, so that when import() is called, the module is already ready (but not evaluated) in the module map:

<link rel="modulepreload" href="awesome-viewer.mjs">

<button onclick="import('./awesome-viewer.mjs').then(m => m.view())">
  View awesome thing
</button>

This typically creates a top-level traversable with an auxiliary browsing context (assuming there is no existing navigable whose target name is "example"):

<a href=help.html target=example>Help!</a>

This creates a top-level traversable with a non-auxiliary browsing context (assuming the same thing):

<a href=help.html target=example rel=noopener>Help!</a>

These are equivalent and only navigate the parent navigable:

<a href=index.html target=_parent>Home</a>

<a href=index.html target=_parent rel=noopener>Home</a>

In the following example the opener is used to allow the help page popup to navigate its opener, e.g., in case what the user is looking for can be found elsewhere. An alternative might be to use a named target, rather than _blank, but this has the potential to clash with existing names.

<a href="..." rel=opener target=_blank>Help!</a>

The appropriate times to fetch and process this type of link are:

• When the external resource link is created on a link element that is already browsing-context connected.

• When the external resource link's link element becomes browsing-context connected.

• When the href attribute of the link element of an external resource link that is already browsing-context connected is changed.

• When the crossorigin attribute of the link element of an external resource link that is already browsing-context connected is set, changed, or removed.

The fetch and process the linked resource steps for this type of linked resource, given a link element el, are to create link options from el and to preconnect given the result.

The process a link header step for this type of linked resource given a link processing options options are to preconnect given options.

To preconnect given a link processing options options:

1. If options's href is an empty string, return.

2. Let url be the result of encoding-parsing a URL given options's href, relative to options's base URL.

   Passing the base URL instead of a document or environment is tracked by issue #9715.

3. If url is failure, then return.

4. If url's scheme is not an HTTP(S) scheme, then return.

5. Let partitionKey be the result of determining the network partition key given options's environment.

6. Let useCredentials be true.

7. If options's crossorigin is Anonymous and options's origin does not have the same origin as url's origin, then set useCredentials to false.

8. The user agent should obtain a connection given partitionKey, url, and useCredentials.

   This connection is obtained but not used directly. It will remain in the connection pool for subsequent use.

   The user agent should attempt to initiate a preconnect and perform the full connection handshake (DNS+TCP for HTTP, and DNS+TCP+TLS for HTTPS origins) whenever possible, but is allowed to elect to perform a partial handshake (DNS only for HTTP, and DNS or DNS+TCP for HTTPS origins), or skip it entirely, due to resource constraints or other reasons.

   The optimal number of connections per origin is dependent on the negotiated protocol, users current connectivity profile, available device resources, global connection limits, and other context specific variables. As a result, the decision for how many connections should be opened is deferred to the user agent.

The appropriate times to fetch and process this type of link are:

• When the external resource link is created on a link element that is already browsing-context connected.

• When the external resource link's link element becomes browsing-context connected.

• When the href attribute of the link element of an external resource link that is already browsing-context connected is changed.

• When the crossorigin attribute of the link element of an external resource link that is already browsing-context connected is set, changed, or removed.

The fetch and process the linked resource algorithm for prefetch links, given a link element el, is as follows:

1. If el's href attribute's value is the empty string, then return.

2. Let options be the result of creating link options from el.

3. Let request be the result of creating a link request given options.

4. If request is null, then return.

5. Set request's initiator to "prefetch".

6. Let processPrefetchResponse be the following steps given a response response and null, failure, or a byte sequence bytesOrNull:

   1. If response is a network error, fire an event named error at el.

   2. Otherwise, fire an event named load at el.

7. The user agent should fetch request, with processResponseConsumeBody set to processPrefetchResponse. User agents may delay the fetching of request to prioritize other requests that are necessary for the current document.

The process a link header steps for this type of linked resource are to do nothing.

The appropriate times to fetch and process the linked resource for such a link are:

• When the external resource link is created on a link element that is already browsing-context connected.

• When the external resource link's link element becomes browsing-context connected.

• When the href attribute of the link element of an external resource link that is already browsing-context connected is changed.

• When the as attribute of the link element of an external resource link that is already browsing-context connected is changed.

• When the type attribute of the link element of an external resource link that is already browsing-context connected, but was previously not obtained due to the type attribute specifying an unsupported type for the request destination, is set, removed, or changed.

• When the media attribute of the link element of an external resource link that is already browsing-context connected, but was previously not obtained due to the media attribute not matching the environment, is changed or removed.

To consume a preloaded resource for Window window, given a URL url, a string destination, a string mode, a string credentialsMode, a string integrityMetadata, and onResponseAvailable, which is an algorithm accepting a response:

1. Let key be a preload key whose URL is url, destination is destination, mode is mode, and credentials mode is credentialsMode.

2. Let preloads be window's associated Document's map of preloaded resources.

3. If key does not exist in preloads, then return false.

4. Let entry be preloads[key].

5. Let consumerIntegrityMetadata be the result of parsing integrityMetadata.

6. Let preloadIntegrityMetadata be the result of parsing entry's integrity metadata.

7. If none of the following conditions apply:

   • consumerIntegrityMetadata is no metadata;

   • consumerIntegrityMetadata is equal to preloadIntegrityMetadata; or

     This comparison would ignore unknown integrity options. See issue #116.

   then return false.

   A mismatch in integrity metadata between the preload and the consumer, even if both match the data, would lead to an additional fetch from the network.

   It is important that network errors are added to the preload cache so that if a preload request results in an error, the erroneous response isn't re-requested from the network later. This also has security implications; consider the case where a developer specifies subresource integrity metadata on a preload request, but not the following resource request. If the preload request fails subresource integrity verification and is discarded, the resource request will fetch and consume a potentially-malicious response from the network without verifying its integrity. [SRI]

8. Remove preloads[key].

9. If entry's response is null, then set entry's on response available to onResponseAvailable.

10. Otherwise, call onResponseAvailable with entry's response.

11. Return true.

For the purposes of this section, a string type matches a preload destination destination if the following algorithm returns true:

1. If type is an empty string, then return true.

2. If destination is "fetch", then return true.

3. Let mimeTypeRecord be the result of parsing type.

4. If mimeTypeRecord is failure, then return false.

5. If mimeTypeRecord is not supported by the user agent, then return false.

6. If any of the following are true:

   • destination is "script" and mimeTypeRecord is a JavaScript MIME type;

   • destination is "image" and mimeTypeRecord is an image MIME type;

   • destination is "font" and mimeTypeRecord is a font MIME type;

   • destination is "style" and mimeTypeRecord's essence is text/css; or

   • destination is "track" and mimeTypeRecord's essence is text/vtt,

   then return true.

7. Return false.

To create a preload key for a request request, return a new preload key whose URL is request's URL, destination is request's destination, mode is request's mode, and credentials mode is request's credentials mode.

To translate a preload destination given a string destination:

1. If destination is not a preload destination, then return null.

2. Return the result of translating destination.

To preload given a link processing options options and an optional processResponse, which is an algorithm accepting a response:

1. If options's type doesn't match options's destination, then return.

2. If options's destination is "image" and options's source set is not null:

   1. Assert: options's document is not null.

   2. Let selected be the result of selecting an image source from a source set given options's source set and options's document.

   3. If selected is null, then return.

   4. Set options's href to selected[0].

3. Let request be the result of creating a link request given options.

4. If request is null, then return.

5. Let unsafeEndTime be 0.

6. Let entry be a new preload entry whose integrity metadata is options's integrity.

7. Let key be the result of creating a preload key given request.

8. If options's document is null, then set request's initiator type to "early hint".

9. Let controller be null.

10. Let reportTiming given a Document document be to report timing for controller given document's relevant global object.

11. Set controller to the result of fetching request, with processResponseConsumeBody set to the following steps given a response response and null, failure, or a byte sequence bodyBytes:

    1. If bodyBytes is a byte sequence, then set response's body to bodyBytes as a body.

       By using processResponseConsumeBody, we have extracted the entire body. This is necessary to ensure the preloader loads the entire body from the network, regardless of whether the preload will be consumed (which is uncertain at this point). This step then resets the request's body to a new body containing the same bytes, so that other specifications can read from it at the time of actual consumption, despite us having already done so once.

    2. Otherwise, set response to a network error.

    3. Set unsafeEndTime to the unsafe shared current time.

    4. If options's document is not null, then call reportTiming given options's document.

    5. If entry's on response available is null, then set entry's response to response; otherwise call entry's on response available given response.

    6. If processResponse is given, then call processResponse with response.

12. Let commit be the following steps given a Document document:

    1. If entry's response is not null, then call reportTiming given document.

    2. Set document's map of preloaded resources[key] to entry.

13. If options's document is null, then set options's on document ready to commit. Otherwise, call commit with options's document.

The fetch and process the linked resource steps for this type of linked resource, given a link element el, are:

1. Update the source set for el.

2. Let options be the result of creating link options from el.

3. Let destination be the result of translating the keyword representing the state of el's as attribute.

4. If destination is null, then return.

5. Set options's destination to destination.

6. Preload options, with the following steps given a response response:

   1. If response is a network error, fire an event named error at el. Otherwise, fire an event named load at el.

      The actual browsers' behavior is different from the spec here, and the feasibility of changing the behavior has not yet been investigated. See issue #1142.

The process a link header step for this type of link given a link processing options options is to preload options.

A link element of this type is implicitly potentially render-blocking if the element was created by its node document's parser.

When the disabled attribute of a link element with a stylesheet keyword is set, disable the associated CSS style sheet.

The appropriate times to fetch and process this type of link are:

• When the external resource link is created on a link element that is already browsing-context connected.

• When the external resource link's link element becomes browsing-context connected.

• When the href attribute of the link element of an external resource link that is already browsing-context connected is changed.

• When the disabled attribute of the link element of an external resource link that is already browsing-context connected is set, changed, or removed.

• When the crossorigin attribute of the link element of an external resource link that is already browsing-context connected is set, changed, or removed.

• When the type attribute of the link element of an external resource link that is already browsing-context connected is set or changed to a value that does not or no longer matches the Content-Type metadata of the previous obtained external resource, if any.

• When the type attribute of the link element of an external resource link that is already browsing-context connected, but was previously not obtained due to the type attribute specifying an unsupported type, is removed or changed.

• When the external resource link that is already browsing-context connected changes from being an alternative style sheet to not being one, or vice versa.

The linked resource fetch setup steps for this type of linked resource, given a link element el and request request, are:

1. If el's disabled attribute is set, then return false.

2. If el contributes a script-blocking style sheet, append el to its node document's script-blocking style sheet set.

3. If el's media attribute's value matches the environment and el is potentially render-blocking, then block rendering on el.

4. If el is currently render-blocking, then set request's render-blocking to true.

5. Return true.

To process this type of linked resource given a link element el, boolean success, response response, and byte sequence bodyBytes:

1. If the resource's Content-Type metadata is not text/css, then set success to false.

2. If el no longer creates an external resource link that contributes to the styling processing model, or if, since the resource in question was fetched, it has become appropriate to fetch it again:

   1. Remove el from el's node document's script-blocking style sheet set.

   2. Return.

3. If el has an associated CSS style sheet, remove the CSS style sheet.

4. If success is true:

   1. Create a CSS style sheet with the following properties:

      type

      text/css

      location

      response's URL list[0]

      We provide a URL here on the assumption that w3c/csswg-drafts issue #9316 will be fixed.

      owner node

      el

      media

      The media attribute of el.

      This is a reference to the (possibly absent at this time) attribute, rather than a copy of the attribute's current value. CSSOM defines what happens when the attribute is dynamically set, changed, or removed.

      title

      The title attribute of el, if el is in a document tree, or the empty string otherwise.

      This is similarly a reference to the attribute, rather than a copy of the attribute's current value.

      alternate flag

      Set if the link is an alternative style sheet and el's explicitly enabled is false; unset otherwise.

      origin-clean flag

      Set if the resource is CORS-same-origin; unset otherwise.

      parent CSS style sheet

      owner CSS rule

      null

      disabled flag

      Left at its default value.

      CSS rules

      Left uninitialized.

      This doesn't seem right. Presumably we should be using bodyBytes? Tracked as issue #2997.

      The CSS environment encoding is the result of running the following steps: [CSSSYNTAX]

      1. If el has a charset attribute, get an encoding from that attribute's value. If that succeeds, return the resulting encoding. [ENCODING]

      2. Otherwise, return the document's character encoding. [DOM]

   2. Fire an event named load at el.

5. Otherwise, fire an event named error at el.

6. If el contributes a script-blocking style sheet:

   1. Assert: el's node document's script-blocking style sheet set contains el.

   2. Remove el from its node document's script-blocking style sheet set.

7. Unblock rendering on el.

The process a link header steps for this type of linked resource are to do nothing.

This document is about some gems, and so it is tagged with "https://en.wikipedia.org/wiki/Gemstone" to unambiguously categorize it as applying to the "jewel" kind of gems, and not to, say, the towns in the US, the Ruby package format, or the Swiss locomotive class:

<!DOCTYPE HTML>
<html lang="en">
 <head>
  <title>My Precious</title>
 </head>
 <body>
  <header><h1>My precious</h1> <p>Summer 2012</p></header>
  <p>Recently I managed to dispose of a red gem that had been
  bothering me. I now have a much nicer blue sapphire.</p>
  <p>The red gem had been found in a bauxite stone while I was digging
  out the office level, but nobody was willing to haul it away. The
  same red gem stayed there for literally years.</p>
  <footer>
   Tags: <a rel=tag href="https://en.wikipedia.org/wiki/Gemstone">Gemstone</a>
  </footer>
 </body>
</html>

In this document, there are two articles. The "tag" link, however, applies to the whole page (and would do so wherever it was placed, including if it was within the article elements).

<!DOCTYPE HTML>
<html lang="en">
 <head>
  <title>Gem 4/4</title>
 </head>
 <body>
  <article>
   <h1>801: Steinbock</h1>
   <p>The number 801 Gem 4/4 electro-diesel has an ibex and was rebuilt in 2002.</p>
  </article>
  <article>
   <h1>802: Murmeltier</h1>
   <figure>
    <img src="https://upload.wikimedia.org/wikipedia/commons/b/b0/Trains_de_la_Bernina_en_hiver_2.jpg"
         alt="The 802 was red with pantographs and tall vents on the side.">
    <figcaption>The 802 in the 1980s, above Lago Bianco.</figcaption>
   </figure>
   <p>The number 802 Gem 4/4 electro-diesel has a marmot and was rebuilt in 2003.</p>
  </article>
  <p class="topic"><a rel=tag href="https://en.wikipedia.org/wiki/Rhaetian_Railway_Gem_4/4">Gem 4/4</a></p>
 </body>
</html>