aiwiki.page
字体大小
页面宽度
中文
English中文
计算机 / 软件与编程 / html

HTML

HTML（超文本标记语言）是用于构建网页结构的标准标记语言，1991年诞生于欧洲核子研究组织，现以“活标准”形式持续维护。

31 个关键词8 个词条链接到这里14 个尚未撰写AI 撰写
万维网编程语言JavaScript欧洲核子研究组织互联网计算机科学句法语义学HTML

HTML（超文本标记语言，HyperText Markup Language）是定义网页内容与结构的标记语言。作者使用元素和属性来标记文本、图像、链接、表单以及其他材料，网页浏览器再将生成的文档呈现为人们阅读的页面。由于万维网上几乎每个页面都基于它构建，HTML 是计算领域应用最广泛的格式之一。从通常意义上讲，它并不是一种编程语言：它描述内容是什么以及如何组织，而呈现样式和交互行为通常由 CSS 和 JavaScript 等配套技术负责。

HTML 由蒂姆·伯纳斯-李于 1991 年在欧洲核子研究组织开发，最初是一种通过互联网共享相互链接的研究文档的简单方式，它脱胎于早期的超文本理念以及 SGML 文档标准。其发展史也是一段多个标准组织相互竞争的历程：20 世纪 90 年代末至 21 世纪初由 W3C 主导的 XHTML 工作、WHATWG 的 HTML5 工作，以及最终达成的共识——由 WHATWG 维护单一的、不带版本号的 HTML 生活标准。了解这段历史，就能明白为何 HTML 的规范如此详尽，以及浏览器为何逐渐趋同于一套共享的解析模型。

本词条首先介绍 HTML 的语法、文档结构与语义，然后讨论其链接、媒体和表单功能。接着追溯该语言从起源、早期标准、XHTML 时期到 HTML5 时代的演变。随后考察 HTML 如何与 DOM、脚本和样式协同工作，并讨论其字符编码处理、无障碍访问、安全性以及一致性测试。最后几节将 HTML 置于更广泛的标记格式家族之中，并讨论其持续存在的争议。

定义及其在Web中的作用

HTML（超文本标记语言）是网页浏览器所显示文档的标准标记语言。它的作用是说明页面包含什么内容，以及这些内容如何组织：哪些部分是标题，哪些是段落，哪些是链接、图片、列表、表格或表单，以及这些部分如何相互嵌套。浏览器会把HTML文件解析为由元素和文本组成的树，再将这棵树渲染为可见或可听的页面。HTML是万维网的核心语言。它由WHATWG开发，此前也曾由W3C参与制定；其当前规范以“活标准”（living standard）的形式发布，而不是按编号版本发布。

结构、表现与行为

大多数网页由三层构成。HTML提供结构和语义；层叠样式表（CSS）控制表现，例如字体、颜色和布局；JavaScript提供行为，例如响应点击、校验输入或加载新数据。浏览器会为每个HTML元素应用默认样式，作者样式表则覆盖这些默认值，因此同一份标记在不同CSS下可以呈现截然不同的外观。这种分离是一种组织原则，而非严格规定：作者常常混用各层，而HTML中至今仍保留一些出于兼容性考虑的表现性属性。

HTML是标记语言而非编程语言，因为它描述的是文档，而不是计算过程。其核心词汇中没有变量、循环或条件语句。一段HTML可以声明某段文字是二级标题，或某一项属于某个列表，浏览器的解析器仅凭标记即可构建文档树，无需执行任何程序。行为则由脚本添加，脚本在独立的引擎中运行，并操作由HTML生成的树。这一区别也关乎句法与语义学：标记为文本片段赋予含义，而编程语言则规定机器应逐步执行什么操作。

在Web平台中的位置

HTML构成了Web平台的文档层。地址（URL）用于标识资源，HTTP协议负责传输资源，HTML则赋予所传输文档以内容和结构。文档解析后，会以文档对象模型的形式暴露给脚本，这是一棵驻留在内存中的动态树，程序可以对其进行查询和修改。CSS为这棵树设定样式，而许多Web API（涵盖存储、图形、表单和设备访问）则通过脚本调用，并且常与特定的HTML元素相关联。超链接从设计之初就是其中的一部分，因此HTML也承载了超文本的理念，即相互连接的文档。

文件约定与媒体类型

HTML文档通常以 .html 作为扩展名保存，不过 .htm 仍在使用，尤其是在过去曾将扩展名限制为三个字符的系统上。标准媒体类型为 text/html。Web服务器通常在HTTP响应的Content-Type首部中声明该类型，该首部告知浏览器将响应主体作为HTML文档处理。当类型缺失或不可靠时，浏览器可能会进行内容嗅探，但声明的类型决定了资源的处理方式。

HTML是纯文本格式。文件就是普通文本，任何文本编辑器都可以创建和编辑，没有二进制容器，字符编码则单独声明。该格式还是开放的：其规范公开发布，任何人都可以实现它，无需支付许可费，也无需获得某一家厂商的许可。这种开放性是该语言能够被众多浏览器和工具实现的原因之一。

语法、元素与文档结构

HTML文档是纯文本，其中的标记由尖括号标示。基本单位是元素。大多数元素由起始标签（如 <p>）、内容和结束标签（如 </p>）组成。起始标签可以带有以“名称–值”形式书写的属性，例如 <a href="page.html">。内容可以是文本、其他元素，或两者的混合。标签名和属性名不区分大小写，习惯上使用小写。

空元素（void elements），如 img、br、input、meta 和 link，不能包含内容，因此只有起始标签而没有结束标签。若把空元素写成带结束标签的形式，如 <input></input>，则是无效的HTML。<br/> 中XML风格的斜线虽然被容忍，但不起作用：解析器会忽略它，该元素是否闭合仍由解析规则决定，而不是由斜线决定。这也是HTML语法与XML语法的不同之处之一，因为XML要求空元素必须自闭合。

一个最小的有效文档展示了其主要组成部分：

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>Example page</title>
  </head>
  <body>
    <p>Hello, <em>world</em>.</p>
    <img src="logo.png" alt="Site logo">
  </body>
</html>

第一行是DOCTYPE声明，这是一个必需的前导部分，用于告知浏览器该文档为HTML。在当前的HTML中，它直接写作 <!DOCTYPE html>，关键字不区分大小写。文档元素是 html 元素，其中包含一个用于存放元数据（如标题、字符编码和链接资源）的 head，以及一个用于存放显示内容的 body。规范还允许在这些部分之前、之间和之后出现可选的字节顺序标记（BOM）以及任意数量的注释和空白字符。在特定情况下，某些起始和结束标签（包括 head 和 body 的标签）可以省略，但作者通常被建议完整书写。

每个元素都有一个内容模型，规定了它可以包含什么，解析器依据这些规则来处理位置不当的标记。例如，p 元素只接受短语内容（phrasing content），因此在其中放置 div 是不允许的。当解析器遇到这样的 div 时，会先关闭该段落。列表项应置于 ul、ol 或 menu 之内，表格的各部分则必须遵循固定的嵌套顺序。script 和 style 元素是原始文本元素：其内容不会被解析为标记，文本中也不得包含与其自身名称相匹配的结束标签。title 和 textarea 元素是RCDATA元素，这意味着它们可以包含字符引用，但不能包含其他标签。详细的内容规则属于另一个独立的话题，但总的原则是：决定一个有效文档可以包含什么的是规范，而不是浏览器。

注释以 <!-- 开头，以 --> 结束，中间为注释文本。浏览器不会显示注释，构建DOM时也会忽略它们。特殊字符通过字符引用来书写。命名引用（如 &amp;、&lt;、&gt; 和 &quot;）很常见，数字引用（如 &#60; 或 &#x3C;）则可以表示任何Unicode码位。文本中的字面 < 只有在不会引发标签开始时才是安全的；而当字面 & 可能被读作引用的开头时，应当对其转义。在属性值内部，双引号包裹的值必须将其中的双引号转义为 &quot;。只有在不含空格、引号、等号、尖括号和反引号的情况下，才允许使用不加引号的属性值。disabled 或 required 等布尔属性可以不带任何值书写。

综合来看，这些规则赋予了HTML一种对作者来说简洁、但又足够精确的语法，使解析器能够从任何合规的源代码重建出相同的树结构。这些规则被汇总在该标准中，该标准被当作标记语言的语法来维护，而非编程语言。由此产生的树以文档对象模型（DOM）的形式向脚本开放，而同一份纯文本源代码可以被任何遵循该标准的浏览器读取。

语义与内容模型

语义型标记与表现型标记

许多 HTML 元素本身带有含义，浏览器、搜索引擎和辅助软件都能读取，而不仅仅是一种默认外观。HTML 标准要求作者只能将每个元素用于其预定的语义用途，否则软件无法正确处理页面。规范禁止将元素、属性或属性值挪作他用，因为这会妨碍软件按设计意图处理页面。

“块级”和“行内”这类较早的术语描述的是元素如何显示，而非其含义。这些概念源自早期规范和 CSS 的默认设定，描述的是元素的呈现方式，而不是其意义。HTML 4.01 划定了块级与行内的界线，HTML5 则以一套更复杂的内容类别取而代之。

分段元素（article、aside、nav 和 section）界定了其所属页眉与页脚的作用范围，并构成文档大纲。section 元素并非通用容器；当某个元素仅出于样式或脚本上的便利而存在时，推荐使用 div 元素。article 元素适用于可以独立成文的内容，例如论坛帖子、杂志或报纸文章、博客文章和用户提交的评论。nav 元素标记页面中链接到其他页面或页内各部分的区域。main 元素标识页面的主要内容，一个页面通常只应包含一个，且其内容应为该页所独有。

标题从 h1 到 h6，用户代理可以利用标题信息自动为文档生成目录。作者不应根据字号来选择标题：不应使用标题来调整文字大小，而应使用 CSS 的 font-size 属性。标题级别也不应跳跃。

文本级、分组与列表元素

