html5設計原理(推薦收藏)_html5教學技巧

實際上，確實有人會談到規範的內容。史蒂夫·福克納（Steve Faulkner）會講HTML5與可訪問性。而保羅·艾里什（Paul Irish）則會講HTML5提供的各種API。因此，我今天站在這裡，不會光講一講HTML5就算完事了。

說老實話，在正式開始之前，我想先交待清楚我所說的HTML5到底是什麼意思。這話聽起來有點搞笑：這會子你一直在說HTML5，難道我們還不知道什麼是HTML5嗎？大家知道，有一個規範，它的名字叫HTML5。我所說的HTML5，指的就是這個規範。但問題是，有些人所說的HTML5，指的不只是這個規範，還有別的意思。比如說，用HTML5來代指CSS3就是一種常見的叫法。我可不是這樣的。我所說的HTML5，不含CSS3，就是HTML5。
類似的術語問題以前也有過。 Ajax本來是一種意義明確的技術，但過了不久，它的意義就變成了「用JavaScript來做一切好玩的東西」。這就是Ajax，對不對？今天，HTML5也面臨同樣的問題，它本來指的是一個特定的規範，但如今含義卻成了「在Web上做一切好玩的事。」我說的不是這種HTML5，不是這種涵蓋了最近剛出現的各種新東東的HTML5。我說的只是規範本身：HTML5。
剛才已經說了，我今天想要講的內容不多，也沒有打算介紹HTML5都包含什麼。今天我要講的是它的另一面，也就是HTML5的設計。換句話說，我要講的不是規範裡都包含什麼，而是規範裡為什麼會包含它們，以及在設計這個規範的時候，設計者是怎麼看待這些東西的。

設計原理

設計原理本質上是一種信念、一種想法、一個概念，是你行動的支柱。不管你是製定規範，還是製造一種有形的物品，或是寫軟體，甚至發明程式語言。你都能找到背後的一個或多個設計原理，多人協作的任何成果都是例證。不僅僅Web開發領域是這樣。縱觀人類歷史，像國家和社會這樣大規模的建構活動背後，同樣也有設計原理。
就拿美國為例吧，美國的設計原理都寫在了《獨立宣言》中了。
我們認為這些真理是不言而喻的，人人生而平等，造物主賦予了每個人不可剝奪的權利，包括生存、自由和追求幸福。
這裡有一句口號：生存、自由和追求幸福。這是被寫進憲法中的核心理念，它關係到我們所有人的一切，也就是我們建構自己社會的原則。
還有一個例子，就是卡爾‧馬克思（Karl Marx），他的著作在20世紀曾被奉為建設社會主義的圭臬。其基本思想大致可以歸結為下面這條設計原理：

各盡所能，各取所需。

這其實就是一種經濟體系背後的設計原理。

還有一個例子，比前面兩個的歷史更久遠一些，不過大同小異：

人人為我，我為人人。

這個極為簡單的設計原理，是兩千年前的拿撒勒猶太人耶穌基督提出來的。而這條原則成為了後來許多宗教的核心教義。原理與實務有時候並不是同步的。
以下是小說中的一個例子。英國小說家喬治‧歐威爾（George Orwell）筆下的《動物農莊》，就是在一個設計原理的基礎上建構起來的虛擬社會。這條設計原理是：
四條腿的都是好人，兩條腿的都是壞蛋！
《動物農莊》中有趣的是，隨著社會的變遷－變得越來越壞，這條設計原理也跟著發生了改變，變成了「四條腿的都是好人，兩條腿的就更好了。
還有一套虛構的作品是以三條設計原理為基礎構建起來的，那就是美國著名小說家艾薩克·阿西莫夫（Issac Asimov）的機器人經典系列。阿西莫夫發明了機器人學這個術語，並提出了機器人學三大法則，然後在這三個簡單的設計原理基礎上創作了一系列經典作品——大約有50本書。無論作品的情節如何變化，其實都是從不同的角度來闡釋這三大設計原理。我想，在座各位對機器人三大法則都不該陌生。

機器人不得傷害人類，或袖手旁觀人類受傷害。
機器人必須服從人類命令，除非命令違反第一法則。
機器人必須自衛，只要不違反第一和第二法則。

這些恐怕是第一次出現在小說中的針對軟體的設計原理了。雖然基於這三個設計原理的軟體運行在虛構的機器人的「正電子腦」中，但我想這應該是軟體設計原理的事實開端。從此以後，我們才看到大量優秀軟體背後的設計原理。
蒂姆·伯納斯-李（Tim Berners-Lee），Web的發明者，在W3C的網站上發表過一份文檔，其中有一個URL給出了他自己的一套設計原理。這些設計原理並不那麼容易理解，不僅多，而且隨著時間推移，他還會不斷補充、修改和刪除。不過我還是覺得把自己認同的設計原理寫出來放在某個地方真是個不錯的主意。
實際上，CSS的發明人之一伯特·波斯（Bert Bos），也在W3C的網站上放著一份文檔，其中講的都是基本的設計原理，比如怎樣設計並構建一種格式，無論是CSS或其他格式。推薦大家看一看。
只要你在W3C的站點中隨便找一找，就可以發現非常多的這種設計原理，包括蒂姆·伯納斯-李個人的。當然，你也會看到他從軟體工程學校借用的一些口號：分權（decentalisation）、容忍（tolerance）、簡易（simplicity）、模組化（modularity）。這些都是在他發明新格式的時候，腦中無時無刻不在想的那些關鍵字。
在座各位對蒂姆·伯納斯-李的貢獻都是非常熟悉的，因為大家每天都在用。他發明了Web，與羅伯特·卡里奧（Robert Cailliau）共同發明了Web，而且在發明Web的同時，也發明了我們每天在Web上使用的語言。當然，這門語言就是HTML：超文本標記語言。

HTML

