p elementhr elementpre elementblockquote elementol elementul elementmenu elementli elementdl elementdt elementdd elementfigure elementfigcaption elementmain elementdiv elementa elementem elementstrong elementsmall elements elementcite elementq elementdfn elementabbr elementruby elementrt elementrp elementdata elementtime elementcode elementvar elementsamp elementkbd elementsub and sup elementsi elementb elementu elementmark elementbdi elementbdo elementspan elementbr elementwbr elementa and area elementsa and area elementsalternate"author" 链接类型bookmark" 链接类型canonical"dns-prefetch" 链接类型external" 链接类型help" 链接类型icon"license" 链接类型manifest"modulepreload"nofollow" 链接类型noopener"noreferrer"opener"pingback" 链接类型preconnect 链接类型"prefetch" 链接类型preload"prerender" 链接类型search"stylesheet"tag" 链接类型picture elementsource elementimg elementsource,
img, and link elementsiframe elementembed elementobject elementparam elementvideo 元素audio elementtrack elementTrackEvent interfacemap elementarea elementtable elementcaption elementcolgroup elementcol elementtbody elementthead elementtfoot elementtr elementtd elementth elementtd and th elementsform elementlabel elementinput elementtype 属性的状态type=hidden)type=text) state and Search state (type=search)type=tel)type=url)type=email)type=password)type=date)type=month)type=week)type=time)type=datetime-local)type=number)type=range)type=color)type=checkbox)type=radio)type=file)type=submit)type=image)type=reset)type=button)input 元素属性input element APIsbutton elementselect elementdatalist elementoptgroup elementoption elementtextarea elementoutput elementprogress elementmeter elementfieldset elementlegend elementname attributedirname attributemaxlength attributeminlength attributedisabled attributescript elementnoscript elementtemplate elementslot elementcanvas elementPath2D objectsImageBitmap 渲染上下文OffscreenCanvas interfacecanvas 元素的安全问题hidden 属性contenteditable content attributedesignMode getter and setterinputmode attributeenterkeyhint
attributeWindow,
WindowProxy, 和 Location 对象的安全基础设施 Window objectWindowProxy exotic objectHistory interfaceLocation interfacemultipart/x-mixed-replace 资源的媒体的页面加载处理模型X-Frame-Options` headerWindowOrWorkerGlobalScope mixinbutton 元素details 和 summary 元素input 元素作为文本输入微件input element as domain-specific widgetsinput element as a range controlinput element as a color
wellinput element as a checkbox and radio button widgetsinput element as a file upload controlinput element as a buttonmarquee elementmeter elementprogress elementselect elementtextarea elementtext/htmlmultipart/x-mixed-replaceapplication/xhtml+xmltext/cache-manifesttext/pingapplication/microdata+jsontext/event-streamCross-Origin-Embedder-Policy`Cross-Origin-Embedder-Policy-Report-Only`Cross-Origin-Opener-Policy`Origin-Isolation`Ping-From`Ping-To`Refresh`Last-Event-ID`X-Frame-Options`web+ scheme prefix本标准详细地定义了 Web 平台的很大一部分内容。Web 平台的标准栈中，它相对于其他标准的定位可以总结为：
This section is non-normative.
简单地说：是的。
详细地说，广义的 "HTML5" 是指一系列的现代 Web 技术。 这些技术中很多都由 WHATWG 开发，本文档就是其中之一。 其他的可以在这里访问： the WHATWG Standards overview。
This section is non-normative.
HTML 是万维网的核心标记语言。最初 HTML 主要设计为在语义级别描述科学文档的语言。 然而它的总体设计使它在接下来的几年中能够适配一些其他类型的文档，甚至包括应用程序。
This section is non-normative.
本标准是为以下读者提供的：使用了本标准定义的特性的文档和脚本的作者， 用于操作那些使用了本标准定义的特性的页面的工具的实现者， 希望根据本标准的要求确认文档或实现的正确性的个人。
本文档对还没有整体熟悉 Web 技术的读者可能不合适, 因为在有些地方为精确性而省略了具体阐述，为完整性而较为简洁概括。 易懂的教程和编写指南可以为这个话题提供更加温和的介绍。
具体地，为了完整地理解本标准中那些更加技术的部分，对 DOM 基础的熟悉是必要的。 对 Web IDL，HTTP，XML，Unicode，字符编码，JavaScript 和 CSS 的理解在有些地方也有帮助，但并非完全必要。
This section is non-normative.
本标准只限于为编写可访问的 Web 页面（从静态文档到动态应用） 提供语义级别的标记语言，以及相应的语义级别的脚本 API。
本标准的范围不包括提供具体媒体的自定义呈现机制（尽管 Web 浏览器的默认渲染规则在本标准末尾有所涵盖， 一些挂钩到 CSS 的机制也作为语言的一部分加以提供）。
本标准的范围并非要描述整个操作系统。具体地，硬件配置软件、图像操作工具、 以及用户在高端工作站日常使用的应用程序都在范围之外。 对于应用软件，本标准只针对用户偶尔使用的，或定期使用但在不同地点的， 且 CPU 要求较低的特定应用。这样的应用例如在线购物系统、搜索系统、游戏（尤其是多人在线游戏）、 公开电话簿或地址簿、通信软件（邮件客户端、即时通信客户端、讨论软件）， 文档编辑软件等。
This section is non-normative.
在最初的5年中（1990-1995），HTML经历了若干次修订和扩展。最初由 CERN 主要托管，随后是 IETF。
随着 W3C 的诞生，HTML 的开发再次易主。1995 年第一次扩展 HTML 的尝试（HTML 3.0）以失败告终，随后转变为更加务实的 HTML 3.2，在 1997 年完成。 就在同年很快开始了 HTML4 的开发。
随后一年 W3C 成员决定停止 HTML 的演变，并开始开发基于 XML 的替代品 XHTML。 该 工作首先将 HTML4 重新规划为 XML，也就是著名的 XHTML 1.0。 唯一增加的特性就是新的序列化，该工作在 2000 年完成。 XHTML 1.0 之后，在 XHTML 模块化的口号下 W3C 的主要精力转向让其他工作组更容易地扩展 XHTML。 与此同时，W3C 致力于一门新的、与此前的 HTML 和 XHTML 都不兼容的语言：XHTML2。
大概在 1998 年 HTML 停止演化的时候，浏览器厂商开发的部分 HTML API 被标准化和发布在 DOM Level 1（1998） 和 DOM Level 2 Core，以及 DOM Level 2 HTML（2000年开始2003年完成）中。 在 2004 年发布了一些 DOM Level 3 标准，但是 Level 3 草案尚未全部完成工作组就关闭了。 这些工作也最终不了了之。
2003 年 XForms （一项定位于下一代 Web 表单的技术）的发布 重新激起了对 HTML 演化的兴趣，而不是像从前那样寻求新的替代品。 这时人们发现 XML 作为 Web 技术的部署只局限于全新的技术（比如 RSS 和后来的 Atom）， 而不是取代已经部署的技术（比如 HTML）。
概念验证显示，在不要求浏览器实现与现存 HTML Web 页面不兼容的渲染引擎的情况下， 也可能扩展 HTML4 的表单来提供 XForms 1.0 引入的很多特性。 这一概念验证是对 HTML 重新燃起的兴趣产生的第一项成果。 在这早期阶段，虽然本草案已经公开可用且已广泛征求建议，该标准只在 Opera Software 版权下发布。
应该重新开启 HTML 演化的想法在 W3C 工作组得到了测试。 Mozilla 和 Opera 共同向 W3C 工作组提交了提议，包括 HTML5 工作背后的一些原则（见下文），以及前述的只涉及表单特性的早期草案。 该提议因为与此前选择的 Web 演化方向冲突而被拒绝， W3C 职员和会员投票支持继续开发基于 XML 的替代品。
此后 Apple，Mozilla 和 Opera 共同声明他们将继续在 WHATWG（一个新的组织）团体下投入工作。 他们为此创建了一个公开的邮件列表，草案也移交到了 WHATWG 网站。随后版权也修改为这三家共同拥有， 同时允许该标准的重用。
WHATWG 基于若干核心原则，具体地：技术需要向后兼容，标准和实现需要相符（即使这意味着更改标准而不是实现）， 标准需要足够详细来使得一个实现在不需对其他实现进行逆向工程的情况下，就能可达到完全的互操作性。
其中后一个原则，要求 HTML5 标准的范围应包括先前在 HTML4，XHTML1，和 DOM2 HTML 这三篇独立的文档中标准化的内容。 同时意味着相比于此前的考虑，需要显著地引入更多的细节。
2006 年，W3C 暗示了参与 HTML5 开发的兴趣，并于 2007 年组建了工作组来与 WHATWG 共同开发 HTML5 标准。 Apple，Mozilla，和 Opera 允许 W3C 在 W3C 版权下发布该标准， 只要保留一版 WHATWG 网站的那份较少限制的许可协议。
数年中各方一同工作，然而在 2011 年，这些工作组最终发现他们有着不同的目标： W3C 希望发布一个"完成的" HTML5 版本，而 WHATWG 希望持续地维护一个 HTML Living Standard， 持续地维护该标准而不是锁定在一个带着已知问题的状态， 同时按照需求增加新的特性来发展整个平台。
从此 WHATWG 一直在（与其他组织一同）开发该标准， W3C 则复制 WHATWG 的修复工作到他们所在的文档分支（也有其他的一些改动）。
This section is non-normative.
必须承认 HTML 的很多方面乍一看毫无意义或者不太一致。
HTML，它的 DOM API，以及很多其他的支持技术是由互不相识的有着不同目的的人，经数十年开发完成。
因此特性的出现有着不同的来源，也未经专门的一致的方式设计。 而且由于 Web 独有的特点，实现的 Bug 常常会变成事实上的惯例，以及现在合法的、标准的行为。 因为编写的内容常常会无意地依赖于这些未能及时修复的实现。
尽管这样，人们还是为坚持某些设计目标而付出努力。在接下来的几个小节中描述了这些努力。
This section is non-normative.
为了避免让 Web 作者处理多线程的复杂性，HTML 和 DOM API 的设计使得脚本无法检测同时运行的其他脚本。 甚至在使用 workers 时，设计意图中实现的行为可以被认为是 在所有 浏览环境 中串行地执行所有脚本。
This section is non-normative.
本标准和多种多样的其他有相互影响和依赖。很不幸在某些情况下，相互冲突的需求使得本标准违反了其他标准的要求。 当这种情况发生时，每一项冲突都会标记为 "willful violation"，而且会说明该冲突的原因。
This section is non-normative.
HTML 有广泛的可扩展性机制，可用来安全地添加语义：
作者可以使用 class 属性来扩展元素，
在使用最接近的 "真实" HTML 元素的同时，也等效于创建了他们自己的元素，
因此不知道该扩展的浏览器和其他工具仍然可以在某种程度上很好地支持。
比如微格式就是使用的这种策略。
作者可以使用data-*=""属性来包含数据，
在客户端脚本或服务器端的站点脚本中加以处理。可以保证浏览器永远不会碰这些数据，
使得脚本可以在 HTML 元素中引入数据，并在后续脚本中寻找或者处理。
通过<meta name="" content=""> 机制，
作者可以为预定义的元数据名称的集合注册扩展
来引入页面级别的元数据。
通过rel="" 机制，
作者可以通过为预定义的链接类型注册扩展，
来给链接标注特定的含义。微格式也使用了这种机制。
作者可以使用 <script type=""> 来内嵌自定义类型的原始数据，
用于在内联脚本或服务器端脚本中做进一步处理。
作者可以使用 JavaScript 原型机制来扩展 API。这在脚本库中有广泛的使用。
作者可以使用微数据特性（itemscope="" 和 itemprop=""属性）
来嵌入嵌套的键值对数据，以供其他应用和站点共享。
This section is non-normative.
本标准定义了一个描述文档和应用的抽象语言，以及一些 API 来与使用该语言的资源的内存表示进行交互。
这一内存表示又称为 "DOM HTML"，或简称为 "DOM"。
对于传输使用了该抽象语言的资源，有很多不同的具体语法。本标准中定义了其中两种。
第一个这样的具体语法是 HTML 语法。这是对多数作者推荐的格式，它与多数遗留的 Web 浏览器相兼容。
如果一个文档以text/html MIME type进行传输，
然后它将会被 Web 浏览器作为 HTML 文档处理。
本标准定义了最新的 HTML 语法，简单地称为 "HTML"。
第二个具体的语法是 XML。当一篇文档以XML MIME type（比如application/xhtml+xml）
传输时，它将会被 Web 浏览器当做 XML 文档处理，被 XML 处理器解析。
作者需要注意 XML 和 HTML 的处理存在差别；具体地，即使很小的语法错误都将阻止 XML 文档的完整渲染，
然而它们在 HTML 语法中将会被忽略。
给 HTML 用的 XML 语法此前被称为 "XHTML"，但本标准不适用该术语 （原因之一是 MathML 和 SVG 的 HTML 语法中未使用该术语）。
DOM，HTML 语法，XML 语法不能用来表示同样的内容。
例如 HTML 语法不能表示命名空间，但 DOM 和 XML 语法却支持。
类似地，HTML 语法可以表示使用 noscript 特性的文档，
但 DOM 和 XML 语法却不能。
包含 "-->" 的注释只能在 DOM 中表示，HTML 和 XML 语法却不行。
This section is non-normative.
本标准分为以下主要的部分：
EventSource，
以及一个为脚本提供的双向全双工套接字协议，称为 Web Sockets。
还有一些附录，列出了 废弃的特性 和 IANA 考虑，以及一些索引。
阅读本标准的方式与其他标准类似。首先应该完整地阅读多次，然后至少倒着读一次， 然后应该从目录中随机选入章节并跟着所有交叉引用读一次。
如下面一致性要求部分所述，本标准描述了各一致性等级的一致性标准。 特别地，有些一致性要求适用于生产者（例如作者和他们创建的文档）， 也有一些适用于消费者（例如 Web 浏览器）。 他们的要求是不同的：对生产者的要求声明了什么是允许的，而对消费者的要求声明了软件的行为。
对生产者的要求不会对消费者产生任何影响。
继续上述例子，“属性值必须是合法的整数”刻意地没有暗示对消费者的要求。 事实上消费者可能被要求把该属性当做透明的字符串，完全不关心它的值是否满足要求。 也可能被要求以指定的规则来解析它的值（就像上述例子中那样），这些规则就定义了如何处理不合法的值（在本例子中就是非数字的值）。
这是定义、要求，或者解释。
这是注意事项。
这是翻译者的注释。
这是例子。
这是未解决的问题。
这是警告
[Exposed=Window]
interface Example {
// 这是一个 IDL 定义（接口描述语言）
};method( [ optionalArgument ] )这是给作者看的，描述了接口的使用。
/* 这是一个 CSS 片段 */术语的定义标记为 这样。 该术语的使用标记为 这样 或 这样。
元素、属性或 API 的定义标记为这样。
该元素、属性或 API 的引用标记为 这样。
其他代码片段标记为这样。
变量标记为这样。
在算法中，同步部分的步骤标记为 ⌛。
有些情况下，要求以列表的形式给出，列表项包括条件和对应的要求。 在该情况下，适用于某项条件的要求紧跟着条件出现，这些要求的条件可能有很多个。例如：
This section is non-normative.
一个基本的 HTML 文档看起来像这样：
<!DOCTYPE html> <html lang="en"> <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 文档由树状的元素和文本组成。源码中每个元素由
一个 开始标签（例如 "<body>"）
和一个 结束标签（例如 "</body>"）表示。
（某些开始标签和结束标签在某些情况下可以 省略。）
标签的嵌套必须使所有标签都完全在其他标签内部，不应出现重叠：
<p>This is <em>very <strong>wrong</em>!</strong></p>
<p>This <em>is <strong>correct</strong>.</em></p>
本标准定义了 HTML 中使用的一些元素，以及它们的嵌套规则。
元素可以有属性来控制元素的行为。在下面的例子中是一个 超链接，
由一个a元素和它的 href 属性组成：
<a href="demo.html">simple</a>
属性 应放置在开始标签中，由
属性名 和 属性值构成，
以 "=" 分隔。
如果不包含空格" ' ` = < 或
>， 属性值可以保持 没有引号 ；
否则必须使用单引号或双引号。
如果属性值是空字符串，属性值以及 "=" 可以一起省略。
<!-- 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 用户代理（比如 Web 浏览器）解析这些标记，把它转化为 DOM（Document Object Model）树。 DOM 树是文档在内存中的表示。
DOM 数包含若干种节点，具体地：DocumentType 节点、
Element节点、Text 节点、Comment 节点，
以及有时会出现的 ProcessingInstruction 节点。
本章顶部的代码片段将会转化为下列 DOM 树：
树中的document 元素 是 html 元素，
在 HTML 文档的这一位置总是应该有这样一个元素。它包含两个元素，
head 和 body，以及它们之间的一个 Text 节点。
DOM 树中的 Text 节点比你预想的要多，因为源码包含一些空格（表示为"␣"）和换行（"⏎"），
这些都会变成 DOM 中的 Text 节点。然而因为历史原因，并非所有这些源码中的空格和换行都出现在 DOM 中。
具体地，所有head开始标签前的空白都会被悄悄地丢掉，所有body结束标签后的空白都会出现在body的尾部。
head 元素包含一个 title 元素，其中包含一个
内容为 "Sample page" 的 Text 节点。类似地，body 元素包含一个
h1 元素，一个p 元素，和一个注释。
页面中的脚本可以操作该 DOM 树。脚本（比如 JavaScript）是可以使用
script标签或 事件处理内容属性内嵌的小程序。
比如下面是一个表单，其中的脚本设置了表单中output元素的内容并输出 "Hello World"：
<form name="main"> Result: <output name="result"></output> <script> document.forms.main.elements.result.value = 'Hello World'; </script> </form>
DOM 树中的每个元素表示为一个对象，这些对象提供 API 以供操作。
例如，一个链接（比如上述树中的a元素）的
"href"属性可以通过多种方式改变：
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', 'https://example.com/'); // change the content attribute directly
由于 DOM 树是实现者（尤其是像 Web 浏览器这样的交互式实现）用来处理和显示 HTML 文档的， 本标准更多地是按照 DOM 树来介绍的，而不是按照上面描述的标记代码。
HTML 文档表示了交互式内容的一种媒体无关的描述。HTML 文档可能会渲染在屏幕、语音合成器、或者盲文点触设备。 为了精确地控制渲染行为，作者可以使用一个像 CSS 这样的样式语言。
在下列例子中，使用 CSS 将页面设置为蓝底白字。
<!DOCTYPE html>
<html lang="en">
<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>
关于更多 HTML 的使用细节，鼓励作者参考教程和指南。 本标准中的一些示例可能也有用，但新手作者需要注意本标准必须非常详细地定义该语言， 以至于一开始可能很难理解。
This section is non-normative.
当使用 HTML 创建交互式网站时，需要注意避免引入漏洞，使得攻击者通过这些漏洞危害网站本身或网站用户信息的完整性。
对这一问题的全面研究超出了本文档的范围，我们强烈建议网站作者去更详细地研究这一问题。 即便如此，本节尝试对 HTML 应用程序开发中的一些常见陷阱作简单介绍。
Web 的安全模型基于“域”的概念，因此 Web 上许多潜在的攻击涉及跨域操作。[ORIGIN]
当接受不可信输入时（例如文本评论这样的用户生成内容，URL 参数中的值，来自第三方网站的消息等）， 必须在使用前验证数据，并在显示时正确转义。 否则就会允许恶意的用户执行各种攻击， 这些攻击可能是轻微的，例如提供诸如负的年龄这样的假的用户信息； 也可能是严重的，例如在每次用户查看包含该信息的页面时执行脚本； 也可能是传播性的攻击导致灾难性后果，比如删除服务器中的所有数据。
当编写过滤器验证用户输入时，过滤器应当是基于白名单的，允许已知的安全构造并禁止所有其他输入。 基于黑名单的过滤器（禁止已知的错误输入并允许其他所有输入）是不安全的， 因为并不是所有错误输入都是已知的（因为它可能会在未来发明）。
例如，一个页面查看它的 URL 查询字符串来决定显示的内容， 然后网站将用户重定向到显示该消息的页面。比如：
<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>
如果这一消息没有转义就显示给用户，恶意的攻击者可能会构造一个包含脚本元素的 URL：
https://example.com/message.cgi?say=%3Cscript%3Ealert%28%27Oh%20no%21%27%29%3C/script%3E
如果攻击者随后说服受害者访问此页面，攻击者选择的脚本将在页面上运行。 这样的脚本可以执行任意的恶意操作，只要是站点提供的。 例如站点是电子商务商店，这样的脚本可以导致在用户不知情的情况下进行任意的购买。
这称为跨站脚本攻击。
有很多构造可以欺骗网站执行代码。以下是网站作者在编写白名单过滤器时应考虑的事项：
img这样看起来无害的元素时，重要的是同时为所有提供的属性给出白名单。
比如，如果一个元素允许所有属性，攻击者可能会使用onload属性来运行任意脚本。javascript:”，
用户代理也可能会实现其他的一些scheme，由于历史原因确实已经实现了不少。base 元素意味着页面中的任何相对链接的 script 元素都可能被劫持，
类似地任何表单提交也可能重定向到恶意站点。如果网站允许用户提交的表单产生用户相关的影响，例如使用名字在论坛上发布消息， 进行购买或申请护照，那么很有必要核实该请求确实是用户有意发起的， 而不是由另一个站点欺骗用户不知情地发起请求。
该问题的存在是因为 HTML 表单可能被提交到其他域名。
站点可以通过为表单填充用户相关的隐藏标记或检查所有请求的`Origin`头字段，
来防止这样的攻击。
如果页面为用户提供的界面中包含用户可能不希望执行的操作时， 该页面应当经过特殊设计来避免用户被欺骗以激活该界面的可能性。
一种用户被欺骗的可能是，如果恶意站点将受害站点放在一个小的 iframe 中然后让用户去点击，
例如让用户玩一个反应类游戏。一旦用户开始玩这个游戏，恶意站点可以在用户正要点击时快速地将这个 iframe 放到鼠标光标下。
以此来欺骗用户点击受害站点的界面。
为了避免这种情况，鼓励不期望在 iframe 下使用的站点只有检测（例如通过比较window对象和top属性的值）
到它们不在 iframe 下时才激活它们的界面。
This section is non-normative.
HTML 中的脚本有着"运行到完成"的语义，这意味着浏览器通常在执行任何其他操作 （诸如触发进一步的事件或继续解析文档）之前会不中断地执行脚本。
另一方面，HTML 文件的解析是逐步发生的，这意味着解析器可以在任何地方暂停来让脚本运行。 这通常是一件好事，但确实意味着作者需要小心地避免在事件可能已经触发之后才绑定事件处理程序。
有两项技术能够可靠地完成这件事情：使用 事件处理程序内容属性， 或者在同一脚本中创建元素和添加事件处理程序。后一种更为安全，因为如前所述， 脚本会在进一步的事件发生前一直运行到完成。
一个可以表示此种情形的例子是img元素和load事件。
该事件在元素解析完成时就会触发，特别是当图片已经被缓存之后（这很常见）。
这里，作者在img标签上使用 onload 事件处理程序
来捕捉 load 事件：
<img src="games.png" alt="Games" onload="gamesLogoHasLoaded(event)">
如果使用脚本添加元素，那么只要在同一脚本中添加事件处理函数，该事件就不会被错过：
<script>
var img = new Image();
img.src = 'games.png';
img.alt = 'Games';
img.onload = gamesLogoHasLoaded;
// img.addEventListener('load', gamesLogoHasLoaded, false); // would work also
</script>
然而如果作者首先创建了img元素，然后在另一个单独的脚本中添加了事件监听器，
那么有可能load事件会在两者之间触发，导致它被错过：
<!-- Do not use this style, it has a race condition! -->
<img id="games" src="games.png" alt="Games">
<!-- the 'load' event might fire here while the parser is taking a
break, in which case you will not see it! -->
<script>
var img = document.getElementById('games');
img.onload = gamesLogoHasLoaded; // might never fire!
</script>
This section is non-normative.
鼓励作者使用一致性检查器（又称验证器）来发现常见的错误。 WHATWG 维护着这种工具的一个列表：https://validator.whatwg.org/
This section is non-normative.
与以前版本的 HTML 规范不同，此规范不仅定义了对有效文档的处理， 也详细定义了对无效文档的处理过程。
然而，即使无效内容的处理在大多数情况下是良好定义的，文档的一致性仍然很重要： 在实践中，互操作性（所有实现以可靠和相同或等同的方式处理特定内容的情况）并不是文档一致性要求的唯一目标。 本节详细地介绍了合法文档和错误文档仍然有所区别的一些常见原因。
This section is non-normative.
先前 HTML 版本的大多数表示性特性不再被允许。一般来说，表示性的标记有这样一些问题：
尽管使用显示性的标记也可以为使用辅助技术（Assistive Technologies，AT）的用户 提供可接受的体验（比如使用 ARIA），但这样做显然比使用适当的语义标记更加困难。 此外，即使使用这样的技术也不能帮助那些既没有 AT 又没有图形的用户（比如使用文本模式浏览器的用户）访问页面。
另一方面，使用媒体无关的标记为编写更多用户（比如文本浏览器的用户）可用的文档提供了简单的方式。
使用样式无关的标记编写的站点，显然更容易维护。比如，对于到处都在使用 <font color=""> 的站点，更改颜色需要更改整个站点，
然而对基于 CSS 的站点做类似的改动，只需更改一个文件。
表示性标记往往会增加冗余，因此导致更大的文档大小。
出于这些原因，在本版本的 HTML 中移除了表示性的标记。 这一改动并不突然，HTML4 在很多年前就已经不推荐使用表示性标记， 并提供了一种模式（HTML4 Transitional） 来帮助作者从表示性标记进行迁移； 后来 XHTML 1.1 更进一步地一起废弃了那些特性。
HTML 中唯一保留下来的表示性标记特性是 style 属性和 style 元素。
生产环境中使用 style 属性也在某种程度上不再推荐，
但在创建原型（这些规则之后可以直接移动到单独的样式表中）
以及在特殊情况下（当单独的样式表不方便时）提供特定样式很有用。
类似地，style 元素在引入外部样式内容或者提供页面特定样式时很有用。
但一般来说，当样式适用于多个页面时，外部样式表可能更加方便。
值得注意的是有些先前的表示性元素在本标准中已经被重新定义为媒体无关的：
b, i,
hr, s, small, and u.
This section is non-normative.
限制 HTML 的语法是为了避免各种各样的问题。
某些不合法的语法构造在解析后会导致很不直观的 DOM 树。
为了允许在受控环境中使用的用户代理不必实现更奇怪和复杂的错误处理规则， 允许用户代理在遇到解析错误时失败。
一些错误处理行为（比如上面提到的<table><hr>...）
与流式用户代理（不存储状态且通过一次遍历来处理 HTML 文件的用户代理）不兼容。
为了避免与这样的用户代理的互操作性问题，任何导致该行为的语法都是无效的。
当一个基于 XML 的用户代理连接到一个 HTML 解析器时， 某些 XML 强制的不变式（比如元素或属性名不可包含多个冒号）可能被 HTML 文件违反。 处理这种情况可能要求解析器将 HTML DOM 信息强加给 XML 兼容的信息集。 要求这一处理的多数语法构造都是不合法的。 （包含两个连续的间隔符的注释，或以一个间隔符结尾的注释是特例，这在 HTML 语法中是允许的）。
这一规则意味着基于 XML 的用户代理只需连接一个 HTML 解析器（Parser）即可拥有理解 HTML 的能力。所以 HTML 与 XML 只是语法有所不同， 表达语义的能力应当是等价的。
某些语法构造可能导致很差的性能。为了阻止这些构造的使用，通常把它们归为不合规范的。
由于历史原因有一些语法构造相对脆弱。为了避免用户意外地掉到坑里，它们也被归为不合规范的。
例如，即使省略了关闭分号，对属性中命名的字符引用的解析也会发生。
可以安全地引入一个&以及紧随其后的不构成特殊命名的字符引用，
但如果这些字母改成构成命名的字符引用，它们将会被解释为那个特殊字符。
在这个代码片段中，属性值是“?bill&ted”：
<a href="?bill&ted">Bill and Ted</a>
在下面的代码片段中，属性值实际上会变成“?art©”，
而不是 期望的 “?art©”，
因为即使没有最后的分号“©”也会一样地被处理为
“©”最终被解释为“©”：
<a href="?art©">Art and Copy</a>
为了避免这一问题，要求所有命名的字符引用以分号结束， 所有使用命名字符引用但未添加分号的都被标记为错误。
因此正确地表达上述情况的方式如下：
<a href="?bill&ted">Bill and Ted</a> <!-- &ted is ok, since it's not a named character reference -->
<a href="?art&copy">Art and Copy</a> <!-- the & has to be escaped, since © is a named character reference -->
某些语法构造在旧的用户代理中会造成一些已知的细微或严重的问题。 因此他们被标记为不合规范的来帮助作者避免这些问题。
例如 U+0060 重音符（`）不允许出现在没有引号的属性中。 因为在某些旧用户代理中，它有时会被当做一个引号。
某些限制纯粹是为了避免已知的安全问题。
例如，对使用 UTF-7 的限制纯粹是为了避免作者成为使用 UTF-7 的已知跨站脚本攻击的的目标。[UTF7]
作者意图不清楚的标记通常被划为不规范的。 尽早修复这些错误会使得后续维护更为容易。
当用户发生了拼写错误，提早捕获该错误是有帮助的，因为这可以节省作者很多调试时间。 因此本标准通常认为使用与本标准中定义的名字不匹配的元素名、属性名等是错误的。
例如，如果作者键入<capton> 而不是 <caption>，这将被标记为错误，作者可以立即更正错字。
为了允许将来扩展语言语法，某些本来无害的特性也是不允许的。
例如，在结束标签中的“属性”目前被忽略，但它们是非法的。 以防未来使用该语法特性的语言变更与已部署（但是合法的！）内容产生冲突。
一些作者发现，在实践中总是用引号包含所有的属性并且总是包含所有的可选标签很有帮助， 相比于利用 HTML 语法的灵活性而带来的一点简洁，更偏好这一做法带来的一致性。 为了协助这样的作者，一致性检查器可以提供执行这一惯例的运行模式。
This section is non-normative.
除了语言的语法，本标准还对如何指定元素和属性做出了限制。 这些限制是出于类似的原因：
为了避免误用定义了含义的元素， 定义内容模型时，限制了可疑的元素嵌套方式。
类似地，为了让作者对元素使用中的错误引起注意， 表达出的语义存在明显的矛盾也被认为是一致性错误。
例如下面的片段中的语义是毫无意义的： 分隔符不能同时是单元格，单选按钮也不能是进度条。
<hr role="cell">
<input type=radio role=progressbar>
另一个例子是对ul元素的内容模型的限制，
该限制只允许 li 子元素。根据定义列表只可包含一些列表项。
所以如果 ul 元素包含一些除了 li 之外的元素，
它的含义就不清楚了。
某些元素有一些默认样式和行为，它们的某些组合可能会令人困惑。 如果存在没有这一问题的等效替代，就不允许这样令人困惑的组合。
例如，div 元素会被渲染为 block boxes，span 元素则为 inline boxes。将 block box 放到
inline box 中就会导致不必要的困惑；因为只嵌套 div
元素，或只嵌套 span 元素，或在div元素中嵌套
span 元素都可以与在span元素中嵌套div元素
达到同样的目的。但只有后者涉及到在 inline box 中嵌套 block box，
所以后者的组合方式是不允许的。
另一个可能的例子是 交互内容
不可嵌套。例如： button 元素不可包含 textarea 元素。
这是因为这样嵌套交互元素可能对用户造成困惑。可以并排放置这些元素。
有时，某些禁止是因为允许它将可能会让作者困惑。
例如，设置 disabled
属性为 "false" 是不允许的，因为表面上看起来它的含义是元素可用，
但实际上含义是元素被 禁用
（实现中起作用的是该属性是否存在，而非它的值）。
一些一致性错误简化了作者需要学习的语言。
例如，area 元素的 shape 属性，在实践中虽然同时接受 circ 和 circle
取值并作为同义词，但禁止
circ 值的使用，
以此来简化教程和其他学习材料。同时允许它们并没有好处，
但它们可能在学习语言时造成额外的困惑。
某些元素的解析有点奇怪（通常是由于历史原因）， 它们的内容模型限制旨在避免作者碰到这些问题。
例如，phrasing content 中不允许
form 元素，因为当解析 HTML 时，
form 元素的开始标签将会产生一个
p 元素的关闭标签。因此下面的标记会产生两个
段落（而不是一个）：
<p>Welcome. <form><label>Name:</label> <input></form>
与下面代码的解析结果完全一样：
<p>Welcome. </p><form><label>Name:</label> <input></form>
有些错误旨在避免难以调试的脚本问题。
比如，这就是为什么有两个等值的 id 属性是不合法的。
重复的 ID 导致选择到错误的元素，有时会产生难以确定原因的灾难性后果。
某些构造被禁止是因为历史上它们曾浪费大量的编写时间。 鼓励作者避免使用这些构造，将来可以节省很多时间。
例如，script 元素的 src 属性会导致元素的内容被忽略。
然而这并不明显（尤其是元素内容是可执行脚本时）—
这会导致作者花费大量时间尝试调试内联脚本，却没意识到它并未执行。
为了减少这一问题，在本标准中src
属性出现时，script元素中不允许存在可执行脚本。
这意味着作者在验证他们的文档时，不太可能在这样的错误上浪费时间。
有些作者喜欢编写用 XML 和 HTML 解释可以得到类似结果的文件。 由于种种微妙的复杂性（尤其是涉及脚本、样式、或其他任何自动的序列化）， 一般并不鼓励这一做法，尽管如此，本标准也有一些限制意在在某种程度上减轻困难。 这让作者在 HTML 和 XML 语法之间迁移时，可以更容易地将其用于过渡步骤。
例如，围绕 lang 和
xml:lang 属性有一些复杂的规则，
就是为了让 HTML 和 XML 同步。
另一个例子可能是在 HTML 序列化中对 xmlns 属性值的限制，意在确保不管是 HTML 还是 XML 解析，
合法的文档中元素总在同一命名空间。
对语法的某些限制是为了允许语言的未来版本中添加新的语法， 类似地，对元素和属性取值的内容模型的一些限制是为了允许将来对 HTML 词库进行扩充。
例如，限制 target 属性的值，
以 U+005F 下划线（_）起始的只能是特定的预定义值。这允许了在将来引入新的预定义值，
同时不会与作者定义的值产生冲突。
某些限制意在支持其他标准作出的限制。
例如，使用媒体查询列表的属性只能使用 合法的 媒体查询列表，强调了遵循那一标准的一致性规则的重要性。
This section is non-normative.
本标准的读者可能对以下文档感兴趣。
这个架构风格标准定义了 World Wide Web 中可互操作的文本操作。为其他标准的作者、软件开发者，以及内容开发者提供了通用的参考。 该标准构建在 Universal Character Set 之上，同时定义在 Unicode Standard 和 ISO/IEC 10646。 涉及的话题包括：字符、编码、字符串、引用处理模型、字符编码的选择和识别、字符转义，以及字符串索引。
由于 Unicode 包含大量的字符，引入了世界上不同的书写系统， 错误的使用会将程序和系统暴露在可能的安全攻击之下。随着越来越多的产品被国际化该问题尤为重要。 该标准描述了程序员、系统分析师、标准开发者，以及用户应当考虑的安全事项，为减少风险提供了明确的建议。
Web Content Accessibility Guidelines (WCAG) 2.0 对于提高 Web 内容的可访问性给出了广泛的建议。 遵循这些指导可以使更多的残障人士（包括失明和弱视、失聪和听觉损耗、学习和认知障碍、行动不便、语言障碍、光过敏等）可访问您的内容。 遵循这些指导也通常会使您的 Web 内容对普通用户更加可用。
该标准为设计 Web 内容写作工具提供了指导意见，使得残障人士也可使用这些工具。 遵从这些指导的写作工具将会通过为残障作者提供可访问的用户界面以提升可访问性，以及为所有作者提供、支持和提升产出 Web 内容的可访问性。
该文档为设计降低残障人士 Web 访问门槛的用户代理提供了指导意见。 用户代理包括浏览器和其他获取和渲染 Web 内容的软件。 遵循这些指导的用户代理通过它自己的用户界面以及其他内部工具 （包括与其他技术通信的能力，尤其是辅助性技术）提升可访问性。 此外，除残障人士之外的所有用户都会发现遵循该标准用户代理更加可用。
该标准依赖于 WHATWG Infra 标准。 [INFRA]
该标准所说的属性，指的是 HTML，XML 和 IDL 属性，通常在同一个上下文中。当未具体提及所指时，HTML 和 XML 属性指的是 content attributes，而 IDL attributes指的是在 IDL 接口中定义的属性。同样，“属性”这个词也同时指 Javascript 对象属性和 CSS 属性。在可能产生混淆时， 该标准使用 object properties 和 CSS properties 来区别。
一般而言，当该标准申明一个特性可以在 HTML 语法 或 XML 语法 中应用，则在另一个中也可用。 当一个特性仅在两个语言之一中应用时，该标准将显式申明它不能在另一个语言中使用， 如：“可在 HTML 中使用，…… （该语法不可用于 XML）”。
该标准使用术语 文档指任何 HTML，从短小精悍的文档到长篇累牍的论文，
亦或是多媒体报告、完整的交互式应用程序。该术语同时指 Document 对象和他们的后裔 DOM 树。至于序列化的字节流，
则根据上下文使用 HTML 语法 或 XML 语法 来表示。
在 DOM 结构的上下文中，使用的术语 HTML 文档 和
XML 文档 定义在 DOM 标准中，
并且特指 Document 对象所处的两种不同模式。 [DOM] （这样的使用都会超链接到它们的定义）
在字节流的上下文中，术语 HTML 文档 指标记为 text/html 的资源，
术语 XML 文档 指标记为 XML MIME type 的资源。
简单起见，像 shown, displayed, 以及 visible 这样的术语可能会用来指明文档渲染给用户的方式， 这些术语并不是指应用于视觉媒介；必须考虑将它们以等价的方式应用于其他的媒介。
某个元素是visible的并不仅仅指该元素在视觉上可见，比如屏幕阅读器也应将该元素阅读给用户。
To run steps in parallel means those steps are to be run, one after another, at the same time as other logic in the standard (e.g., at the same time as the event loop). This standard does not define the precise mechanism by which this is achieved, be it time-sharing cooperative multitasking, fibers, threads, processes, using different hyperthreads, cores, CPUs, machines, etc. By contrast, an operation that is to run immediately must interrupt the currently running task, run itself, and then resume the previously running task.
For guidance on writing specifications that leverage parallelism, see Dealing with the event loop from other specifications.
To avoid race conditions between different in parallel algorithms that operate on the same data, a parallel queue can be used.
A parallel queue represents a queue of algorithm steps that must be run in series.
A parallel queue has an algorithm queue (a queue), initially empty.
To enqueue steps to a parallel queue, enqueue the algorithm steps to the parallel queue's algorithm queue.
To start a new parallel queue, run the following steps:
Let parallelQueue be a new parallel queue.
Run the following steps in parallel:
While true:
Let steps be the result of dequeueing from parallelQueue's algorithm queue.
If steps is not nothing, then run steps.
Assert: running steps did not throw an exception, as steps running in parallel are not allowed to throw.
Implementations are not expected to implement this as a continuously running loop. Algorithms in standards are to be easy to understand and are not necessarily great for battery life or performance.
Return parallelQueue.
Steps running in parallel can themselves run other steps in in parallel. E.g., inside a parallel queue it can be useful to run a series of steps in parallel with the queue.
Imagine a standard defined nameList (a list), along with a method to add a name to nameList, unless nameList already contains name, in which case it rejects.
The following solution suffers from race conditions:
Let p be a new promise.
Run the following steps in parallel:
Return p.
Two invocations of the above could run simultaneously, meaning name isn't in nameList during step 2.1, but it might be added before step 2.3 runs, meaning name ends up in nameList twice.
Parallel queues solve this. The standard would let nameListQueue be the result of starting a new parallel queue, then:
Let p be a new promise.
Enqueue the following steps to nameListQueue:
Return p.
The steps would now queue and the race is avoided.
本标准中术语 支持 是指用户代理是否实现了对外部资源的语义的解码能力。 支持 某种格式或类型是指这一实现可以处理该格式或类型的外部资源，且处理过程不会忽略关键方面。 是否 支持 某种特定资源取决于该资源类型有哪些在用的特性。
例如，如果可以解码和渲染 PNG 图片的像素数据，就可以认为支持 PNG 图片格式。 即使这一实现不知道该图片还包含了动画数据。
如果不支持使用的压缩格式，即使实现可以从文件的元数据确定电影的尺寸，MPEG-4 视频文件也不会被视为支持的格式。
有些标准中（特别是 HTTP 标准）中称为 表示（representation） 的在本标准中称为 资源（resource）。 [HTTP]
资源的 关键子资源 是那些需要被正确处理的资源。 哪些资源被认为是关键的，由定义该资源格式的标准来定义。
为了方便从 HTML 迁移到 XML，遵循本标准的用户代理会把 HTML 中的元素放在
http://www.w3.org/1999/xhtml 命名空间，
至少是为了 DOM 和 CSS 的目的。
本标准中使用的术语 "HTML 元素"，是指所有在那个命名空间中的元素，
包括 XML 文档中的。
除非另有声明，所有本标准中定义和提到的元素均位于
HTML
（"http：//www.w3.org/1999/xhtml"），
本标准中所有定义和提到的属性（Attribute）没有命名空间。
术语 元素类型 用于指代给定命名空间和局部名的那些元素。
例如，button 元素的元素类型为 button，意味着它们的局部名为
"button" 且（如上述定义地）命名空间为
HTML。
如果属性名匹配 XML 中定义的 Name 生成式且不包含
U+003A COLON 字符（：），那么它就是 XML 兼容的 [XML]
当声明 忽略 某些元素或属性，或当作其他值处理，或当作其他东西处理时， 都是指节点在 DOM 中之后的处理。在这些情形下用户代理禁止改动 DOM。
只有内容属性的新值和原值不同时，才说内容属性的值发生了 改变； 将内容属性设置到它已有的值不会让它发生改变。
术语 空 用于属性值、文本 节点、或字符串时，
表示文本的长度是零（即不包含控制字符 或 U+0020 SPACE）。
插入节点 A 到节点 B 是指以 A 作为参数调用 插入步骤， 然后 A 新的父节点就是 B。类似地，从节点 B 移除节点 A 是指以 A 作为 removedNode 参数，以 B 作为 oldParent 参数调用 移除步骤。
插入节点到文档 是指把它作为参数调用 插入步骤， 然后它就 在文档树中 了。类似地， 从文档中移除节点 是指把它作为参数调用 移除步骤， 然后它就不 在文档树中 了。
把节点作为参数调用 插入步骤 后， 节点就 变成已连接的。 类似地，把它作为参数调用 移除步骤 后， 节点就 变成了分离的。
如果节点是 已连接的 且它的 包含 Shadow 的根 有 浏览环境，那么它是 连接到浏览环境的。 把节点作为参数调用 插入步骤 后， 它就 连接到了浏览环境。 把节点作为参数调用移除步骤， 或者它的 包含 Shadow 的根 不再拥有 浏览环境 后， 它就 与浏览环境分离了。
有时会用构造 "一个 Foo 对象"
（其中 Foo 其实是一个接口），
来表示 "一个实现了 Foo 接口的对象"。
获取 IDL 属性的值称为 获取（例如在作者的脚本中）， 将新的值赋值给 IDL 属性则称为 设置。
如果 DOM 对象是 活的，该对象上的属性和方法 必须 在真正的底层数据（而不是数据快照）上进行操作。
术语 插件 是指一些用户代理定义的内容处理程序，用户代理用它们
参与 Document 对象的渲染，但不会作为 Document 的
子浏览环境，也不会给
Document 的 DOM 引入任何 Node 对象。
通常，这样的内容处理程序由第三方提供，尽管用户代理也可以将内置的内容处理程序指定为插件。
用户代理不得将 text/plain 和 application/octet-stream 类型视为注册有
插件。
插件的一个例子是当用户导航到PDF文件时在 浏览环境 中实例化的PDF查看器。 无论执行PDF查看器组件的一方是否与实现用户代理本身的方相同，这将被视为插件。 但是根据定义，与用户代理（而不是使用相同的接口）分开启动的PDF查看器应用程序不是插件。
该规范没有定义与插件交互的机制，因为插件预期就是用户代理和平台特定的。 UA 可以选择支持某种插件机制，比如 Netscape Plugin API； 也可以选择对某些类型使用远程内容转换器或提供内置支持。 实际上，本标准根本没有要求用户代理支持插件。[NPAPI]
安全 插件应该遵循
sandbox 属性的语义。
例如，在沙盒 iframe 中初始化的
安全插件应该阻止其中的内容创建弹出窗口。
在与 插件 的外部内容交互时，浏览器应该格外小心。 当第三方软件以与用户代理本身相同的权限运行时，第三方软件中的漏洞变得与用户代理中的漏洞同样危险。
因为不同的用户有不同的 插件，这提供了唯一识别用户的指纹向量， 推荐用户代理对每个用户都支持同样的 plugins。
字符编码 或着没有歧义时说的 编码，是一种字节流与 Unicode 字符串的转换， 定义在 Encoding 中。编码 包括一个 编码名称 和一个或更多的 编码标签，编码的 名称 和 标签 定义在 Encoding 标准中。 [ENCODING]
本标准描述了 用户代理（实现者相关）和 文档 （作者和编写工具的实现者相关） 的符合性标准。
符合规范的文档 是符合所有符合性要求的文档。 为了提高可读性，有些符合性要求是对作者提出的；这些是对文档的隐性要求： 按照定义所有文档都有对应的作者。（有些情况下，作者本身可能是一个用户代理 — 这些用户代理受其他规则的约束，见下文。）
例如，如果一项要求声明 "作者 禁止使用
foobar 元素"，意味着文档不允许包含名为 foobar 的元素。
文档的符合性要求与实现的符合性要求没有隐含的关系。 用户代理不能随意处理不合规范的文档；不论输入的文档是否合规，本标准中描述的处理模型都适用。
按照不同的符合性要求，用户代理分为（有重合的）几类。
支持 XML 语法 的 Web 浏览器必须按照本标准的描述 处理 XML 文档中 HTML 命名空间 的元素和属性， 以便用户与之交互，除非那些元素的语义已经被其他标准覆盖。
在 XML 文档中查找 script 元素时，符合规范的 Web
浏览器会执行该元素包含的脚本。然而，如果该元素处于 XSLT 变换中（假设用户代理也支持 XSLT），
那么处理器会将 script 元素作为组成这一变换的不透明元素处理。
支持 HTML 语法 的 Web 浏览器必须按照本标准的描述 处理标记为 HTML MIME 类型 的文档，以便用户与它们交互。
支持脚本的用户代理也必须一致地实现本标准中的 IDL 片段，IDL 片段定义在 Web IDL 标准中。 [WEBIDL]
除非明确声明，覆盖 HTML 元素语义的标准不覆盖对（表示这些元素的） DOM 对象的要求。
例如，上面例子中的 script 元素仍然实现 HTMLScriptElement 接口。
处理 HTML 和 XML 文档并纯粹地渲染它们的非交互式版本的用户代理必须遵循与 Web 浏览器同样的符合性规范，除了它们可以免除用户交互的要求。
非交互式用户代理的典型例子就是打印机（静态 UA）和投影仪（动态 UA）。 多数静态的非交互式用户代理 不支持脚本。
非交互式的动态 UA 仍然会执行脚本，以便动态提交表单。 但是因为没有获得焦点的概念，这些 UA 可能不需要实现焦点相关的 DOM API。
无论是交互式还是非交互式用户代理，都可以被指定（比如通过作为用户选项）本标准定义的建议默认渲染。
这并非强制要求，特别是即使用户代理实现了建议默认渲染，也建议为此提供设置来提升用户体验， 例如改变色彩对比度，使用不同的焦点样式，或者其他提升可访问性和可用性的方式。
如果指定了建议默认渲染，支持建议默认渲染的用户代理必须根据 渲染部分 定义的规则实现 用户代理 期望 实现的行为。
不支持脚本的实现（或者完全禁用了其脚本特性的用户代理）可以不支持本标准中提到的事件和 DOM 接口。 但对于本标准中定义的事件模型和 DOM，这些用户代理仍然必须表现地像支持事件和 DOM 一样。
脚本可能是构成应用的一部分。不支持脚本或禁用了脚本的 Web 浏览器可能无法完全表达作者的意图。
符合性检查器必须验证文档是否符合
符合性检查程序必须验证文档是否符合本规范中描述的适用的一致性标准。
自动化的符合检查程序可以不必检测需要解释作者意图的错误（例如，
blockquote 的内容不是引用文档就不符合标准，如果符合性检查程序在运行时没有人为判断的输入，
就不必检查 blockquote 元素是否只包含引用的内容）。
符合性检查器必须检查没有 浏览环境 （意味着没有脚本运行，并且禁用了解析器的 脚本标志 ）时解析输入文档符合规范， 还应检查在会执行脚本的 浏览环境 下解析输入文档符合规范，并且脚本的执行永远不会导致不符合规范的状态（脚本执行过程中除外）出现。 （这只是一个“应该”而不是“必须”的要求，因为这已被证明是不可能的。[COMPUTABLE]）
"HTML 校验器" 可以指代遵循本标准中的适用要求的符合性检查器。
XML DTD 无法表达本标准的所有符合性要求。因此 XML 校验器加 DTD 不能代替符合性检查器。 此外本标准中定义的这两种写作格式都不属于 SGML，因此 SGML 系统也不能代替符合性检查器。
换句话说，有三种符合性规则：
符合性检查器可以检查前面两种。简单的基于 DTD 的校验器只能检查第一类错误， 因此根据本标准，它不是一种遵循标准的符合性检查器。
不是出于渲染文档或检查文档是否符合规范目的的，处理 HTML 和 XML 文档的应用程序和工具， 其行为应当与其处理的文档的语义保持一致。
只增加每个段落（paragraph）的嵌套层级但不增加每个章节（section）的嵌套层级的 文档大纲 生成工具是不合规范的。
只增加 <p> 的层级而不增加
<section> 的层级会破坏 DOM 原有的语义，比如让段落变成了子段落。
编写工具和标记生成器必须生成 符合规范的文档。 在适当的地方，适用于作者的符合性规则也适用于编写工具。
如果编写工具还不能决定作者的意图，可以免除“只能按规定的用途使用元素”的严格要求。 但是编写工具禁止自动地错误使用元素或鼓励它们的用户这样做。
例如，将 address 元素用于任意的联系信息是不合规范的；
该元素只能用于标记文档或章节作者的联系信息。因为编写工具不能区分此意图，所以可以免除这项要求。
但这不意味着（比如）编写工具可以为了斜体字而任意地使用 address 元素；
只意味着编写工具可以在用户给章节插入联系信息时不验证它，
也不需保证用户没用它做别的事或插入别的东西。
在符合性检查方面，文本编辑器必须像符合性检查器一样输出符合规范的文档。
当使用编写工具编辑不符合规范的文档时，可以保持未编辑部分的符合性错误。 （即允许错误的内容经过编辑工具而不发生改变）。 但如果保持了错误，禁止编写工具声明其输出是符合规范的。
编写工具大致分为两类：在结构化或语义数据上进行编辑， 或者在所见即所得的（WYSIWYG）特定媒体上进行编辑。
前者是编写 HTML 工具的理想机制，因为源码信息中的结构可用于更好地选择 HTML 元素和属性。
但是 WYSIWYG 工具也是合理的。WYSIWYG 工具应该使用它们认为合适的元素，
不应该使用它们不确定是否合适的元素。这可能在特定极端情况下意味着对能够使用的流式元素做出限制，
比如 div，b，i，以及 span，以及使用大量的
style 属性。
不论是不是 WYSIWYG，所有编写工具都应该尽量让用户创建良构的、语义丰富的、媒体无关的内容。
为了防范诸如 DoS 攻击、内存耗尽，或解决平台相关的限制， 用户代理可能会对本来不受约束的输入强加实现相关的限制。
为了兼容既有内容与标准，本标准描述了两种写作格式： 一种基于 XML， 另一种基于 SGML 启发的 自定义格式 （称为 HTML 语法）。 本标准鼓励实现同时支持以上两种格式，但至少支持其中一种。
一些符合性要求称为元素、属性、方法或对象的要求。 这些要求分为两类：描述内容模型限制的，和描述实现行为的。 前者是对文档和编写工具的要求，后者是对用户代理的要求。 类似地，另一些符合性要求称为对作者的要求；这些要求应解释为对作者产出的文档的符合性要求。 （换句话说，本标准不区分对作者和对文档的符合性要求）
This specification relies on several other underlying specifications.
The following terms are defined in Infra: [INFRA]
The Unicode character set is used to represent textual data, and Encoding defines requirements around character encodings. [UNICODE]
This specification introduces terminology based on the terms defined in those specifications, as described earlier.
The following terms are used as defined in Encoding: [ENCODING]
Implementations that support the XML syntax for HTML must support some version of XML, as well as its corresponding namespaces specification, because that syntax uses an XML serialization with namespaces. [XML] [XMLNS]
Data mining tools and other user agents that perform operations on content without running scripts, evaluating CSS or XPath expressions, or otherwise exposing the resulting DOM to arbitrary content, may "support namespaces" by just asserting that their DOM node analogues are in certain namespaces, without actually exposing the namespace strings.
In the HTML syntax, namespace prefixes and namespace declarations do not have the same effect as in XML. For instance, the colon has no special meaning in HTML element names.
The attribute with the name space in the XML namespace is defined by
Extensible Markup Language (XML). [XML]
The Name production is defined in XML. [XML]
This specification also references the <?xml-stylesheet?>
processing instruction, defined in Associating Style Sheets with XML documents.
[XMLSSPI]
This specification also non-normatively mentions the XSLTProcessor
interface and its transformToFragment() and transformToDocument() methods. [XSLTP]
The following terms are defined in URL: [URL]
application/x-www-form-urlencoded formatapplication/x-www-form-urlencoded serializerA number of schemes and protocols are referenced by this specification also:
about: scheme [ABOUT]blob: scheme [FILEAPI]data: scheme [RFC2397]http: scheme [HTTP]https: scheme [HTTP]mailto: scheme [MAILTO]sms: scheme [SMS]urn: scheme [URN]Media fragment syntax is defined in Media Fragments URI. [MEDIAFRAG]
The following terms are defined in the HTTP specifications: [HTTP]
Accept` headerAccept-Language` headerCache-Control` headerContent-Disposition` headerContent-Language` headerLast-Modified` headerReferer` headerThe following terms are defined in HTTP State Management Mechanism: [COOKIES]
Cookie` headerThe following term is defined in Web Linking: [WEBLINK]
Link` headerThe following terms are defined in Structured Field Values for HTTP: [STRUCTURED-FIELDS]
The following terms are defined in MIME Sniffing: [MIMESNIFF]
The following terms are defined in Fetch: [FETCH]
about:blankUser-Agent` valueOrigin` headerCross-Origin-Resource-Policy` headerRequestCredentials enumerationRequestDestination enumerationfetch() methodThe following terms are defined in Referrer Policy: [REFERRERPOLICY]
Referrer-Policy` HTTP headerReferrer-Policy` header algorithmno-referrer",
"no-referrer-when-downgrade",
"origin-when-cross-origin", and
"unsafe-url" referrer policiesThe following terms are defined in Mixed Content: [MIX]
The following terms are defined in Paint Timing: [PAINTTIMING]
The following terms are defined in Long Tasks: [LONGTASKS]
The IDL fragments in this specification must be interpreted as required for conforming IDL fragments, as described in Web IDL. [WEBIDL]
The following terms are defined in Web IDL:
[LegacyFactoryFunction][LegacyLenientThis][LegacyNullToEmptyString][LegacyOverrideBuiltIns][LegacyTreatNonObjectAsNull][LegacyUnenumerableNamedProperties][LegacyUnforgeable]The Web IDL also defines the following types that are used in Web IDL fragments in this specification:
ArrayBufferArrayBufferViewbooleanDOMStringdoubleErrorFunctionlongobjectUint8ClampedArrayunrestricted doubleunsigned longUSVStringVoidFunctionThe term throw in this
specification is used as defined in Web IDL. The DOMException
type and the following exception names are defined by Web IDL and used by this
specification:
IndexSizeError"HierarchyRequestError"InvalidCharacterError"NotFoundError"NotSupportedError"InvalidStateError"SyntaxError"InvalidAccessError"SecurityError"NetworkError"AbortError"QuotaExceededError"DataCloneError"EncodingError"NotAllowedError"When this specification requires a user agent to create a Date object
representing a particular time (which could be the special value Not-a-Number), the milliseconds
component of that time, if any, must be truncated to an integer, and the time value of the newly
created Date object must represent the resulting truncated time.
For instance, given the time 23045 millionths of a second after 01:00 UTC on
January 1st 2000, i.e. the time 2000-01-01T00:00:00.023045Z, then the Date object
created representing that time would represent the same time as that created representing the
time 2000-01-01T00:00:00.023Z, 45 millionths earlier. If the given time is NaN, then the result
is a Date object that represents a time value NaN (indicating that the object does
not represent a specific instant of time).
Some parts of the language described by this specification only support JavaScript as the underlying scripting language. [JAVASCRIPT]
The term "JavaScript" is used to refer to ECMA-262, rather than the official
term ECMAScript, since the term JavaScript is more widely known. Similarly, the MIME
type used to refer to JavaScript in this specification is text/javascript, since that is the most commonly used type, despite it being an officially obsoleted type according to RFC
4329. [RFC4329]
The following terms are defined in the JavaScript specification and used in this specification:
Atomics objectDate classRegExp classSharedArrayBuffer classTypeError classRangeError classeval() functionimport()import.metatypeof operatordelete operatorUsers agents that support JavaScript must also implement ECMAScript Internationalization API. [JSINTL]
The following term is defined in WebAssembly JavaScript Interface: [WASMJS]
The Document Object Model (DOM) is a representation — a model — of a document and its content. The DOM is not just an API; the conformance criteria of HTML implementations are defined, in this specification, in terms of operations on the DOM. [DOM]
Implementations must support DOM and the events defined in UI Events, because this specification is defined in terms of the DOM, and some of the features are defined as extensions to the DOM interfaces. [DOM] [UIEVENTS]
In particular, the following features are defined in DOM: [DOM]
Attr interfaceComment interfaceDOMImplementation interfaceDocument interfaceDocumentOrShadowRoot interfaceDocumentFragment interfaceDocumentType interfaceChildNode interfaceElement interfaceattachShadow() method.Node interfaceNodeList interfaceProcessingInstruction interfaceShadowRoot interfaceText interfaceHTMLCollection interface, its
length attribute, and its
item() and
namedItem() methodsDOMTokenList interface, and its
value attributecreateDocument() methodcreateHTMLDocument() methodcreateElement() methodcreateElementNS() methodgetElementById() methodgetElementsByClassName() methodappendChild() methodcloneNode() methodimportNode() methodpreventDefault() methodid attributesetAttribute() methodtextContent attributeEvent interfaceEvent and derived interfaces constructor behaviorEventTarget interfaceEventInit dictionary typetype attributetarget attributecurrentTarget attributebubbles attributecancelable attributecomposed attributeisTrusted attributeinitEvent() methodaddEventListener() methodEventListener callback interfaceDocumentNode, and the concept of
cloning steps used by that algorithmis valueMutationObserver interface and mutation observers in generalThe following features are defined in UI Events: [UIEVENTS]
MouseEvent interfaceMouseEvent interface's relatedTarget attributeMouseEventInit dictionary typeFocusEvent interfaceFocusEvent interface's relatedTarget attributeUIEvent interfaceUIEvent interface's view attributeauxclick eventclick eventdblclick eventmousedown eventmouseenter eventmouseleave eventmousemove eventmouseout eventmouseover eventmouseup eventwheel eventkeydown eventkeypress eventkeyup eventThe following features are defined in Touch Events: [TOUCH]
Touch interfacetouchend eventThe following features are defined in Pointer Events: [POINTEREVENTS]
pointerup eventThis specification sometimes uses the term name to refer to the event's
type; as in, "an event named click" or "if the event name is keypress". The terms
"name" and "type" for events are synonymous.
The following features are defined in DOM Parsing and Serialization: [DOMPARSING]
The following features are defined in Selection API: [SELECTION]
User agents are encouraged to implement the features described in execCommand. [EXECCOMMAND]
The following parts of Fullscreen API are referenced from this
specification, in part to define the rendering of dialog elements, and also to
define how the Fullscreen API interacts with HTML: [FULLSCREEN]
requestFullscreen()High Resolution Time provides the current high
resolution time and the DOMHighResTimeStamp
typedef. [HRT]
This specification uses the following features defined in File API: [FILEAPI]
Blob interface and its
type attributeFile interface and its
name and
lastModified attributesFileList interfaceBlob's snapshot stateThis specification uses cleanup Indexed Database transactions defined by Indexed Database API. [INDEXEDDB]
The following terms are defined in Media Source Extensions: [MEDIASOURCE]
The following terms are defined in Media Capture and Streams: [MEDIASTREAM]
MediaStream interfaceThe following terms are defined in Reporting: [REPORTING]
The following features and terms are defined in XMLHttpRequest: [XHR]
XMLHttpRequest interface, and its
responseXML attributeProgressEvent interface, and its
lengthComputable,
loaded, and