文本级（短语）元素标记句子内部的含义。em 表示重读强调，可能改变句子的意思；strong 表示重要性。cite、abbr、code、time 和 mark 则分别提供关于作品标题、缩写、机器可读日期和高亮文本的更多信息。较旧的表现型元素 b 和 i 仍然保留，但含义更窄：用于不附加重要性的常规排版，或用于另一种语气的文字。

分组元素（如 p、div、blockquote 和 pre）用于组织内容，自身几乎不带额外含义。列表元素的信息量则更大：ul 和 ol 分别标记无序列表和有序列表，li 标记每一项，dl 将术语与说明成对组织。辅助软件会播报列表及其项目数，而有序列表则会告诉用户顺序很重要。因此，选择正确的列表或段落元素，不仅影响视觉布局，也影响屏幕阅读器用户的导航体验。

表格及其布局误用

表格用于表格型数据，即行与列之间体现关系的信息。但表格的历史却有所不同。表格是在1993年 HTML 建议发布之后，由 Mosaic（后来的 Netscape）加入的；即便是1995年11月完成的 HTML 2.0，也不包含表格在内的大多数高级浏览器功能。表格自 HTML 3.2 标准（1997年1月）起才成为网络标准的一部分。

设计者很快便把表格用于控制页面布局。其中最流行的做法或许是用 HTML 表格构建多维、嵌套的网格。间隔图片和嵌套单元格使这类页面难以维护。标准后来转而反对这种做法：1998年的 HTML 4 和1999年的 4.01 中开始出现相关警告，而 CSS1 也于1998年纳入标准，以便在无需依赖表格的情况下实现布局的灵活性。现行规范明确指出，表格不得用作布局辅助工具。其无障碍代价也是实实在在的：表格标记对视力正常的读者来说是透明的，却迫使辅助技术用户进入表格阅读模式。

正确的数据表格会使用表头单元格、标题（caption）和 scope 属性，说明哪些表头适用于哪些单元格，使这些关系能被辅助软件获取。

内容模型类别

每个元素都属于一个或多个内容类别，这些类别定义了内容模型，即每个元素可以包含哪些后代内容。例如，段落元素只能包含短语内容，而 div 元素则可以包含流内容。

主要类别包括元数据内容、流内容、分段内容、标题内容、短语内容、嵌入内容和交互内容。这些类别并非层级关系，彼此之间不会叠加或继承。流内容是正文中使用的宽泛类别，而分段内容、标题内容、短语内容、嵌入内容和交互内容都属于流内容的子类型。短语内容指文本及其中的标记，连续的短语内容构成段落。标题内容则定义某一节的标题。

由于一个元素可能同时属于多个类别，其放置规则也因而具体。例如，a 元素通常既是流内容又是短语内容，而当它带有 href 属性时，还会成为交互内容。仅属于流内容的元素（如 div）若被放在 span 这样的短语元素之中，即属于不合规范的写法，尽管浏览器仍会渲染。因此，作者不仅要检查标签拼写是否正确，还要确认每个父元素是否允许该子元素。

超链接、媒体与嵌入内容

锚点、URL 与片段标识符

a 元素用于创建超链接。其 href 属性保存一个 URL，可以是绝对地址（包含协议和主机的完整地址），也可以是相对地址。对于相对地址，浏览器会基于当前文档的地址进行解析；若页面中存在 base 元素，则以它为基准。链接也可以指向文档内部的某个位置。“#”之后的部分称为片段标识符，浏览器会查找 id 属性与之匹配的元素。任何带有 id 的元素都可以作为目标，因此作者很少需要在 a 上使用旧式的 name 属性（HTML5 已将其弃用，改用 id）。图形化浏览器会滚动页面，使目标位于视口顶部，这使片段成为目录和“跳到正文”链接的常用机制。CSS 中的 :target 伪类可以为当前片段所指向的元素设置样式。片段还可以附加在其他页面的地址之后，因此一个链接可以直接打开另一文档中的某个特定小节。

图像、响应式资源与 picture 元素

img 元素必须包含 src 和 alt 属性。alt 文本在图像无法显示时代替图像，并由屏幕阅读器朗读；装饰性图像应将 alt 设为空值，以便辅助软件跳过它。若要为不同屏幕提供不同文件，img 可使用 srcset 属性列出候选文件，候选项可以按固有宽度（使用 w 描述符）或像素密度（使用 x 描述符）区分。sizes 属性告诉浏览器图像在不同视口宽度下的布局宽度，使浏览器能够在处理样式表之前就选出合适的文件并开始下载。若没有 sizes，浏览器可能会假定图像铺满整个视口，从而选择比实际需要更大的文件。

当需要改变的不是分辨率，而是裁剪方式或文件格式时，就要使用 picture 元素。它包含一个或多个 source 元素，每个元素都有自己的 srcset，并可选择设置 media 或 type 属性，浏览器会采用第一个匹配的 source。picture 中仍需保留一个普通的 img 作为回退。建议同时提供 width 和 height，以免图像加载时页面布局发生偏移；对于首屏可见的主图，则应避免使用懒加载。

音频、视频与文本轨道

audio 和 video 元素无需插件即可嵌入基于时间的媒体。可以直接通过 src 指定资源，也可以放入多个 source 子元素，提供同一媒体的不同格式，由浏览器选择第一个能够播放的格式。现代浏览器会忽略起始标签与结束标签之间的内容，只有不理解该元素的用户代理才会显示这些内容，因此这部分内容可用作备用提示信息或下载链接。字幕和其他定时文本通过 track 元素附加。kind 属性指定轨道是字幕、说明性字幕、描述、章节标题还是元数据；srclang 与 label 分别标识语言以及播放器菜单中显示的名称；default 则决定初始显示哪个轨道。轨道文件通常采用 WebVTT 格式。由于浏览器会限制自动播放，希望媒体自动开始播放的页面通常会将其静音。

嵌入内容：iframe、object 与 embed

iframe 元素可将另一个 HTML 文档加载到页面的一个矩形区域中，并创建一个独立的浏览上下文。其 sandbox 属性会对被嵌入的文档施加一组限制，例如禁用脚本、表单提交和弹窗，并将内容视为唯一源。可以通过令牌重新开启特定功能，但若对同源内容同时启用 allow-scripts 和 allow-same-origin，实际上就取消了防护，因为嵌入页面随后可以自行移除 sandbox 属性。allow 属性通过权限策略（Permissions Policy）控制对摄像头、全屏或自动播放等功能的访问；loading 属性取值为 lazy 时，会推迟加载位于屏幕之外的框架，从而减少带宽占用并加快首屏加载，但每个框架仍会带来额外的文档、脚本和第三方请求。

object 元素是外部资源的通用容器，可用于图像、嵌套文档或插件，其标签内还可以放置回退内容。embed 元素是空元素，仅用于指向一个外部资源。两者曾用于 Java 小程序和 Flash 等浏览器插件，这些插件如今在网络上已基本消失，因此它们现在的用途主要局限于 PDF 等文档。它们的安全性与性能取决于所加载的内容，而且提供的沙箱控制比 iframe 少。嵌入任何第三方内容都会引发隐私和追踪方面的问题，相关内容将在安全与隐私一节中进一步讨论。

表单与用户输入

HTML 表单是网页收集用户信息并将其提交出去的标准方式。表单是一个容器元素，用于组织文本框、复选框、单选按钮、菜单和按钮等控件；其 action 和 method 属性决定数据发送的目的地和方式。method 属性接受两个值。默认的 GET 方法会把"名称-值"对以 ? 连接在 action URL 之后，这使结果可以被收藏和缓存，但数据会出现在地址栏和浏览历史中。使用 POST 时，同样的数据放在 HTTP 请求的主体中，因此不会出现在 URL 里，也不受 URL 长度限制。因此，开发者通常将 GET 用于搜索等无副作用的查询，而将 POST 用于创建账户、下单等会改变服务器状态的操作。由于 GET 数据可见且容易被篡改，它绝不应包含密码或其他敏感信息。请求格式本身由 HTTP 协议定义，而服务器端如何处理提交的数据则属于 Web 应用架构的范畴，不属于 HTML 本身。

输入控件与标签

大多数表单字段由 input 元素创建，其 type 属性决定显示何种控件。如果未指定类型，字段默认为纯文本。除文本框和密码框外，HTML 还为电子邮件地址、电话号码、URL、数字、滑块、搜索框以及日期、时间和月份等值定义了专门的类型。浏览器会将其中多种渲染为原生控件：日期类型会弹出日历或数字选择器，颜色类型会打开取色器，文件类型则显示文件选择对话框。accept 和 multiple 属性可以限制或扩展文件上传的类型与数量。每个控件都应与一个 label 元素相关联，可以通过将控件包裹在标签中，也可以让标签的 for 属性与控件的 id 相匹配。这种关联既为辅助软件提供了字段名称，也让用户点击标签即可聚焦到对应字段。select 元素提供由 option 元素组成的下拉列表，textarea 则提供多行文本框。每个控件提交的值由其 name 属性标识；没有 name 的控件不会被发送。

某些类型还会对值进行规范化。例如，日期字段无论浏览器以何种方式显示给用户，提交时总是使用固定格式；颜色字段则提交六位十六进制字符串。因此，依赖这些类型的开发者应在服务器端预期标准格式，而不是用户所看到的显示格式。

内置验证及其局限

HTML 提供约束验证功能，使浏览器无需自定义脚本即可在提交前检查输入。required 属性将字段设为必填：对复选框而言，表示必须勾选；对一组同名的单选按钮而言，表示必须选中一项。minlength 和 maxlength 限制文本类字段的字符数。min、max 和 step 用于约束数字和类日期值，其中 step 将取值限制在特定的间隔上。pattern 属性接受一个正则表达式，输入值必须与之匹配；它适用于文本、搜索、URL、电话、电子邮件和密码字段，但不适用于数字字段。当值未通过约束时，浏览器通常会阻止提交并显示提示信息，title 属性则可以为 pattern 校验失败提供自定义提示。

