W3C发布HTML5最终推荐规范（2014年10月28日）

需积分: 10 49 浏览量更新于2024-07-22 收藏 22.13MB PDF 举报

HTML5 最终规范（2014 年 10 月 28 日发布） HTML5 最终规范是 World Wide Web Consortium（W3C）在 2014 年 10 月 28 日发布的最终推荐规范。该规范定义了 HTML5 的所有方面，包括基本语法、文档结构、表单、多媒体、API 等。 HTML5 是一種基于 XML 的标记语言，用於创建结构化的文档和应用程序。它扩展了 HTML4 的功能，添加了许多新的特性和元素，使得开发者可以创建更加丰富和交互的网页应用程序。 HTML5 规范中定义了许多新的元素和属性，例如 `<canvas>`、`<video>`、`<audio>` 等多媒体元素， `<section>`、`<article>`、`<nav>` 等结构元素，`<input>`、`<textarea>` 等表单元素等。这些元素和属性使得开发者可以创建更加丰富和交互的网页应用程序。 HTML5 规范还定义了许多新的 API，例如 Geolocation API、Web Storage API、Web Workers API 等。这些 API 使得开发者可以创建更加强大和功能丰富的网页应用程序。 W3C 是一个非营利的国际组织，旨在推动万维网的发展和标准化。W3C 的成员来自世界各地的组织和个人，包括 Google、Microsoft、Apple 等大型科技公司。 HTML5 规范的发布标志着 HTML5 的成熟和标准化。该规范的发布为开发者提供了一个统一的标准，使得他们可以创建更加丰富和交互的网页应用程序。 HTML5 最终规范是 HTML5 的最终推荐规范，定义了 HTML5 的所有方面，包括基本语法、文档结构、表单、多媒体、API 等。该规范的发布标志着 HTML5 的成熟和标准化，为开发者提供了一个统一的标准，使得他们可以创建更加丰富和交互的网页应用程序。知识点： 1. HTML5 是一種基于 XML 的标记语言，用於创建结构化的文档和应用程序。 2. HTML5 规范定义了许多新的元素和属性，例如 `<canvas>`、`<video>`、`<audio>` 等多媒体元素， `<section>`、`<article>`、`<nav>` 等结构元素，`<input>`、`<textarea>` 等表单元素等。 3. HTML5 规范定义了许多新的 API，例如 Geolocation API、Web Storage API、Web Workers API 等。 4. W3C 是一个非营利的国际组织，旨在推动万维网的发展和标准化。 5. HTML5 最终规范是 HTML5 的最终推荐规范，定义了 HTML5 的所有方面，包括基本语法、文档结构、表单、多媒体、API 等。 6. HTML5 规范的发布标志着 HTML5 的成熟和标准化，为开发者提供了一个统一的标准，使得他们可以创建更加丰富和交互的网页应用程序。