HTML最早是從2.0版開始的。從來就沒有1.0版。如果有人告訴你說，他最早是從HTML 1.0開始使用HTML的，那他絕對是在忽悠你。從前確實有一個名叫HTML Tags的文檔，其中的部分標籤一直用到現在，但那個文檔並非官方的規範。
使用標籤、尖括號、p或h1，等等，並不是提姆·伯納斯-李首創的想法。當時的SGML裡就有了這些概念，而且當時的CERN（Conseil Europeen pour la Recherche Nucleaire，歐洲核子研究委員會）也在使用SGML的一個特定的版本。也就是說，即便在那個時代，他也沒有白手起家；這點在HTML後來的發展過程中也體現了出來：繼往開來、承前啟後，而不是另立門戶、從頭開始。
換句話說，這篇名為HTML Tags的文件可以算是HTML的第一個版本，但它卻不是一個正式的版本。第一個正式版本，HTML 2.0，也不是出自W3C之手。 HTML 2.0是由IETF，因特網工程任務小組（Internet Engineering Task Force）所製定的。在W3C成立之前，IETF已經發布了許多標準。但從第三個版本開始往後，W3C，萬維網聯盟（World Wide Web Consortium）開始接手，並負責後續版本的製定工作。
20世紀九十年代HTML有過幾次快速的發展。眾所周知，在那個時代要建立網站，可是一項十分複雜的工程。瀏覽器大戰曾令人頭痛不已。市場競爭的結果就是各家瀏覽器裡都塞滿了各種專有的特性，都試圖在專有特性上勝人一籌。當時的混亂程度不堪回首，HTML到底還重不重要，或者它作為Web格式的前景如何，誰都說不清楚。
從1997年到1999年，HTML的版本從3.2到4.0到4.01，經歷了非常快速的發展。問題是到了4.01的時候，W3C的認知發生了倒退，他們說「好了，這個版本就這樣了，HTML也就這樣了；HTML 4.01是HTML的最後一個版本了，我們用不著HTML工作小組了。 」
W3C並沒有停止開發這門語言，只不過他們對HTML不再感興趣了。在HTML 4.01之後，他們提出了XHTML 1.0。雖然聽起來完全不同，但XHTML 1.0跟HTML 4.01其實是一樣的。我的意思是說，從字面上看這兩個規範的內容是一樣的，詞彙表是一樣的，所有的元素是一樣，所有的屬性都是一樣的。唯一一點不同之處，就是XHTML 1.0要求使用XML語法。也就是說，所有屬性都必須使用小寫字母，所有元素也必須使用小寫字母，所有屬性值都必須加引號，你還得記著使用結束標籤，記著對img和br要使用自結束標籤。
從規範本身的內容來看，其實是相同的，沒有什麼不同。不同之處就是編碼風格，因為對瀏覽器來說，讀取符合HTML 4.01、HTML 3.2，或者XHTML 1.0規範的網頁都沒有問題，對瀏覽器來說這些網頁都是一樣的，都會產生相同的DOM樹。只不過人們會比較喜歡XHTML 1.0，因為不少人認同它比較嚴格的程式設計風格。
到了2000年，Web標準專案（Web Standards Project）的活動進行得如火如荼，開發人員對瀏覽器裡包含的那些亂七八糟的專有特性已經忍無可忍了。大家都很生氣，就罵那些瀏覽器廠商「遵守個規範就他媽的真有那麼難嗎？」當時CSS有了長足的發展，而且與XHTML 1.0結合得也很緊密，CSS加XHTML 1.0基本上就可以算是「最佳實踐」了。雖然在我看來HTML 4.01與XHTML 1.0沒有本質上的不同，但大家都接受了。專業的開發人員能做到元素全部小寫，屬性全部小寫，屬性值也全部加引號：由於專業人員起到了模範帶頭作用，越來越多的人也都開始支持這種語法。
我就是一個例子！過去的10年，我一直都使用XHTML 1.0文件類型，原因是這樣一來驗證器就能給我幫上很大的忙，對不對？只要我寫的是XHTML 1.0，然後用驗證器測試，它就能告訴我是不是忘了給屬性值加引號，是不是沒有結束某個標籤，等等等等。而如果我寫的是HTML 4.01，同樣的問題就變成了有效的了，驗證器就不一定會提醒我了。
這就是我一直使用XHTML 1.0的原因。我估計很多人都…使用XHTML 1.0的朋友，請把手舉起來。好的。 HTML 4.01呢？人少多了。那一直沒有舉手的呢，大聲一點，你們用什麼？ HTML5，也很好！更早的呢，還有人使用更早的文檔類型嗎？沒有了？
10年來我一直使用XHTML 1.0，就是因為驗證器能夠真正幫助我。有人用XHTML 1.1嗎？你知道有人用嗎？請舉手，別放下。有人把網頁標記為XML文件嗎？有嗎？那你們使用的就不是XHTML 1.1。
這就是個大問題。 XHTML 1.0之後是XHTML 1.1，只是小數點後面的數字加了一個1，而且從詞彙表的角度看，規範本身沒有什麼新東西，元素也都相同，屬性也都相同。但對XHTML 1.1來說，唯一的改變是你必須把自己的文件標記為XML文件。在使用XHTML 1.0的時候，還可以把文件標記為HTML，而我們也正是這樣做的，否則把文件標記為XML沒準真會把人逼瘋的。
為什麼這麼說呢？首先，把文檔標記為XML後，Internet Explorer不能處理。當然，IE9是可以處理了。恐怕有人會講“真是太可愛了”，他們到現在居然都沒有忘了這件事。這艘船終於靠岸了！不過那時候，作為全球領先的瀏覽器，IE無法處理接收到的XML文檔類型的文檔，而規範又要求你以XML文檔類型來發送文檔，這不把人逼瘋才怪呢。
所以說XHTML 1.1有點脫離現實，而你不想把文件以XML格式傳送給那些能夠理解XML的瀏覽器，則是因為XML的錯誤處理模型。 XML的語法，無論是屬性小寫，元素小寫，還是總是要給屬性值加引號，這些都沒有問題，都很好，事實上我也喜歡這樣做，但XML的錯誤處理模型卻是這樣的：解析器如果遇到錯誤，停止解析。規範裡就是這麼寫的。如果你把XHTML 1.1標記為XML文檔類型，假設你用Firefox打開這個文檔，而文檔中有一個和號（&）沒有正確編碼，就算整個頁面中就這一處錯誤，你看到的也將是黃屏，瀏覽器死掉了。 Firefox會說：「沒戲了，頁面中有一個錯誤，你看不到這個網頁了。」根據XML規範，這樣處理是正確的，對Firefox而言，遇到錯誤就停止解析，並且不呈現其他任何內容是嚴格依照XML規範做的。因為它不是HTML，HTML根本就沒有錯誤處理模型，但根據XML規範，這樣做沒錯。
這就是為什麼你不會把文件標記為XML的另一個原因。接下來，新的版本是XHTML 2，大家注意到後面沒有日期，因為這個規範沒有完成。
現在就說說XHTML 2，我很願意把問題說清楚，XHTML 2其實真是非常非常好的規範，確實非常好…從理論的角度來說。我的意思是說，制定這個規範的人都是非常非常有頭腦的。直說吧，領導制定這個規範的傢伙是史蒂芬‧彭伯頓（Stephen Pemberton），他應該是本地人，是個聰明過人的傢伙。規範本身也很了不起，如果所有人都同意使用的話，也一定是非常好的格式。只不過，還不夠實際。
首先，XHTML 2仍然使用XML錯誤處理模型，你必須保證以XML文件類型發送文件；這一點不言自明：沒人願意這樣做。其次，XHTML 2有意不再向後相容已有的HTML的各個版本。他們甚至曾經討論過廢除img元素，這對每天都在做Web開發的人來說確實有點瘋了的味道。但我們知道，他們之所以這樣做，理論上確實有充足的理由——使用object元素可能會更好。
因此，無論XHTML 2在理論上是多麼完美的一種格式，但卻從未有機會付諸實踐。而之所以難以付諸實踐，就是因為像你我這樣的開發人員永遠不會支援它，它不向後相容。同樣，瀏覽器廠商也不會，瀏覽器廠商必須確保向後相容。
為什麼XHTML 1.1沒有像XML那樣真正廣泛應用，為什麼XHTML 2從未落實？因為它違反了一條設計原理，這條設計原理就是著名的伯斯塔爾法則（Postel’s Law）。大家都知道：