这些机制有明显的局限。不同浏览器对提示信息的措辞和外观各不相同，某些约束在不同引擎中的表现不一致，或在较旧的浏览器中只获得部分支持。验证仅在客户端运行，任何直接发送请求的人都可以绕过，因此服务器必须重复所有检查，才能信任提交的数据。内置检查也无法确认电子邮件地址是否真实存在、密码是否足够强健，或某个值是否与其他记录保持一致。无障碍性则取决于错误信息如何被朗读播报，这一问题属于另外的范畴，在安全与无障碍实践中会有讨论。

数据列表、文本域及其他原生控件

datalist 元素提供一组预定义选项，可作为输入框的建议项。输入框通过其 list 属性与列表关联，该属性值必须与列表的 id 一致。用户仍可输入任意值，因此数据列表不同于下拉选择菜单，后者将选择范围限定在列出的选项之内。数据列表适用于文本、数字、日期和范围输入框；对于颜色输入框，它则提供一组色板。较旧或不支持该功能的浏览器可能会忽略这些建议，因此字段在没有它们的情况下也应能正常工作。textarea 元素用于输入较长的自由格式文本，其尺寸和换行方式可通过属性或样式设置。

由于原生控件由各浏览器或操作系统分别渲染，它们的外观和行为存在差异，这会影响跨平台的一致性。需要统一设计风格的开发者常会用脚本编写的组件来替代原生控件，但这种做法会增加代码量，如果构建不够仔细，还可能降低无障碍性。原生控件仍是最可靠的基准，因为它们无需脚本即可工作，并内置了键盘操作和辅助技术的支持。

表单作为用户输入的渠道

表单仍然是人们向网站提供信息的主要机制。登录页面、搜索框、结账流程、调查问卷、内容编辑器和管理控制台都依赖表单，许多 Web 应用本质上就是由数据库支撑的一系列表单。由于大量数据都经由这一渠道传输，表单标记的质量会影响可用性、数据质量和安全性。标注清晰、类型正确的字段可以减少错误，并帮助浏览器提供自动填充功能；而设计不良的表单则会导致交易中途放弃和产生无效记录。由于表单数据属于不可信输入，必须在服务器端进行验证并安全处理，而对所提交个人信息的保护则将本主题与数据隐私问题联系在一起。

欧洲核子研究中心的起源（1989–1991）

HTML 的起源可以追溯到蒂姆·伯纳斯-李在欧洲粒子物理实验室（位于日内瓦，即欧洲核子研究中心，CERN）的工作。1980年，他以合同工身份在那里工作时编写了 ENQUIRE，这是一个笔记本程序，可以让他把任意信息节点链接起来。每个节点都有标题、类型，以及一组带类型的双向链接。ENQUIRE 从未公开发布，但它为万维网提供了概念基础。它要解决的是一个实际问题：来自许多国家的物理学家来到欧洲核子研究中心后，使用的计算机和演示软件互不兼容，他们的信息分散在各自独立的数据库中，无法相互连接。

1989年3月，伯纳斯-李分发了一份题为*《信息管理：一个提案》的文件，主张建立一个基于互联网的超文本系统。它的反响平淡，管理层几乎没有表现出兴趣。1990年5月该文件被再次传阅，同年10月在部门管理层的鼓励下重新修订，罗伯特·卡约（Robert Cailliau）成为共同作者。1990年11月，两人正式提交了一份管理层提案，题为《万维网：超文本项目提案》*，申请组建一个为期六个月的小型团队。管理层只在较低级别上支持这一项目，但伯纳斯-李的上司迈克·森德尔（Mike Sendall）鼓励他在新购入的 NeXT 工作站上构建试验性实现。提案把设想中的系统分为浏览器和服务器两部分，二者通过标准化协议通信；提案还明确将版权执行和数据安全排除在范围之外，因为欧洲核子研究中心的文化建立在信息自由交流的基础之上。

到1990年底，NeXT 机器上已经具备了核心组件：标记格式（HTML）、URL 方案、早期版本的 HTTP、第一个浏览器和第一个服务器，服务器运行在地址 info.cern.ch 上。这个名为 WorldWideWeb 的浏览器同时也是一个编辑器。它是一款“所见即所得”的程序，允许直接在页面中创建链接，体现了伯纳斯-李最初的目标：万维网应当支持创作和个人信息组织，而不仅仅是阅读。已知最早的 HTML 文档注明日期为1990年12月3日。卡约负责项目的组织和推广工作，而第一个网页本身就是对该项目的介绍，这使得早期的万维网在很大程度上具有自我说明的特点。

该语言的首次公开说明是一份题为“HTML 标签”的文档，于1991年底放在欧洲核子研究中心的服务器上；Web Design Museum 将其日期定为1991年10月29日。文档描述了最初的十八个标签，其中包括 title、a（锚点）、p、h1 至 h6、address、列表元素 ul、li、dl、dt 和 dd，以及 menu 和 dir。除超链接标签外，这些元素大多深受 SGMLguid 的影响。SGMLguid 是欧洲核子研究中心内部使用的一种基于 SGML 的文档格式。最初的元素中，有十一个在 HTML 4 中仍然存在。

早期设计更重视简洁性和科学文档的共享，而非视觉排版。其目标是一种可在任何计算机上显示的通用格式，每个元素具体如何呈现由浏览器决定。标题、段落、列表和链接描述的是文本“是什么”，而不是它“应该如何呈现”。这一选择契合了物理学家交换报告和数据的需要，后来成为该标准所追求的结构与表现相分离的理论基础。极简的词汇表也使这门语言易于学习和实现，这在伯纳斯-李与卡约公开发布软件之后，帮助网络迅速发展起来。

早期标准与浏览器时代（1993–1997）

HTML的正式标准化工作从CERN转入了互联网标准制定流程。1993至1995年间，相关文档由IETF公开发布，最早于1993年6月作为互联网草案（Internet Draft）发布。1994年，互联网工程任务组（IETF）成立了HTML工作组，该工作组发布了多份HTML规范的互联网草案。最终成果是RFC 1866，由IETF的HTML工作组编写、Dan Connolly编辑，于1995年11月发布，称为"HTML 2.0"。

RFC 1866将HTML描述为一种用于创建与平台无关的超文本文档的简单标记语言。HTML文档是具有通用语义的SGML文档，因此该语言是依据SGML定义的，而不是作为独立的语法存在。其声明的适用范围相当广泛，涵盖超文本新闻、邮件、文档和超媒体、选项菜单以及数据库查询结果等。该规范大致对应1994年6月之前常用的HTML功能，因此它是对既有实践的规范化总结，而非设计新的体系。它对表现形式的支持极为有限：允许通过LINK元素将外部样式表与文档关联，但本身并未定义样式。

此后，标准的主导权发生了转移。IETF的HTML工作组于1995年12月解散，W3C成为HTML标准化的主要承担者。W3C成立于1994年10月，伯纳斯-李担任主任。其第一份HTML规范HTML 3.2于1997年1月作为W3C推荐标准（W3C Recommendation）发布。该规范是与业界参与者共同制定的，W3C后来指出，HTML 3.2是与IBM、微软、Netscape Communications Corporation、Novell、SoftQuad、Spyglass和Sun Microsystems等厂商共同开发的。工作组在1996年的目标是将通行做法规范化，也就是把浏览器中已在使用的功能写入标准。HTML 3.2新增了表格、applet、图片周围的文字环绕以及上标和下标等功能。此前一份雄心勃勃得多的HTML 3.0草案曾于1995年流传，但并未成为标准的基础。

浏览器厂商之间的竞争，尤其是Netscape与微软之间的竞争，使HTML同时朝多个方向发展。在标准跟上之前，各厂商为满足客户需求，纷纷引入了非标准的元素和属性，例如Netscape的blink及与字体相关的标记，以及微软的marquee。依赖这些功能的页面只能在某一种浏览器中正常显示，厂商实践与已发布规范之间的差距导致了兼容性问题，并持续多年。此后为定义HTML解析和错误处理方式所做的大量工作，在很大程度上可以看作是对这一时期的回应。

HTML 4.0于1997年12月18日成为W3C推荐标准。它通过样式表、脚本、框架和嵌入对象等机制扩展了HTML，改进了对从右到左书写及混合方向文本的支持，增强了表格功能，并改进了表单，从而为残障人士提供了更好的无障碍访问能力。

在这一时期，将表现与结构分离成为了明确的目标。样式表此前已有人提出：1994年10月，Håkon Lie提出了层叠样式表（cascading style sheets）的语法方案，旨在将HTML内容的样式指令与其语义结构分开。在样式表被广泛使用之前，HTML 3.2包含了许多用于控制对齐、字号和文字颜色的元素与属性。作者还常借助表格和图片来进行页面布局。HTML 4.0将此视为一个问题：其开发者表示，更好地区分文档结构与表现形式是首要任务，并鼓励作者使用样式表而非表现性元素。规范解释说，样式表可以简化HTML标记，并在很大程度上使HTML不再承担表现形式的职责。因此，W3C表示将逐步淘汰HTML中的许多表现性元素和属性，并将这些功能标记为"已弃用"（deprecated）。这一政策影响了后续版本的设计。

XHTML与XML转向（1998–2009）

将HTML重新表述为XML

1998年，W3C的HTML工作组开始在XML 1.0的基础上重构HTML。XML 1.0是W3C于1998年2月发布的推荐标准。其第一个成果XHTML 1.0于2000年1月26日成为W3C推荐标准。它被定义为以XML应用形式对HTML 4的重新表述，并提供了与HTML 4的严格型、过渡型和框架型相对应的三种文档类型。其目标是让现有页面在浏览器中继续正常显示，同时使文档能够被XML工具（如XSLT转换和CSS样式）以及将文档作为DOM树进行处理的程序所使用。该规范还包含兼容性指南，说明如何编写当前浏览器仍能正确显示的XHTML。

这一转向的动机部分来自技术层面。浏览器长期以来容忍标记错误，而为纠正这些错误所需的额外代码造成了性能问题，在小型设备上尤为明显。HTML 4名义上是SGML的一种应用，但SGML较为复杂，浏览器和HTML 4规范都未能完全遵循它。XML则提供了一种更简单的底层语法，服务器可以更方便地生成和转换这种语法，以适配移动电话及其他设备。因此，XHTML是一种押注：严格定义的语法将使网络更加可预测。

