HTML 5

The history attribute of the Window interface must return the object implementing the History interface for that Window object's Document.

This does not imply that the user interface need be linear. See the notes below.

User agents may discard the Document objects of entries other than the current entry that are not referenced from any script, reloading the pages afresh when the user or script navigates back to such pages. This specification does not specify when user agents should discard Document objects and when they should cache them.

Entries that have had their Document objects discarded must, for the purposes of the algorithms given below, act as if they had not. When the user or script navigates back or forwards to a page which has no in-memory DOM objects, any other entries that shared the same Document object with it must share the new object as well.

The length attribute of the History interface must return the number of entries in this session history.

The actual entries are not accessible from script.

The go(delta) method causes the UA to move the number of steps specified by delta in the session history.

If the delta is zero, or if the argument is omitted, then the user agent must act as if the location.reload() method was called instead.

Otherwise, if the index of the current entry plus delta is less than zero or greater than or equal to the number of items in the session history, then the user agent must do nothing.

Otherwise, the user agent must cause the current browsing context to traverse the history to the specified entry. The specified entry is the one whose index equals the index of the current entry plus delta.

When the user navigates through a browsing context, e.g. using a browser's back and forward buttons, the user agent must translate this action into the equivalent invocations of the history.go(delta) method on the various affected window objects.

Some of the other members of the History interface are defined in terms of the go() method, as follows:

The pushState(data, title, url) method adds a state object to the history.

When this method is invoked, the user agent must run the following steps:

1. Let clone data be a structured clone of the specified data. If this throws an exception, then rethrow that exception and abort these steps.

2. If a third argument is specified, run these substeps:

   1. Resolve the value of the third argument, relative to the first script's base URL.
   2. If that fails, raise a SECURITY_ERR exception and abort the pushState() steps.
   3. Compare the resulting absolute URL to the document's address. If any part of these two URLs differ other than the <path>, <query>, and <fragment> components, then raise a SECURITY_ERR exception and abort the pushState() steps.

   For the purposes of the comparison in the above substeps, the <path> and <query> components can only be the same if the URLs use a hierarchical <scheme>.

3. Remove from the session history any entries for the Document from the entry after the current entry up to the last entry in the session history that references the same Document object, if any. If the current entry is the last entry in the session history, or if there are no entries after the current entry that reference the same Document object, then no entries are removed.

4. Add a state object entry to the session history, after the current entry, with cloned data as the state object, the given title as the title, and, if the third argument is present, the absolute URL that was found earlier in this algorithm as the URL of the entry.

5. If the third argument is present, set the document's current address to the absolute URL that was found earlier in this algorithm.

6. Update the current entry to be the this newly added entry.

The title is purely advisory. User agents might use the title in the user interface.

User agents may limit the number of state objects added to the session history per page. If a page hits the UA-defined limit, user agents must remove the entry immediately after the first entry for that Document object in the session history after having added the new entry. (Thus the state history acts as a FIFO buffer for eviction, but as a LIFO buffer for navigation.)

The clearState() method removes all the state objects for the Document object from the session history.

When this method is invoked, the user agent must remove from the session history all the entries from the first state object entry for that Document object up to the last entry that references that same Document object, if any.

Then, if the current entry was removed in the previous step, the current entry must be set to the last entry for that Document object in the session history.

When an entry in the session history is activated (which happens during session traversal, as described above), the user agent must run the following steps:

1. If the entry is a state object entry, let state be a structured clone of that state object. Otherwise, let state be null.

2. Run the appropriate according to the conditions described:

   If the current document readiness is set to the string "complete"

   Queue a task to fire a popstate event in no namespace on the Window object of the Document, using the PopStateEvent interface, with the state attribute set to the value of state. This event must bubble but not be cancelable and has no default action. The task source for this task is the DOM manipulation task source.

   Otherwise

   Let the Document's pending state object be state. (If there was already a pending state object, the previous one is discarded.)

   The event will then be fired just after the load event.

The pending state object must be initially null.

The initPopStateEvent() and initPopStateEventNS() methods must initialize the event in a manner analogous to the similarly-named methods in the DOM3 Events interfaces. [DOM3EVENTS]

The state attribute represents the context information for the event, or null, if the state represented is the initial state of the Document.

The location attribute of the HTMLDocument interface must return the Location object for that Document object, if it is in a browsing context, and null otherwise.

