天天看點
傳回

HTML5設計原則

“Be conservative in what you send; be liberal in what you accept.  –The Robustness principle”

“對于自己輸出要嚴格; 對于他人的輸入要靈活.  –魯棒性原則”

一切從魯棒性原則說起, 把魯棒性原則放在第一位, 是為了:

1. 讓大家帶着魯棒性原則的思考來聽這次分享.

2. 魯棒性原則是促成HTML5的設計原則主線.

3. 魯棒性的引申義可以上升到為人處世中去.

一. XHTML2 & HTML5之間不得不說的故事

HTML Tag的文檔作為HTML誕生的見證, 但是HTML Tag這份文檔并不是官方的規範.

真正的官方HTML規範是從HTML2開始的,HTML2繼承了HTML Tag的成果, 繼往開來, 承前啟後, 而非另立門戶, 從頭開始.

但是小悲劇的是, HTML2的标準出台的時候恰好是浏覽器大戰的年代,  浏覽器廠商各行其道, 無視标準的存在, 而W3C也在這個時期也不停的将一些浏覽器私有特性轉換成标準的一部分. (Cowpaths)

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,我印象很深刻的是:當時還在用Editplus, 去官網找了個xHTML1.1的template, 結果…

xHTML1.1 和xHTML1.0不僅僅是版本号加了0.1這樣的差異, 1.1居然是要求必須把文檔标記成XML? 而當時最先進的IE無法處理接收到XML文檔類型的文檔, 這這太崩潰了.而真正使人不想把文檔标注成XML的原因是, 如果你在文檔中哪怕是隻寫錯了一點點, 比如&沒有編碼成&那整個頁面的渲染結果就是黃屏了,沒戲了,這個頁面中有一個錯誤,你丫别想看這個網頁了. “如果解析器管道錯誤,那就停止解析”是的.這就是XML文檔的錯誤處理機制.

依稀記得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的伊恩希克森(google)來?又一次投票,同意了這個提案.

這 就變成了2個工作組都有一份自己的規範,而且看起來基本上一樣,那到底那份是真正的規範呢?實際上這兩個标準還是會分道揚镳,W3C最重要制定一 個具體的規範,這個規範最終會成為一個working draft,然後就定格了,而WHATWG呢?他們在不斷的疊代,即便是現在HTMl5都不能涵蓋他們的目标,他們是正在開發一項簡單的HTML或者 web技術.

這兩個工作組的流程截然相反,因為他們的理念完全不同.

WHATWG可以說是一種獨裁的工作機制。我剛才說了，伊恩·希克森是編輯。他會聽取各方意見，在所有成員各抒己見，充分陳述自己的觀點之後，他準許自己認為正确的意見。

W3C是一種民主的工作機制。所有成員都可以發表意見，而且每個人都有投票表決的權利。這個流程的關鍵在于投票表決

WHATWG 的工作機制讓人很不舒服,而W3C的工作機制讓人聽起來很舒服,但實際情況是WHATWG工作的非常順暢,主要歸功于伊恩·希克森。他 的的确确是一個非常稱職的編輯。他在聽取各方意見時，始終可以做到絲毫不帶個人感情色彩。W3C的工作機制很公平，而實際上卻非常容易在某些流程或環節上 卡殼，造成工作停滞不前，一件事情要達成決議往往需要花費很長時間。

兩個截然不同的工作組之是以能夠同心同德，主要原因是HTML5的 設計思想。因為他們從一開始就确定了設計HTML5所要堅持的原則。結果，我們不僅看到了一份規範，也就是W3C站點上公布的那份文檔，即HTML5語言規範，還在W3C站點上看到了另一份文檔，也就是HTML設計原理。

二.HTML5設計原則

設計原則, 是一種信念, 一種原則, 一種概念, 是設計原則涉及的人群行動的動力.

不管是W3C在制定規範, 還是通用在制造汽車,還是我們在編寫軟體, 甚至是大牛們在創造程式設計語言, 設計原則也許就是貫穿整件事情的一條主脈, 任何沖突與挫折都可以用他去衡量.

例如離我們最近的Alibaba公司的設計原則就可以認為是: 讓天下沒有難做的生意.

再例如Jquery的設計原則是: write less, do more.

說到這裡, 我就想起來我們應該問問自己:

1.我們的工業化設計原則是什麼?

2.我們的架構的設計原則是什麼?

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>
<meta charset="utf-8" />
<link rel="stylesheet" href="" />
<script src=""></script>

僅 此而已。好了，就連我也能過目不忘了。我用不着把這幾個字元記在記事本裡了。我得說，在我第一次看到這個doctype的時候——我當然以為這是 一個HTML文檔的doctype——被它吓了一跳：“是不是還少一個數字5啊？”我心裡想：“這個doctype想告訴浏覽器什麼呢？就說這個文檔是 HTML嗎？難道這是有史以來唯一一個HTML版本嗎，這件事我得首先搞清楚，HTML今後永遠不會再有新版本了嗎？”好一副唯我獨尊的架式！我錯了，因 為這個doctype并沒有這個意思。為此，必須先搞清楚為什麼文檔一開頭就要寫doctype。它不是寫給浏覽器看的。Doctype是寫給驗證器看 的。也就是說，我之是以要在文檔一開頭寫那行XHTML1.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這個工作組中有很多人代表的是浏覽器廠商，他們肯定是要考慮支援已有内容的。

再來看幾段代碼:

​​​​

<img src="foo" alt="bar" /> <p class="foo">Hello World</p> 
 
<img src="foo" alt="bar"> <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>

這幾段代碼有問題嗎? 沒有, 是的, 完全沒有問題!

因為我們讨論的隻是編碼風格或者寫作風格，跟哪種文法正确無關.

在JavaScript，你可以在每條語句末尾加上分号，但不是必需的，因為JavaScript會自動插入分号.

當然這并不阻礙我們用XHTML的文法規範來規約大家書寫辨識度高的文檔, 當然也可以借由lint工具來為我們驗證整個文檔的正确性.

我 個人認為，不僅對團隊來說，就算是你自己寫代碼，也要堅持一種文法風格。從浏覽器解析的角度講，不存在哪種文法比另一種更好的問題，但我認為，作為專業人士，我們必須能夠自信地講“這就是我的編碼風格。”然而，我不認為語言裡應該内置這種開關。你可以使用lint工具來統一編碼風格。現在就來說說 lint工具。大家可以登入htmllint.com，在其中運作你的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>

很NB吧…

f. Priority of  constituencies

最終使用者優先

事先聲明, 這是條很哲學的設計原則, 沒有代碼可以看.

它的意義就是: 一旦遇到沖突，最終使用者優先，其次是作者，其次是實作者，其次标準制定者，最後才是理論上的完滿。

在 有人建議了某個特性，而HTML5工作組為此争論不下時，如果有浏覽器廠商說“我們不會支援這個特性，不會在我們的浏覽器中實作這個特性”，那麼 這個特性就不會寫進規範。因為即使是把特性寫進規範，如果沒有廠商實作，規範不過是一紙空文，對不對？實作者可以拒絕實作規範。

嗯,要學會辯證的去看這些問題, 别鑽牛角尖就好.

最後附上PPT, 花了老子半天時間整的20頁啊!!!

​​HTML5 設計原則​​

還有這次分享的出處, Jeremy老闆在W3C Tech上的分享的PPT(PDF)

​​Jeremy-DesignOfHTML5​​

html5 html 3c
上一篇: 我是如何通過系統內建項目管理工程師3條經驗分享
下一篇: 系統內建項目管理工程師學習經驗集【60,59】

繼續閱讀