發送時要保守；接收時要開放。

沒錯，接收的時候要開放，而這也正是Web得以建構的基礎。開發瀏覽器的人必須敞開胸懷，接收所有發送給瀏覽器的東西，因為它們過去一直都在接收那些不夠標準的東西，對不對？ Web上的許多文件都不規範，但那正是Web發展的動力。從某個角度講，Web走的正是一條混沌發展之路，雖然混沌，卻非常美麗誘人。在Web上，格式不規範的文件隨處可見，但那又怎樣呢？如果所有人都能夠寫出精準的XML，所有文件的格式都十分正確，那當然好了。可是，那不現實。現實是伯斯塔爾法則。
身為專業人士，在發送文件的時候，我們會盡量保守一些，盡量採用最佳實踐，盡量確保文件格式良好。但從瀏覽器的角度說，它們必須以開放的姿態去接收任何文件。
有人可能會說XML有錯誤處理模型，XHTML 1.1和XHTML 2都使用該模型，但那個錯誤處理模型太苛刻了。它絕對不符合接收時開放這個法則，遇到一個錯誤就停止解析怎麼能叫開放呢？我們只能說它與健壯性法則（也就是伯斯塔爾法則）是對立的。

HTML5

之後，就到了HTML5，但HTML5並不是由W3C直接製定的​​。故事的經過是這樣的，到20世紀末的時候，還沒有HTML工作組，W3C內部的一些人就開始琢磨了，「HTML也許還可以更長壽一點，只要我們對它稍加擴展就行了。只要把我們放在XHTML上的時間和精力拿出一部分來，就可以提升一下HTML中的表單，可以讓HTML更接近程式語言，就可以讓它更上一層樓。 W3C成員內部的研討會上，當時Opera公司的代表伊恩·希克森（Ian Hickson）提出了一個擴展和改進HTML的建議。他建議新任務小組可以跟著XHTML 2並行，但在已有HTML的基礎上進行工作，目標是擴充HTML。 W3C投票表決的結果是—“反對”，因為HTML已經死了，XHTML 2才是未來的方向。然後，Opera、Apple等瀏覽器廠商，以及其他一些成員說：「那好吧，不指望他們了，我們自已一樣可以做這件事，我們脫離W3C。」他們成立了Web Hypertext Applications Technology Working Group（ Web超文本應用技術工作小組，WHATWG）－可巧的是，他們自稱工作小組，而不是特別小組（task force），這就為HTML5將來的命運埋下了伏筆。
WHATWG決定完全脫離W3C，在HTML的基礎上開展工作，並在其中添加一些新東西。這個工作小組的成員裡有瀏覽器廠商，因此他們不僅可以說加就加，而且還能夠一一實現。結果，大家不斷提出一些好點子，並且逐一做到了瀏覽器中。
WHATWG的工作效率很高，不久就初見成效。在此期間，W3C的XHTML 2沒有什麼實質的進展。特別是，如果從實現的角度來說，用原地踏步形容似乎也不為過。
結果，一件有意思的事情發生了。那是在2006年，蒂姆·伯納斯-李寫了一篇博客，說：“你們知道嗎？我們錯了。我們錯在企圖一夜之間就讓Web跨入XML時代，我們的想法太不切實際了，是的，也許我們應該重新組成HTML工作小組了。 W3C在2007年組成了HTML5工作小組。這個工作小組面臨的第一個問題，毫無疑問就是「我們是從頭開始做起呢，還是在2004年成立的那個叫WHATWG的工作組既有成果的基礎上開始工作呢？」答案是顯而易見的，他們當然希望從已經取得的成果著手，以之為基礎展開工作。於是他們又投了一次票，同意「在WHATWG工作成果的基礎上繼續開展工作」。好了，這下他們要跟WHATWG並肩戰鬥了。
第二個問題就是如何理順兩個工作組之間的關係。 W3C這個工作小組的編輯應該由誰擔任？是不是還讓WHATWG的編輯，也就是現在Google的伊恩‧希克森來兼任？於是他們又投了一次票，贊成「讓伊恩·希克森擔任W3C HTML5規範的編輯，同時兼任WHATWG的編輯，更有助於新工作組開展工作。」
這就是他們投票的結果，也就是我們今天看到的局面：一種格式，兩個版本。 WHATWG的網站上有這個規範，而W3C的網站上同樣也有一份。
如果你不了解內情，很可能會產生這樣的疑問：「哪個版本才是真正的規範？」當然，這兩個版本內容是一樣的…基本上相同。實際上，這兩個版本將來還會分道揚鑣。現在已經有了分道揚鑣的跡象了。我的意思是說，W3C最終要製定一個具體的規範，這個規範會成為一個工作草案，定格在某個歷史時刻。
而WHATWG呢，他們還在不斷地迭代。即使目前我們說的HTML5，也不能完全涵蓋WHATWG正在從事的工作。最準確的理解是他們正在開發一項簡單的HTML或Web技術，因為這才是他們工作的核心目標。然而，同時有兩個這樣的工作小組，這兩個工作小組同時發展一個基本上相同的規範，這無論如何也容易讓人產生誤解。誤解就可能造成麻煩。
其實這兩個工作小組背後各自有各自的流程，因為它們的理念完全不同。在WHATWG，可以說是一種獨裁的工作機制。我剛才說了，伊恩·希克森是編輯。他會聽取各方意見，在所有成員各抒己見，充分陳述自己的觀點之後，他批准自己認為正確的意見。
W3C則是截然相反，可以說是一種民主的工作機制。所有成員都可以發表意見，而且每個人都有投票表決的權利。這個流程的關鍵在於投票表決。從表面上看，WHATWG的工作機制讓人不好接受。豈止不好接受，簡直是歷史的倒退。相信誰都會認為「運作任何專案都不能採取這種方式！」
W3C的工作機制聽起來讓人很舒服。至少體現了人人平等嘛。但在實務中，WHATWG的工作機制運作得非常非常好。我認為之所以會這樣，主要歸功於伊恩·希克森。他的的確確是一個非常稱職的編輯。他在聽取各方意見時，始終可以做到絲毫不帶個人感情色彩。
從原理上講，W3C的工作機制很公平，而實際上卻非常容易在某些流程或環節上卡殼，造成工作停滯不前，一件事情要達成決議往往需要花費很長時間。那到底哪種工作機制最好呢？我認為，最好的工作機制是將二者結合。而事實也是兩個規範制定主體在共同製定一份相同的規範，我想，這倒是非常有利於兩種工作機制相互取長補短。
兩個工作小組之所以能夠同心同德，主要原因是HTML5的設計思想。因為他們從一開始就確定了設計HTML5所要堅持的原則。結果，我們不僅看到了一份規範，也就是W3C站點上公佈的那份文檔，即HTML5語言規範，還在W3C站點上看到了另一份文檔，也就是HTML設計原理。而這份文檔的一位編輯今天也來到了我們大會的現場，她他就是安妮·奇泰絲（Anne Van Kesteren）。如果大家對這份文檔有問題，可以請教安妮。
這份文件非常好，真的非常出色。這份文檔，可以說見證了W3C與WHATWG同心共謀發展的歷程。難道你們不覺得他們像是一對歡喜冤家嗎？那他們還怎麼同心同德呢？這份文件忠實地記錄了他們一道做了什麼，他們共同擁護什麼。
接下來，我想要講的就是這份文檔。因為，既然他們能就這份文檔達成共識，那麼我相信，HTML5必將是一個偉大的規範，而他們已經認可這就是他們的共同行動綱領。為此，你才會看到諸如相容性、實用性、互用性之類的概念。即便W3C與WHATWG之間再有多大的分歧——確實相當多——至少他們還有這份文件中記錄的共識。這一點才是至關重要的。正因為他們有了共識，才有了這份基於共識描述設計原理的文件。

