“Be conservative in what you send; be liberal in what you accept.
–The Robustness principle”
“發送時要保守；接收時要開放。
–伯斯塔爾法則”
一切從伯斯塔爾法則說起,伯斯塔爾法則是促成了HTML5規范形成的主線,當然它的引申義也可以上升到為人處世中去.
簡單說,HTML5只是HTML語言規范中的一個版本.
HTML最早是從2.0版開始的。從來就沒有1.0版。如果有人告訴你說，他最早是從HTML 1.0開始使用HTML的，那他絕對是在忽悠你。從前確實有一個名叫HTML Tags的文檔，其中的部分標簽一直用到現在，HTML Tag的文檔作為HTML誕生的見證, 但是HTML Tag這份文檔并不是官方的規范.
真正的官方HTML規范是從HTML2開始的, HTML2繼承了HTML Tag的成果, 繼往開來, 承前啟后, 而非另立門戶, 從頭開始.
但是小悲劇的是, HTML2的標準出臺的時候恰好是瀏覽器大戰的年代, 瀏覽器廠商各行其道, 無視標準的存在, 而W3C也在這個時期也不停的將一些瀏覽器私有特性轉換成標準的一部分.
97年 – 99年, 瀏覽器大戰如火如荼, HTML標準也經歷了從3.2 – 4.0 – 4.01的版本變遷, 非常的迅猛, 但是到了HTML4.01是, W3C的頭也許是被敲壞了, 認為:”好了, HTML就這樣了, HTML4.01是HTML的最后一個版本了, 我們也用不著HTML工作組了.”
而事實上W3C并沒有停止開發這門語言, 只不過他們對HTML失去了興趣, 在HTML4.01后, 他們提出了xHTML1.0,雖然聽起來完全不同，但是xHTML1.0與HTML4.01其實都是一樣的，唯一不同的，就是xHTML1.0要求使用 XML語法。也就是說我們現在習以為常的：所有標簽必須小寫，所有屬性必須小寫，所有屬性值都必須加引號，所有標簽必須閉合…
從規范本身的內容看,實際是相同的, 不同之處就是編碼風格, 因為對瀏覽器來說, 讀取符合HTML4.01,HTML3.2或者xHTML1.0規范的網頁都沒有問題, 對于瀏覽器來說,都會生成相同的DOM樹,只不過xHTML1.0嚴格的編碼風格讓人們比較偏好.
到了2000年,Web標準項目的活動如火如荼, 開發人員對那些個私有特性都忍無可忍, 大家都在罵瀏覽器廠商:”他媽的支持個標準真有這么難嗎?!”. 正巧那個時候CSS有了長足的發展,而且與xHTML1.0的結合也很緊密, CSS + xHTML1.0基本上就成了”最佳實踐”.而xHTML的那種優雅的書寫風格在專業人士的帶領下, 成為了業界最被認可接受的風格了.
在xHTML1.0之后緊跟著出來的是xHTML1.1,xHTML1.1和xHTML1.0不僅僅是版本號加了0.1這樣的差異, 1.1居然是要求必須把文檔標記成XML? 而當時最先進的IE無法處理接收到XML文檔類型的文檔, 這這太崩潰了.
而真正使人不想把文檔標注成XML的原因是, 如果你在文檔中哪怕是只寫錯了一點點, 比如&沒有編碼成&那整個頁面的渲染結果就是黃屏了,沒戲了,這個頁面中有一個錯誤,你丫別想看這個網頁了. “解析器如果遇到錯誤，停止解析。”是的.這就是XML文檔的錯誤處理機制.
接下來，新的版本是XHTML 2，大家注意后面沒有日期，因為這個規范并沒有完成。
當然并不是說這樣的規范不好, 恰恰相反, 從理論角度他是個非常好的規范, 是個非常好的格式, 但僅限于理論角度, 問題就是他并不實際.
首先，XHTML 2仍然使用XML錯誤處理模型，你必須保證以XML文檔類型發送文檔；這一點不言自明：沒人愿意這樣做。
其次，XHTML 2有意不再向后兼容已有的HTML的各個版本。他們甚至曾經討論過廢除img元素，這對每天都在做Web開發的人來說確實有點瘋了的味道。但我們知道，他們之所以這樣做，理論上確實有充足的理由——使用object元素可能會更好。
依稀記得xHTML2的墳還沒長草, 而促使他死亡的原因就是伯斯塔爾法則.
1.程序員們不會去支持他,因為XML的錯誤處理機制和xHTML2故意而為的不向后兼容.
2.瀏覽器廠商不會去支持他,因為瀏覽器必須要保證向后兼容.
作為專業人士，在發送文檔的時候，我們會盡量保守一些，盡量采用最佳實踐，盡量確保文檔格式良好。但從瀏覽器的角度說，它們必須以開放的姿態去接收任何文檔。
可以說伯斯塔爾法則是殺死xHTML2.0的戰略性理論武器. 而且讓他死的非常瞑目.
好吧, 回到當初和xHTML2.0并駕齊驅的HTML5.
HTML5并不是直接由W3C制定的,就在大伙認為HTML應該在HTML4.01時結束生命時, 有那么一伙人認為”也許HTML應該更加長壽一些,只要我們對他稍加擴展,只要我們把放在xHTML的時間和精力拿出一部分，就可以提升下HTML中的表 單，讓HTML更加接近編程語言，就可以讓他更上一層樓”
于是，在2004年Opera的伊恩.希克森提出了一個擴展和改進HTML的建議,他建議新任務和xHTML2并行,但在已有的HTML基礎上開展工作,目標是對HTML進行擴展.W3C的投票結果是NO,因為HTML已死,xHTML2才是未來.
于是,Opera,Apple等瀏覽器廠商以及一些成員說, 那好吧不指望他們了,我們自己也能做好這件事,我們脫離W3C.他們成立了WHATWG.而在接下去的一段時間內,WHATWG的工作效率非常高， 并且在短時間得出了一些成果， 因為他們的工作組成員里有瀏覽器廠商，因為他們不僅可以說加就加，而且還能夠一一實現，大家不斷地提出一些好點子并且逐一做到了瀏覽器中。 反觀W3C的xHTML2沒有什么實質性的進展，特別是從實現的角度來看，用原地踏步形容都不足為過。
戲劇性的事情又發生了， 2006年蒂姆.伯納斯-李寫了一篇博客,說:你們知道嗎?我們錯了,我們錯在企圖一夜之間就讓web跨入XML時代,我們的想法太不切實際了,是的,也許我們應該重建HTML工作組了.
So,2007年故事就真的這樣發展了,W3C組建了HTML5工作組, 這個工作組面臨的第一個問題是:我們重頭開始做呢,還是在04年成立的那個啥WHATWG工作組的既有成果上開始工作? 答案顯而易見,他們又一次投票同意了在WHATWG基礎上繼續工作.ok, W3C和WHATWG有并肩作戰了.
那第二個問題就成了這兩個工作組之間的關系,W3C這個工作組的主編是由誰來干呢?是不是讓WHATWG的伊恩希克森來兼任?又一次投票,同意了這個提案.
這就變成了2個工作組都有一份自己的規范,而且看起來基本上一樣,那到底那份是真正的規范呢?實際上這兩個標準還是會分道揚鑣,W3C最重要制定一 個具體的規范,這個規范最終會成為一個working draft,然后就定格了,而WHATWG呢?他們在不斷的迭代,即便是現在HTMl5都不能涵蓋他們的目標,他們是正在開發一項簡單的HTML或者 web技術.
這兩個工作組的流程截然相反,因為他們的理念完全不同.
WHATWG可以說是一種獨裁的工作機制。我剛才說了，伊恩·希克森是編輯。他會聽取各方意見，在所有成員各抒己見，充分陳述自己的觀點之后，他批準自己認為正確的意見。
W3C是一種民主的工作機制。所有成員都可以發表意見，而且每個人都有投票表決的權利。這個流程的關鍵在于投票表決
WHATWG的工作機制讓人很不舒服,而W3C的工作機制讓人聽起來很舒服,但實際情況是WHATWG工作的非常順暢,主要歸功于伊恩·希克森。他 的的確確是一個非常稱職的編輯。他在聽取各方意見時，始終可以做到絲毫不帶個人感情色彩。W3C的工作機制很公平，而實際上卻非常容易在某些流程或環節上 卡殼，造成工作停滯不前，一件事情要達成決議往往需要花費很長時間。
兩個截然不同的工作組之所以能夠同心同德，主要原因是HTML5的設計思想。因為他們從一開始就確定了設計HTML5所要堅持的原則。結果，我們不 僅看到了一份規范，也就是W3C站點上公布的那份文檔，即HTML5語言規范，還在W3C站點上看到了另一份文檔，也就是HTML設計原理。
設計原則, 是一種信念, 一種原則, 一種概念, 是設計原則涉及的人群行動的動力.
不管是W3C在制定規范, 還是通用在制造汽車, 還是我們在編寫軟件, 甚至是大牛們在創造編程語言, 設計原則也許就是貫穿整件事情的一條主脈, 任何矛盾與挫折都可以用他去衡量.
下面我就給大家介紹一些HTML5的設計原理。
- a. avoid needless complexity 避免不必要的復雜性
舉個栗子:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
<link rel="stylesheet" type="text/css" href=""/>
<script type="text/javascript"></script>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
<link rel="stylesheet" type="text/css" href=""/>
<script type="text/javascript"></script>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" dir="ltr">
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<link rel="stylesheet" type="text/css" href=""/>
<script type="text/javascript"></script>
上面3端代碼片段分別代表著XHTML1, HTML4.01, XHTML1.1的文檔類型申明和字符編碼申明以及引入JavaScript和CSS時要書寫的內容. 好吧, 誰能把這幾段默寫出來? 大概有人會說:”你瘋了嗎? 為什么不用模板生成呢?”
好吧, 讓我們來看一看HTML5的這部分內容:
<!DOCTYPE html>
<html lang="en">
<meta charset="utf-8" />
<link rel="stylesheet" href="" />
<script src=""></script>
僅此而已。好了，就連我也能過目不忘了。我用不著把這幾個字符記在記事本里了。我得說，在我第一次看到這個doctype的時候——我當然以為這是 一個HTML文檔的doctype——被它嚇了一跳：“是不是還少一個數字5啊？”我心里想：“這個doctype想告訴瀏覽器什么呢？就說這個文檔是 HTML嗎？難道這是有史以來唯一一個HTML版本嗎，這件事我得首先搞清楚，HTML今后永遠不會再有新版本了嗎？”好一副唯我獨尊的架式！我錯了，因 為這個doctype并沒有這個意思。為此，必須先搞清楚為什么文檔一開頭就要寫doctype。它不是寫給瀏覽器看的。Doctype是寫給驗證器看 的。也就是說，我之所以要在文檔一開頭寫那行XHTML 1.0的doctype，是為了告訴驗證器，讓驗證器按照該doctype來驗證我的文檔。
瀏覽器反倒無所謂了。假設我寫的是HTML 3.2文檔，文檔開頭寫的是HTML 3.2的doctype。而在文檔中某個地方，我使用了HTML 4.01中才出現的一個元素。瀏覽器會怎么處理這種情況？它會因為這個元素出現在比doctype聲明的HTML版本更晚的規范中，就不解釋呈現該元素 嗎？不會，當然不會！它照樣會解釋呈現該元素，別忘了伯斯塔爾法則，別忘了健壯性。瀏覽器在接收的時候必須要開放。因此，它不會檢查任何格式類型，而驗證 器會，驗證器才關心格式類型。這才是存在doctype的真正原因。
而按照HTML5的另一個設計原理，它必須向前向后兼容，兼容未來的HTML版本——不管是HTML6、HTML7，還是其他什么——都要與當前的HTML版本，HTML5，兼容。因此，把一個版本號放在doctype里面沒有多大的意義，即使對驗器證也一樣。
剛才，我說doctype不是為瀏覽器寫的，這樣說大多數情況下沒有問題。在有一種情況下，你使用的doctype會影響到瀏覽器，相信在座諸位也 都知道。但在這種情況下，Doctype并非真正用得其所，而只是為了達到某種特殊的目的才使用doctype。當初微軟在引入CSS的時候，走在了標準 的前頭，他們率先在瀏覽器中支持CSS，也推出了自己的盒模型——后來標準發布了，但標準中使用了不一樣的盒模型。他們怎么辦？他們想支持標準，但也想向 后兼容自己過去推出的編碼方式。他們怎么知道網頁作者想使用標準，還是想使用他們過去的方式？
于是，他們想出了一個非常巧妙的主意。那就是利用doctype，利用有效的doctype來觸發標準模式，而不是兼容模型（quiks mode）。這個主意非常巧妙。我們今天也都是這樣在做，在我們向文檔中加入doctype時，就相當于聲明了“我想使用標準模式”，但這并不是發明 doctype的本意。這只是為了達到特殊的目的在利用doctype。
這是在Internet Explorer中觸發標準模式的最少字符數目。我認為這也說明了HTML5規范的本質：它不追求理論上的完美。HTML5所體現的不是“噢，給作者一個 簡短好記的doctype不好嗎？”，沒錯，簡短好記是很好，但如果這個好記的doctype無法適應現有的瀏覽器，還不如把它忘了更好。因此，這個平衡 把握得非常好，不僅理論上看是個好主意——簡短好記的doctype，而且實踐中同樣也是個好主意——仍然可以觸發標準模式。應該說，Doctype是一 個非常典型的例子。
簡短好記。我能背下來。
同樣，這樣寫也是有效的。它不僅適用于最新版本的瀏覽器，只要是今天還有人在用的瀏覽器都同樣有效。為什么？因為在我們把這些meta元素輸入瀏覽 器時，瀏覽器會這樣解釋它：“元數據（meta）點點點點點，字符集（charset）utf-8。”這就是瀏覽器在解釋那行字符串時真正看到的內容。它 必須看到這些內容，根據就是伯斯塔爾法則，對不對？
我多次提到伯斯塔爾法則，但總有人不理解。我們換一種說法，瀏覽器會想“好，我覺得作者是想要指定一個字符集……看，沒錯，utf-8。”這些都是規范里明文規定的。如今，不僅那個斜杠可以省了，而且總共只要寫meta charset=”utf-8″就行了。
關于省略不必要的復雜性，或者說避免不必要的復雜性的例子還有不少。但關鍵是既能避免不必要的復雜性，還不會妨礙在現有瀏覽器中使用。比如說，在 HTML5中，如果我使用link元素鏈接到一個樣式表，我說了rel=”stylesheet”，然后再說type=”text/css”，那就是重復 自己了。對瀏覽器而言，我就是在重復自己。瀏覽器用不著同時看到這兩個屬性。瀏覽器只要看到rel=”stylesheet”就夠了，因為它可以猜出來你 要鏈接的是一個CSS樣式表。所以就不用再指定type屬性了。你不是已經說了這是一個樣式表了嘛；不用再說第二次了。當然，愿意的話，你可以再說；如果 你想包含type屬性，請便。
同樣地，如果你使用了script元素，你說type=”text/javascript”，瀏覽器差不多就知道是怎么回事了。對Web開發而言，你還使用其他的腳本語言嗎？如果你真想用其他腳本語言，沒人會阻攔你。但我要奉勸你一句，任何瀏覽器都不會支持你。
愿意的話，你可以添加一個type屬性。不過，也可以什么都不寫，瀏覽器自然會假設你在使用JavaScript。避免-不必要的-復雜性。
- b. Support existing content 支持已有的內容
顯然，我們都會考慮讓Web的未來發展得更好，但他們則必須考慮過去。別忘了W3C這個工作組中有很多人代表的是瀏覽器廠商，他們肯定是要考慮支持已有內容的。
再來看幾段代碼:
<p class="foo">Hello World</p>
<p class="foo">Hello World
<IMG SRC="foo" ALT="bar"><P CLASS="foo">Hello World</P>
<img src=foo alt=bar><p class=foo>Hello World</p>
這個例子展示了編寫同樣內容的四種不同方式。一個是img元素，另一個是帶屬性的段落元素。四種寫法唯一的不同點就是語法。把其中任何一段代碼交給瀏覽器，瀏覽器都會生成相同的DOM樹，沒有任何問題。從瀏覽器的角度看，這四種寫法沒有區別。因而在HTML5中，你可以隨意使用下列任何語法。
這幾段代碼有問題嗎? 沒有, 是的, 完全沒有問題!
有誰看到這些之后想“噢，這不是亂寫嘛，這樣做不對”？只有我這樣想嗎？還有別人嗎？
但是，HTML5必須支持已經存在的內容，而已有的內容就是這個樣子的。不是嗎？根據伯斯塔爾法則，瀏覽器沒有別的選擇。
有人可能會說“這樣不行。我覺得語言本身應該提供一種開關，讓作者能夠表明自己想做什么。”比如說，想使用某種特定的語法，像XHTML，而不是使用其他語法。我理解這些人的想法。但我不贊成在語言里設置開關。因為我們討論的只是編碼風格或者寫作風格，跟哪種語法正確無關。對于像我們這樣的專業人士，我認為可以使用lint工具（一種軟件質量保證工具，或者說是一種更加嚴格的編譯器。它不僅可以象普通編譯器那樣檢查出一般的語法錯誤，還可以檢查出那些雖然完全合乎語法要求，但很可能是潛在的、不易發現的錯誤），對其他技術我們不是也在使用lint工具嘛。
比如說對JavaScript使用lint工具。JavaScript同樣也是比較混亂、不嚴謹的例子，但它非常強大，原因恰恰是它混亂、不嚴謹，而且有很多不同的編碼方式。在JavaScript，你可以在每條語句末尾加上分號，但不是必需的，因為JavaScript會自動插入分號……是不是聽起來有點不好接受？
正因為如此，才有了像JSlint這樣的工具，在道格拉斯·克勞克福德（Douglas Crockford）的網站jslint.org上面。有個網頁上寫著“JSlint可能會傷害你的感情。”但這確實是個非常棒的工具，它可以把JavaScript代碼變得完美無瑕。如果你通過JSlint運行JavaScript，它會告訴你“好，你的JavaScript代碼有效，但寫法不妥。你這種編碼風格啊，我不喜歡。不贊成你這樣寫。這樣寫不好。”特別是對團隊，對于要使用統一的編碼風格的團隊，JSlint是非常方便的工具。
我個人認為，不僅對團隊來說，就算是你自己寫代碼，也要堅持一種語法風格。從瀏覽器解析的角度講，不存在哪種語法比另一種更好的問題，但我認為，作為專業人士，我們必須能夠自信地講“這就是我的編碼風格。”然而，我不認為語言里應該內置這種開關。你可以使用lint工具來統一編碼風格。現在就來說說lint工具。大家可以登錄htmllint.com，在其中運行你的HTML5文檔，它會幫你檢查屬性值是否加了引號，元素是否小寫，你還可以通過勾選復選框來設置其他檢查項。
但這不意味著拒絕粗心大意的標記，做不做清理完全取決于你自己。我說過，因為瀏覽器必須支持已有的內容，HTML5自然也不能例外。歸根結底還是伯斯塔爾法則。我們始終離不開伯斯塔爾法則。
- c. solve real problems 解決現實的問題
這看起來有點像再說廢話, 誰不是為了解決問題在做事情的呢?
而這條設計原理才是真正要解決今天的人們所面臨的現實問題、令人頭疼的問題。
好吧, 繼續看代碼:
<h2>Heading text</h2>
<p>Paragraph text.</p>
現在我們需要給這兩個文本都加上一個鏈接, 那我們的做法會是什么? 給h2和p分別加上一個a標簽？ 或許，也有聰明的同學會用a標簽來整個包住h2和p，就像：
<a href="somewhere">
<h2>Heading text</h2>
<p>Paragraph text.</p>
</a>
這樣寫有錯嗎？沒錯吧？只不過是種不太好的習慣, 并且通不過嚴格的校驗.
但是這樣的應用場景肯定存在的, 那為什么不能這樣寫呢?
這種寫法其實早就已經存在于瀏覽器中了，因為早就有人這樣寫了，當然以前這樣寫是不合乎規范的。所以，說HTML5解決現實的問題，其本質還是“你都這樣寫了很多年了吧？現在我們把標準改了，允許你這樣寫了。”
- d. pave the cowpaths 求真務實
Cowpath： 把一群牛放在地里，然后看牛喜歡怎么走，然后根據牛群踩過的痕跡來鋪一條給牛走的路。
很有趣的比喻吧, 說的就是把一些既然存在的東西變得更加標準一些. 接上地氣的標準才是能夠被執行的標準.
舉個栗子:
WHATWG對抽樣對大量網站進行了分析, 得出了這樣的一個結論:
id=”header”, id=”footer”, id=”content”, id=”navigation”, id=”sidebar” 這樣的命名方式非常常見, 那好吧, 那我就給你們一些這樣的標簽!
<section>,<article>,<aside>,<nav>,<header>,<footer>,<details>,<figure>
看代碼:
<body>
<div id="header"></div>
<div id="navigation"></div>
<div id="main"></div>
<div id="sidebar"></div>
<div id="footer"></div>
</body>
變!
<body>
<header></header>
<nav></nav>
<div id="main"></div>
<aside></aside>
<footer></footer>
</body>
怎么樣? 像模像樣了吧?
再看:
<div class="item">
<h2></h2>
<div class="meta"></div>
<div class="content"></div>
<div class="link"></div>
</div>
再變!
<section class="item">
<header><h2></h2></header>
<footer class="meta"></ footer >
<div class="content"></div>
<nav class="link"></nav>
</section>
雖然在這個文檔中，我們用這些新元素來替換的是id，但在我個人看來，將它們作為類的替代品更有價值。為什么這么說呢？因為這些元素在一個頁面中不 止可以使用一次，而是可以使用多次。沒錯，你可以為文檔添加一個頭部（header），再添加一個腳部（footer）；但文檔中的每個分區 （section）照樣也都可以有一個頭部和一個腳部。而每個分區里還可以嵌套另一個分區，被嵌套的分區仍然可以有自己的頭部和腳部，是這樣吧？
這四個新元素：section、article、aside和nav，之所以說它們強大，原因在于它們代表了一種新的內容模型，一種HTML中前所 未有的內容模型——給內容分區。迄今為止，我們一直都在用div來組織頁面中的內容，但與其他類似的元素一樣，div本身并沒有語義。但section、 article、aside和nav實際上是在明確地告訴你——這一塊就像文檔中的另一個文檔一樣。位于這些元素中的任何內容，都可以擁有自己的概要、標 題，自己的腳部。
其中最為通用的section，可以說是與內容最相關的一個。而article則是一種特殊的section。aside呢，是一種特殊的section。最后，nav也是一種特殊的section。
最重要的是它們的語義；跟位置沒有關系。
這里，請注意，最重要的還不是我用幾個新元素替換了原來的div加類，而是我把原來的H2換成了H1——震撼吧，我看到有人發抖了。我碰到過不少職 業的Web開發人員，多年來他們一直認為規范里說一個文檔中只能有一個H1。還有一些自詡為萬能的SEO秘訣同樣說要這樣。很多SEO的技巧其實是很教條 的。所謂教條，意思就是不相信數據。過去，這種教條表現為“不行，頁面中包含兩個以上的H1，你就會死掉的。”在HTML5中，只要你建立一個新的內容 塊，不管用section、article、aside、nav，還是別的元素，都可以在其中使用H1，而不必擔心這個塊里的標題在整個頁面中應該排在什 么級別；H2、H3，都沒有問題。
這個變化太厲害了。想一想吧，這個變化對內容管理是革命性的。因為現在，你可以把每個內容分區想象一個獨立的、能夠從頁面中拿出來的部分。此時，根 據上下文不同，這個獨立部分中的H1，在整個頁面中沒準會扮演H2或H3的角色——取決于它在文檔中出現的位置。面對這個突如其來的變化，也許有人的腦子 會暫時轉不過彎來。不要緊，但我可以告訴你，我認為這才是HTML5中這些新語義標記的真正價值所在。換句話說，我們現在有了獨立的元素了，這些元素中的 標題級別可以重新定義。
- e. degrade gracefully 優雅降級
HTML5中設計了這么些新玩意：
input type="number"
input type="search“
input type="range"
input type="email"
input type="date"
input type="url"
很有趣, 但是瀏覽器不認識, 怎么辦呢?
最關鍵的問題在于瀏覽器在看到這些新type值時會如何處理。現有的瀏覽器，不是將來的瀏覽器，現有的瀏覽器是無法理解這些新type值的。但在它們看到自己不理解的type值時，會將type的值解釋為text。
無論你寫的是input type=”foo”還是input type=”bar”，現有的任何瀏覽器都會說：“嗯，也許作者的意思是text。”因而，你從現在開始就可以使用這些新值，而且你也可以放心，那些不理 解它們的瀏覽器會把新值看成type=”text”，而這真是一個瀏覽器實踐平穩退化原理的好例子。
比如說，你現在輸入了type=”number”。假設你需要一個輸入數值的文本框。那么你可以把這個input的type屬性設置為 number，然后理解它的瀏覽器就會呈現一個可愛的小控件，像帶小箭頭圖標的微調控件之類的。對吧？而在不理解它的瀏覽器中，你會看到一個文本框，一個 你再熟悉不過的文本框。既然如此，為什么不能說輸入type=”number”就會得到一個帶小箭頭圖標的微調控件呢？
當然，你還可以設置最小和最大值屬性，它們同樣可以平穩退化。這是問題的關鍵。
HTML5還為輸入元素增加了新的屬性，比如placeholder（占位符）。有人不知道這個屬性的用處嗎，沒有吧？沒錯，就是用于在文本框中預 先放一些文本。不對，不是標簽（label）——占位符和標簽完全不是一回事。占位符就是文本框可以接受的示例內容，一般顏色是灰色的。只要你一點擊文本 框，它就消失了。如果你把已經輸入的內容全部刪除，然后單擊了文本框外部，它又會出現。
使用JavaScript編寫一些代碼當然也可以實現這個功能，但HTML5只用一個placeholder屬性就幫我們解決了問題。
當然，對于不支持這個屬性的瀏覽器，你還是可以使用JavaScript來實現占位符功能。通過JavaScript來測試瀏覽器支不支持該屬性也非常簡單。如果支持，后退一步，把路讓開，樂享其成即可。如果不支持，可以再讓你的JavaScript來模擬這個功能。
再來看一個比較極端的優雅降級方案:
<video>
<source src="movie.mp4">
<source src="movie.ogv">
<source src="movie.webm">
<object data="movie.swf">
<a href="movie.mp4">download</a>
</object>
</video>
上面的代碼中包含了4個不同的層次。
1、如果瀏覽器支持video元素，也支持H264，沒什么好說的，用第一個視頻。
2、如果瀏覽器支持video元素，支持Ogg，那么用第二個視頻。
3、如果瀏覽器不支持video元素，那么就要試試Flash影片了。
4、如果瀏覽器不支持video元素，也不支持Flash，我還給出了下載鏈接。
不錯，一開始就能考慮這么周到很難得啊。有了這幾個層次，已經夠完善了。
- f. Priority of constituencies 最終用戶優先
事先聲明, 這是條很哲學的設計原則, 沒有代碼可以看.
它的意義就是: 一旦遇到沖突，最終用戶優先，其次是作者，其次是實現者，其次標準制定者，最后才是理論上的完滿。
在有人建議了某個特性，而HTML5工作組為此爭論不下時，如果有瀏覽器廠商說“我們不會支持這個特性，不會在我們的瀏覽器中實現這個特性”，那么 這個特性就不會寫進規范。因為即使是把特性寫進規范，如果沒有廠商實現，規范不過是一紙空文，對不對？實現者可以拒絕實現規范。
嗯, 要學會辯證的去看這些問題, 別鉆牛角尖就好.
設計原理是Web發展背后的驅動力，也是通過HTML5反映出來的某種思維方式。我想，下面這條原理你絕對不會陌生：
大多數人的意見和運行的代碼。
對不對？這句話經常在我腦際回響，它囊括了Web的真諦，觸及了HTML5的靈魂。
