原文：https://www.w3.org/TR/html-de…
摘要
HTML5 是万维网核心语言 HTML 的第五个主要版本，本文档描述了 HTML 发展工作组使用的一套指导原则。在设计 HTML 时，这些原则提供了在兼容性、实用性、可交互性领域的指导
1. 简介
HTML 工作组有来自很多不同社区包括 WHATWG 和其他 W3C 工作组的代表。在 whatwg 下的 HTML5 工作，以及过去几年中在各种 W3C 标准上的大部分工作，都是基于不同的目标和对优秀设计的不同想法。为了取得有用的进展，我们需要就这个小组的目标达成一些基本共识
1.1. 文档和实现的一致性
很多语言规范会对有效文档定义一套一致性要求，与相应的处理有效文档的实现一致性要求。而 HTML5 在对非标准文档的实现一致性上有一些不同寻常
规范的双重性使我们能够为作者提供一种相对清晰和可理解的语言。同时也支持现存的文档使用旧的或者非标准的结构，也允许交互性更好的错误处理
一些设计原则更多应用于内容的一致性要求（conforming language，一致性语言），另外一些更多应用于实现的一致性要求（supported language，支持语言），支持语言是一致性语言的严格超集，会有想当多的重叠
2. 兼容性
有很多方法可以解释兼容性，有时会用到‘向前兼容’、‘向后兼容’等术语，但往往这些术语的含义是不清晰的。本节的原则讨论了兼容性的不同方面。
2.1 支持现存内容
这条原则主要应用与支持语言
现存内容常常依赖期望的用户代理（user agent）和行为来达到预期。实施规范必须确保可以处理绝大多数现存内容。特别是它应该可以把现存的 HTML 当做 HTML5 处理并且达到作者和用户的预期而无需模式切换
内容依赖浏览器的可能有多种形式。它可能依赖早期的 HTML 规范的元素、属性或者 API，或者一些专属特性。它可能依赖特定的错误处理规则。在较少情况，可能依赖早期的 HTML 规范中的非标准实现特性
当考虑对遗留特性或表现的改变，对当前实现和作者期望，下面的问题需要纳入考虑
- 是否有相当多数量的内容依赖于这个特性或者表现
- 某个依赖的内容是否发生于特别流行的网站
- 依赖性内容是否真正用于消费，而不是仅出现在测试用例或示例中？
- 依赖性内容是出现在公网还是仅仅供有限用户访问的内部网络
- 依赖性内容意图作用与多个流行的 UA，或者仅仅指向某一种 UA，或者非常旧的或者不流行的 UA
建议更改的益处和破坏内容的代价应该根据这些标准进行权衡。在某些情况，如果某个非标准特性或表现满足有效用户场景，把它加入一致性语言是可取的
2.1.1. 例子
- 许多网站使用损坏的标记，例如嵌套不良的元素
(abc)，作者和用户都寄希望于 UA 的错误处理。对这种内容的处理我们需要定义与预期兼容的处理要求 - 一些网站使用 <u> 元素来展示下划线效果
2.2 优雅降级
这条原则主要用于一致性语言
网站作者通常不情愿使用新语言特性，因为可能会在旧的 UA 上引发问题的新，或者没有提供优雅回退方法。HTML5 文档一致性要求应设计为在旧的或者缺乏能力的 UA 上可以优雅降级，即使使用了新的元素、属性、API 和内容模型
考虑所有 UA 包括一些非常旧的浏览器版本或者极不流行的工具是不可取的。当然下面一些类型的 UA 需要着重考虑
- 最主流浏览器的当前版本
- 主流浏览器旧的但是流行的版本
- 设计用于满足特定需求或者解决特定市场的顶级 UA，如辅助技术、移动浏览器，或者非典型媒体如纯文本终端或打印的 UA
在某些场景，一个新特性可能不适用于特定类型的 UA，或者可能无法以一种可以降低质量的方式进行设计。例如新的脚本 API 不能在无脚本 UA 上运行。但很多场景可以使用下面的方法
- 一个新的元素或属性可以提供额外的语义，如此在不被理解时也不会失去基本功能
- 一个新的脚本方法或者属性在使用前可以先使用 ECMAScript 内省工具做测试
- 一个新的元素或属性可能会提供语义和一个简单的使用 css 实现的默认呈现，这样附加的小样式表就可以优雅降级
- 一个新元素，属性或脚本 API 的表现可能通过附加的脚本来模拟实现，尽管脚本方法可能在性能和易用性水平上不相同
- 一个新的元素可能需要高度专业化的呈现，但允许给不理解的 UA 提供不同的内容作为回退
这个列表并不详尽；在某些情况下，稍微复杂一些的方法更有效
2.2.1. 例子
- irrelevant 属性的默认展现可以通过 css 规则 [irrelevant] {display: none;} 来模拟实现
- 多媒体元素如 <canvas> fallback </canvas> 或 <video> fallback
</video> 在旧的 UA 上会显示回退内容 - getElementsByClassName()方法在 UA 不支持时可以基于脚本实现
- <datalist> 元素可能包含一个隐藏的 <select> 元素并且与
<input> 元素关联。这种组合框的回退可以使用一个文本框或者一个文本框关联一个弹出式菜单来实现
2.3. 不要重新发明轮子
如果已经存在广泛使用和实施的技术能够覆盖特定用例，就要考虑指认这个技术而不是为同样的意图发明一个新东西。但也有时候，新的用例要求一个新的方式而不是在旧方法上进行拓展
contenteditable=”” 在 UA 上早已使用和实施，没必要去发明一个新特性
2.4. 铺好牛道
当某种实践在作者中已经广泛流传了，接受它比禁止它或者发明新东西更可取
作者们在 HTML 中已经使用了 <br/> 语法而不是 < br>，允许这样做没有任何害处
2.5. 进化而不是革命
革命有时会使世界变好。然而通常来说演化一个设计比抛弃它更好。这样作者不必学习新的模型内容也会寿命更长。更确切的说，这意味着设计者设计的特性能够使旧内容享受它的优点而不必做不相干的改变。实施应该能够在现有代码上增加新特性，而不用开发整个独立的模式
切换到 xml 语法需要全球变更，因此继续支持经典的 HTML 语法
3. 公共设施
这些原则要求一个能恩确保 HTML 有效地实现预期目的设计
3.1. 解决现实问题
对规范的更改应该解决现实世界的问题。非基于现有需求的抽象结构设计比不上解决具体问题的实用设计。如有可能，应解决普遍存在的问题
3.2. 选区的优先权
在有冲突的情况下，用户利益高于作者高于实施者高于专业人士高于纯理论。换个方式说在权重上，应用户成本和难度 > 实施者成本 > 规范作者成本 > 仅出于理论的提案。
3.3. 设计安全
确保特性不破坏 web 安全模型，最好直接在规范中解决安全问题
不同站点的跨文档沟通很有用，但是不严格的版本可能把用户数据至于险境。跨文档消息只有在不违反安全约束的条件下才允许
3.4. 关注点分离
HTML 应该允许内容和表现分离。基于这个理由，表示结构的标记通常优先于纯展示标记。而且，结构性标记是一种结束的手段，如果无法结束则需要进行深入详细和语义编码。为不同媒体定义合理的默认展示就足够了。HTML 在语义表达和实用性之间取得了平衡。标记中的元素和属性的名称可能是简写的而不是精确完整的
article 元素定义一个单独的文章，而不是它怎样展示的细节。一个杂志文章可能是页面上唯一的文章，多列格式，而博客站点上则可能一个页面上有多个文章，显现为有边框的盒子
3.5.DOM 一致性
序列化解析器构造的 DOM 树对脚本和其他能在文档树上操作的程序代码的可行性要保持一致，允许实现的兼容性差异，但应尽可能小
HTML (text/html)解析器把 http://www.w3.org/1999/xhtml…
4. 交互性
这些原则用来提升 HTML 可交互性
4.1. 明确的行为
最好清晰定义内容作者可以依赖的行为，而不是模糊的或实现定义的行为。这样更容易编写各种 UA 中的内容。当然实施依然可以自由地对用户界面和渲染质量做出提高
4.2. 避免不必要的复杂性
简单的解决方案比复杂的更受欢迎，简单的特性也更容易实现，可操作性更高，也更便于作者理解。不过这不能成为违反其他原则的接口
4.3. 错误处理
优雅的错误恢复比硬故障更好，这样编写错误就不会暴露给用户
5. 通用接入
特性的设计必须可通用接入。这个类别覆盖各种相关的原则
5.1 媒体独立
设计的特性必须可跨平台、设备、媒体工作。这并不是说如果某个媒体或平台不支持就省去这个特性。例如一些交互特性不会因为无法在打印文档上表现出来就有去掉它们。
HTML 的重排能力使其更适合可变屏幕尺寸，而不是精确字形位置的表示
超链接在打印文档上并不会有动作，但我们没有理由要去掉 a 元素
5.2. 支持世界语言
可使用世界上所有的语言发表。但并不是说要把它当做一个均衡语言系统禁止不支持所有语言的特性。把多个翻译打包到一个文件里的特性超出了这个范畴
支持 Unicode 允许世界上大多数语言，包括不同语言的混合文本
意大利文很有用，因为它适用于很多二进制的脚本，尽管很多脚本并没有这种概念。类似的，ruby 对很多脚本有用，尽管它有一个 CJK 焦点
元素内容中的文本相比属性内容中的文本有更好的语言支持；元素内容中可插入 ruby 注释，以及 dir 属性和 bdo 元素，以防 Unicode 双向算法不能正确的对相邻的混合方向文本排序
5.3. 可用性
特性的设计必须对有残障的用户可用。对所有人可用很重要。但也不是说如果特性不是对所有人可用就完成省去它，而是提供替代机制
图像元素对盲人不可见，因此可以提供一个替代文本
progress 元素本质是可以访问的，因为它具有明确的进度条语义，允许映射到可访问 api