避免不必要的複雜性

下面我就來跟大家介紹一些這份文件中記載的設計原理。第一個，非常簡單：避免不必要的複雜性。好像很簡單吧。我用一個例子來說明。

假設我使用HTML 4.01規範，我開啟文檔，輸入doctype。這裡有人記得HTML 4.01的doctype嗎？好，沒有，我猜沒有。除非……我的意思是說，你是傻冒。現場恐怕真有人背過，這就是HTML 4.01的doctype：

複製代碼

代碼如下:

br />

/p>"http://www.w3.org/TR/html4/strict.dtd">

我不記這個兩行程式碼，不然還要記事本、要Google、要模板有什麼用呢？

要是我使用XHTML 1.0呢，這個規範我都已經用了10年了。有誰記得住這個doctype嗎？沒錯，它的長度跟HTML 4.01的差不太多：

複製代碼

代碼如下:

/p>

p> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

是不是，基本上相同。它要告訴瀏覽器的是：這個文件是XHTML 1.0的文檔。那麼在HTML 5中，省掉不必要的複雜性，doctype就簡化成了：

複製代碼

代碼如下:🎜>

僅此而已。好了，就連我也能過目不忘了。我用不著把這幾個字符記在記事本裡了。我必須說，在我第一次看到這個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。
下面我出一道有獎搶題，聽好：「一分鐘後開始，如果你手快的話，第一個在文檔前面寫完doctype html，然後我用Internet Explorer打開你的文檔，會觸發它的標準模式，還是會觸發它的相容模式？ 」
答案是，這是在Internet Explorer中觸發標準模式的最少字元數目。我認為這也說明了HTML5規範的本質：它不追求理論上的完美。 HTML5所體現的不是“噢，給作者一個簡短好記的doctype不好嗎？”，沒錯，簡短好記是很好，但如果這個好記的doctype無法適應現有的瀏覽器，還不如把它忘了更好。因此，這個平衡把握得非常好，不僅理論上是個好主意──簡短好記的doctype，實務上同樣也是個好主意──仍然可以觸發標準模式。應該說，Doctype就是一個非常典型的例子。
還有一個例子，同樣可以說明規範是如何省略不必要的複雜性，避免不必要的複雜性的。如果前面的文件使用的是HTML 4.01，假設我要指定文件的字元編碼。理想的方式，是透過伺服器在頭部資訊中傳送字元編碼，不過也可以在文件這個層級上指定：