The location attribute of the Window interface must return the Location object for that Window object's Document.

The href attribute must return the current address of the associated Document object, as an absolute URL.

On setting, the user agent must act as if the assign() method had been called with the new value as its argument.

When the assign(url) method is invoked, the UA must resolve the argument, relative to the first script's base URL, and if that is successful, must navigate the browsing context to the specified url.

When the replace(url) method is invoked, the UA must resolve the argument, relative to the first script's base URL, and if that is successful, navigate the browsing context to the specified url with replacement enabled.

Navigation for the assign() and replace() methods must be done with the browsing context of the script that invoked the method as the source browsing context.

If the resolving step of the assign() and replace() methods is not successful, then the user agent must instead throw a SYNTAX_ERR exception.

The resolveURL(url) method must resolve its url argument, relative to the first script's base URL, and if that succeeds, return the resulting absolute URL. If it fails, it must throw a SYNTAX_ERR exception instead.

5.9.4.1 Security

User agents must raise a SECURITY_ERR exception whenever any of the members of a Location object are accessed by scripts whose effective script origin is not the same as the Location object's associated Document's effective script origin, with the following exceptions:

• The href setter, if the script is running in a browsing context that is allowed to navigate the browsing context with which the Location object is associated

User agents must not allow scripts to override the href attribute's setter.

5.9.5 Implementation notes for session history

This section is non-normative.

The History interface is not meant to place restrictions on how implementations represent the session history to the user.

For example, session history could be implemented in a tree-like manner, with each page having multiple "forward" pages. This specification doesn't define how the linear list of pages in the history object are derived from the actual session history as seen from the user's perspective.

Similarly, a page containing two iframes has a history object distinct from the iframes' history objects, despite the fact that typical Web browsers present the user with just one "Back" button, with a session history that interleaves the navigation of the two inner frames and the outer page.

Security: It is suggested that to avoid letting a page "hijack" the history navigation facilities of a UA by abusing pushState(), the UA provide the user with a way to jump back to the previous page (rather than just going back to the previous state). For example, the back button could have a drop down showing just the pages in the session history, and not showing any of the states. Similarly, an aural browser could have two "back" commands, one that goes back to the previous state, and one that jumps straight back to the previous page.

In addition, a user agent could ignore calls to pushState() that are invoked on a timer, or from event handlers that do not represent a clear user action, or that are invoked in rapid succession.

5.10.1 Navigating across documents

Certain actions cause the browsing context to navigate to a new resource. Navigation always involves source browsing context, which is the browsing context which was responsible for starting the navigation.

For example, following a hyperlink, form submission, and the window.open() and location.assign() methods can all cause a browsing context to navigate.

A user agent may provide various ways for the user to explicitly cause a browsing context to navigate, in addition to those defined in this specification.

When a browsing context is navigated to a new resource, the user agent must run the following steps:

1. If the source browsing context is not the same as the browsing context being navigated, and the source browsing context is not one of the ancestor browsing contexts of the browsing context being navigated, and the source browsing context has its sandboxed navigation browsing context flag set, then abort these steps. The user agent may offer to open the new resource in a new top-level browsing context or in the top-level browsing context of the source browsing context, at the user's option, in which case the user agent must navigate that designated top-level browsing context to the new resource as if the user had requested it independently.

2. If the source browsing context is the same as the browsing context being navigated, and this browsing context has its seamless browsing context flag set, then find the nearest ancestor browsing context that does not have its seamless browsing context flag set, and continue these steps as if that browsing context was the one that was going to be navigated instead.

3. Cancel any preexisting attempt to navigate the browsing context.

4. Fragment identifiers: If the absolute URL of the new resource is the same as the address of the active document of the browsing context being navigated, ignoring any <fragment> components of those URLs, and the new resource is to be fetched using HTTP GET or equivalent, then navigate to that fragment identifier and abort these steps.

5. If the new resource is to be handled by displaying some sort of inline content, e.g. an error message because the specified scheme is not one of the supported protocols, or an inline prompt to allow the user to select a registered handler for the given scheme, then display the inline content and abort these steps.

6. If the new resource is to be handled using a mechanism that does not affect the browsing context, e.g. ignoring the navigation request altogether because the specified scheme is not one of the supported protocols, then abort these steps and proceed with that mechanism instead.

