11. Obsolete features

11.1. Obsolete but conforming features

Features listed in this section will trigger warnings in conformance checkers.

Authors should not specify a border attribute on an img element. If the
attribute is present, its value must be the string "0". CSS should be used instead.

Authors should not specify a language attribute on a script element. If
the attribute is present, its value must be an ASCII case-insensitive match for the string
"JavaScript" and either the type attribute must be omitted or its value
must be an ASCII case-insensitive match for the string "text/javascript".
The attribute should be entirely omitted instead (with the value "JavaScript", it has
no effect), or replaced with use of the type attribute.

Authors should not specify the name attribute on a elements. If the
attribute is present, its value must not be the empty string and must neither be equal to the
value of any of the IDs in the element’s home subtree other than the element’s own id, if any, nor be equal to the value of any of the other name attributes on a elements in the element’s home subtree. If this attribute is present and the
element has an id, then the attribute’s value must be equal to the element’s id. In
earlier versions of the language, this attribute was intended as a way to specify possible targets
for fragment identifiers in URLs. The id attribute should be used instead.

Authors should not, but may despite requirements to the contrary elsewhere in this specification,
specify the maxlength and size attributes on input elements
whose type attributes are in the Number state. One
valid reason for using these attributes regardless is to help legacy user agents that do not
support input elements with type="number" to still render the text field with a
useful width.

11.1.1. Warnings for obsolete but conforming features

To ease the transition from HTML Transitional documents to the language defined in this specification, and to discourage certain features that are only allowed in very few circumstances,
conformance checkers must warn the user when the following features are used in a document. These
are generally old obsolete features that have no effect, and are allowed only to distinguish
between likely mistakes (regular conformance errors) and mere vestigial markup or unusual and
discouraged practices (these warnings).

The presence of a size attribute on an input element whose type attribute is in the Number state.

Conformance checkers must distinguish between pages that have no conformance errors and have none
of these obsolete features, and pages that have no conformance errors but do have some of these
obsolete features.

For example, a validator could report some pages as "Valid HTML" and others as "Valid HTML with
warnings".

11.2. Non-conforming features

Elements in the following list are entirely obsolete, and must not be used by authors:

Where the tt element would have been used for marking up keyboard input,
consider the kbd element; for variables, consider the var element;
for computer code, consider the code element; and for computer output, consider
the samp element.

Similarly, if the big element is being used to denote a heading, consider using
the h1 element; if it is being used for marking up important passages, consider
the strong element; and if it is being used for highlighting text for reference
purposes, consider the mark element.

Use text that begins in an unambiguous and terse manner, and include any more elaborate text
after that. The title attribute can also be useful in including more detailed
text, so that the cell’s contents can be made terse. If it’s a heading, use th (which has an abbr attribute).

The border attribute on the table element can be used to provide basic fallback
styling for the purpose of making tables legible in browsing environments where CSS support is
limited or absent, such as text-based browsers, WYSIWYG editors, and in situations where CSS
support is disabled or the style sheet is lost. Only the empty string and the value
"1" may be used as border values for this purpose. Other values are
considered obsolete. To regulate the thickness of such borders, authors should instead use CSS.

11.3. Requirements for implementations

11.3.1. The applet element

This feature is in the process of being removed from the Web platform. (This is a long process
that takes many years.) Using the applet element at this time is highly
discouraged.

The applet element is a Java-specific variant of the embed element.
The applet element is now obsoleted so that all extension frameworks (Java, .NET,
Flash, etc) are handled in a consistent manner.

When the element matches any of the following conditions, it represents its contents:

Otherwise, the user agent should instantiate a Java Language runtime plugin, and should
pass the names and values of all the attributes on the element, in the order they were added to
the element, with the attributes added by the parser being ordered in source order, and then a
parameter named "PARAM" whose value is null, and then all the names and values of parameters given by param elements that are children of the applet element, in tree order, to the plugin used. If the plugin supports a scriptable interface, the HTMLAppletElement object representing the
element should expose that interface. The applet element represents the plugin.

