The html element in the following example declares
that the document's language is English.

<!DOCTYPE html>
<html lang="en">
<head>
<title>Swapping Songs</title>
</head>
<body>
<h1>Swapping Songs</h1>
<p>Tonight I swapped some of the songs I wrote with some friends, who
gave me some of the songs they wrote. I love sharing my music.</p>
</body>
</html>

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

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

Returns the contents of the element, ignoring child nodes that
aren't text nodes.

Can be set, to replace the element's children with the given
value.

The IDL attribute text must return a
concatenation of the contents of all the text nodes that are direct children of the
title element (ignoring any other nodes such as
comments or elements), in tree order. On setting, it must act the
same way as the textContent IDL attribute.

Here are some examples of appropriate titles, contrasted with
the top-level headings that might be used on those same pages.

<title>Introduction to The Mating Rituals of Bees</title>
...
<h1>Introduction</h1>
<p>This companion guide to the highly successful
<cite>Introduction to Medieval Bee-Keeping</cite> book is...

The next page might be a part of the same site. Note how the
title describes the subject matter unambiguously, while the first
heading assumes the reader knows what the context is and therefore
won't wonder if the dances are Salsa or Waltz:

The string to use as the document's title is given by the document.title IDL attribute.

User agents should use the document's title when referring to the
document in their user interface. When the contents of a
title element are used in this way, the
directionality of that title element should be
used to set the directionality of the document's title in the user
interface.

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

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

The types of link indicated (the relationships) are given by the
value of the rel
attribute, which, if present, must have a value that is a set
of space-separated tokens. The allowed
keywords and their meanings are defined in a later
section. If the rel attribute is absent, has no
keywords, or if none of the keywords used are allowed according to
the definitions in this specification, then the element does not
create any links.

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

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

The exact behavior for links to external resources depends on the
exact relationship, as defined for the relevant link type. Some of
the attributes control whether or not the external resource is to be
applied (as defined below).

For external resources that are represented in the
DOM (for example, style sheets), the DOM representation must be made
available even if the resource is not applied. To obtain the resource, the user
agent must run the following steps:

If the href attribute's
value is the empty string, then abort these steps.

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

The semantics of the protocol used (e.g. HTTP) must be followed
when fetching external resources. (For example, redirects will be
followed and 404 responses will cause the external resource to not
be applied.)

Once the attempts to obtain the resource and its critical
subresources are complete, the user agent must, if the loads
were successful, queue a task to fire a simple
event named load at the
link element, or, if the resource or one of its
critical subresources failed to completely load for any
reason (e.g. DNS error, HTTP 404 response, a connection being
prematurely closed, unsupported Content-Type), queue a
task to fire a simple event named error at the link
element. Non-network errors in processing the resource or its
subresources (e.g. CSS parse errors, PNG decoding errors) are not
failures for the purposes of this paragraph.

The element must delay the load event of the
element's document until all the attempts to obtain the resource and
its critical subresources are complete. (Resources that
the user agent has not yet attempted to obtain, e.g. because it is
waiting for the resource to be needed, do not delay the load
event.)

Interactive user agents may provide users with a
means to follow the
hyperlinks created using the link element,
somewhere within their user interface. The exact interface is not
defined by this specification, but it could include the following
information (obtained from the element's attributes, again as
defined below), in some form or another (possibly simplified), for
each hyperlink created with each link element in the
document:

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

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

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

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

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

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

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

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

For external resource
links, the type attribute
is used as a hint to user agents so that they can avoid fetching
resources they do not support. If the attribute
is present, then the user agent must assume that the resource is of
the given type (even if that is not a valid MIME type,
e.g. the empty string). If the attribute is omitted, but the
external resource link type has a default type defined, then the
user agent must assume that the resource is of that type. If the UA
does not support the given MIME type for the given link
relationship, then the UA should not obtain the resource; if the UA
does support the given MIME type for the given link
relationship, then the UA should obtain the resource at the
approprite time as specified for the external resource
link's particular type. If the attribute is omitted, and the
external resource link type does not have a default type defined,
but the user agent would obtain the resource if the type
was known and supported, then the user agent should obtain the resource under the
assumption that it will be supported.

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

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

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

...then a compliant UA that supported only CSS style sheets
would fetch the B and C files, and skip the A file (since
text/plain is not the MIME type for CSS style
sheets).

For files B and C, it would then check the actual types returned
by the server. For those that are sent as text/css, it
would apply the styles, but for those labeled as
text/plain, or any other type, it would not.

If one of the two files was returned without a
Content-Type metadata, or with a syntactically
incorrect type like Content-Type: "null", then the default type
for stylesheet links would kick
in. Since that default type is text/css, the
style sheet would nonetheless be applied.

