html5设计原则-2007

原文：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