複製程式碼

程式碼如下:

同樣，我也不會把這行程式碼背下來。我還想省下自己的腦細胞去記點別的更有價值的東西呢。不過，如果我想指定文件使用UTF-8編碼，只能加入這行程式碼。這是在HTML 4.01中需要這樣做。要是你在XHTML 1.0指定同樣的編碼，就得多敲一下鍵盤，因為你還得聲明meta元素位於一個開始的XML標籤中。

複製程式碼

程式碼如下:

在HTML5中，你要敲的字元只有：

複製程式碼

程式碼如下:

簡短好記。我能背下來。

同樣，這樣寫也是有效的。它不僅適用於最新版本的瀏覽器，只要是今天還有人在使用的瀏覽器都同樣有效。為什麼？因為當我們把這些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。避免-不必要的-複雜性。

支援已有的內容

支援已有的內容。這點非常重要，因為很多人都認為HTML5很新，很閃亮；它應該代表未來發展的方向，應該把Web推向一個新的發展階段。這就是HTML5，對嗎？顯然，我們都會考慮讓Web的未來發展得更好，但他們必須考慮過去。別忘了W3C這個工作小組中有很多人代表的是瀏覽器廠商，他們一定是要考慮支援已有內容的。只要你想建立一款瀏覽器，就必須記住這個原則：必須支援現有的內容。
下面我們就來看一個HTML5支援已有內容的範例。
這個例子展示了編寫同樣內容的四種不同方式。上面是一個img元素，下面是帶一個屬性的段落元素。四種寫法唯一的不同點就是文法。把其中任何一段程式碼交給瀏覽器，瀏覽器都會產生相同的DOM樹，沒有任何問題。從瀏覽器的角度來看，這四種寫法並沒有差別。因而在HTML5中，你可以隨意使用下列任何語法。

複製程式碼

程式碼如下:

Hello world

Hello world

Hello world

Hello world

好了，看到這幾段程式碼，恐怕有人會說「不對不對不對。其中只有一個是對的，另外三個－－說不好。」不對，應該給屬性值加引號！拜託，我們可是一直都給屬性值加引號的！元素名大寫對嗎？這種做法10年不是就被拋棄了嗎？
看到HTML5同時允許這些寫法，我心裡忍不住一陣陣想吐。我寫了10年的XHTML 1.0，已經非常適應嚴格的文法了。但你必須明白，站在瀏覽器的角度上，這些寫法其實都是一樣的。確實沒有什麼問題。
還有誰也感到不舒服了嗎？有誰看到這些之後想「噢，這不是亂寫嘛，這樣做不對」？只有我這樣想嗎？還有別人嗎？
但是，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自然也不能例外。歸根究底還是伯斯塔爾法則。我們始終離不開伯斯塔爾法則。

解決現實的問題

HTML5的另一個設計原理是解決現實的問題。顯而易見的是，解決各種問題的格式和規範已經比比皆是了，因此在我看來，這個原理其實是要解決理論問題，而非解決現實的問題。這條設計原理是要從理論上承認人們普遍存在的問題，消除敏感問題。但在我看來，那些格式和規範要解決的都是理論問題，而非現實問題。這條設計原理才是真正要解決今天的人所面臨的現實問題、令人頭痛的問題。
下面我來舉個例子。相信這個例子有不少人都遇過。假設我使用HTML 4或XHTML 1，頁面中已經有了一塊內容，我想為整塊內容加個鏈接，怎麼辦？問題是這塊內容包含一個標題，一個段落，也許還有一張圖片。如果我想給它們全部都可以點擊，必須使用3個連結元素。於是，我得先把遊標放在標題（比如說h2元素）中，寫一個連結標籤，然後再選中所有要包含到連結裡面來的文字。接著，再把遊標放在段落裡，寫一個連結標籤，然後把段落中的文字放在連結裡…

複製程式碼

程式碼如下:

Headline text

Paragraph text.

在HTML5中，我只要簡單地把所有內容都包裝在一個連結元素中就行了。

複製程式碼

程式碼如下:

Headline text

Paragraph text.

沒錯，連結包含的都是區塊級元素，但現在我可以用一個元素包含它們。這樣太好了。因為我碰到過類似的情形，必須給幾個塊級元素加上相同的鏈接，所有能這樣寫就太好了。為此，我非常歡迎HTML5這個新標準。

它解決了一個現實的問題。我敢說在座不少朋友都曾經遇到這個問題。

那這到底解決的是什麼問題呢？瀏覽器不必因此重新寫入程式碼來支援這種寫法。這種寫法其實早就已經存在於瀏覽器中了，因為早就有人這樣寫了，當然以前這樣寫是不合乎規範的。所以，說HTML5解決現實的問題，其本質還是「你都這樣寫了很多年了吧？現在我們把標準改了，允許你這樣寫了。」

求真務實

在所有設計原理中，這條恐怕是最響亮的了－求真務實。不知道大家有沒有在公司開會時聽過這種口號：「開拓進取，求真務實。」實際上，除了作為企業的口號，它還是一條非常重要的設計原理，因為求真務實對於HTML的意思是：在解決那些令人頭痛的問題之前，先看看人們為應對這些問題都想出了哪些辦法。集中精力去理解這些「民間的」解決方案才是當務之急。
HTML5中新的語意元素就是遵循求真務實原理的反映。新增的元素不算多，談不上無限的擴充性，但卻不失為一件好事。儘管數量屈指可數，但意義卻非同一般。這些新元素涉及頭部（header）、腳部（footer）、分區（section）、文章（article）……，相信大家都不會覺得陌生。我的意思是說，即便你不使用HTML5，也應該熟悉這些稱呼，這些都是你曾經使用過的類名，比如class=”header”/“head”/“heading”，或class=”footer” /“foot”。當然，也可能是ID，id=”header”，id=”footer”。這些不都是我們已經司空見慣了的嘛。
好，舉個例子吧，假設你今天寫了下面這篇文件。