模块化与XHTML Basic

在核心语言之外，工作组还发展了模块化机制。XHTML Basic于2000年12月成为W3C推荐标准，它为电话、寻呼机和电视等设备挑选了一组最小的模块。《XHTML模块化》于2001年4月10日作为推荐标准发布，它将XHTML 1.0拆分为可以组合、裁剪或扩展的抽象模块。基于这些模块构建的XHTML 1.1则于2001年5月31日发布。其意图是，像移动通信这样的行业可以通过去掉表格或框架等功能，并加入来自其他XML命名空间的词汇，来定义属于自己的XHTML变体。

实际上，这一机制要求很高。通过DTD扩展模块需要大量参数实体工作，因此这些模块后来改用XML Schema重新表达，2010年又出现了RelaxNG版本。以这种方式使语言具备可扩展性的尝试，预示了XHTML 2.0更为宏大的目标。

严格解析与推广难题

XML要求每个元素都必须闭合，属性必须加引号，文档必须格式良好。符合规范的XML处理器应在遇到第一个格式错误时停止，而不是猜测作者的意图。浏览器则恰恰相反，它们接受作者多年来习惯编写的宽松“标签汤”式代码。这使作者陷入两难。如果XHTML以text/html类型发送，浏览器会按HTML处理，严格性随之丧失。如果以application/xhtml+xml发送（RFC 3236将其注册为媒体类型），任何错误都可能导致页面无法显示，而且一些广泛使用的浏览器（包括旧版Internet Explorer）根本不支持该类型。

许多作者、内容管理系统和工具供应商认为这种严格性代价高昂，因此从HTML向XHTML的迁移并未达到W3C预期的规模。结果是，大多数页面即使自称是XHTML，仍然使用HTML语法。

XHTML 2.0与回归HTML

XHTML 2.0本应是更具雄心的后继版本。其首份W3C草案出现于2002年，最后一次更新是在2006年，XHTML2工作组于2007年3月获得章程授权。该设计打破了与XHTML 1.0的兼容性，W3C后来认定这是该项目被放弃的主要原因。2009年7月2日，W3C宣布该工作组的章程将于2009年底到期且不再续期，相关资源将转入HTML工作组，以加快HTML5的进程并明确HTML的未来方向。XHTML2工作组于2010年12月17日正式关闭，XHTML 2.0的草案仅作为工作组笔记发布。XHTML则作为一种序列化形式得以留存：HTML5规范中包含XHTML语法一节，而W3C的XHTML 1.0第二版于2018年被标记为已退役。

WHATWG、HTML5与生存标准（2004年至今）

WHATWG的起源（2004年）

21世纪初，万维网标准组织正转向XHTML，即基于XML的HTML后继版本。2004年6月的一次W3C研讨会上，Opera和Mozilla提交了一份立场文件，建议对HTML进行扩展，并使其与现有浏览器保持兼容。研讨会以投票结束，结果为8票赞成、14票反对，即不继续推进HTML的相关工作。WHATWG邮件列表于2004年6月4日宣布成立，而就在两天前，Opera与Mozilla联合提出的倡议在W3C网络应用与复合文档研讨会上被W3C成员投票否决。随后，Apple、Mozilla和Opera以“超文本应用技术工作组”（Web Hypertext Application Technology Working Group）的名义继续推进这项工作。新工作组的目标是制定更好的HTML规范，以支持新一代网络应用，而且关键在于不破坏向后兼容性。

其规范目标十分具体。WHATWG的一个关键目标是保持向后兼容，以确保现有网站能够正确渲染。另一个目标是让规范足够详尽，使浏览器开发者等实现者无需逆向工程即可实现完全的互操作性。

从HTML5到HTML（2007–2014年）

W3C的HTML工作组后来以WHATWG的成果作为其工作起点。2007年5月9日，W3C新成立的HTML工作组决定如此行事。WHATWG于2008年1月22日发布了第一份公开草案，HTML5也在同一天以面向公众的形式首次发布。2011年1月，WHATWG将其规范由HTML5更名为HTML生存标准（HTML Living Standard）。但W3C仍继续推进发布HTML5的计划。2011年5月，W3C将HTML5推进到“最后征求意见”（Last Call）阶段；2014年10月28日，HTML5正式成为W3C推荐标准（W3C Recommendation）。此后陆续发布了若干快照版本：5.0（2014年）、5.1（2016年）、5.2（2017年）。

2012年的分裂

两个组织于2012年正式分开各自的工作。WHATWG的编辑伊恩·希克森（Ian Hickson）解释说，W3C已将其HTML5内容拆分为多个子规范，而WHATWG曾尝试与之保持相同的结构。结果是规范版本日益混乱，因此WHATWG最终又回到只维护一份规范的做法，这份规范即成为HTML生存标准。希克森表示，两方目标各不相同：WHATWG将专注于制定HTML及相关技术的权威描述，而W3C则会依照其历史悠久的标准流程发布阶段性快照。实际上，双方的分歧部分源于术语之争。2012年，两个团体宣布WHATWG将维护一份生存标准，而W3C则继续发布带版本号的标准。

结果是两者逐渐分道扬镳。2007年时，W3C标准与WHATWG的文本是相同的，此后由于设计决策不同，两者的差异逐步扩大。浏览器厂商通常将WHATWG的文本视为权威参考。一位Mozilla工程师在2014年曾这样描述：“当W3C与WHATWG的HTML规范存在分歧时，我们通常遵循WHATWG的版本。”

生存标准模式

生存标准没有版本号，而是持续修订。其理念是规范永远不会完成，始终处于更新和改进之中。可以添加新功能，但不会移除既有功能。这一模式也改变了新功能进入网络的方式：浏览器开始在官方规范完全定义之前，就以实验性功能的形式实现新元素和API。真实世界的实现经验随后再反馈到规范文本中。

重新趋同

这一分裂最终在实践中得到了扭转。根据2019年5月签署的一份谅解备忘录，WHATWG将维护HTML和DOM生存标准，而W3C则将直接在WHATWG的代码仓库中推动社区工作。W3C将停止发布其指定的规范列表，并致力于把WHATWG的评审草案（Review Drafts）推进为W3C推荐标准。依此安排，WHATWG的文本成为HTML的主要来源，而W3C则继续为其快照版本背书。

解析与错误处理

将提供的文档转换为 DOM 树分两个阶段完成。输入是一串码点，先经过分词阶段，再进入树构建阶段。分词器读取字符并将其组合为记号（token），树构建器消费这些记号，生成 Document 对象。分词器由状态机驱动，据一种说法，其状态数为 80 个。记号可归为少数几类：文档类型声明、开始标签和结束标签、注释、字符数据以及文件结束标记。

两个阶段紧密耦合。记号一经发出，必须立即由树构建阶段处理。树构建器依据当前的插入模式应用相应规则，因此同一个记号在解析器所处的文档位置不同，处理方式也可能不同。构建器还维护一个打开元素栈，用于自动修正错误，既能关闭作者遗漏未关的元素，也能插入作者隐含的元素。它还可以改变分词器读取输入的方式：当树构建器遇到某些开始标签记号时，会将分词器切换到类文本模式。例如 title、textarea（RCDATA），以及 style、xmp、iframe、noembed、noframes、noscript（若启用了脚本）（RAWTEXT）等。

脚本带来了进一步的依赖。脚本可以在解析期间调用 <code>document.write</code>，插入的标记必须由分词器接着读取，因此规范会跟踪脚本嵌套层级和解析器暂停标志。树构建阶段是可重入的，也就是说，在处理某个记号的同时，分词器可能会被恢复运行。解析完成之后，树也并未冻结：脚本仍可实时修改树，这正是 JavaScript 之后改动文档对象模型（DOM）的途径。

规范把解析错误视为解析过程中的正常组成部分，而非停止解析的理由。无论 HTML 文档在语法上是否正确，规范都为其定义了解析规则。用户代理既可以应用规范定义的恢复行为，也可以在遇到其不愿套用规则的错误时，于第一处此类错误处中止处理。一致性检查器的职责则不同：若文档中存在一个或多个解析错误情况，它必须至少向用户报告其中一个，但无需从解析错误中恢复。恢复规则的目的在于一致性。由于规则是固定的，HTML 解析器比 SGML 或 XML 解析器更完备、更具确定性。字节层面的问题也遵循同样的模式：无法转换为 Unicode 码点的字节或字节序列，必须转换为 U+FFFD REPLACEMENT CHARACTER（替换字符）。

这种一致性是对历史的回应。SGML 同样没有规定任何错误处理行为，与此同时，网络内容往往格式不规范，各浏览器也发展出了各自的容错习惯。结果便是人们常说的标签汤，即每个浏览器都以不同的方式修正这些错误。

与 XML 的对比解释了 HTML 为何保留宽容的语法。XML 发布于 1997 年，它规定所有处理 XML 的程序都必须将所谓的“良构性”错误视为致命错误，XML 处理器需报告此类错误并停止正常处理。XHTML 将这一模型引入网络，以 XML 方式提供 XHTML 的浏览器也必须遵循它。代价是：尽管浏览器同意执行这种严苛的错误处理，却导致大量空白错误页面的出现。链接 <code>href</code> 中一个未转义的和号（&）就足以使页面无法渲染。因此，HTML 保留了宽容的解析模型，被视为一种拥有独立解析规则的语言，而非 XML 的方言。

对作者而言，实际影响是：浏览器的容错往往掩盖了错误，而非将其报告出来。验证和代码检查是在标记到达浏览器之前发现格式错误的工具。解析算法定义了标记损坏时浏览器的显示结果，正是这一定义使同一个损坏的页面在不同引擎中往往呈现相同的样子。

与 CSS、JavaScript 和 DOM 的集成

文档对象模型