2014年12月3日 HTML5
http://www.w3.org/TR/html5/single-page.html 16/624
predefined set of metadata names.
Authors can use the rel="" mechanism to annotate links with specific meanings by registering extensions to the predefined set of link
types. This is also used by microformats. Additionally, absolute URLs that do not contain any non-ASCII characters, nor characters in
the range U+0041 (LATIN CAPITAL LETTER A) through U+005A (LATIN CAPITAL LETTER Z) (inclusive), may be used as link types.
Authors can embed raw data using the <script type=""> mechanism with a custom type, for further handling by inline or server-side
scripts.
Authors can create plugins and invoke them using the embed element. This is how Flash works.
Authors can extend APIs using the JavaScript prototyping mechanism. This is widely used by script libraries, for instance.
1.6 HTML vs XHTML
This section is non-normative.
This specification defines an abstract language for describing documents and applications, and some APIs for interacting with in-memory
representations of resources that use this language.
The in-memory representation is known as "DOM HTML", or "the DOM" for short.
There are various concrete syntaxes that can be used to transmit resources that use this abstract language, two of which are defined in this
specification.
The first such concrete syntax is the HTML syntax. This is the format suggested for most authors. It is compatible with most legacy Web
browsers. If a document is transmitted with the text/html MIME type, then it will be processed as an HTML document by Web browsers.
This specification defines version 5.0 of the HTML syntax, known as "HTML 5".
The second concrete syntax is the XHTML syntax, which is an application of XML. When a document is transmitted with an XML MIME
type, such as application/xhtml+xml, then it is treated as an XML document by Web browsers, to be parsed by an XML processor. Authors
are reminded that the processing for XML and HTML differs; in particular, even minor syntax errors will prevent a document labeled as XML
from being rendered fully, whereas they would be ignored in the HTML syntax. This specification defines version 5.0 of the XHTML syntax,
known as "XHTML 5".
The DOM, the HTML syntax, and the XHTML syntax cannot all represent the same content. For example, namespaces cannot be
represented using the HTML syntax, but they are supported in the DOM and in the XHTML syntax. Similarly, documents that use the
noscript feature can be represented using the HTML syntax, but cannot be represented with the DOM or in the XHTML syntax. Comments
that contain the string "-->" can only be represented in the DOM, not in the HTML and XHTML syntaxes.
1.7 Structure of this specification
This section is non-normative.
This specification is divided into the following major sections:
Introduction
Non-normative materials providing a context for the HTML standard.
Common infrastructure
The conformance classes, algorithms, definitions, and the common underpinnings of the rest of the specification.
Semantics, structure, and APIs of HTML documents
Documents are built from elements. These elements form a tree using the DOM. This section defines the features of this DOM, as well
as introducing the features common to all elements, and the concepts used in defining elements.
The elements of HTML
Each element has a predefined meaning, which is explained in this section. Rules for authors on how to use the element, along with
user agent requirements for how to handle each element, are also given. This includes large signature features of HTML such as
video playback and subtitles, form controls and form submission, and a 2D graphics API known as the HTML canvas.
Loading Web pages
HTML documents do not exist in a vacuum — this section defines many of the features that affect environments that deal with multiple
pages, such as Web browsers and offline caching of Web applications.
Web application APIs
This section introduces basic features for scripting of applications in HTML.
User interaction
HTML documents can provide a number of mechanisms for users to interact with and modify content, which are described in this
section, such as how focus works.
The HTML syntax
The XHTML syntax
All of these features would be for naught if they couldn't be represented in a serialized form and sent to other people, and so these
sections define the syntaxes of HTML and XHTML, along with rules for how to parse content using those syntaxes.
Rendering
This section defines the default rendering rules for Web browsers.
There are also some appendices, listing obsolete features and IANA considerations, and several indices.
This specification should be read like all other specifications. First, it should be read cover-to-cover, multiple times. Then, it should be read
backwards at least once. Then it should be read by picking random sections from the contents list and following all the cross-references.
As described in the conformance requirements section below, this specification describes conformance criteria for a variety of conformance
classes. In particular, there are conformance requirements that apply to producers, for example authors and the documents they create,
and there are conformance requirements that apply to consumers, for example Web browsers. They can be distinguished by what they are
requiring: a requirement on a producer states what is allowed, while a requirement on a consumer states how software is to act.
1.7.1 How to read this specification

2014年12月3日 HTML5

http://www.w3.org/TR/html5/single-page.html 17/624

Code Example:

For example, "the foo attribute's value must be a valid integer" is a requirement on producers, as it lays out the allowed values; in

contrast, the requirement "the foo attribute's value must be parsed using the rules for parsing integers" is a requirement on consumers,

as it describes how to process the content.

Requirements on producers have no bearing whatsoever on consumers.

Code Example:

Continuing the above example, a requirement stating that a particular attribute's value is constrained to being a valid integer

emphatically does not imply anything about the requirements on consumers. It might be that the consumers are in fact required to treat

the attribute as an opaque string, completely unaffected by whether the value conforms to the requirements or not. It might be (as in

the previous example) that the consumers are required to parse the value using specific rules that define how invalid (non-numeric in

this case) values are to be processed.

This is a definition, requirement, or explanation.

Note: This is a note.

This is an example.

This is an open issue.

Warning! This is a warning.

This definition is non-normative. Implementation requirements are given below this definition.

variable = object . method( [ optionalArgument ] )

This is a note to authors describing the usage of an interface.

/* this is a CSS fragment */

The defining instance of a term is marked up like this. Uses of that term are marked up like this or like this.

The defining instance of an element, attribute, or API is marked up like this. References to that element, attribute, or API are marked up

like this.

Other code fragments are marked up like this.

Variables are marked up like this .

In an algorithm, steps in synchronous sections are marked with .

In some cases, requirements are given in the form of lists with conditions and corresponding requirements. In such cases, the requirements

that apply to a condition are always the first set of requirements that follow the condition, even in the case of there being multiple sets of

conditions for those requirements. Such cases are presented as follows:

↪ This is a condition

↪ This is another condition

This is the requirement that applies to the conditions above.