7. If the new resource is to be fetched using HTTP GET or equivalent, then check if there are any relevant application caches that are identified by a URL with the same origin as the URL in question, and that have this URL as one of their entries, excluding entries marked as foreign. If so, then the user agent must then get the resource from the most appropriate application cache of those that match.

   For example, imagine an HTML page with an associated application cache displaying an image and a form, where the image is also used by several other application caches. If the user right-clicks on the image and chooses "View Image", then the user agent could decide to show the image from any of those caches, but it is likely that the most useful cache for the user would be the one that was used for the aforementioned HTML page. On the other hand, if the user submits the form, and the form does a POST submission, then the user agent will not use an application cache at all; the submission will be made to the network.

   Otherwise, fetch the new resource, if it has not already been obtained. If the resource is being fetched using HTTP, and the method is not GET, then the user agent must include an XXX-Origin header whose value is determined as follows:

   If the navigation algorithm has so far contacted more than one origin

   If there is no source browsing context

   The value must be the string "null".

   Otherwise

   The value must be the ASCII serialization of the origin of the active document of the source browsing context at the time the navigation was started.

8. If fetching the resource is synchronous (i.e. for javascript: URLs and about:blank), then this must be synchronous, but if fetching the resource depends on external resources, as it usually does for URLs that use HTTP or other networking protocols, then at this point the user agents must yield to whatever script invoked the navigation steps, if they were invoked by script.

9. If fetching the resource results in a redirect, return to the step labeled "fragment identifiers" with the new resource.

   Cross-origin redirects cause the XXX-Origin header to become "null" on subsequent requests in the chain.

10. Wait for one or more bytes to be available or for the user agent to establish that the resource in question is empty. During this time, the user agent may allow the user to cancel this navigation attempt or start other navigation attempts.

11. If the resource was not fetched from an application cache, and was to be fetched using HTTP GET or equivalent, and its URL matches the fallback namespace of one or more relevant application caches, and the user didn't cancel the navigation attempt during the previous step, and the navigation attempt failed (e.g. the server returned a 4xx or 5xx status code or equivalent, or there was a DNS error), then:

    Let candidate be the fallback resource specified for the fallback namespace in question. If multiple application caches match, the user agent must use the fallback of the most appropriate application cache of those that match.

    If candidate is not marked as foreign, then the user agent must discard the failed load and instead continue along these steps using candidate as the resource. The document's address, if appropriate, will still be the originally requested URL, not the fallback URL, but the user agent may indicate to the user that the original page load failed, that the page used was a fallback resource, and what the URL of the fallback resource actually is.

12. If the document's out-of-band metadata (e.g. HTTP headers), not counting any type information (such as the Content-Type HTTP header), requires some sort of processing that will not affect the browsing context, then perform that processing and abort these steps.

    Such processing might be triggered by, amongst other things, the following:

    • HTTP status codes (e.g. 204 No Content or 205 Reset Content)
    • HTTP Content-Disposition headers
    • Network errors

    HTTP 401 responses that do not include a challenge recognized by the user agent must be processed as if they had no challenge, e.g. rendering the entity body as if the response had been 200 OK.

    User agents may show the entity body of an HTTP 401 response even when the response do include a recognized challenge, with the option to login being included in a non-modal fashion, to enable the information provided by the server to be used by the user before authenticating. Similarly, user agents should allow the user to authenticate (in a non-modal fashion) against authentication challenges included in other responses such as HTTP 200 OK responses, effectively allowing resources to present HTTP login forms without requiring their use.

13. Let type be the sniffed type of the resource.

14. If the user agent has been configured to process resources of the given type using some mechanism other than rendering the content in a browsing context, then skip this step. Otherwise, if the type is one of the following types, jump to the appropriate entry in the following list, and process the resource as described there:

    "text/html"

    Follow the steps given in the HTML document section, and abort these steps.

    Any type ending in "+xml"

    "application/xml"

    "text/xml"

    Follow the steps given in the XML document section. If that section determines that the content is not to be displayed as a generic XML document, then proceed to the next step in this overall set of steps. Otherwise, abort these steps.

    "text/plain"

    Follow the steps given in the plain text file section, and abort these steps.

    A supported image type

    Follow the steps given in the image section, and abort these steps.

    A type that will use an external application to render the content in the browsing context

    Follow the steps given in the plugin section, and abort these steps.

    Setting the document's address: If there is no override URL, then any Document created by these steps must have its address set to the URL that was originally to be fetched, ignoring any other data that was used to obtain the resource (e.g. the entity body in the case of a POST submission is not part of the document's address, nor is the URL of the fallback resource in the case of the original load having failed and that URL having been found to match a fallback namespace). However, if there is an override URL, then any Document created by these steps must have its address set to that URL instead.

    An override URL is set when dereferencing a javascript: URL.