当浏览器收到一个 HTML 文件时，会将字节流转换为内存中的对象树，即文档对象模型（DOM）。每个元素、属性和文本片段都会成为一个节点。页面加载完成后，脚本不再读取源代码中的标记，而是查询和修改这棵树，例如通过 ID 查找元素、更改其文本或插入新节点。渲染引擎随后将这棵树与 CSS 规则计算出的样式结合起来，生成可见的页面。由于 DOM 是文档的实时状态，脚本所做的更改无需重新加载文件即可在屏幕上体现，而原始 HTML 源代码保持不变。定义 HTML 的标准同时也定义了 DOM 的结构，因此标记、树状结构和脚本接口是同一份文档的三种视图。

script 与 style 元素及加载顺序

JavaScript 的 script 元素是 HTML 将控制权交给代码的主要方式，其加载行为是影响页面性能最关键的细节之一。默认情况下，经典脚本会阻塞 HTML 解析器：浏览器需要时先下载外部文件，执行脚本，然后才继续构建树。原因在于脚本可能会写入文档，因此解析器无法安全地提前工作。此后，浏览器加入了预解析（speculative parsing），可以提前扫描需要获取的资源，但内联脚本仍会中断主解析过程。

async 和 defer 属性以不同方式放宽了这一限制。async 脚本会并行下载，并在下载完成后立即执行，这可能发生在解析结束之前，且执行顺序与文档顺序不一致；它适用于相互独立的脚本，例如统计分析代码。defer 脚本同样并行下载，但要等到解析完成后才执行，多个延迟脚本按其在文档中出现的顺序执行。模块脚本默认为延迟执行。这两个属性对没有 src 的内联脚本都不起作用。

样式表也会影响这一流程。指向样式表的 link 不会阻止解析器构建 DOM，但会阻塞渲染；位于样式表之后的脚本必须等待该样式表可用，因为脚本可能会读取计算后的样式。因此，在页面的 head 中放置普通脚本可能会推迟首次可见绘制的时间。

通过 HTML 暴露的 Web API

用户在网络应用中体验到的许多功能，都是通过 HTML 元素或附加在文档和 window 上的接口实现的。canvas 元素提供了一个绘图表面，脚本可以获取其 2D 渲染上下文并向其发出绘图命令，同一表面的内容也可以导出为图像数据。Web Storage API 提供两种键值存储：localStorage 按源（origin）隔离，关闭浏览器后数据仍然保留；sessionStorage 则限定在单个标签页和页面会话内。History API 允许脚本在不完整重新加载的情况下修改单页应用的 URL 和导航状态。这些 API 分别定义在不同的规范中，但同属 Web 平台的一部分，并受与文档其他部分相同的源和权限规则约束。

自定义元素、Shadow DOM 与模板

HTML 的组件模型建立在三项标准之上。template 元素中的标记会被解析器存储，但不会渲染或执行；需要时，脚本可以克隆其内容。自定义元素允许开发者将新的元素类型定义为继承 HTMLElement 的 JavaScript 类，并通过 customElements.define 注册；按照约定，名称必须包含连字符，以便与内置元素区分。Shadow DOM 将一个封装的子树附加到元素上，使组件的内部结构和 CSS 不会泄漏到周围页面，也不会受其影响；slot 元素则控制外部的 light DOM 子节点在该子树中的放置位置。两者结合，便能提供独立、可复用、行为接近内置元素的组件。较新的浏览器还支持声明式 Shadow DOM：带有 shadowrootmode 属性的 template 元素可以让 HTML 解析器在无需脚本的情况下创建 shadow root，这有助于服务端渲染的组件。封装性也有其局限，尤其是在与 shadow 树共享全局样式表时；并且需要与可访问性相权衡，因为隐藏在 shadow root 中的内容可能会使焦点管理和标签关联变得复杂。

字符编码、语言与元数据

字符编码

浏览器必须先知道如何把HTML文件的字节转换为字符，才能显示内容。作者通常会在 meta 元素中通过 charset 属性声明字符编码，这一声明应放在 head 靠前的位置，以便解析器在遇到任何非 ASCII 文本之前就能看到它。声明的编码与实际编码不一致会导致乱码。典型例子是一个 UTF-8 页面中的德语地名可能显示错误，原因是软件在检测 UTF-8 之前先猜测了另一种编码。

UTF-8 已成为近乎通用的选择。2026年9月，W3Techs 统计显示，在其已知字符编码的所有网站中，UTF-8 占 99.1%，而排名第二的 ISO-8859-1 仅占 0.8%。UTF-8 是对网络最重要的 Unicode统一码 编码形式。它采用一到四个字节的可变长度编码，支持所有有效的 Unicode 码位，使单个 HTML 文档无需切换编码即可同时包含拉丁字母、阿拉伯文、中文、天城文和表情符号。由于它在基本拉丁字符范围内与 ASCII 兼容，仅含 ASCII 的旧内容也依然有效。

语言与方向

lang 属性可以放在任何元素上，用来声明其内容的自然语言。浏览器利用这一信息选择字体、进行断字和拼写检查，辅助技术则用它来选择正确的语音合成声音。语言和方向是两个独立的属性。正如一份指南所指出的，声明语言并不意味着声明方向，反之亦然，因此两者必须分别设置。

dir 属性控制基础文本方向，取值为 ltr、rtl 或 auto。作者通常在 html 标签上设置 dir 属性，若页面为从右到左书写，则将其设为页面默认的基础方向；在需要不同方向的个别块级内容上则单独应用该属性。auto 值适用于事先无法确定方向的内容，例如来自用户输入或外部来源的数据。方向会从父元素继承；若没有任何祖先元素设置方向，默认为从左到右。W3C 的国际化指南建议在 HTML 中使用标记而非 CSS 来控制文本方向，因为 HTML 规范对 dir 属性的预期行为有明确定义。

元数据

元数据元素承载的是不显示在页面上的信息。meta 元素包含供浏览器和搜索引擎使用的信息，而非直接可见的页面内容。带名称的 meta 元素将一个 name 与一个 content 值配对，最常见的名称包括 description、theme-color 和 viewport。谷歌等搜索引擎会利用 description 来调整页面在搜索结果中的显示方式。theme-color 的值则提示浏览器可以采用的颜色，用于定制页面或周围的界面。

viewport 类 meta 元素控制移动设备上的布局。广泛使用的写法 width=device-width, initial-scale=1.0 向浏览器说明如何控制页面的尺寸与缩放。width 值使布局跟随设备屏幕宽度，initial-scale 则设定首次加载时的缩放级别。除非有充分理由，开发者应避免限制用户缩放，因为允许用户缩放有助于无障碍访问，除非有特定的限制要求。

link 元素与 meta 不同，它用于标识与文档相关的资源，例如样式表、图标、其他语言版本以及规范 URL。其 rel 和 hreflang 属性描述了每个资源与页面的关系。

国际化的挑战

混合文字是结构上最为复杂的情况。当文档包含从右到左书写的字符时，用户代理必须应用双向算法来决定各段文本的视觉顺序。只有标记正确，结果才可能正确：包含英文单词的希伯来语句子，只有在双向算法正确处理这些单词时，才会以正确的顺序显示；与基础方向相反的行内短语，则应包裹在自行设定方向的元素中。因此，双向文本规则常常是多语言页面出错的常见来源。

日期、时间和数字也带来类似的问题。HTML 提供了带有机器可读 datetime 属性的 time 元素，使页面可以承载明确的值（例如 ISO 8601 日期），再由浏览器或脚本依据读者的区域设置进行格式化。不同文化中的日期顺序、历法系统、数字字形和小数点符号各不相同，因此通常使用 Intl 等 JavaScript API 来应用区域惯例，而不是硬编码单一格式。

无障碍访问

无障碍访问对HTML很重要，因为大多数辅助技术无法读取页面的视觉呈现效果。屏幕阅读器、盲文显示器、开关设备和语音控制软件都依赖浏览器从网页文档中生成的无障碍功能树（辅助功能树）工作。作者选择的元素在很大程度上决定了这棵树的结构。原生的button自带角色、名称、状态和键盘行为；而一个绑定了点击处理函数的div则一样都没有。因此，语义化标记是实现无障碍访问最经济的方式。

语义化标记与文本替代

真正的标题（h1至h6）、header、nav、main和footer等地标元素，以及规范的列表，能让屏幕阅读器用户在各个区域之间快速跳转、跳过重复的导航，并得知列表包含多少项。非文本内容需要文本替代。img上的alt属性即用于提供这种替代文本，空的alt值则表示装饰性图片，使辅助软件将其跳过。表格需要将表头单元格与对应的数据单元格正确关联，多媒体内容则需要字幕和文字记录。仅依赖颜色或位置等视觉提示的作者，会将无法感知这些提示的用户排除在外。

ARIA与第一条规则

WAI-ARIA是W3C下属无障碍倡议（WAI）制定的规范。它定义了一系列角色、状态和属性，用于描述标签页、树形视图和实时状态消息等动态或自定义界面组件，而原生HTML无法表达这些内容。ARIA只改变辅助技术感知元素的方式，并不会添加键盘处理、焦点行为或样式。该规范的第一条规则是：应优先使用已具备所需语义和行为的原生元素或属性，而不是改造某个元素并额外添加角色。第二条规则是：除非确有必要，不要更改原生语义，例如不应把标题改成标签页。实践中两者的差别十分明显：要让div充当按钮，开发者需要添加role="button"和tabindex，并编写处理Enter键和空格键的脚本；原生button则默认提供这些功能。据一份行业指南引用的2026年WebAIM Million报告显示，使用ARIA的页面平均可检测到的错误数量高于未使用ARIA的页面，这表明ARIA常被错误使用。不过，该结果属于相关性数据，并不能证明因果关系。

键盘访问、焦点与表单标签

原生交互元素无需额外处理即可通过键盘访问，并自带焦点指示器。自定义控件则必须自行实现方向键导航、焦点移动和可见的焦点环。例如，对话框打开时应获得焦点，关闭时应将焦点交还给触发它的控件。每个表单控件都需要一个无障碍名称。常用做法是使用label元素，通过for与id与控件关联，或直接将控件包裹在label中。若无法使用可见标签，则可用aria-label或aria-labelledby提供名称。仅靠占位文本和图标无法提供可靠的名称。控件还必须能在不使用鼠标的情况下操作，这一要求同样适用于与表单相关的脚本组件。