↪ This is a third condition

This is the requirement that applies to the third condition.

1.8 Privacy concerns

This section is non-normative.

Some features of HTML trade user convenience for a measure of user privacy.

In general, due to the Internet's architecture, a user can be distinguished from another by the user's IP address. IP addresses do not

perfectly match to a user; as a user moves from device to device, or from network to network, their IP address will change; similarly, NAT

routing, proxy servers, and shared computers enable packets that appear to all come from a single IP address to actually map to multiple

users. Technologies such as onion routing can be used to further anonymize requests so that requests from a single user at one node on

the Internet appear to come from many disparate parts of the network.

However, the IP address used for a user's requests is not the only mechanism by which a user's requests could be related to each other.

Cookies, for example, are designed specifically to enable this, and are the basis of most of the Web's session features that enable you to

log into a site with which you have an account.

There are other mechanisms that are more subtle. Certain characteristics of a user's system can be used to distinguish groups of users

interface Example {

// this is an IDL definition

};

IDL

1.7.2 Typographic conventions

2014年12月3日 HTML5
http://www.w3.org/TR/html5/single-page.html 18/624
from each other; by collecting enough such information, an individual user's browser's "digital fingerprint" can be computed, which can be as
good, if not better, as an IP address in ascertaining which requests are from the same user.
Grouping requests in this manner, especially across multiple sites, can be used for both benign (and even arguably positive) purposes, as
well as for malevolent purposes. An example of a reasonably benign purpose would be determining whether a particular person seems to
prefer sites with dog illustrations as opposed to sites with cat illustrations (based on how often they visit the sites in question) and then
automatically using the preferred illustrations on subsequent visits to participating sites. Malevolent purposes, however, could include
governments combining information such as the person's home address (determined from the addresses they use when getting driving
directions on one site) with their apparent political affiliations (determined by examining the forum sites that they participate in) to determine
whether the person should be prevented from voting in an election.
Since the malevolent purposes can be remarkably evil, user agent implementors are encouraged to consider how to provide their users with
tools to minimize leaking information that could be used to fingerprint a user.
Unfortunately, as the first paragraph in this section implies, sometimes there is great benefit to be derived from exposing the very
information that can also be used for fingerprinting purposes, so it's not as easy as simply blocking all possible leaks. For instance, the
ability to log into a site to post under a specific identity requires that the user's requests be identifiable as all being from the same user,
more or less by definition. More subtly, though, information such as how wide text is, which is necessary for many effects that involve
drawing text onto a canvas (e.g. any effect that involves drawing a border around the text) also leaks information that can be used to group
a user's requests. (In this case, by potentially exposing, via a brute force search, which fonts a user has installed, information which can
vary considerably from user to user.)
Features in this specification which can be used to fingerprint the user are marked as this paragraph is. 
Other features in the platform can be used for the same purpose, though, including, though not limited to:
The exact list of which features a user agents supports.
The maximum allowed stack depth for recursion in script.
Features that describe the user's environment, like Media Queries and the Screen object. [MQ] [CSSOMVIEW]
The user's time zone.
1.9 A quick introduction to HTML
This section is non-normative.
A basic HTML document looks like this:
<!DOCTYPE html>
<html>
 <head>
  <title>Sample page</title>
 </head>
 <body>
  <h1>Sample page</h1>
  <p>This is a <a href="demo.html">simple</a> sample.</p>
  <!-- this is a comment -->
 </body>