15. Non-document content: If, given type, the new resource is to be handled by displaying some sort of inline content, e.g. a native rendering of the content, an error message because the specified type is not supported, or an inline prompt to allow the user to select a registered handler for the given type, then display the inline content and abort these steps.

16. Otherwise, the document's type is such that the resource will not affect the browsing context, e.g. because the resource is to be handed to an external application. Process the resource appropriately.

Some of the sections below, to which the above algorithm defers in certain cases, require the user agent to update the session history with the new page. When a user agent is required to do this, it must queue a task to run the following steps:

1. Unload the Document object of the current entry, with the recycle parameter set to false.

2. If the navigation was initiated for entry update of an entry

   1. Replace the entry being updated with a new entry representing the new resource and its Document object and related state. The user agent may propagate state from the old entry to the new entry (e.g. scroll position).

   2. Traverse the history to the new entry.

   Otherwise

   1. Remove all the entries after the current entry in the browsing context's Document object's History object.

      This doesn't necessarily have to affect the user agent's user interface.

   2. Append a new entry at the end of the History object representing the new resource and its Document object and related state.

   3. Traverse the history to the new entry.

   4. If the navigation was initiated with replacement enabled, remove the entry immediately before the new current entry in the session history.

3. If the document's address has a fragment identifier, then run these substeps:

   1. Wait for a user-agent defined amount of time, as desired by the user agent implementor. (This is intended to allow the user agent to optimize the user experience in the face of performance concerns.)

   2. If the Document object has no parser, or its parser has stopped parsing, or the user agent has reason to believe the user is no longer interested in scrolling to the fragment identifier, then abort these substeps.

   3. Scroll to the fragment identifier given in the document's current address. If this fails to find an indicated part of the document, then return to the first step of these substeps.

The task source for this task is the networking task source.

5.10.2 Page load processing model for HTML files

When an HTML document is to be loaded in a browsing context, the user agent must create a Document object, mark it as being an HTML document, create an HTML parser, associate it with the document, and begin to use the bytes provided for the document as the input stream for that parser.

The input stream converts bytes into characters for use in the tokenizer. This process relies, in part, on character encoding information found in the real Content-Type metadata of the resource; the "sniffed type" is not used for this purpose.

When no more bytes are available, an EOF character is implied, which eventually causes a load event to be fired.

After creating the Document object, but potentially before the page has finished parsing, the user agent must update the session history with the new page.

Application cache selection happens in the HTML parser.

5.10.3 Page load processing model for XML files

When faced with displaying an XML file inline, user agents must first create a Document object, following the requirements of the XML and Namespaces in XML recommendations, RFC 3023, DOM3 Core, and other relevant specifications. [XML] [XMLNS] [RFC3023] [DOM3CORE]

The actual HTTP headers and other metadata, not the headers as mutated or implied by the algorithms given in this specification, are the ones that must be used when determining the character encoding according to the rules given in the above specifications. Once the character encoding is established, the document's character encoding must be set to that character encoding.

If the root element, as parsed according to the XML specifications cited above, is found to be an html element with an attribute manifest, then, as soon as the element is inserted into the document, the user agent must resolve the value of that attribute relative to that element, and if that is successful, must run the application cache selection algorithm with the resulting absolute URL as the manifest URL, and passing in the newly-created Document. Otherwise, if the attribute is absent or resolving it fails, then as soon as the root element is inserted into the document, the user agent must run the application cache selection algorithm with no manifest, and passing in the Document.

Because the processing of the manifest attribute happens only once the root element is parsed, any URLs referenced by processing instructions before the root element (such as <?xml-stylesheet?> and <?xbl?> PIs) will be fetched from the network and cannot be cached.