合规的标准与法律依据

《网页内容无障碍指南》（WCAG）是主要的技术参考标准，多个司法辖区的法律都引用了它。美国联邦机构及接受联邦资助的组织受《康复法案》第508条约束，该条款在2017年修订后引用WCAG 2.0的A级和AA级标准。在欧盟，《欧洲无障碍法案》适用于许多数字产品和服务，自2025年6月起执行，它依托EN 301 549标准，而该标准纳入了WCAG 2.1 AA级。美国私营部门的网站则依据《美国残疾人法案》接受评估，美国法院通常以WCAG AA级作为基准。因此，合规既是一项法律义务，也是一项采购条件。自动化检测工具只能发现部分问题，仍需借助辅助技术进行人工测试。社会层面的理由同样直接：无障碍设计使残障人士能够参与教育、就业和公共服务，并缩小数字鸿沟所描述的差距。

安全与隐私

注入与跨站脚本

大多数 HTML 安全问题都始于页面在未经编码的情况下将不可信文本写入标记。如果网站把搜索词或评论直接回显到文档中，攻击者就可以提供包含 script 标签或事件处理属性的片段，浏览器便会以页面的权限执行它。这就是跨站脚本攻击（XSS），十多年来安全研究人员一直将其视为网络上最顽固的威胁之一。反射型、存储型和基于 DOM 的变体在恶意载荷的来源及写入页面的位置上有所不同，但都源于同一个错误：数据被当作标记来解释。通常的防御手段是根据上下文进行输出编码，使尖括号、引号等字符在元素文本、属性值和脚本块中以不同方式转义。开发者还会避免将不可信字符串赋值给会解析 HTML 的属性，并优先使用以文本形式插入内容的 API。

净化用户提交的 HTML

一些应用，如评论系统、维基和富文本编辑器，必须接受用户提供的格式化内容。在这些场景中，输入会经过解析并交由净化器（sanitizer）处理。净化器维护一份安全元素与属性的白名单，并移除其他所有内容，包括 script 元素、事件处理属性以及链接中的危险 URL 协议。净化很容易出错，因为浏览器对格式错误输入的解析行为十分复杂，因此净化器应基于浏览器自身的解析规则构建，而不是依赖正则表达式，并且在出现新属性或新特性时及时更新。出于同样的原因，仅靠服务端过滤也很脆弱，所以通常会与下文所述的策略机制结合使用。

内容安全策略

内容安全策略（CSP）是由 W3C 定义的一种浏览器机制，用于限制页面可以加载和运行哪些资源。它通过 HTTP 响应头下发，策略由以分号分隔的指令组成。最重要的指令是 script-src，它控制外部脚本、内联脚本块、内联事件处理属性、javascript: URL 以及动态求值。例如，将脚本来源限制为页面自身的源，同时将 object-src 和 base-uri 设为 none，即使页面自身的转义失效，也能阻断许多注入途径。主机白名单则不够稳健，因为托管用户内容或宽松 JSONP 接口的白名单域名可能被滥用。更严格的设计则依赖于每次响应的 nonce 或已批准脚本的哈希值，使得只有服务器标记为自身的脚本才能执行。未经此类标记的内联脚本和样式会被阻止，这迫使开发者重构旧代码。CSP 也有 meta 元素形式，但该形式无法表达所有指令，因此对于涉及安全的关键设置，更推荐使用响应头。

框架沙箱与跨源数据控制

iframe 上的 sandbox 属性会对嵌入文档施加限制。空值会应用全部限制，包括唯一的不透明源、禁止脚本、表单提交和弹窗；而以空格分隔的标记，如 allow-scripts 或 allow-same-origin，则可解除特定限制。若对来自父页面同源的内容同时启用 allow-scripts 和 allow-same-origin，实际上等同于没有沙箱，因为嵌入的脚本可以自行移除该属性。W3C 也曾警告，此类组合需要谨慎考量。直接在新标签页中打开同一个不可信文档时，沙箱同样会失效，因此恶意的用户上传内容应当由独立的源提供。Referrer-Policy 响应头与 referrerpolicy 属性控制向其他站点发送多少来源 URL 信息；现代浏览器默认采用 strict-origin-when-cross-origin 策略。rel="noreferrer" 关键字会移除链接的 Referer 头，并隐含 noopener；而当前浏览器中，target="_blank" 的链接已默认隐含 noopener，从而消除了早期的反向钓鱼（reverse tabnabbing）风险。Cross-Origin-Opener-Policy 响应头则提供了一种文档级别的方式，用于隔离浏览上下文组。

隐私考量

安全与隐私相互交织，但并不相同。表单自动填充很方便，但 autocomplete 属性决定了浏览器可以填写哪些字段、应保持哪些字段不动；对于一次性验证码或密码等敏感数据的字段，通常最好明确标注。第三方内容，包括广告脚本、分析代码片段和嵌入式小部件，都可以读取页面上下文，并设置或读取存储；而从第三方服务器获取的每一张图片或样式表，都会暴露访问者的地址，并可能通过 Referer 头泄露其正在浏览的完整 URL。开发者可通过以下方式减少这种暴露：限制 referrer 数据、借助 CSP 限定允许通过的第三方来源、仅在用户请求时才懒加载嵌入内容，以及避免不必要的跨站请求。由于追踪可以通过普通页面资源进行，这些做法也与更广泛的数据保护义务相关联。

一致性、测试与互操作性

对HTML一致性的检查有两种方式：一是使用工具检测单个文档，二是使用共享的测试套件检测浏览器引擎。最知名的文档检测工具是W3C标记验证服务（W3C Markup Validation Service）。2008年11月，W3C发布了validator.nu HTML5引擎，使其能够检查文档是否符合HTML5的一致性要求。当前的检测工具是一款开源的HTML验证器，依据WHATWG维护的HTML活标准（living standard）检查文档。它不止检查语法：还会标记错误的嵌套、已废弃元素的使用以及与无障碍相关的HTML错误。验证器可以证明页面遵循了语法，但无法预测每个引擎会如何渲染该页面。

第二种方式是web-platform-tests（WPT）项目，该项目创立于2010年，旨在测试浏览器对Web标准的符合程度。其测试用例的编写方式使其可以在所有浏览器中运行，这让各浏览器项目能够确信其发布的软件与其他实现相互兼容。该套件规模庞大且持续运行：据原始资料报道，其测试超过56,552项（包含180万个子测试），其基础设施每天都会在所有主要浏览器引擎的最新版本上运行这些测试。就HTML标准而言，W3C指出，HTML5推荐标准的完整测试套件作为WPT项目的一部分被持续维护并保持更新。

每一个W3C HTML版本发布时还附有一份实现报告。例如，HTML 5.2报告概述了HTML 5.1至HTML 5.2之间新增功能的已知实现情况，并附有逐项功能的支持情况表，涵盖Blink、Gecko、Edge、Internet Explorer和WebKit。其声明的目的是证明已具备足够的互操作性，以支持HTML 5.2从候选推荐标准（Candidate Recommendation）进入下一阶段；该报告也并未预计会在2017年10月之后更新。这些表格也揭示了理想行为与实际行为之间的差距。例如，在HTML 5.1报告中，<input type="month"> 在Chrome、Yandex和Edge中获得支持，但在Firefox和Safari中被标记为不支持。许多单元格还被标为未知，因此这些表格衡量的是已测试的内容，而非标准所要求的内容。

测试套件的结果也可能被误读。2010年，W3C内部的HTML5测试结果被复制到一个公开网站上，媒体将其视为某一厂商在HTML5合规性方面处于领先的证据。一位Opera工程师回应称：“该测试套件极不完整。”这一事件表明，测试套件的得分反映的是其覆盖范围，而非完全合规。浏览器在处理无效标记时也存在差异：遇到无效的HTML时，浏览器会采用错误恢复算法，而不同引擎对同一段标记可能会有不同的解读。

厂商之间的协调通过多种渠道进行。WPT通过征求意见（Request for Comment，RFC）流程，在浏览器工程团队之间就测试套件的变更和治理模式形成共识；无法通过该流程解决的分歧将上报至核心团队（Core Team）。Interop项目定义了一套基于一组Web技术的指标，并利用自动化测试来衡量每个参与的浏览器在实现共同目标方面取得了多大进展。W3C浏览器测试与工具工作组则采用了一条并行规则：凡对候选推荐标准中的规范或已有实际实现的功能所做的任何修改，都必须附带测试。这些机制共同作用，逐步将标准的理想行为转化为可互操作的浏览器行为。

相关格式、生态与实际用途

HTML 属于标记语言家族，它的语法随着同类语言的发展而变化。HTML 源自 SGML，即最早的版本所遵循的文档标准。HTML5 标准已不再被视为 SGML 的应用，而是定义了自己的语法。HTML5 可以用两种序列化形式书写：一种是以 text/html 提供的 HTML 形式，另一种是以 application/xhtml+xml 提供的 XML 形式。后者通常被称为 XHTML5。在大多数情况下，两种序列化形式都能表示同一份文档，但各自都有局限。HTML 形式不能在某些父元素中嵌套某些结构化的行内元素，而 XML 形式则无法表示 HTML 错误恢复机制可能生成的所有树结构。浏览器根据 MIME 类型而非 DOCTYPE 选择解析模式，因此仅有 XHTML 1.0 的 DOCTYPE 并不能使文档成为 XHTML。

出版业是 HTML 词汇最大的实际使用者之一。EPUB 3 是广泛使用的电子书格式，基于 HTML5、CSS 和 JavaScript，其内容文档可以使用 HTML5 元素。然而，EPUB 3 规范只接受 XML 序列化形式，因此电子书内容实际上是 XHTML。这说明了在 HTML 与 XHTML 之间的选择，如何影响真实的工具和读者。