複製程式碼

程式碼如下:

程式碼如下:

...

...

...

...

...

這裡有一個div使用了id=”header”，另一個div使用了id=”navigation”，…。怎麼樣，都輕車熟路了吧？在HTML5中，這些元素都可以換掉。說起新增的語意元素，它們價值的一方面可以這樣來體現：「嘿，看啊，這樣多好，用HTML5新增的元素可以把這些div都替換掉。」

複製程式碼

程式碼如下:

...

...

...

...

...

當然了，你可以這樣做。在文件層級上使用這些元素沒有問題。但是，如果新增這些元素的目的只是為了取代原來的div，那就真是有點多此一舉了。
雖然在這個文件中，我們用這些新元素來替換的是ID，但在我個人看來，將它們作為類的替代品更有價值。為什麼這麼說呢？因為這些元素在一個頁面中不只可以使用一次，而是可以使用多次。沒錯，你可以為文件添加一個頭部（header），再增加一個腳部（footer）；但文件中的每個分區（section）照樣也都可以有一個頭部和一個腳部。而每個分區裡還可以嵌套另一個分區，被嵌套的分區仍然可以有自己的頭部和腳部，是這樣吧？
這四個新元素：section、article、aside和nav，之所以說它們強大，原因在於它們代表了一種新的內容模型，一種HTML中前所未有的內容模型——給內容分區。到目前為止，我們一直都在用div來組織頁面中的內容，但與其他類似的元素一樣，div本身並沒有語義。但section、article、aside和nav實際上是在明確地告訴你——這一塊就像文檔中的另一個文件一樣。位於這些元素中的任何內容，都可以擁有自己的概要、標題，自己的腳部。
其中最為通用的section，可以說是與內容最相關的一個。而article則是一種特殊的section。 Aside呢，是一種特殊的section。最後，Nav也是一種特殊的section。
好，即便是現在，你照樣可以使用div和類別來描述頁面中不同的部分，就像下面這樣：

複製程式碼

程式碼如下:

...

...

...

...

其中包含可能是有關內容作者的元數據，而下面會給出一些鏈接，差不多就這樣。在HTML5中，我完全可以說這塊內容就是一個文檔，透過對內容分區，使用section或article或aside，我可以說「這一塊完全是可以獨立存在的。」因此，我當然可以使用header和footer 。

複製程式碼

程式碼如下:

...

...

...

...

請注意，即便是footer，也不一定要出現在下面，不是嗎？這幾個元素，header、footer、aside、nav，最重要的是它們的語意；跟位置沒有關係。一想到footer這個詞，我們總會不由自主地想，「噢，應該放在下面。」同樣，我們把aside想像成一個側邊欄。可是，如果你看一看規範，你會發現這些元素只跟內容有關。因此，放在footer中的內容也可以是署名，文章作者之類的，它只是你使用的一個元素。這個元素並沒有說「必須把我放在文件或分區的下面。」
這裡，請注意，最重要的還不是我用幾個新元素替換了原來的div加類，而是我把原來的H2換成了H1——震撼吧，我看到有人發抖了。我碰到過不少職業的Web開發人員，多年來他們一直認為規範裡說一個文檔中只能有一個H1。還有一些自詡為萬能的SEO秘訣也說要這樣。很多SEO的技巧其實是很教條的。所謂教條，意思就是不相信數據。過去，這種教條表現為「不行，頁面中包含兩個以上的H1，你就會死掉的。」在HTML5中，只要你建立一個新的內容塊，不管用section、article、aside、nav，還是別的元素，都可以在其中使用H1，而不必擔心這個區塊裡的標題在整個頁面中應該排在什麼級別；H2、H3，都沒有問題。
這個變化太厲害了。想一想吧，這個變化對內容管理來說是革命性的。因為現在，你可以把每個內容分區想像一個獨立的、能夠從頁面中拿出來的部分。此時，根據上下文不同，這個獨立部分中的H1，在整個頁面中沒準會扮演H2或H3的角色－取決於它在文件中出現的位置。面對這個突如其來的變化，也許有人的腦會暫時轉不過彎來。不要緊，但我可以告訴你，我認為這才是HTML5中這些新語意標記的真正價值所在。換句話說，我們現在有了獨立的元素了，這些元素中的標題等級可以重新定義。
我的文件中可能會包含一個分區，這個分區中可能會嵌套另一個分區，或者一篇文章，然後文章再嵌套分區，分區再嵌套文章、嵌套分區，文章再嵌套文章。而且每個分區和文章都可以擁有自己的H1到H6。從這個意義上講，H元素真可謂「子子孫孫，無窮匱也」了。但是，在你寫內容或內容管理系統的時候，它們又都是獨立的，完全獨立的內容區塊。這才是真正的價值。
實際上，這個點子並不是HTML5工作組拍腦門想出來的，也不是W3C最近才提出來的。以下這幾句話摘自蒂姆·伯納斯-李1991年的一封郵件，郵件是發給丹·康納利（Dan Connolly）的。他在郵件中解釋了對HTML的理解，他說：「你知道…知道我的想法，我認為H1、H2這樣單調地排下去不好，我希望它成為一種可以嵌套的元素，或者說一個通用的H元素，我們可以在其中嵌套不同的層次。內容。 20年後的今天，這個理想終於實現了。

平穩退化

下一條原理大家應該都很熟悉了，那就是平穩退化。畢竟，我們已經遵守這條規則好多年了。漸進增強的另一面就是平穩退化。
有關HTML5遵循這條原理的例子，就是使用type屬性增強表單。下面列出了可以為type屬性指定的新值，有number、search、range，等等。