The title
attribute gives the title of the link. With one exception, it is
purely advisory. The value is text. The exception is for style sheet
links, where the title
attribute defines alternative style sheet sets.

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

The sizes attribute is used
with the icon link type. The attribute
must not be specified on link elements that do not have
a rel attribute that specifies
the icon keyword.

Some versions of HTTP defined a Link:
header, to be processed like a series of link elements.
If supported, for the purposes of ordering links defined by HTTP
headers must be assumed to come before any links in the document, in
the order that they were given in the HTTP entity header. (URIs in
these headers are to be processed and resolved according to the
rules given in HTTP; the rules of this specification don't
apply.) [HTTP][WEBLINK]

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

The IDL attribute disabled only applies
to style sheet links. When the link element defines a
style sheet link, then the disabled attribute behaves as
defined for the alternative
style sheets DOM. For all other link elements it
always return false and does nothing on setting.

The meta element can represent document-level
metadata with the name
attribute, pragma directives with the http-equiv attribute, and the
file's character encoding declaration when an HTML
document is serialized to string form (e.g. for transmission over
the network or for disk storage) with the charset attribute.

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

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

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

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

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

4.2.5.1 Standard metadata names

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

The value must be a short free-form string giving the name
of the Web application that the page represents. If the page is not
a Web application, the application-name metadata name
must not be used. There must not be more than one meta
element with its name attribute
set to the value application-name per
document. User agents may use the application
name in UI in preference to the page's title, since
the title might include status messages and the like relevant to
the status of the page at a particular moment in time instead of
just being the name of the application.

author

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

description

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

generator

The value must be a free-form string that identifies one of the
software packages used to generate the document. This value must
not be used on hand-authored pages.

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

Many search engines do not consider such keywords,
because this feature has historically been used unreliably and
even misleadingly as a way to spam search engine results in a way
that is not helpful for users.

To obtain the list of keywords that the author has specified as
applicable to the page, the user agent must run the following
steps:

Let keywords be an empty
list.

For each meta element with a name attribute and a content attribute and whose
name attribute's value is
keywords, run the following
substeps:

Return keywords. This is the list of
keywords that the author has specified as applicable to the
page.

User agents should not use this information when there is
insufficient confidence in the reliability of the value.

For instance, it would be reasonable for a
content management system to use the keyword information of pages
within the system to populate the index of a site-specific search
engine, but a large-scale content aggregator that used this
information would likely find that certain users would try to game
its ranking mechanism through the use of inappropriate
keywords.

4.2.5.2 Other metadata names

Anyone is free to edit the WHATWG Wiki MetaExtensions page at any
time to add a type. These new names must be specified with the
following information:

Keyword

The actual name being defined. The name should not be
confusingly similar to any other defined name (e.g. differing only
in case).

Brief description

A short non-normative description of what the metadata
name's meaning is, including the format the value is required to be
in.

Specification

A link to a more detailed description of the metadata name's
semantics and requirements. It could be another page on the Wiki,
or a link to an external page.

Synonyms

A list of other names that have exactly the same processing
requirements. Authors should not use the names defined to be
synonyms, they are only intended to allow user agents to support
legacy content. Anyone may remove synonyms that are not used in
practice; only names that need to be processed as synonyms for
compatibility with legacy content are to be registered in this
way.

Status

One of the following:

Proposed

The name has not received wide peer review and
approval. Someone has proposed it and is, or soon will be, using
it.

Ratified

The name has received wide peer review and approval. It has a
specification that unambiguously defines how to handle pages that
use the name, including when they use it in incorrect ways.

Discontinued

The metadata name has received wide peer review and it has
been found wanting. Existing pages are using this metadata name,
but new pages should avoid it. The "brief description" and
"specification" entries will give details of what authors should
use instead, if anything.

If a metadata name is found to be redundant with existing
values, it should be removed and listed as a synonym for the
existing value.

If a metadata name is registered in the "proposed" state for a
period of a month or more without being used or specified, then it
may be removed from the registry.

If a metadata name is added with the "proposed" status and
found to be redundant with existing values, it should be removed
and listed as a synonym for the existing value. If a metadata name
is added with the "proposed" status and found to be harmful, then
it should be changed to "discontinued" status.

Anyone can change the status at any time, but should only do so
in accordance with the definitions above.

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

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

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

4.2.5.3 Pragma directives

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

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

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

Conformance checkers will include a warning if
this pragma is used. Authors are encouraged to use the lang attribute instead.

If another meta element with an http-equiv attribute in the
Content
Language state has already been successfully processed
(i.e. when it was inserted the user agent processed it and
reached the last step of this list of steps), then abort these
steps.