网络上的大多数 HTML 并非手工编写。模板系统将数据插入 HTML 骨架之中，Web 框架和内容管理系统则在服务器端或浏览器中生成页面。Markdown 标记语言 等轻量级语言让作者可以用简单的标点符号书写文本，再由转换器将其转为 HTML。静态站点生成器则提前对整个站点执行这一过程，使服务器直接交付已完成的文件。HTML 也出现在电子邮件中，邮件客户端只支持该语言的一个子集；此外，在一些文档生成流程中，HTML 模板被用来生成报告或发票。

HTML 也已进入桌面和移动设备领域。Electron 是一个使用 JavaScript、HTML 和 CSS 构建桌面应用程序的框架。它内嵌了 Chromium 渲染引擎和 Node.js 运行时，因此同一套代码可以面向 微软 Windows、macOS 和 Linux 发布。多款广泛使用的桌面程序，例如 Visual Studio Code 和 Slack，都是以这种方式构建的。Electron 应用将工作分配给主进程和渲染进程：主进程使用 JavaScript 运行，可以访问系统资源；渲染进程则负责显示 HTML 页面。移动应用采用的思路与此类似，它们通过嵌入式网页视图，在 智能手机 的原生应用外壳中渲染 HTML。这类应用可以与网站共享大部分界面代码，但应用的安装、更新以及对设备功能的访问，仍然由原生外壳决定。

这些用途表明，HTML 已不再局限于网页。它的文档模型、通过 CSS 实现的样式设计，以及通过 JavaScript 实现的脚本功能，如今已构成一个通用基础，支撑着通过浏览器、阅读器、邮件客户端和桌面窗口触达用户的各类软件。

争议与未决问题

最持久的争论围绕"活标准"模式本身展开。自2011年起，WHATWG 便以无版本号的方式维护 HTML，持续不断地添加新功能；而 W3C 则发布带版本号的快照。支持者认为，这种做法更符合浏览器实际发布功能的方式，也避免了以往那种漫长的版本间隔——正是那种间隔催生了作为"最终目标"的 HTML5。批评者则指出，一份不断变动的文本让学校、测评机构、采购人员和工具厂商很难明确一份文档应遵循的语言版本。分歧还源于二者对目的的不同理解。两个组织曾经共用同一份源文档，但 W3C 希望推出一个"定型"的 HTML5，而 WHATWG 则优先考虑持续的修复与功能演进。如今，W3C 大约每年依据 WHATWG 的文本发布一次推荐标准，这只在一定程度上调和了两种模式：一项合规声明仍须注明它所指的是哪一个快照、哪一个日期。

治理问题是第二个争议焦点。WHATWG 的指导委员会（Steering Group）由苹果、谷歌、微软和 Mozilla 组成，这四家公司分别是主流浏览器引擎的背后推手；每份规范的编辑决定哪些内容进入文本，有争议时则交由该委员会裁决。批评者看到的是结构性的集中：实现 HTML 的公司同时也掌控着它的演进，这可能使那些对大型引擎团队而言成本低廉的功能更受青睐，而拖慢外部提案的采纳。支持者则回应说，整个流程是公开的，主要在 GitHub 上进行，并且在2017年专门制定了正式的知识产权政策，以便包括微软在内的更多组织能够平等地参与贡献。对于这种开放程度是否足以满足独立研究者、无障碍倡导者和小型项目的需求，目前仍有争论；由于绝大多数参与者本身受雇于各大浏览器厂商，这一问题更难给出明确答案。

第三个争论涉及范围：HTML 应当继续作为文档语言，还是应不断吸收应用层面的行为？在过去十年中，该规范纳入了许多曾经属于脚本或插件范畴的功能，包括 canvas、媒体播放、拖放、存储、自定义元素、popover 机制以及声明式影子根（declarative shadow roots）等。支持者将此视为浏览器成为应用平台的必然结果，并指出一个声明式、标准化的核心可以减少对庞大 JavaScript 框架的依赖，同时改善性能与无障碍性。批评者则担心，这门语言正变成一个庞大而机制重叠的运行时，其描述文档的原初角色正在被稀释，而每一项新增功能都会扩大实现者与作者必须掌握的范围。这种张力在实践中清晰可见：一项声明式功能可以取代某个依赖脚本的控件，但前提是各浏览器对其细节达成一致。

最后，标准本身的复杂性也带来了自身的问题。规范涵盖解析、DOM、渲染钩子、安全策略、无障碍语义以及大量 API，其庞大的体量使得准确实现的成本很高。这提高了构建一款全新独立浏览器引擎的门槛，使得少数几个引擎体系实际上决定了该标准的实际行为。互操作性工作既展示了协调的价值，也暴露了其局限。在 Interop 项目中，所选 web 平台测试的总体通过率从2025年初的约29%提升到年底的97%；然而，组织者也注意到，较高的测试分数仍可能与各浏览器之间存在差异的行为并存。与此同时，无障碍方面的缺口依然存在：尽管原生元素已提供了大部分所需行为，作者自行构建的许多交互组件仍然不具备无障碍性。因此，如何在稳定性与持续变化之间、在开放性与引擎厂商的影响力之间、在广度与简洁性之间权衡，仍是悬而未决的问题，而这些问题的答案将塑造网络的未来发展方向。