複製代碼

代碼如下:

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=”html5設計原理(推薦收藏)_html5教學技巧”，現有的任何瀏覽器都會說：“嗯，也許作者的意思是text。”因而，你從現在開始就可以使用這些新值，而且你也可以放心，那些不理解它們的瀏覽器會把新值看成type=”text”，而這真是一個瀏覽器實踐平穩退化原理的好例子。
比如說，你現在輸入了type=”number」。假設你需要一個輸入數值的文字方塊。那你可以把這個input的type屬性設定為number，然後理解它的瀏覽器就會呈現一個可愛的小控件，像是帶有小箭頭圖示的微調控件之類的。對吧？而在不理解它的瀏覽器中，你會看到一個文字框，一個你再熟悉不過的文字框。既然如此，為什麼不能說輸入type=”number」就會得到一個帶有小箭頭圖示的微調控制呢？
當然，你也可以設定最小和最大值屬性，它們同樣可以平穩退化。這是問題的關鍵。
再看input type=”search”。你也可以考慮一下這種輸入框，因為這種輸入框在Safari中會被呈現為一個系統級的搜尋控件，右邊還有一個點擊即可清除搜尋關鍵字的X。而在其他瀏覽器中，你得到的則是一個文字框，就像你寫的是input type=”text”一樣，也就是你已經非常熟悉的文字框。那為什麼還不使用input type=”search”呢？它不會有什麼副作用，沒有，對不對？
HTML5也為輸入元素增加了新的屬性，例如placeholder（佔位符）。有人不知道這個屬性的用嗎，沒有吧？沒錯，就是用於在文字方塊中預先放一些文字。不對，不是標籤（label）──佔位符和標籤完全不是一回事。佔位符就是文字方塊可以接受的範例內容，一般顏色是灰色的。只要你一點擊文字框，它就消失了。如果你把已經輸入的內容全部刪除，然後點選了文字方塊外部，它又會出現。
使用JavaScript寫一些程式碼當然也可以實作這個功能，但HTML5只用一個placeholder屬性就幫我們解決了問題。
當然，對於不支援這個屬性的瀏覽器，你還是可以使用JavaScript來實作佔位符功能。透過JavaScript來測試瀏覽器支不支援該屬性也非常簡單。如果支持，退後一步，把路讓開，樂享其成即可。如果不支持，可以再讓你的JavaScript來模擬這個功能。
現在，我不得不提另一個主題了：HTML5對Flash。也許你早聽過了，或是在哪裡看到了這方面的討論。說實話，我一點也不明白。我搞不懂人們怎麼會僅憑自己的推測來展開爭論。
首先，他們所說的HTML5對Flash，並不是指的HTML5，也不是指的Flash。而是指HTML5的一個子集和Flash的子集。具體來說，他們指的是影片。因此，不管你在哪裡聽到別人說“HTML5對Flash”，那很可能說的只是HTML5視頻對Flash視頻。
其次，一說HTML5對Flash，就好像你必須作選擇一樣：你站在哪一邊？實際上不是這樣的。 HTML5規範的設計能讓你做到魚和熊掌兼得。
好，下面就來看看這個新的video元素；真是非常貼心的一個元素，而且設計又簡單，又實用。一個開始的video元素，加上一個結束的video元素，中間可以放後備內容。注意，是後備內容，不是保證可訪問性的內容，是後備內容。以下就是針對不支援video元素的瀏覽器所寫的程式碼：

複製程式碼

程式碼如下:

那麼，在後備內容裡面放些什麼東西呢？好，你可以放Flash影片。這樣，HTML5的影片與Flash的影片就可以協同起來了。你不用作出選擇。

複製程式碼

程式碼如下:

當然，你的程式碼其實沒有這麼簡單。因為這裡我使用了H264，部分瀏覽器支援這種影片格式。但有的瀏覽器不支援。
對不起，請不要跟我談影片格式，我一聽就心煩。不是因為技術。技術倒無所謂，關鍵是會牽扯到一大堆專利還有律師、智慧財產權等等，這些都是Web的天敵，對我建網站一點好處都沒有。
可你實際上要做的，僅僅就是把後備內容放在那而已，後備內容可以包含多種影片格式。如果願意的話，可以使用source元素而非src屬性來指定不同的視訊格式。

複製程式碼

程式碼如下:

上面的程式碼包含了4個不同的層次。
1、如果瀏覽器支援video元素，也支援H264，沒什麼好說的，用第一個影片。
2、如果瀏覽器支援video元素，支援Ogg，那麼用第二個影片。
3.如果瀏覽器不支援video元素，那麼就要試試Flash影片了。
4、如果瀏覽器不支援video元素，也不支援Flash，我還給了下載連結。

不錯，一開始就能考慮這麼周到很難得啊。有了這幾個層次，已經夠完善了。

總之，我建議你各種技術要兼顧，無論是HTML5，還是Flash，一個也不能少。如果只使用video元素提供視頻，難免搬起石頭砸自己的腳，我個人認為。而如果只提供Flash影片，情況也好不到哪裡去，性質是一樣的。所以還是應該兩者兼顧。

為什麼要兼顧這兩種技術？假設你需要面向某些不支援Flash的手持設備——只是舉個例子——提供視頻，你當然希望手持設備的用戶能夠看到視頻了，不是嗎？

至於為什麼要使用不同的格式，為什麼Flash視訊和音訊如此成功，我想可以歸結為另一個設計原理，即梅特卡夫定律(Metcalfe’s Law)：

網路價值同網路使用者數量的平方成正比。