The applet element is unaffected by the CSS display property. The
Java Language runtime is instantiated even if the element is hidden with a 'display:none' CSS
style.

The align, alt, archive, code, height, hspace, name, object, vspace, and width IDL attributes must reflect the respective content attributes of the same name. For the purposes of reflection, the applet element’s object content attribute is defined as containing a URL.

The codeBase IDL attribute must reflect the codebase content attribute, which for the purposes of reflection
is defined as containing a URL.

A marquee element has a marquee scroll interval, which is obtained as follows:

If the element has a scrolldelay content
attribute, and parsing its value using the rules for parsing non-negative integers does
not return an error, then let delay be the parsed value. Otherwise, let delay be 85.

If the element does not have a truespeed attribute, and the delay value
is less than 60, then let delay be 60 instead.

A marquee element has a marquee scroll distance, which, if the
element has a scrollamount content attribute,
and parsing its value using the rules for parsing non-negative integers does not return an
error, is the parsed value interpreted in CSS pixels, and otherwise is 6 CSS pixels.

A marquee element has a marquee loop count, which, if the element has a loop content attribute, and parsing its value
using the rules for parsing integers does not return an error or a number less than 1, is
the parsed value, and otherwise is -1.

The loop IDL attribute, on getting,
must return the element’s marquee loop count; and on setting, if the new value is different
than the element’s marquee loop count and either greater than zero or equal to -1, must set
the element’s loop content attribute (adding it if necessary) to the valid integer that represents the new value. (Other values are ignored.)

A marquee element also has a marquee current loop index, which is zero when the
element is created.

The rendering layer will occasionally increment the marquee current loop index, which
must cause the following steps to be run:

When the browsing context is created, if a name content attribute is present, the browsing context name must be set to the value of this
attribute; otherwise, the browsing context name must be set to the empty string.

The name, scrolling, and src IDL attributes of the frame element must reflect the respective content attributes of the same name. For the purposes
of reflection, the frame element’s src content attribute is defined as containing a URL.

The frameBorder IDL attribute of the frame element must reflect the element’s frameborder content attribute.

The longDesc IDL attribute of the frame element must reflect the element’s longdesc content attribute, which
for the purposes of reflection is defined as containing a URL.

The noResize IDL attribute of the frame element must reflect the element’s noresize content attribute.

A URL in the list can be flagged with multiple different types, and thus an
entry can end up being categorized as multiple entries. For example, an entry can be a manifest
entry and an explicit entry at the same time, if the manifest is listed within the manifest.

Zero or more fallback namespaces, each of
which is mapped to a fallback entry.

These are used as prefix match patterns, and declare URLs for which the user
agent will ignore the application cache, instead fetching them normally (i.e., from the network
or local HTTP cache as appropriate).

An online safelist wildcard
flag, which is either open or blocking.

The open state indicates that any URL not listed as cached is to
be implicitly treated as being in the online
safelist namespaces; the blocking state indicates that URLs not listed
explicitly in the manifest are to be treated as unavailable.

A cache mode flag, which is either in the fast state or the prefer-online state.

Each application cache has a completeness flag, which is either complete or incomplete.

Multiple application caches in different application cache groups can contain the same resource,
e.g., if the manifests all reference that resource. If the user agent is to select an application cache from a list of relevant application caches that contain a resource, the
user agent must use the application cache that the user most likely wants to see the resource
from, taking into account the following:

which application cache was most recently updated,

which application cache was being used to display the resource from which the user decided to
look at the new resource, and

which application cache the user prefers.

A URL matches a fallback namespace if
there exists a relevant application cache whose manifest’s URL has the same origin as the
URL in question, and that has a fallback
namespace that is a prefix match for the URL being examined. If multiple
fallback namespaces match the same URL, the longest one is the one that matches. A URL looking for
a fallback namespace can match more than one application cache at a time, but only matches one
namespace in each cache.

11.3.4.1. Parsing cache manifests

When a user agent is to parse a manifest, it means that the user agent must run the
following steps:

UTF-8 decode the byte stream corresponding with the manifest to be parsed.

Remove all the characters in manifest path after the last U+002F SOLIDUS
character (/), if any. (The first character and the last character in manifest path after this step will both be slashes, the URL path separator character.)

Apply the URL parser steps to the base URL, so that the
components from its URL record can be used by the subsequent steps of this
algorithm.

Let position be a pointer into input, initially
pointing at the first character.

If the characters starting from position are "CACHE", followed by a
U+0020 SPACE character, followed by "MANIFEST", then advance position to the
next character after those. Otherwise, this isn’t a cache manifest; abort this algorithm with a
failure while checking for the magic signature.

If the character at position is neither a U+0020 SPACE character, a
U+0009 CHARACTER TABULATION (tab) character, U+000A LINE FEED (LF) character, nor a U+000D
CARRIAGE RETURN (CR) character, then this isn’t a cache manifest; abort this algorithm with a
failure while checking for the magic signature.

This is a cache manifest. The algorithm cannot fail beyond
this point (though bogus lines can get ignored).

Collect a sequence of characters that are not U+000A LINE FEED (LF)
or U+000D CARRIAGE RETURN (CR) characters, and ignore those characters. (Extra text on the first
line, after the signature, is ignored.)

Let mode be "explicit".

Start of line: If position is past the end of input, then jump to the last step. Otherwise, collect a sequence of
characters that are U+000A LINE FEED (LF), U+000D CARRIAGE RETURN (CR), U+0020 SPACE, or
U+0009 CHARACTER TABULATION (tab) characters.

Drop any trailing U+0020 SPACE and U+0009 CHARACTER TABULATION (tab) characters at the end
of line.

If line is the empty string, then jump back to the step labeled start
of line.