If the meta element has no content attribute, or if that
attribute's value is the empty string, then abort these
steps.

If the element's content attribute contains a
U+002C COMMA character (,) then abort these steps.

If the meta element has no content attribute, or if that
attribute's value is the empty string, then abort these
steps.

Set the preferred style sheet set to the
value of the element's content attribute. [CSSOM]

Refresh state (http-equiv="refresh")

This pragma acts as timed redirect.

If another meta element with an http-equiv attribute in the
Refresh state
has already been successfully processed (i.e. when it was
inserted the user agent processed it and reached the last step of
this list of steps), then abort these steps.

If the meta element has no content attribute, or if that
attribute's value is the empty string, then abort these
steps.

If the character in input pointed to
by position is a U+0055 LATIN CAPITAL LETTER
U character (U) or a U+0075 LATIN SMALL LETTER U character (u),
then advance position to the next
character. Otherwise, jump to the last step.

If the character in input pointed to
by position is a U+0052 LATIN CAPITAL LETTER
R character (R) or a U+0072 LATIN SMALL LETTER R character (r),
then advance position to the next
character. Otherwise, jump to the last step.

If the character in input pointed to
by position is s U+004C LATIN CAPITAL LETTER
L character (L) or a U+006C LATIN SMALL LETTER L character (l),
then advance position to the next
character. Otherwise, jump to the last step.