梅特卡夫的這個定律雖然是針對電話網提出來的，但在許多領域裡也是適用的。使用網路的使用者越多，網路的價值就越大。人人都上Facebook，還不是因為人人都去Facebook嘛。雖然Facebook真正的價值不在於此，但只有人人上才會讓它的變得如此有價值。
梅特卡夫定律也適用於傳真機。如果只有一個人買了傳真機，當然也沒有什麼用處。但如果其他人也陸續買了傳真機，那麼他的投資就會得到回報。
當然，面對競爭性的視頻格式和不同的編碼方式，你感覺不到梅特卡夫定律的作用，我也很討厭以不同的方式來編碼視頻，但只向瀏覽器發送用一種方式編碼的影片是行不通的。而這也正是Flash在視訊/音訊領域如此成功的原因。你只要把Flash影片傳送給瀏覽器就好了，然後安裝了插件的瀏覽器都能正常播放。本質上講，Flash利用了梅特卡夫定律。

最終用戶優先

今天我要講的最後一個設計原理，也是我個人最推崇的一個，但沒有要展示的程式碼範例。這個原理更有哲學的味道，即最終用戶優先。
這個設計原理本質上是一種解決衝突的機制。換句話說，當你面臨一個要解決的問題時，如果W3C給了一個解決方案，而WHATWG給了另一個解決方案，一個人這麼想，另一個人那麼想…這時候，有人站出來說：「對這個問題我們這樣來解決。」

一旦遇到衝突，最終用戶優先，其次是作者，其次是實現者，其次標準制定者，最後才是理論上的完滿。
理論上的完滿，大致是指盡可能創造出最完美的格式。標準制定者，指的是工作小組、W3C，等等。實現者，指的是瀏覽器廠商。作者，就是我們這些開發人員，對吧？看看我們在這個鏈條裡面的位置多靠上！我們的地位僅次於最終用戶——事情本來就是這個樣子。用戶是第一位的。而我們的聲音在標準制定過程中也同樣非常非常重要。
Hixie（即Ian Hickson， Acid2、Acid3的作者及維護者，HTML5、CSS 2.1規範的製定者）經常說，在有人建議了某個特性，而HTML5工作組為此爭論不下時，如果有瀏覽器廠商說“我們不會支援這個特性，不會在我們的瀏覽器中實現這個特性”，那麼這個特性就不會寫進規範。因為即使是把特性寫進規範，如果沒有廠商實現，規範不過是一紙空文，對不對？實現者可以拒絕實現規範。
而根據最終用戶優先的原理，我們在鏈條中的位置高於實現者，假如我們發現了規範中的某些地方有問題，我們想「這樣規定我們不能同意，我們不支持實現這個特性”，那麼就等於把相應的特性給否定了，規範裡就得刪除，因為我們的聲音具有更高的權重。我覺得這樣挺好！本質上是我們擁有了更大的發言權，對吧？我認為開發人員就應該擁有更多的發言權。
我覺得這應該是最重要的一條設計原理了，因為它承認了你的權利，無論是設計一種格式，還是設計軟體，這條原理保證了你的發言權。而這條原理也正道出了事物運作的本質。難道還不夠明顯嗎？使用者的權利大於作者，作者的權利大於實現者，實現者的權利大於標準制定者。然而，反觀其他規範，例如XHTML2，你會發現完全相反的做法。把追求理論的完滿放在第一位，而把用戶——需要忍受嚴格錯誤處理帶來的各種麻煩的用戶——放在了鏈條的最底端。我並沒有說這種做法就是錯的，但我認為這是一種完全不同的思考方式。
因此，我認為無論你做什麼，不管是建立像HTML5這樣的格式，還是建立一個網站，亦或是一個內容管理系統，明確你的設計原理都至關重要。

軟體，就像所有技術一樣，具有天然的政治性。代碼必然會反映作者的選擇、偏見和期望。

下面我們來講一個例子。 Drupal社群曾聯絡馬克·博爾頓（Mark Boulton）和麗莎·雷賀特（Leisa Reichilt）設計Drupal的介面。他們計劃遵循一些設計原理。為此，他們並沒有紙上談兵，而是經過了一段時間的思考和醞釀，提出指導將來工作的4個設計原理：

簡化最常見的任務，讓不常見的任務不至於太麻煩。
只為80%設計。
給內容創作者最大的權利。
預設設定智能化。

實際上，當我跟馬克談到這個問題時，馬克說主要還是那兩個，即「只為80%設計。給內容創作者最大的權利。」這就很不錯了，至少它表明了立場，「我們認為內容創作者比這個專案中的任何人都重要。」在製定設計原則時，很多人花了很多時間都抓不住重點，因為他們想取悅所有人。關鍵在於我們不是要取悅所有人，而是要明確哪些人最重要。他們認為內容創作者才是最重要的。
另一條設計原理，只為80%設計，其實是一條常見的設計原理，也是一種通用模式，即帕累托原理（Pareto principle）。
帕累托是義大利經濟學家，他提出這個比例，80/20，說的是世界上20%的人口擁有80%的財富。這個比例又暗合了自然界各領域的冪律分佈現象。總之，無論你是寫軟體，還是製造什麼東西，都是一樣的，也就是20%的努力可以觸及80%的用例。最後20%的用例則需要付出80%甚至更多的努力。因此，有時候據此確定只為80%設計是很合理的，因為我們知道為此只要付出20%的努力即可。
再比如，微格式同樣也利用了帕累托原理，只處理常見用例，而沒有考慮少數情形。他們知道自己不會讓所有人都滿意；而他們的目標不是讓所有人都滿意。他們遵循的設計原理很多，也都非常有價值，但最吸引人的莫過於下面這條了：

先為人類設計，其次是機器設計。

同樣，你我都會覺得這是一條再明顯不過的道理，但現實中仍然有不少例子違反了這條原理：容易讓機器理解（解析）比容易讓用戶理解更重要。
所以，我認為平常多看一看別人推崇的設計原理，有助於做好自己手邊的工作。你可以把自己認為有道理的設計原理貼在牆上。當然，你可以維護一個URL，把自己認為有價值的設計原理分享出來，就像Mozilla基金會那樣，對不對，以下是Mozilla的設計原理：

Internet作為一種公共資源，其運作效率取決於互通性（協定、資料格式、內容）、變革及全球範圍內的協作。
基於透明社區的流程有助於增進協作、義務和信任。