If the first character in line is a U+0023 NUMBER SIGN character (#),
then jump back to the step labeled Start of line.

If line equals "CACHE:" (the word "CACHE" followed by a U+003A COLON
character (:)), then set mode to "explicit" and jump back to the step labeled Start of line.

If line equals "FALLBACK:" (the word "FALLBACK" followed by a U+003A
COLON character (:)), then set mode to "fallback" and jump back to the step
labeled Start of line.

If line equals "NETWORK:" (the word "NETWORK" followed by a U+003A
COLON character (:)), then set mode to "online safelist" and jump back to
the step labeled Start of line.

If line equals "SETTINGS:" (the word "SETTINGS" followed by a U+003A
COLON character (:)), then set mode to "settings" and jump back to the step
labeled Start of line.

If line ends with a U+003A COLON character (:), then set mode to "unknown" and jump back to the step labeled Start of line.

This is either a data line or it is syntactically incorrect.

Let position be a pointer into line, initially
pointing at the start of the string.

Let tokens be a list of strings, initially empty.

While position doesn’t point past the end of line:

Let current token be an empty string.

While position doesn’t point past the end of line and the character at position is neither a U+0020 SPACE
nor a U+0009 CHARACTER TABULATION (tab) character, add the character at position to current token and advance position to the next character in input.

Add current token to the tokens list.

While position doesn’t point past the end of line and the character at position is either a U+0020 SPACE
or a U+0009 CHARACTER TABULATION (tab) character, advance position to the
next character in input.

Process tokens as follows:

If mode is "explicit"

Let urlRecord be the result of parsing the first item in tokens, with base URL; ignore the rest.

If urlRecord is failure, then jump back to the step labeled Start of line.

If urlRecord has a different scheme component than base URL (the manifest’s URL), then jump back to the step labeled Start of line.

Let new URL be the result of applying the URL serializer algorithm to urlRecord, with the exclude fragment flag set.

Add new URL to the explicit URLs.

If mode is "fallback"

Let part one be the first token in tokens, and let part two be the second token in tokens.

Some of these steps have requirements that only apply if the user agent shows caching
progress. Support for this is optional. Certain events
fired during the application cache download process allow the script to override the
display of such an interface. (Such events are delayed until after the load event has fired.)

User agents are encouraged not to show
prominent update progress notifications for applications that cancel the relevant events.

Optionally, wait until the permission to start the application cache download
process has been obtained from the user and until the user agent is confident that the
network is available. This could include doing nothing until the user explicitly opts-in to
caching the site, or could involve prompting the user for permission. The algorithm might never
get past this point. (This step is particularly intended to be used by user agents running on
severely space-constrained devices or in highly privacy-sensitive environments).

Atomically, so as to avoid race conditions, perform the following substeps:

If these steps were invoked with a cache host, and the status of cache group is checking or downloading, then queue a post-load task to fire a
simple event named checking that is
cancelable at the ApplicationCache singleton of that cache host. The
default action of this event must be, if the user agent shows caching progress,
the display of some sort of user interface indicating to the user that the user agent is
checking to see if it can download the application.

The MIME type of the resource is ignored — it is assumed to
be text/cache-manifest. In the future, if new manifest formats are supported, the
different types will probably be distinguished on the basis of the file signatures (for the
current format, that is the "CACHE MANIFEST" string at the top of the
file).

If fetching the manifest fails due to a 404 or 410 response status, then run these
substeps:

Mark cache group as obsolete. This cache group no
longer exists for any purpose other than the processing of Document objects
already associated with an application cache in the cache
group.

For each cache host associated with an application cache in cache group, create a task to fire
a simple event named obsolete that is
cancelable at the ApplicationCache singleton of the cache host, and
append it to task list. The default action of these events must be, if the
user agent shows caching progress, the display of some sort of user interface
indicating to the user that the application is no longer available for offline use.

For each entry in cache group’s list of pending master entries, create a task to fire a simple event that is cancelable named error (not obsolete!) at the ApplicationCache singleton of the Document for this entry, if there still is one, and append it to task list. The default action of this event must be, if the user agent shows caching progress, the display of some sort of user interface indicating to
the user that the user agent failed to save the application for offline use.

Otherwise, if fetching the manifest fails in some other way (e.g., the server returns
another 4xx or 5xx response, or there is a DNS error, or the connection times out, or the user
cancels the download, or the parser for manifests fails when checking the magic signature), or
if the server returned a redirect, then run the cache failure steps. [HTTP]

If this is an upgrade attempt and the newly
downloaded manifest is byte-for-byte identical to the manifest found in the newestapplication cache in cache
group, or the response status is 304, then run these substeps:

If the download failed (e.g., the server returns a 4xx or 5xx response, or there is a DNS
error, the connection times out, or the user cancels the download), or if the resource is
labeled with the "no-store" cache directive, then create a task to fire a simple event that is cancelable named error at the ApplicationCache singleton of the Document for this entry, if there still is one, and append it to task list. The default action of this event must be, if the user agent shows
caching progress, the display of some sort of user interface indicating to the user
that the user agent failed to save the application for offline use.

For each cache host associated with an application cache in cache group, create a task to fire
a simple event that is cancelable named noupdate at the ApplicationCache singleton
of the cache host, and append it to task list. The default
action of these events must be, if the user agent shows caching progress, the
display of some sort of user interface indicating to the user that the application is up to
date.

If the resource URL being processed was flagged as neither an "explicit entry" nor or a
"fallback entry", then the user agent may skip this URL.

This is intended to allow user agents to expire resources not listed in the
manifest from the cache. Generally, implementors are urged to use an approach that expires
lesser-used resources first.

For each cache host associated with an application cache in cache group, queue a progress post-load task to fire a trusted event with the name progress, which does not
bubble, which is cancelable, and which uses the ProgressEvent interface, at the ApplicationCache singleton of the cache host. The lengthComputable attribute must be set to
true, the total attribute must be set to the
number of files in file list, and the loaded attribute must be set to the number of files in file list that have been either downloaded or skipped so far. The default
action of these events must be, if the user agent shows caching progress, the
display of some sort of user interface indicating to the user that a file is being downloaded
in preparation for updating the application. [XHR]

Fetchrequest. If this is an upgrade attempt, then use the newestapplication cache in cache
group as an HTTP cache, and honor HTTP caching semantics (such as expiration, ETags, and
so forth) with respect to that cache. User agents may also have other caches in place that are
also honored.

If the previous step fails (e.g., the server returns a 4xx or 5xx response, or there is a
DNS error, or the connection times out, or the user cancels the download), or if the server
returned a redirect, or if the resource is labeled with the "no-store" cache directive, then
run the first appropriate step from the following list: [HTTP]

If the URL being processed was flagged as an "explicit entry" or a "fallback entry"

If these steps are being run in parallel for any other URLs in file
list, then abort these steps for those other URLs. Run the cache failure
steps.

Redirects are fatal because they are either indicative of a network problem
(e.g., a captive portal); or would allow resources to be added to the cache under URLs that
differ from any URL that the networking model will allow access to, leaving orphan entries;
or would allow resources to be stored under URLs different than their true URLs. All of
these situations are bad.

If the error was a 404 or 410 HTTP response

If the resource was labeled with the "no-store" cache directive

Skip this resource. It is dropped from the cache.

Otherwise

Copy the resource and its metadata from the newestapplication cache in cache group whose completeness
flag is complete, and act as if that was the fetched resource, ignoring the
resource obtained from the network.

These rules make errors for resources listed in the manifest fatal, while
making it possible for other resources to be removed from caches when they are removed from
the server, without errors, and making non-manifest resources survive server-side errors.

Except for the "no-store" directive, HTTP caching rules that would cause a
file to be expired or otherwise not cached are ignored for the purposes of the application cache download process.

Otherwise, the fetching succeeded. Store the resource in the new
cache.

If the user agent is not able to store the resource (e.g., because of quota restrictions),
the user agent may prompt the user or try to resolve the problem in some other manner (e.g.,
automatically pruning content in other caches). If the problem cannot be resolved, the user
agent must run the cache failure steps.

If the URL being processed was flagged as an "explicit entry" in file
list, then categorize the entry as an explicit
entry.

If the URL being processed was flagged as a "fallback entry" in file
list, then categorize the entry as a fallback
entry.

If the URL being processed was flagged as an "master entry" in file
list, then categorize the entry as a master
entry.

As an optimization, if the resource is an HTML or XML file whose root element is an html element with a manifest attribute
whose value doesn’t match the manifest URL of the application cache being processed, then the
user agent should mark the entry as being foreign.

For each cache host associated with an application cache in cache group, queue a progress post-load task to fire a trusted event with the name progress, which does not bubble,
which is cancelable, and which uses the ProgressEvent interface, at the ApplicationCache singleton of the cache host. The lengthComputable attribute must be set to
true, the total and the loaded attributes must be set to the number of files in file list. The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the
user that all the files have been downloaded. [XHR]

If the download failed (e.g., the server returns a 4xx or 5xx response, or there is a DNS
error, the connection times out, or the user cancels the download), or if the resource is
labeled with the "no-store" cache directive, then run these substeps:

Queue a post-load task to fire a simple event that is
cancelable named error at the ApplicationCache singleton of the Document for this entry, if there
still is one. The default action of this event must be, if the user agent shows caching
progress, the display of some sort of user interface indicating to the user that the
user agent failed to save the application for offline use.

Let second manifest be the result of fetchingrequest. HTTP caching semantics should again
be honored for this request.

If the previous step failed for any reason, or if the fetching attempt involved a redirect,
or if second manifest and manifest are not byte-for-byte
identical, then schedule a rerun of the entire algorithm with the same parameters after a short
delay, and run the cache failure steps.

Otherwise, store manifest in new cache, if it’s not
there already, and categorize its entry as the
manifest.

If this is a cache attempt, then for each cache host associated with an application cache in cache
group, create a task to fire a simple event that is cancelable named cached at the ApplicationCache singleton of the cache host, and append it to task list. The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to
the user that the application has been cached and that they can now use it offline.

Otherwise, it is an upgrade attempt. For each cache host associated with an application cache in cache
group, create a task to fire a simple event that is cancelable named updateready at the ApplicationCache singleton of the cache host, and append it to task list. The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to
the user that a new version is available and that they can activate it by reloading the
page.

If appropriate, remove any user interface indicating that an update for this cache is in
progress.

Create a task to fire a simple event that
is cancelable named error at the ApplicationCache singleton of the Document for this entry, if there
still is one, and append it to task list. The default action of these
events must be, if the user agent shows caching progress, the display of some sort
of user interface indicating to the user that the user agent failed to save the application for
offline use.

For each cache host still associated with an application cache in cache group, create a task to fire
a simple event that is cancelable named error at
the ApplicationCache singleton of the cache host, and append it to task list. The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the
user that the user agent failed to save the application for offline use.

Each Document has a list of pending application cache download process
tasks that is used to delay events fired by the algorithm above until the document’s load event has fired. When the Document is created, the
list must be empty.

When the steps above say to queue a post-load tasktask, where task is a task that dispatches an event on a
target ApplicationCache object target, the user agent must run
the appropriate steps from the following list:

11.3.4.3. The application cache selection algorithm

When the application cache selection algorithm algorithm is invoked with a Documentdocument and optionally a
manifest URLmanifest URL, the user agent must run the first
applicable set of steps from the following list:

If there are relevant application caches that
are identified by a URL with the same origin as the URL of document, and that have this URL as one of their entries, excluding entries
marked as foreign, then the user agent should use
the most appropriate application cache of those
that match as an HTTP cache for any subresource loads. User agents may also have other caches in
place that are also honored.

Fetch the resource normally. If this results in a redirect to a resource with another origin (indicative of a captive portal), or a 4xx or 5xx status code, or if
there were network errors (but not if the user canceled the download), then instead get, from
the cache, the resource of the fallback entry corresponding to the fallback namespacef. Abort these steps.

The above algorithm ensures that so long as the online safelist wildcard flag is blocking, resources that are not present in the manifest will always fail to load (at least, after the application cache has been primed the first time), making the testing of offline
applications simpler.

11.3.4.5. Expiring application caches

As a general rule, user agents should not expire application caches, except on request from the
user, or after having been left unused for an extended period of time.

Application caches and cookies have similar implications with respect to privacy (e.g., if the
site can identify the user when providing the cache, it can store data in the cache that can be
used for cookie resurrection). Implementors are therefore encouraged to expose application caches
in a manner related to HTTP cookies, allowing caches to be expunged together with cookies and
other origin-specific data.

11.3.4.6. Disk space

User agents should consider applying constraints on disk usage of application caches, and care should be taken to ensure that the restrictions cannot
be easily worked around using subdomains.

User agents should allow users to see how much space each domain is using, and may offer the
user the ability to delete specific application caches.

11.3.4.7. Security concerns with offline applications caches

This section is non-normative.

The main risk introduced by offline application caches is that an injection attack can be
elevated into persistent site-wide page replacement. This attack involves using an injection
vulnerability to upload two files to the victim site. The first file is an application cache
manifest consisting of just a fallback entry pointing to the second file, which is an HTML page
whose manifest is declared as that first file. Once the user has been directed to that second
file, all subsequent accesses to any file covered by the given fallback namespace while either the
user or the site is offline will instead show that second file. Targeted denial-of-service
attacks or cookie bombing attacks (where the client is made to send so many cookies that the
server refuses to process the request) can be used to ensure that the site appears offline.

To mitigate this, manifests can only specify fallbacks that are in the same path as the
manifest itself. This means that a content injection upload vulnerability in a particular
directory on a server can only be escalated to a take-over of that directory and its
subdirectories. If there is no way to inject a file into the root directory, the entire site
cannot be taken over.

If a site has been attacked in this way, simply removing the offending manifest might eventually
clear the problem, since the next time the manifest is updated, a 404 error will be seen, and the
user agent will clear the cache. "Eventually" is the key word here, however; while the attack on
the user or server is ongoing, such that connections from an affected user to the affected site
are blocked, the user agent will simply assume that the user is offline and will continue to use
the hostile manifest. Unfortunately, if a cookie bombing attack has also been used, merely
removing the manifest is insufficient; in addition, the server has to be configured to return a
404 or 410 response instead of the 413 "Request Entity Too Large" response.

TLS does not inherently protect a site from this attack, since the attack relies on content
being served from the server itself. Not using application caches also does not prevent this
attack, since the attack relies on an attacker-provided manifest.

Switches to the most recent application cache, if there is a newer one. If there isn’t,
throws an InvalidStateError exception.

There is a one-to-one mapping from cache hosts to ApplicationCache objects. The applicationCache attribute on Window objects must return the ApplicationCache object associated with the Window object’s active document. The applicationCache attribute
on SharedWorkerGlobalScope objects must return the ApplicationCache object associated with the worker.

A Window or SharedWorkerGlobalScope object has an
associated ApplicationCache object even if that cache host has no actual application cache.

The status attribute, on getting, must
return the current state of the application cache that the ApplicationCache object’s cache host is associated with, if any. This
must be the appropriate value from the following list:

If the swapCache() method is invoked,
the user agent must run the following steps:

Check that ApplicationCache object’s cache host is associated
with an application cache. If it is not, then throw an InvalidStateError exception and abort these steps.

Let cache be the application cache with which the ApplicationCache object’s cache host is associated. (By definition,
this is the same as the one that was found in the previous step.)

If cache’s application cache group is marked as obsolete, then unassociate the ApplicationCache object’s cache host from cache and
abort these steps. (Resources will now load from the network instead of the cache.)

Check that there is an application cache in the same application cache group as cache whose completeness
flag is complete and that is newer than cache. If there is not, then throw an InvalidStateError exception and abort these steps.

The align IDL attribute of the h1–h6 elements must reflect the content attribute of the same name.

The profile IDL attribute on head elements (with the HTMLHeadElement interface) is intentionally omitted. Unless so required
by another applicable specification, implementations would
therefore not support this attribute. (It is mentioned here as it was defined in a previous
version of the DOM specifications.)

User agents may treat the scheme content attribute
on the meta element as an extension of the element’s name content attribute when
processing a meta element with a name attribute whose value is one that the user
agent recognizes as supporting the scheme attribute.

User agents are encouraged to ignore the scheme attribute and instead process the
value given to the metadata name as if it had been specified for each expected value of the scheme attribute.

For example, if the user agent acts on meta elements with name attributes having the value "eGMS.subject.keyword", and knows that the scheme attribute is used with this metadata name, then it could take the scheme attribute
into account, acting as if it was an extension of the name attribute. Thus the
following two meta elements could be treated as two elements giving values for two
different metadata names, one consisting of a combination of "eGMS.subject.keyword" and "LGCL",
and the other consisting of a combination of "eGMS.subject.keyword" and "ORLY":

The attributes of the Document object listed in the first column of the following table must reflect the content attribute on the body element with the name given in the
corresponding cell in the second column on the same row, if the body element is a body element (as opposed to a frameset element). When there is no body element or if it is a frameset element, the attributes must instead return the empty string on getting and do
nothing on setting.

The user agent must act as if the ToBoolean() operator in JavaScript converts the object
returned for all to the false value.

The user agent must act as if, for the purposes of the == and != operators in JavaScript, the object returned for all compares as equal to the undefined and null values. (Comparisons using the === operator, and comparisons to other values such as strings or objects, are unaffected.)

The user agent must act such that the typeof operator in JavaScript returns the
string undefined when applied to the object returned for all.

These requirements are a willful violation of the JavaScript specification current at the
time of writing (ECMAScript edition 6). The JavaScript specification requires that the
ToBoolean() operator convert all objects to the true value, and does not have provisions for
objects acting as if they were undefined for the purposes of certain operators.
This violation is motivated by a desire for compatibility with two classes of legacy content:
one that uses the presence of document.all as a way to detect legacy user agents,
and one that only supports those legacy user agents and uses the document.all object without testing for its presence first. [ECMA-262]