参考来源

  1. HTML Standardhtml.spec.whatwg.org
  2. HTMLen.wikipedia.org
  3. Hypertext Markup Language - 2.0w3.org
  4. MIME TEXT/HTMLmimes.info
  5. What is the MIME Type?reqbin.com
  6. MIME Types - HTML5: Up and Running [Book]oreilly.com
  7. 13 The HTML syntaxhtml.spec.whatwg.org
  8. Void element - Glossary - MDN Web Docs - Mozilladeveloper.mozilla.org
  9. Void elementdeveloper.mozilla.org
  10. HTML Standardhtml.spec.whatwg.org
  11. HTML content categories - Max Designmaxdesign.com.au
  12. HTML Content Model Categories - Max Designrussmaxdesign.github.io
  13. HTML Standardhtml.spec.whatwg.org
  14. 3-8: Introducing HTML5 footer, header, nav, article, section and aside elementscellbiol.com
  15. <h1>–<h6> HTML section heading elements - MDN Web Docsdeveloper.mozilla.org
  16. Tables for Layout? Absurd. - The History of the Webthehistoryoftheweb.com
  17. The History of HTML Table Layouts - Posts by Eli (@Tarwn)tiernok.com
  18. show bugw3.org
  19. Layout Tables - Accessible Publishing Knowledge Basekb.daisy.org
  20. Content categories - HTML - MDN Web Docs - Mozilladeveloper.mozilla.org
  21. Phrasing contenthtml.spec.whatwg.org
  22. semantic html sectioning elements 7a4428ac74b9medium.com
  23. HTML Main, Section & Article Tagsunwiredlearning.com
  24. Table/layout TABLE deprecation - HTML accessibility task force Wikiw3.org
  25. Table Like It's 2023 - HTMHellhtmhell.dev
  26. [html5] r6006 - [e] (0) apply wg decision Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=10963lists.whatwg.org
  27. [Bug 8745] Deprecation of the use of TABLE for Layoutlists.w3.org
  28. Using responsive images in HTML - MDN Web Docsdeveloper.mozilla.org
  29. Responsive Images in HTML: srcset, sizes & picturestudiolimb.com
  30. Responsive Images - A Reference Guide from A to Zimagekit.io
  31. <iframe> HTML inline frame element - MDN Web Docsdeveloper.mozilla.org
  32. How to Safeguard Your Site with HTML5 Sandbox — SitePointsitepoint.com
  33. HTML links · WebPlatform Docswebplatform.github.io
  34. URI fragmenten.wikipedia.org
  35. Links in HTML documentsw3.org
  36. HTML form methoddofactory.com
  37. <form> HTML form element - MDN Web Docs - Mozilladeveloper.mozilla.org
  38. HTML Form Action: POST and GET (With Examples)programiz.com
  39. HTML form method Attributew3schools.com
  40. HTML input formmethod Attributew3schools.com
  41. What Form Method Tells Your Web Browser In HTMLhtml.com
  42. GET vs POST - Difference and Comparisondiffen.com
  43. HTML5 Form Validation — SitePointsitepoint.com
  44. Mastering Form Validation with HTML and JavaScriptcodesignal.com
  45. <input type="number"> HTML attribute value - MDN Web Docsdeveloper.mozilla.org
  46. HTML Form Input Types and Validation - DEV Communitydev.to
  47. HTML5 Form Validation: Using required, pattern, min/max, and type="email"codyxz.com
  48. DEV Communitydev.to
  49. HTML input type Attributewww-db.deis.unibo.it
  50. Runnable HTML Docs: Input Typescoddy.tech
  51. <input> HTML input element - HTML - MDN Web Docs - Mozilladeveloper.mozilla.org
  52. Datalist with input type colorcodepen.io
  53. The Ultimate Guide to Implementing HTML Datalistdhiwise.com
  54. Tim Berners-Lee published a document called HTML Tags - Web Design Museumwebdesignmuseum.org
  55. Introduction to HTML by Help@Learnfullearnful.ca
  56. A Little History of the World Wide Webw3.org
  57. Web History Primerw3.org
  58. The birth of the World Wide Webtimeline.web.cern.ch
  59. A short history of the Webhome.cern
  60. The birth of the World Wide Web — Google Arts & Cultureartsandculture.google.com
  61. Hivertech - History of the World Wide Webhivertechbd.com
  62. Tim Berners-Lee Proposes an Internet-Based Hypertext ...historyofinformation.com
  63. Computer History Museumcomputerhistory.org
  64. History of HTML: From 1991 to the Living Standard - HTML Bloghtmlblog.net
  65. HyperText Markup Language (HTML) Format Familyloc.gov
  66. Sustainability of Digital Formats: Planning for Library of Congress Collectionsloc.gov
  67. html specw3.org
  68. HyperText Markup Language (HTML) 3.2loc.gov
  69. www.w3.orgw3.org
  70. HTML 4.01w3.org
  71. The World Wide Web Consortium Issues HTML 4.0 as a W3C Recommendationw3.org
  72. HTML 4.01 Specification W3C Proposed Recommendation This version:w3.org
  73. REC-html40-19980424 HTML 4.0 Specificationw3.org
  74. HyperText Markup Language (HTML) 2.0loc.gov
  75. RFC 1866 - Hypertext Markup Language - 2.0datatracker.ietf.org
  76. World Wide Web Consortium Issues XHTML 1.0 as a Recommendationw3.org
  77. World Wide Web Consortium Issues XHTML Basic as a W3C Recommendationw3.org
  78. Extensible HyperText Markup Language (XHTML), 1.0loc.gov
  79. W3C Issues XHTML 1.0 as a Recommendationgilbane.com
  80. XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition) publication historyw3.org
  81. World Wide Web Consortium Issues XHTML 1.0 as a Recommendationw3.org
  82. 61. Create and Validate an XHTML 1.0 Document - XML Hacks [Book]oreilly.com
  83. ko:HTML to XHTML « WordPress Codexcodex.wordpress.org
  84. W3C XHTML2 Working Group Home Pagew3.org
  85. Jeffrey Zeldman Presents - XHTML DOA WTF -zeldman.com
  86. RIP XHTML 2 — SitePointsitepoint.com
  87. HTML Working Groupen.wikipedia.org
  88. Frequently Asked Questions (FAQ) about the future of XHTMLw3.org
  89. XHTML 2 Working Group Expected to Stop Work End of 2009, W3C to Increase Resources on HTML 5w3.org
  90. The mission of the XHTML2 Working Group is to fulfill the promise of XML forw3.org
  91. Modularization of XHTML - Introductionw3.org
  92. RFC 3236 The 'application/xhtml+xml' Media Typeietf.org
  93. XHTML™ Modularization 1.1 - Norman Walshnorman.walsh.name
  94. Extensible HyperText Markup Language (XHTML) 1.1loc.gov
  95. Extending the Web: XHTML Modularizationxml.com
  96. Mix and Match Markup: XHTML Modularizationxml.com
  97. An Overview of XHTML - XHTML 1.1: Modularizationbrainkart.com
  98. Working Draft: Modularization of XHTML 1.0 - Second Editionw3.org
  99. xhtml m12n schemaw3.org
  100. HTML5en.wikipedia.org
  101. WHATWGen.wikipedia.org
  102. The history of the Web - W3C Wikiw3.org
  103. HyperText Markup Language (HTML) 5loc.gov
  104. HTML5 - Wikiwandwikiwand.com
  105. [whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification from Ian Hickson on 2012-07-19 (public-whatwg-archive@w3.org from July 2012)lists.w3.org
  106. A Tale of Two Standards - The History of the Webthehistoryoftheweb.com
  107. Go away, kid, you bother me: Apple, Google, Microsoft, Mozilla kick W3C nerds to the curb • The Registertheregister.com
  108. W3C and WHATWG to collaborate on single HTML and DOM specifications - SD Timessdtimes.com
  109. W3C? WHATWG? Standards?. What is W3C and WHATWG?medium.com
  110. 13.2 Parsing HTML documentshtml.spec.whatwg.org
  111. Deep Dive: Understanding the HTML Parsing State Machine and DOM Memory Architecture • Dev|Journalearezki.com
  112. 8.2.4 Tokenization — HTML5w3.org
  113. The HTML parser - Idiosyncrasies of the HTML parserhtmlparser.info
  114. HTML Parsing Algorithm and Memory Structure - DEV Communitydev.to
  115. 8.2 Parsing HTML documents — HTML5w3.org
  116. Six common HTML myths.fluffyandflakey.blog
  117. Read Idiosyncrasies of the HTML parserleanpub.com
  118. From HTML to HTML (via HTML) - Thymeleafthymeleaf.org
  119. Everything You Know About XHTML Is Wrong - HTML5: Up and Running [Book]oreilly.com
  120. Automatically detecting the ability to execute processing logic after a parser or validation errorimage-ppubs.uspto.gov
  121. 8.2 Parsing HTML documents — HTML5w3.org
  122. tree constructionw3.org
  123. GitHub - novolang/html-nv: Tolerant HTML5: the tokenizer as the specification writes it, a flat-arena tree over the caller's source with a NAMED — NOT IMPLEMENTED: published as its interfacegithub.com
  124. Bruce Lawson's personal site : XML on the Webbrucelawson.co.uk
  125. XHTML and error handling - Robert's talkrobertnyman.com
  126. Mastering XML Syntax: Rules and Best Practices - LIS (Library & Information Science) Academylis.academy
  127. Building the DOM faster: speculative parsing, async, defer and preloadhacks.mozilla.org
  128. Let’s stop labelling asynchronous JavaScript as non-blocking! - Fasterizefasterize.com
  129. <script> HTML script element - HTML - MDN Web Docsdeveloper.mozilla.org
  130. Does CSS Block Parsing and Rendering? A Detailed Analysis - DEV Communitydev.to
  131. HTML Standardhtml.spec.whatwg.org
  132. Declarative Shadow DOMweb.dev
  133. Template, slot, and shadowweb.dev
  134. Shadow DOM v1 - Self-Contained Web Componentsweb.dev
  135. Web Components - Web APIs - MDN Web Docs - Mozilladeveloper.mozilla.org
  136. <template>: The Content Template elementdeveloper.mozilla.org
  137. Web Storage API - MDN Web Docs - Mozilladeveloper.mozilla.org
  138. Using the Web Storage API - Web APIs - MDN Web Docsdeveloper.mozilla.org
  139. Draw and Save HTML Canvas to LocalStoragecodepen.io
  140. HTML: <meta> tagtechonthenet.com
  141. Charset detectionen.wikipedia.org
  142. Usage Statistics and Market Share of Character Encodings for Websites, September 2026w3techs.com
  143. UTF-8en.wikipedia.org
  144. HTMLcodecademy.com
  145. Creating HTML Pages in Arabic, Hebrew and Other Right-to-left Scripts (tutorial)w3.org
  146. dir HTML global attribute - MDN Web Docs - Mozilladeveloper.mozilla.org
  147. Internationalization Best Practices: Handling Right-to-left Scripts in XHTML and HTML Content -- (Editors' copy)w3.org
  148. <meta> name attributedeveloper.mozilla.org
  149. HTML meta name Attributew3schools.com
  150. How to Configure the Viewport Meta Tag - OneNineonenine.com
  151. 8 Language information and text directionw3.org
  152. Popularity of text encodingsen.wikipedia.org
  153. HTML meta tagw3schools.com
  154. <meta name="viewport"> HTML attribute value - MDN Web Docsdeveloper.mozilla.org
  155. Metadataweb.dev
  156. Semantic HTML and ARIAprimer.style
  157. WAI‑ARIA Guidance: Best Practices for Accessible Web Interfaceslevelaccess.com
  158. Using ARIAw3.org
  159. ARIA - Accessibility - MDN Web Docs - Mozilladeveloper.mozilla.org
  160. WAI‑ARIA Explained: A Guide to Accessible Rich Internet Applicationslevelaccess.com
  161. Section 508 Compliance: Why Should it Matter to You? - WCAGwcag.com
  162. What Is Section 508? A Quick Guide to Section 508 Compliancearticulate.com
  163. What's the Difference Between Section 508, WCAG, and the EAA?testparty.ai
  164. ADA Compliance with accessiBeaccessibe.com
  165. Section 508 Amendment to the Rehabilitation Act of 1973en.wikipedia.org
  166. The first rule of ARIA - The Accessibility Collectivea11y-collective.com
  167. ← 4.8 Embedded contentTable of contents4.8.6 The video element →w3.org
  168. Mitigate cross-site scripting (XSS) with a strict Content Security Policy (CSP)web.dev
  169. Content Security Policy Level 3w3.org
  170. Content security policyportswigger.net
  171. script-src directive, the CSP script allowlistcentralcsp.com
  172. Mitigating cross-site scripting with Content Security Policy - DEV Communitydev.to
  173. Referrer-Policy header - HTTP - MDN Web Docsdeveloper.mozilla.org
  174. Introduction to Referrer Policyditig.com
  175. Why rel='noopener' Is Obsolete for Linksblog.openreplay.com
  176. W3C Markup Validation Serviceen.wikipedia.org
  177. W3C HTML Validation at Scale · Rocket Validatorrocketvalidator.com
  178. A Worker-Owned Tech Consultancy - Bocoupbocoup.com
  179. GitHub - web-platform-tests/wpt: Test suites for Web platform specs — including WHATWG, W3C, and othersgithub.com
  180. Improving Web Accessibility with Web Platform Testswebkit.org
  181. HTML5w3.org
  182. HTML 5.2 Implementation reportw3c.github.io
  183. W3C publishes 'extremely silly' HTML5 test results suggesting win for Internet Explorer 9appleinsider.com
  184. GitHub - web-platform-tests/interop: web-platform-tests Interop project · GitHubgithub.com
  185. Browser Testing and Tools Working Group Charterw3.org
  186. Testing in Chromium - web-platform-testschromium.googlesource.com
  187. HTML 5.2w3.org
  188. HTML 5.1 Implementation reportw3c.github.io
  189. The WHATWG Blog — HTML vs. XHTMLblog.whatwg.org
  190. The WHATWG Blog — XHTML5 in a nutshellblog.whatwg.org
  191. Allow pure HTML5 in EPUB 3?edrlab.org
  192. EPUB 3 Changes from EPUB 2.0.1idpf.org
  193. Introductionelectronjs.org
  194. What Is Electron and Why Is It So Polarizing?kirupa.com
  195. From Web to Desktop: Introducing Electron Framework for Web Developersmedium.com
  196. The WHATWG Blog — 2017 — Decemberblog.whatwg.org
  197. Web Platform Governance — Web Platform Contribution Guide documentationwpc.guide
  198. www.whatwg.orgwhatwg.org
  199. github.comgithub.com
  200. Interop 2025: A year of convergencewebkit.org
  201. Launching Interop 2026hacks.mozilla.org
  202. Announcing Interop 2026webkit.org
  203. HTML Working Group Charterw3.org