User agents may examine the namespace of the root Element node of this Document object to perform namespace-based dispatch to alternative processing tools, e.g. determining that the content is actually a syndication feed and passing it to a feed handler. If such processing is to take place, abort the steps in this section, and jump to the next step (labeled "non-document content") in the navigate steps above.

Otherwise, then, with the newly created Document, the user agents must update the session history with the new page. User agents may do this before the complete document has been parsed (thus achieving incremental rendering).

Error messages from the parse process (e.g. XML namespace well-formedness errors) may be reported inline by mutating the Document.

5.10.4 Page load processing model for text files

When a plain text document is to be loaded in a browsing context, the user agent should create a Document object, mark it as being an HTML document, create an HTML parser, associate it with the document, act as if the tokenizer had emitted a start tag token with the tag name "pre", set the tokenization stage's content model flag to PLAINTEXT, and begin to pass the stream of characters in the plain text document to that tokenizer.

The rules for how to convert the bytes of the plain text document into actual characters are defined in RFC 2046, RFC 2646, and subsequent versions thereof. [RFC2046] [RFC2646]

The document's character encoding must be set to the character encoding used to decode the document.

Upon creation of the Document object, the user agent must run the application cache selection algorithm with no manifest, and passing in the newly-created Document.

When no more character are available, an EOF character is implied, which eventually causes a load event to be fired.

After creating the Document object, but potentially before the page has finished parsing, the user agent must update the session history with the new page.

User agents may add content to the head element of the Document, e.g. linking to stylesheet or an XBL binding, providing script, giving the document a title, etc.

5.10.5 Page load processing model for images

When an image resource is to be loaded in a browsing context, the user agent should create a Document object, mark it as being an HTML document, append an html element to the Document, append a head element and a body element to the html element, append an img to the body element, and set the src attribute of the img element to the address of the image.

Then, the user agent must act as if it had stopped parsing.

Upon creation of the Document object, the user agent must run the application cache selection algorithm with no manifest, and passing in the newly-created Document.

After creating the Document object, but potentially before the page has finished fully loading, the user agent must update the session history with the new page.

User agents may add content to the head element of the Document, or attributes to the img element, e.g. to link to stylesheet or an XBL binding, to provide a script, to give the document a title, etc.

5.10.6 Page load processing model for content that uses plugins

When a resource that requires an external resource to be rendered is to be loaded in a browsing context, the user agent should create a Document object, mark it as being an HTML document, append an html element to the Document, append a head element and a body element to the html element, append an embed to the body element, and set the src attribute of the embed element to the address of the resource.

Then, the user agent must act as if it had stopped parsing.

Upon creation of the Document object, the user agent must run the application cache selection algorithm with no manifest, and passing in the newly-created Document.

After creating the Document object, but potentially before the page has finished fully loading, the user agent must update the session history with the new page.

User agents may add content to the head element of the Document, or attributes to the embed element, e.g. to link to stylesheet or an XBL binding, or to give the document a title.

If the sandboxed plugins browsing context flag is set on the browsing context, the synthesized embed element will fail to render the content.

5.10.7 Page load processing model for inline content that doesn't have a DOM

When the user agent is to display a user agent page inline in a browsing context, the user agent should create a Document object, mark it as being an HTML document, and then either associate that Document with a custom rendering that is not rendered using the normal Document rendering rules, or mutate that Document until it represents the content the user agent wants to render.

Once the page has been set up, the user agent must act as if it had stopped parsing.

Upon creation of the Document object, the user agent must run the application cache selection algorithm with no manifest, passing in the newly-created Document.

After creating the Document object, but potentially before the page has been completely set up, the user agent must update the session history with the new page.

5.10.8 Navigating to a fragment identifier

When a user agent is supposed to navigate to a fragment identifier, then the user agent must queue a task to run the following steps:

1. Remove all the entries after the current entry in the browsing context's Document object's History object.

   This doesn't necessarily have to affect the user agent's user interface.