</html>
HTML documents consist of a tree of elements and text. Each element is denoted in the source by a start tag, such as "<body>", and an end
tag, such as "</body>". (Certain start tags and end tags can in certain cases be omitted and are implied by other tags.)
Tags have to be nested such that elements are all completely within each other, without overlapping:
<p>This is <em>very <strong>wrong</em>!</strong></p>
<p>This <em>is <strong>correct</strong>.</em></p>
This specification defines a set of elements that can be used in HTML, along with rules about the ways in which the elements can be
nested.
Elements can have attributes, which control how the elements work. In the example below, there is a hyperlink, formed using the a element
and its href attribute:
<a href="demo.html">simple</a>
Attributes are placed inside the start tag, and consist of a name and a value, separated by an "=" character. The attribute value can remain
unquoted if it doesn't contain space characters or any of " ' ` = < or >. Otherwise, it has to be quoted using either single or double quotes.
The value, along with the "=" character, can be omitted altogether if the value is the empty string.
<!-- empty attributes -->
<input name=address disabled>
<input name=address disabled="">
<!-- attributes with a value -->
<input name=address maxlength=200>
<input name=address maxlength='200'>
<input name=address maxlength="200">
HTML user agents (e.g. Web browsers) then parse this markup, turning it into a DOM (Document Object Model) tree. A DOM tree is an in-
memory representation of a document.
DOM trees contain several kinds of nodes, in particular a DocumentType node, Element nodes, Text nodes, Comment nodes, and in some
cases ProcessingInstruction nodes.
The markup snippet at the top of this section would be turned into the following DOM tree:
DOCTYPE: html

2014年12月3日 HTML5
http://www.w3.org/TR/html5/single-page.html 19/624
The root element of this tree is the html element, which is the element always found at the root of HTML documents. It contains two
elements, head and body, as well as a Text node between them.
There are many more Text nodes in the DOM tree than one would initially expect, because the source contains a number of spaces
(represented here by "␣") and line breaks ("⏎") that all end up as Text nodes in the DOM. However, for historical reasons not all of the
spaces and line breaks in the original markup appear in the DOM. In particular, all the whitespace before head start tag ends up being
dropped silently, and all the whitespace after the body end tag ends up placed at the end of the body.
The head element contains a title element, which itself contains a Text node with the text "Sample page". Similarly, the body element
contains an h1 element, a p element, and a comment.
This DOM tree can be manipulated from scripts in the page. Scripts (typically in JavaScript) are small programs that can be embedded
using the script element or using event handler content attributes. For example, here is a form with a script that sets the value of the form's
output element to say "Hello World":
<form name="main">
 Result: <output name="result"></output>
 <script>
  document.forms.main.elements.result.value = 'Hello World';
 </script>
</form>
Each element in the DOM tree is represented by an object, and these objects have APIs so that they can be manipulated. For instance, a
link (e.g. the a element in the tree above) can have its "href" attribute changed in several ways:
var a = document.links[0]; // obtain the first link in the document
a.href = 'sample.html'; // change the destination URL of the link
a.protocol = 'https'; // change just the scheme part of the URL
a.setAttribute('href', 'http://example.com/'); // change the content attribute directly
Since DOM trees are used as the way to represent HTML documents when they are processed and presented by implementations
(especially interactive implementations like Web browsers), this specification is mostly phrased in terms of DOM trees, instead of the
markup described above.
HTML documents represent a media-independent description of interactive content. HTML documents might be rendered to a screen, or
through a speech synthesizer, or on a braille display. To influence exactly how such rendering takes place, authors can use a styling
language such as CSS.
In the following example, the page has been made yellow-on-blue using CSS.
<!DOCTYPE html>
<html>
 <head>
  <title>Sample styled page</title>
  <style>
   body { background: navy; color: yellow; }
  </style>
 </head>
 <body>
  <h1>Sample styled page</h1>
  <p>This page is just a demo.</p>
 </body>
</html>
For more details on how to use HTML, authors are encouraged to consult tutorials and guides. Some of the examples included in this
specification might also be of use, but the novice author is cautioned that this specification, by necessity, defines the language with a level
of detail that might be difficult to understand at first.
This section is non-normative.
When HTML is used to create interactive sites, care needs to be taken to avoid introducing vulnerabilities through which attackers can
compromise the integrity of the site itself or of the site's users.
A comprehensive study of this matter is beyond the scope of this document, and authors are strongly encouraged to study the matter in
more detail. However, this section attempts to provide a quick introduction to some common pitfalls in HTML application development.
html
head
#text: ⏎␣␣
title
#text: Sample page
#text: ⏎␣
#text: ⏎␣
body
#text: ⏎␣␣
h1
#text: Sample page
#text: ⏎␣␣
p
#text: This is a
a href="demo.html"
#text: simple
#text: sample.
#text: ⏎␣␣
#comment: this is a comment
#text: ⏎␣⏎
1.9.1 Writing secure applications with HTML

2014年12月3日 HTML5

http://www.w3.org/TR/html5/single-page.html 20/624

The security model of the Web is based on the concept of "origins", and correspondingly many of the potential attacks on the Web involve

cross-origin actions. [ORIGIN]

Not validating user input

Cross-site scripting (XSS)

SQL injection

When accepting untrusted input, e.g. user-generated content such as text comments, values in URL parameters, messages from

third-party sites, etc, it is imperative that the data be validated before use, and properly escaped when displayed. Failing to do this can

allow a hostile user to perform a variety of attacks, ranging from the potentially benign, such as providing bogus user information like a

negative age, to the serious, such as running scripts every time a user looks at a page that includes the information, potentially

propagating the attack in the process, to the catastrophic, such as deleting all data in the server.

When writing filters to validate user input, it is imperative that filters always be whitelist-based, allowing known-safe constructs and

disallowing all other input. Blacklist-based filters that disallow known-bad inputs and allow everything else are not secure, as not

everything that is bad is yet known (for example, because it might be invented in the future).

Code Example:

For example, suppose a page looked at its URL's query string to determine what to display, and the site then redirected the user

to that page to display a message, as in:

<ul>

<li><a href="message.cgi?say=Hello">Say Hello</a>

<li><a href="message.cgi?say=Welcome">Say Welcome</a>

<li><a href="message.cgi?say=Kittens">Say Kittens</a>

</ul>

If the message was just displayed to the user without escaping, a hostile attacker could then craft a URL that contained a script

element:

http://example.com/message.cgi?say=%3Cscript%3Ealert%28%27Oh%20no%21%27%29%3C/script%3E

If the attacker then convinced a victim user to visit this page, a script of the attacker's choosing would run on the page. Such a

script could do any number of hostile actions, limited only by what the site offers: if the site is an e-commerce shop, for instance,

such a script could cause the user to unknowingly make arbitrarily many unwanted purchases.

This is called a cross-site scripting attack.

There are many constructs that can be used to try to trick a site into executing code. Here are some that authors are encouraged to

consider when writing whitelist filters:

When allowing harmless-seeming elements like img, it is important to whitelist any provided attributes as well. If one allowed all

attributes then an attacker could, for instance, use the onload attribute to run arbitrary script.

When allowing URLs to be provided (e.g. for links), the scheme of each URL also needs to be explicitly whitelisted, as there are

many schemes that can be abused. The most prominent example is "javascript:", but user agents can implement (and indeed,

have historically implemented) others.

Allowing a base element to be inserted means any script elements in the page with relative links can be hijacked, and similarly

that any form submissions can get redirected to a hostile site.

Cross-site request forgery (CSRF)

If a site allows a user to make form submissions with user-specific side-effects, for example posting messages on a forum under the

user's name, making purchases, or applying for a passport, it is important to verify that the request was made by the user intentionally,

rather than by another site tricking the user into making the request unknowingly.

This problem exists because HTML forms can be submitted to other origins.

Sites can prevent such attacks by populating forms with user-specific hidden tokens, or by checking Origin headers on all requests.

Clickjacking

A page that provides users with an interface to perform actions that the user might not wish to perform needs to be designed so as to

avoid the possibility that users can be tricked into activating the interface.

One way that a user could be so tricked is if a hostile site places the victim site in a small iframe and then convinces the user to click,

for instance by having the user play a reaction game. Once the user is playing the game, the hostile site can quickly position the

iframe under the mouse cursor just as the user is about to click, thus tricking the user into clicking the victim site's interface.

To avoid this, sites that do not expect to be used in frames are encouraged to only enable their interface if they detect that they are

not in a frame (e.g. by comparing the window object to the value of the top attribute).

This section is non-normative.

Scripts in HTML have "run-to-completion" semantics, meaning that the browser will generally run the script uninterrupted before doing

anything else, such as firing further events or continuing to parse the document.

On the other hand, parsing of HTML files happens asynchronously and incrementally, meaning that the parser can pause at any point to let

scripts run. This is generally a good thing, but it does mean that authors need to be careful to avoid hooking event handlers after the events

could have possibly fired.

There are two techniques for doing this reliably: use event handler content attributes, or create the element and add the event handlers in

the same script. The latter is safe because, as mentioned earlier, scripts are run to completion before further events can fire.

Code Example:

One way this could manifest itself is with img elements and the load event. The event could fire as soon as the element has been

parsed, especially if the image has already been cached (which is common).

1.9.2 Common pitfalls to avoid when using the scripting APIs

剩余623页未读，继续阅读

zxccsd

粉丝: 0
资源: 1

W3C发布HTML5最终推荐规范（2014年10月28日）

2014年Web前端开发资源大全：HTML5、PHP、JavaScript趋势与工具

学生HTML5响应式网站制作与规范实践指南

学生期末网页设计大作业：规范的HTML5响应式网站制作

html5最终版规范pdf版

原创2014年会抽奖程序（JavaScript）

2016年酷炫HTML5动画合集

HTML5设计原理

Html5示例源码

HTML5教程 PDF

HTML5 chm 手册

最新资源