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