2. Append a new entry at the end of the History object representing the new resource and its Document object and related state, and set its URL to the address to which the user agent was navigating. (This will be the same as the document's address, but with a new fragment identifier.)

3. Traverse the history to the new entry. This will scroll to the fragment identifier given in the document's current address.

When the user agent is required to scroll to the fragment identifier, it must change the scrolling position of the document, or perform some other action, such that the indicated part of the document is brought to the user's attention. If there is no indicated part, then the user agent must not scroll anywhere.

The indicated part of the document is the one that the fragment identifier, if any, identifies. The semantics of the fragment identifier in terms of mapping it to a specific DOM Node is defined by the MIME type specification of the document's MIME Type (for example, the processing of fragment identifiers for XML MIME types is the responsibility of RFC3023).

For HTML documents (and the text/html MIME type), the following processing model must be followed to determine what the indicated part of the document is.

1. Parse the URL, and let fragid be the <fragment> component of the URL.

2. If fragid is the empty string, then the indicated part of the document is the top of the document.

3. Let decoded fragid be the result of expanding any sequences of percent-encoded octets in fragid that are valid UTF-8 sequences into Unicode characters as defined by UTF-8. If any percent-encoded octets in that string are not valid UTF-8 sequences, then skip this step and the next one.

4. If this step was not skipped and there is an element in the DOM that has an ID exactly equal to decoded fragid, then the first such element in tree order is the indicated part of the document; stop the algorithm here.

5. If there is an a element in the DOM that has a name attribute whose value is exactly equal to fragid (not decoded fragid), then the first such element in tree order is the indicated part of the document; stop the algorithm here.

6. Otherwise, there is no indicated part of the document.

For the purposes of the interaction of HTML with Selectors' :target pseudo-class, the target element is the indicated part of the document, if that is an element; otherwise there is no target element. [SELECTORS]

5.10.9 History traversal

When a user agent is required to traverse the history to a specified entry, the user agent must act as follows:

1. If there is no longer a Document object for the entry in question, the user agent must navigate the browsing context to the location for that entry to perform an entry update of that entry, and abort these steps. The "navigate" algorithm reinvokes this "traverse" algorithm to complete the traversal, at which point there is a Document object and so this step gets skipped. The navigation must be done using the same source browsing context as was used the first time this entry was created.

2. If appropriate, update the current entry in the browsing context's Document object's History object to reflect any state that the user agent wishes to persist.

   For example, some user agents might want to persist the scroll position, or the values of form controls.

3. If the specified entry has a different Document object than the current entry then the user agent must run the following substeps:

   1. If the browsing context is a top-level browsing context (and not an auxiliary browsing context), and the origin of the Document of the specified entry is not the same as the origin of the Document of the current entry, then the following sub-sub-steps must be run:
      1. The current browsing context name must be stored with all the entries in the history that are associated with Document objects with the same origin as the active document and that are contiguous with the current entry.
      2. The browsing context's browsing context name must be unset.
   2. The user agent must make the specified entry's Document object the active document of the browsing context.
   3. If the specified entry has a browsing context name stored with it, then the following sub-sub-steps must be run:
      1. The browsing context's browsing context name must be set to the name stored with the specified entry.
      2. Any browsing context name stored with the entries in the history that are associated with Document objects with the same origin as the new active document, and that are contiguous with the specified entry, must be cleared.

4. Set the document's current address to the URL of the specified entry.

5. If the specified entry is a state object or the first entry for a Document, the user agent must activate that entry.

6. If the specified entry has a URL that differs from the current entry's only by its fragment identifier, and the two share the same Document object, then first, if the Document's current document readiness is the string "complete", then fire a simple event with the name hashchange at the browsing context's Window object; and second, if the new URL has a fragment identifier, scroll to the fragment identifier.

7. User agents may also update other aspects of the document view when the location changes in this way, for instance the scroll position, values of form fields, etc.

8. The current entry is now the specified entry.

When a user agent is to unload a document, it must run the following steps. These steps are passed an argument, recycle, which is either true or false, indicating whether the Document object is going to be re-used. (This is set by the document.open() method.)

1. Set salvageable to true.

2. Let event be a new BeforeUnloadEvent event object with the name beforeunload, with no namespace, which does not bubble but is cancelable.

3. Dispatch event at the Document's Window object.

4. If any event listeners were triggered by the previous step, then set salvageable to false.

5. If the returnValue attribute of the event object is not the empty string, or if the event was canceled, then the user agent should ask the user to confirm that they wish to unload the document.

   The prompt shown by the user agent may include the string of the returnValue attribute, or some leading subset thereof. (A user agent may want to truncate the string to 1024 characters for display, for instance.)

   The user agent must pause while waiting for the user's response.

   If the user refused to allow the document to be unloaded then these steps must be aborted.

6. Fire a simple event called unload at the Document's Window object.

7. If any event listeners were triggered by the previous step, then set salvageable to false.

8. If there are any outstanding transactions that have callbacks that involve scripts whose global object is the Document's Window object, roll them back (without invoking any of the callbacks) and set salvageable to false.

9. If salvageable and recycle are both false, discard the Document.

5.10.10.1 Event definition

The returnValue attribute represents the message to show the user. When the event is created, the attribute must be set to the empty string. On getting, it must return the last value it was set to. On setting, the attribute must be set to the new value.

5.11.2 Following hyperlinks

When a user follows a hyperlink, the user agent must resolve the URL given by the href attribute of that hyperlink, relative to the hyperlink element, and if that is successful, must navigate a browsing context to the resulting absolute URL. In the case of server-side image maps, the URL of the hyperlink must further have its hyperlink suffix appended to it.

If resolving the URL fails, the user agent may report the error to the user in a user-agent-specific manner, may navigate to an error page to report the error, or may ignore the error and do nothing.

If the user indicated a specific browsing context when following the hyperlink, or if the user agent is configured to follow hyperlinks by navigating a particular browsing context, then that must be the browsing context that is navigated.

Otherwise, if the hyperlink element is an a or area element that has a target attribute, then the browsing context that is navigated must be chosen by applying the rules for choosing a browsing context given a browsing context name, using the value of the target attribute as the browsing context name. If these rules result in the creation of a new browsing context, it must be navigated with replacement enabled.

Otherwise, if the hyperlink element is a sidebar hyperlink and the user agent implements a feature that can be considered a secondary browsing context, such a secondary browsing context may be selected as the browsing context to be navigated.

Otherwise, if the hyperlink element is an a or area element with no target attribute, but one of the child nodes of the head element is a base element with a target attribute, then the browsing context that is navigated must be chosen by applying the rules for choosing a browsing context given a browsing context name, using the value of the target attribute of the first such base element as the browsing context name. If these rules result in the creation of a new browsing context, it must be navigated with replacement enabled.

Otherwise, the browsing context that must be navigated is the same browsing context as the one which the hyperlink element itself is in.

The navigation must be done with the browsing context that contains the Document object with which the hyperlink's element in question is associated as the source browsing context.

5.11.2.1 Hyperlink auditing

If an a or area hyperlink element has a ping attribute, and the user follows the hyperlink, and the hyperlink's URL can be resolved, relative to the hyperlink element, without failure, then the user agent must take the ping attribute's value, split that string on spaces, resolve each resulting token relative to the hyperlink element, and then should send a request (as described below) to each of the resulting absolute URLs. (Tokens that fail to resolve are ignored.) This may be done in parallel with the primary request, and is independent of the result of that request.

User agents should allow the user to adjust this behavior, for example in conjunction with a setting that disables the sending of HTTP Referer (sic) headers. Based on the user's preferences, UAs may either ignore the ping attribute altogether, or selectively ignore URLs in the list (e.g. ignoring any third-party URLs).

For URLs that are HTTP URLs, the requests must be performed by fetching the specified URLs using the POST method, with an entity body with the MIME type text/ping consisting of the four-character string "PING". All relevant cookie and HTTP authentication headers must be included in the request. Which other headers are required depends on the URLs involved.

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

The request must include a Ping-From HTTP header with, as its value, the address of the document containing the hyperlink, and a Ping-To HTTP header with, as its value, the address of the absolute URL of the target of the hyperlink. The request must not include a Referer (sic) HTTP header.

Otherwise, if the origins are different, but the document containing the hyperlink being audited was not retrieved over an encrypted connection

The request must include a Referer (sic) HTTP header [sic] with, as its value, the address of the document containing the hyperlink, a Ping-From HTTP header with the same value, and a Ping-To HTTP header with, as its value, the address of the target of the hyperlink.

Otherwise, the origins are different and the document containing the hyperlink being audited was retrieved over an encrypted connection

The request must include a Ping-To HTTP header with, as its value, the address of the target of the hyperlink. The request must neither include a Referer (sic) HTTP header nor include a Ping-From HTTP header.

In addition, an XXX-Origin header must always be included, whose value is the ASCII serialization of the origin of the Document containing the hyperlink. The value of the XXX-Origin header must be set to "null" when following redirects if the origins of all the URLs involved are not the same.

To save bandwidth, implementors might also wish to consider omitting optional headers such as Accept from these requests.

User agents must, unless otherwise specified by the user, honor the HTTP headers (including, in particular, redirects and HTTP cookie headers), but must ignore any entity bodies returned in the responses. User agents may close the connection prematurely once they start receiving an entity body. [RFC2109] [RFC2965]

For URLs that are not HTTP URLs, the requests must be performed by fetching the specified URL normally, and discarding the results.

When the ping attribute is present, user agents should clearly indicate to the user that following the hyperlink will also cause secondary requests to be sent in the background, possibly including listing the actual target URLs.

For example, a visual user agent could include the hostnames of the target ping URLs along with the hyperlink's actual URL in a status bar or tooltip.

To determine which link types apply to a link, a, or area element, the element's rel attribute must be split on spaces. The resulting tokens are the link types that apply to that element.

Some of the types described below list synonyms for these values. These are to be handled as specified by user agents, but must not be used in documents.

If the alternate keyword is used with the type attribute set to the value application/rss+xml or the value application/atom+xml, then the user agent must treat the link as it would if it had the feed keyword specified as well.

Synonyms: For historical reasons, user agents must also treat the keyword "archive" like the archives keyword.

Synonyms: For historical reasons, user agents must also treat link, a, and area elements that have a rev attribute with the value "made" as having the author keyword specified as a link relationship.

The first link, a, or area element in the document (in tree order) that creates a hyperlink with the link type feed must be treated as the default syndication feed for the purposes of feed autodiscovery.

The feed keyword is implied by the alternate link type in certain cases (q.v.).

<link rel="alternate" type="application/atom+xml" href="data.xml">

<link rel="feed alternate" href="data.xml">

 <p>You can access the planets database using Atom feeds:</p>
 <ul>
  <li><a href="recently-visited-planets.xml" rel="feed">Recently Visited Planets</a></li>
  <li><a href="known-bad-planets.xml" rel="feed">Known Bad Planets</a></li>
  <li><a href="unexplored-planets.xml" rel="feed">Unexplored Planets</a></li>
 </ul>

The specified resource is an icon representing the page or site, and should be used by the user agent when representing the page in the user interface.

There is no default type for resources given by the icon keyword. However, for the purposes of determining the type of the resource, user agents must expect the resource to be an image.

To parse and process the attribute's value, the user agent must first split the attribute's value on spaces, and must then parse each resulting keyword to determine what it represents.

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

• If the keyword doesn't contain exactly one U+0078 LATIN SMALL LETTER X character, then this keyword doesn't represent anything. Abort these steps for that keyword.

• Let width string be the string before the "x".

• Let height string be the string after the "x".

• If either width string or height string start with a U+0030 DIGIT ZERO (0) character or contain any characters other than characters in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9), then this keyword doesn't represent anything. Abort these steps for that keyword.

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

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

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