If the character in input pointed to
by position is either a U+0027 APOSTROPHE
character (') or U+0022 QUOTATION MARK character ("), then let
quote be that character, and advance position to the next character. Otherwise, let
quote be the empty string.

Let url be equal to the substring of
input from the character at position to the end of the string.

If quote is not the empty string, and
there is a character in url equal to quote, then truncate url at
that character, so that it and all subsequent characters are
removed.

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

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

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

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

4.2.5.4 Other pragma directives

Such extensions must use a name that is identical to an HTTP
header registered in the Permanent Message Header Field Registry,
and must have behavior identical to that described for the HTTP
header. [IANAPERMHEADERS]

Pragma directives corresponding to headers describing metadata,
or not requiring specific user agent processing, must not be
registered; instead, use metadata names. Pragma
directives corresponding to headers that affect the HTTP processing
model (e.g. caching) must not be registered, as they would result in
HTTP-level behavior being different for user agents that implement
HTML than for user agents that do not.

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

Keyword

The actual name being defined. The name must match a
previously-registered HTTP name with the same
requirements.

Brief description

A short non-normative description of the purpose of the
pragma directive.

Specification

A link to the specification defining the corresponding HTTP
header.

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

4.2.5.5 Specifying the document's character encoding

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

The following restrictions apply to character encoding
declarations:

The character encoding name given must be the name of the
character encoding used to serialize the file.

Authors are encouraged to use UTF-8. Conformance checkers may
advise authors against using legacy encodings. [RFC3629]

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

Encodings in which a series of bytes in the range 0x20 to 0x7E
can encode characters other than the corresponding characters in the
range U+0020 to U+007E represent a potential security vulnerability:
a user agent that does not support the encoding (or does not support
the label used to declare the encoding, or does not use the same
mechanism to detect the encoding of unlabelled content as another
user agent) might end up interpreting technically benign plain text
content as HTML tags and JavaScript. For example, this applies to
encodings in which the bytes corresponding to "<script>" in ASCII can encode a different
string. Authors should not use such encodings, which are known to
include JIS_C6226-1983,
JIS_X0212-1990, HZ-GB-2312, JOHAB (Windows code
page 1361), encodings based on ISO-2022, and encodings based on EBCDIC. Furthermore, authors must not
use the CESU-8, UTF-7, BOCU-1 and SCSU encodings, which also fall
into this category, because these encodings were never intended for
use for Web content.
[RFC1345][RFC1842][RFC1468][RFC2237][RFC1554][RFC1922][RFC1557][CESU8][UTF7][BOCU1][SCSU]

Authors should not use UTF-32, as the encoding detection
algorithms described in this specification intentionally do not
distinguish it from UTF-16. [UNICODE]

Using non-UTF-8 encodings can have unexpected
results on form submission and URL encodings, which use the
document's character encoding by default.

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

In HTML, to declare that the character encoding is UTF-8, the
author could include the following markup near the top of the
document (in the head element):

<meta charset="utf-8">

In XML, the XML declaration would be used instead, at the very
top of the markup:

The type
attribute gives the styling language. If the attribute is present,
its value must be a valid MIME type that designates a
styling language. The charset parameter must
not be specified. The default value for the type attribute, which is used if the
attribute is absent, is "text/css". [RFC2318]

When examining types to determine if they support the language,
user agents must not ignore unknown MIME parameters — types
with unknown parameters must be assumed to be unsupported. The charset parameter must be treated as an unknown
parameter for the purpose of comparing MIME
types here.

The media
attribute says which media the styles apply to. The value must be a
valid media query. The user agent
must apply the styles when the media attribute's value
matches the environment and the other relevant
conditions apply, and must not apply them otherwise.

The styles might be further limited in scope,
e.g. in CSS with the use of @media
blocks. This specification does not override such further
restrictions or requirements.

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

The scoped
attribute is a boolean attribute. If set, it indicates
that the styles are intended just for the subtree rooted at the
style element's parent element, as opposed to the whole
Document.

If the scoped attribute is
present, then the user agent must apply the specified style
information only to the style element's parent element
(if any), and that element's child nodes. Otherwise, the specified
styles must, if applied, be applied to the entire document.

The title attribute on
style elements defines alternative style sheet
sets. If the style element has no title attribute, then it has no
title; the title attribute of
ancestors does not apply to the style element. [CSSOM]

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

The textContent of a style element must
match the style production in the following
ABNF, the character set for which is Unicode. [ABNF]

All descendant elements must be processed, according to their
semantics, before the style element itself is
evaluated. For styling languages that consist of pure text, user
agents must evaluate style elements by passing the
concatenation of the contents of all the text nodes that are direct children of the
style element (not any other nodes such as comments or
elements), in tree order, to the style system. For
XML-based styling languages, user agents must pass all the child
nodes of the style element to the style system.

All URLs found by the styling language's
processor must be resolved,
relative to the element (or as defined by the styling language),
when the processor is invoked.

Once the attempts to obtain the style sheet's critical
subresources, if any, are complete, or, if the style sheet
has no critical subresources, once the style sheet has
been parsed and processed, the user agent must, if the loads were
successful or there were none, queue a task to
fire a simple event named load at the style element,
or, if one of the style sheet's critical subresources
failed to completely load for any reason (e.g. DNS error, HTTP 404
response, a connection being prematurely closed, unsupported
Content-Type), queue a task to fire a simple
event named error at the
style element. Non-network errors in processing the
style sheet or its subresources (e.g. CSS parse errors, PNG decoding
errors) are not failures for the purposes of this paragraph.

The following document has its emphasis styled as bright red
text rather than italics text, while leaving titles of works and
Latin words in their default italics. It shows how using
appropriate elements enables easier restyling of documents.

4.2.7 Styling

The link and style elements can provide
styling information for the user agent to use when rendering the
document. The DOM Styling specification specifies what styling
information is to be used by the user agent and how it is to be
used. [CSSOM]

For style elements, if the user agent does not
support the specified styling language, then the sheet attribute of the element's
LinkStyle interface must return null. Similarly,
link elements that do not represent external resource links that contribute to
the styling processing model (i.e. that do not have a stylesheet keyword in their rel attribute), and link
elements whose specified resource has not yet been fetched, or is
not in a supported styling language, must have their
LinkStyle interface's sheet attribute return null.

Otherwise, the LinkStyle interface's sheet attribute must return a
StyleSheet object with the following properties: [CSSOM]

For link elements, the location must be the
result of resolving the
URL given by the element's href content attribute, relative to
the element, or the empty string if that fails. For
style elements, there is no location.

The style sheet media

The media must be the same as the value of the element's
media content attribute, or the empty string,
if the attribute is omitted.

The style sheet title

The title must be the same as the value of the element's
title content attribute, if the
attribute is present and has a non-empty value. If the attribute is
absent or its value is the empty string, then the style sheet does
not have a title (it is the empty string). The title is used for
defining alternative style sheet sets.

The disabled IDL
attribute on link and style elements must
return false and do nothing on setting, if the sheet attribute of their
LinkStyle interface is null. Otherwise, it must return
the value of the StyleSheet interface's disabled attribute on
getting, and forward the new value to that same attribute on
setting.

The rules for handling alternative
style sheets are defined in the CSS object model specification. [CSSOM]

Style sheets, whether added by a link element, a
style element, an <?xml-stylesheet> PI,
an HTTP Link: header, or some other
mechanism, have a style sheet ready flag, which is
initially unset.

When a style sheet is ready to be applied, its style sheet
ready flag must be set. If the style sheet referenced no
other resources (e.g. it was an internal style sheet given by a
style element with no @import
rules), then the style rules must be synchronously made available to
script; otherwise, the style rules must only be made available to
script once the event loop reaches its "update the
rendering" step.