版权 © 2007 W3C® (MIT, ERCIM, Keio)，保留所有权利。W3C 责任、商标和文档使用规则适用。
HTML 5 定义了万维网核心语言 HTML 的第五次重大修订。本文档描述了 HTML 工作组在开发 HTML5 时使用的一套指导原则。这些原则为 HTML 在兼容性、实用性和互操作性方面的设计提供指导。
本节描述本文档在发布时的状态。其他文档可能会取代本文档。当前的 W3C 出版物列表和本技术报告的最新修订版可在 https://w3org.cn/TR/ 的 W3C 技术报告索引中找到。
此文档是由 HTML 工作组（HTML 活动的一部分）制作的《HTML 设计原则》的首个公开工作草案。工作组计划将本文件作为 工作组说明发布。工作组正在制定一个尚未在 TR 中发布的新版 HTML。与此同时，您可以访问 HTML 5 编辑草稿。对本文件的评论应发送至 public-html-comments@w3.org，该邮件列表拥有 公开归档。
决定请求发布本文档的依据是 HTML 工作组成员的投票，结果为 51 票“同意”、2 票“不同意”、以及 1 票“正式反对”。
记录的具体反对意见被判定为一种可以在后续草案中处理的评论——并非阻止发布的关键理由，并且我们认识到完整共识并非发布的前提，因为 HTML 工作组决定发布本文档的目的在于向社区发出信号，开始认真审阅该文档，并鼓励在 W3C 内外进行广泛评审。
发布为工作草案并不意味着获得 W3C 成员的认可。这是一份草案文档，可能随时被其他文档更新、替换或废弃。将其作为进行中的工作以外的引用是不恰当的。
本文档由遵循 2004 年 2 月 5 日 W3C 专利政策的团队制作。团队并不期望本文件成为 W3C 推荐标准。W3C 维护一份 公开的专利披露列表，其中也包含披露专利的说明。任何实际知晓某专利且认为该专利包含 基本权利要求的个人，必须按照 W3C 专利政策第 6 节进行披露。
在 HTML 工作组中，我们有来自许多不同社区的代表，包括 WHATWG 以及其他 W3C 工作组。WHATWG 的 HTML 5 工作以及过去几年中大量的 W3C 标准工作，都是基于不同的目标和对良好设计的不同认知。为了取得有意义的进展，我们需要在本组的目标上达成基本共识。
这些设计原则尝试捕捉对设计方法的共识。它们是必须相互平衡的务实经验法则，而非绝对准则。它们的精神类似于 TAG 在《万维网结构》中的发现，但专门面向本组的交付物。
许多语言规范为合法文档定义了一套一致性要求，并为处理这些合法文档的实现定义相应的一致性要求。HTML 5 在此之外，还为许多在符合文档中不被允许的构造定义了实现一致性要求，这一点略显特殊。
规范的这种双重特性使我们能够为作者提供相对简洁易懂的语言，同时仍然支持使用旧的或非标准构造的已有文档，并在错误处理方面实现更好的互操作性。
以下部分的设计原则有的侧重于内容的一致性要求（即“符合语言”），有的侧重于实现的一致性要求（即“受支持语言”）。因为受支持语言是符合语言的严格超集，两者之间有相当的重叠，但本原则将尽力明确它们适用于哪一套要求。
兼容性的解释方式有很多。有时会使用“向后兼容”和“向前兼容”，但这些词的含义有时并不清晰。本节的原则针对兼容性的不同侧面进行阐述。
此原则主要适用于受支持语言。
现有内容往往依赖于用户代理的预期处理行为才能实现预定功能。处理要求应当明确，使实现本规范的用户代理能够处理大多数现有内容。特别是，应该能够把已有的 HTML 文档当作 HTML 5 进行处理，并得到与现有浏览器行为相兼容的结果。应当提供在不切换模式的情况下完成此任务的可能性（但并非强制要求）。
依赖现有浏览器行为的内容形式多样。它可能依赖于早期 HTML 规范中的元素、属性或 API（这些在 HTML 5 中已不再出现），也可能依赖完全专有的特性；它可能依赖特定的错误处理规则；在极少数情况下，它可能依赖于早期 HTML 规范中 **未** 按规定实现的特性。
在考虑对传统特性或行为进行修改时（相对于当前实现和作者期望），应当审视以下问题：
应当以这些标准衡量提议变更的收益与因破坏内容而产生的可能成本。在某些情况下，如果非标准特性或行为满足了有效的使用场景，则可以将其纳入符合语言。不过，仅因某特性属于受支持语言并不意味着对其依赖就是被认可或鼓励的。
许多站点使用错误的标记，例如错误嵌套的元素（<b>a<i>b</b>c</i>），作者和用户对旧版用户代理的错误处理方式有一定期待。我们需要定义的处理要求必须与这些内容的预期处理保持兼容。
有些站点依赖 <u> 元素实现下划线的呈现效果。
此原则主要适用于符合语言。
在万维网上，作者往往不愿使用会在旧版用户代理中出现问题，或没有优雅回退方案的新语言特性。HTML 5 的文档符合性要求应当设计为，使得即使使用了新元素、属性、API 与内容模型，内容在旧版或功能较弱的用户代理中也能优雅退化。
并不需要考虑每一个历史上出现过的用户代理，包括那些极少使用的老旧浏览器或工具。但应当重点考虑以下几类用户代理，因为内容作者很可能需要针对它们进行优化：
在某些情况下，新特性可能根本不适用于某类用户代理，或难以实现优雅退化。例如，新的脚本 API 无法在不支持脚本的代理中工作。但许多情况下，可以采用如下方式实现兼容：
此列表并不详尽；在某些情况下，稍微复杂一点的方案会更有效。
建议的 irrelevant 属性的默认呈现可通过 CSS 规则 [irrelevant] { display: none; } 来模拟。
建议的新多媒体元素如 <canvas> fallback </canvas> 或 <video> fallback </video> 允许回退内容。旧版用户代理会显示 “fallback”，而支持 canvas 或 video 的代理则会展示多媒体内容。
建议的 getElementsByClassName() 方法可以比现有库中的纯 ECMAScript 实现快得多，但在原生实现不可用时可以使用基于脚本的实现。
<datalist> 元素可以与 <input> 元素关联，并可包含一个隐藏的 <select> 元素。这样，在主流浏览器中，预期的 “组合框” 控件的回退形式可以是文本字段或带弹出菜单的文本字段。
如果已有广泛使用且已实现的技术能够覆盖特定用例，应优先采用该技术，而不是为同一目的再发明新东西。不过，有时新的使用场景确实需要全新方案，而非在旧方案上继续扩展。
contenteditable="" 已被用户代理使用和实现，无需再发明新特性。
当一种做法已在作者中广泛流行时，考虑采用它，而不是禁止或重新发明。
作者已经在 HTML 中使用 <br/> 语法而非 <br>，允许继续使用不会造成任何伤害。
革命有时会让世界变得更好，但大多数情况下，演进现有设计比彻底抛弃更为理想。这样，作者无需学习全新模型，内容也能获得更长久的生命力。具体而言，应该倾向于设计特性，使旧内容能够在不做无关改动的情况下利用新特性；实现则应能够在已有代码上添加新特性，而不是必须开发全新的模式。
切换到 XML 语法需要全局性的更改，因此仍应继续支持传统的 HTML 语法。
这些原则呼吁一种设计，使 HTML 能够有效地用于其众多预期用途。
规范的修改应解决真实的、实际存在的世界问题。抽象的架构若不能对应现有需求，则不如直接的、务实的解决方案受青睐，且应尽可能解决已广泛存在的问题。
若出现冲突，应按以下顺序考虑：用户 > 作者 > 实现者 > 规范制定者 > 纯理论追求。换言之，用户的成本或困难应比作者的更受重视；作者的又应比实现者的更受重视；实现者的成本应比规范作者的更受重视；而仅出于理论原因提出的改变则应放在最后。当然，最好能够一次性使多个利益相关方受益。
确保特性能够配合 Web 的安全模型工作。最好在规范中直接处理安全考虑。
跨站点文档间的通信很有用，但若不加限制会危及用户数据安全。跨文档消息机制正是为在不违背安全约束的前提下实现此目的而设计的。
HTML 应当实现内容与表现的分离。基于此，表达结构的标记通常优先于纯表现性的标记。不过，结构化标记是一种实现 媒体独立性 的手段。如果能够通过其他方式实现相同目标，则不必追求过于详细的语义编码。为不同媒体定义合理的默认呈现即可。HTML 在语义表达力与实用性之间取得了平衡。元素和属性的名称可能出于简洁、历史或实现便利而采用较为务实的命名，而非完全准确的描述。
article 元素定义了一个独立的文章，但不规定其展示细节。一篇学术期刊文章可能是页面上唯一的文章，采用多栏布局；而一篇博客文章可能与多篇其他文章共存，并以带边框的盒子形式呈现。
b 与 i 元素被广泛使用——为它们在包括听觉在内的各种媒体上提供良好的默认渲染要比试图禁用它们更为合适。
两种序列化方式应设计为，使得各自解析器生成的 DOM 树在脚本和其它程序代码对文档树的操作上尽可能保持一致。为兼容遗留实现可以容许一些差异，但应将差异最小化。
此外，除非为兼容遗留实现和已部署内容所必需，否则应避免因语法外观的无意义差异。
HTML（text/html）解析器在 DOM 中为元素分配 https://w3org.cn/1999/xhtml 命名空间，以兼容 HTML 5 的 XML 语法。
这些原则的存在是为了提升 HTML 实现真正互操作的可能性。
优先明确定义内容作者可以信赖的行为，而不是模糊或实现定义的行为。如此一来，作者更易编写在多种用户代理上都能正常工作的内容。不过，实现仍应有自由在用户界面和渲染质量等方面进行改进。
在可能的情况下，倾向于采用简单的解决方案而非复杂的方案。更简洁的特性更易于用户代理实现，更有可能实现互操作，也更易于作者理解。但这并不意味着可以以此为借口回避满足其他原则的要求。
错误处理应当被定义，以便实现之间可以实现互操作。应优先采用优雅的错误恢复而非硬性失败，从而避免用户暴露于作者错误之中。
特性应面向普遍可及性进行设计。本类别涵盖与此相关的各种原则。
特性应尽可能在不同平台、设备和媒体上运行。这并不意味着如果某些媒体或平台无法支持该特性就必须舍弃它。例如，交互特性不应仅因为在印刷文档中无法表现而被省略。
HTML 文本的整体可重排特性使其相较于精确字形位置的表示更适合可变的屏幕尺寸。
超链接在印刷文档中无法被激活，但这并不是舍弃 a 元素的理由。
应支持所有世界语言的出版。但这并不意味着要通过禁止不适用于所有语言的特性来使书写系统等同。将多个译本打包进同一文件的特性超出了本文档的范围。
支持 Unicode 能够涵盖世界上大多数语言的文本，并能够实现不同语言文本的混排。
斜体文字在许多双形文字系统中都有用，尽管某些文字系统没有斜体概念。同样，ruby 在许多文字系统中都有用，虽重点在 CJK。
元素内容中的文本相较于属性内容拥有更好的语言支持；在元素内容中可以插入 ruby 注释，以及在 Unicode 双向算法不足以正确排列混合方向文本时使用 dir 属性和 bdo 元素。
设计特性时要确保残障用户也能使用。对所有人都能访问是基本要求。这并不意味着如果并非所有用户都能完全使用该特性就完全舍弃，而是需要提供替代机制。
对盲人用户而言，img 中的图像可能不可见，但这应成为提供替代文字的理由，而不是去掉图像本身。
progress 元素本身具备无歧义的进度条语义，可映射到辅助功能 API，从而实现可访问的进度指示器。
编辑们要感谢 Charles McCathie‑Nevile、Chris Wilson、Dan Connolly、Henri Sivonen、Ian Hickson、Jirka Kosek、Lachlan Hunt、Nik Thierry、Philip Taylor、Richard Ishida、Stephen Stewart 与 Steven Faulkner 对本文档以及多年来对 HTML 5 所作的贡献，正是他们让 Web 更加美好！
如果您对本文档有贡献，但上述名单中未出现您的名字，请告知编辑，以便他们纠正此遗漏。