If the attribute is not specified, then the user agent must assume that the given icon is appropriate, but less appropriate than an icon of a known and appropriate size.

Synonyms: For historical reasons, user agents must also treat the keyword "copyright" like the license keyword.

If a user agent follows a link defined by an a or area element that has the noreferrer keyword, the user agent must not include a Referer (sic) HTTP header (or equivalent for other protocols) in the request.

This keyword also causes the opener attribute to remain null if the hyperlink creates a new browsing context.

Quirk: If the document has been set to quirks mode and the Content-Type metadata of the external resource is not a supported style sheet type, the user agent must instead assume it to be text/css.

Synonyms: For historical reasons, user agents must also treat the keywords "top", "contents", and "toc" like the index keyword.

When two links have both the up and index keywords specified together in the same scope and contradict each other by having a different number of up keywords, the link with the greater number of up keywords must be taken as giving the depth of the document.

Synonyms: For historical reasons, user agents must also treat the keywords "begin" and "start" like the first keyword.

Synonyms: For historical reasons, user agents must also treat the keyword "end" like the last keyword.

Synonyms: For historical reasons, user agents must also treat the keyword "previous" like the prev keyword.

Conformance checkers must use the information given on the WHATWG Wiki RelExtensions page to establish if a value not explicitly defined in this specification is allowed or not. When an author uses a new type 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 "proposal" status.