html5的設(shè)計(jì)原理是什么

本篇內(nèi)容主要講解“html5的設(shè)計(jì)原理是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“html5的設(shè)計(jì)原理是什么”吧!

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

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

設(shè)計(jì)原理

設(shè)計(jì)原理本質(zhì)上是一種信念、一種想法、一個(gè)概念，是你行動(dòng)的支柱。不管你是制定規(guī)范，還是制造一種有形的物品，或者編寫軟件，甚至發(fā)明編程語言。你都能找到背后的一個(gè)或者多個(gè)設(shè)計(jì)原理，多人協(xié)作的任何成果都是例證。不僅僅Web開發(fā)領(lǐng)域是這樣?？v觀人類歷史，像國家和社會(huì)這樣大規(guī)模的構(gòu)建活動(dòng)背后，同樣也有設(shè)計(jì)原理。
就拿美國為例吧，美國的設(shè)計(jì)原理都寫在了《獨(dú)立宣言》中了。
我們認(rèn)為這些真理是不言而喻的，人人生而平等，造物主賦予了每個(gè)人不可剝奪的權(quán)利，包括生存、自由和追求幸福。
這里有一句口號(hào)：生存、自由和追求幸福。這是被寫進(jìn)憲法中的核心理念，它關(guān)系到我們所有人的一切，也就是我們構(gòu)建自己社會(huì)的原則。
還有一個(gè)例子，就是卡爾·馬克思（Karl Marx），他的著作在20世紀(jì)曾被奉為建設(shè)社會(huì)主義的圭臬。其基本思想大致可以歸結(jié)為下面這條設(shè)計(jì)原理：

各盡所能，各取所需。

這其實(shí)就是一種經(jīng)濟(jì)體系背后的設(shè)計(jì)原理。

還有一個(gè)例子，比前面兩個(gè)的歷史更久遠(yuǎn)一些，不過大同小異：

人人為我，我為人人。

這個(gè)極為簡單的設(shè)計(jì)原理，是兩千年前的拿撒勒猶太人耶穌基督提出來的。而這條原則成為了后來許多宗教的核心教義。原理與實(shí)踐有時(shí)候并不是同步的。
下面是小說中的一個(gè)例子。英國小說家喬治·奧威爾（George Orwell）筆下的《動(dòng)物莊園》，就是在一條設(shè)計(jì)原理的基礎(chǔ)上構(gòu)建起來的虛擬社會(huì)。這條設(shè)計(jì)原理是：
四條腿的都是好人，兩條腿的都是壞蛋！
《動(dòng)物莊園》中有意思的是，隨著社會(huì)的變遷——變得越來越壞，這條設(shè)計(jì)原理也跟著發(fā)生了改變，變成了“四條腿的都是好人，兩條腿的就更好了?！弊铌P(guān)鍵的是，即使是在虛構(gòu)的作品里，設(shè)計(jì)原理都是存在的。
還有一套虛構(gòu)的作品是以三條設(shè)計(jì)原理為基礎(chǔ)構(gòu)建起來的，那就是美國著名小說家艾薩克·阿西莫夫（Issac Asimov）的機(jī)器人經(jīng)典系列。阿西莫夫發(fā)明了機(jī)器人學(xué)這個(gè)術(shù)語，并提出了機(jī)器人學(xué)三大法則，然后在這三個(gè)簡單的設(shè)計(jì)原理基礎(chǔ)上創(chuàng)作了一系列經(jīng)典作品——大約有50本書。無論作品的情節(jié)如何變化，實(shí)際上都是從不同的角度來闡釋這三大設(shè)計(jì)原理。我想，在座各位對機(jī)器人三大法則都不應(yīng)該陌生。

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

這些恐怕是第一次出現(xiàn)在小說中的針對軟件的設(shè)計(jì)原理了。雖然基于這三個(gè)設(shè)計(jì)原理的軟件運(yùn)行在虛構(gòu)的機(jī)器人的“正電子腦”中，但我想這應(yīng)該是軟件設(shè)計(jì)原理的事實(shí)開端。從此以后，我們才看到大量優(yōu)秀軟件背后的設(shè)計(jì)原理。
蒂姆·伯納斯-李（Tim Berners-Lee），Web的發(fā)明者，在W3C的網(wǎng)站上發(fā)表過一份文檔，其中有一個(gè)URL給出了他自己的一套設(shè)計(jì)原理。這些設(shè)計(jì)原理并不那么容易理解，不僅多，而且隨著時(shí)時(shí)間推移，他還會(huì)不斷補(bǔ)充、修改和刪除。不過我還是覺得把自己認(rèn)同的設(shè)計(jì)原理寫出來放在某個(gè)地方真是個(gè)不錯(cuò)的主意。
實(shí)際上，CSS的發(fā)明人之一伯特·波斯（Bert Bos），也在W3C的網(wǎng)站上放著一份文檔，其中講的都是基本的設(shè)計(jì)原理，比如怎樣設(shè)計(jì)并構(gòu)建一種格式，無論是CSS還是其他格式。推薦大家看一看。
只要你在W3C的站點(diǎn)中隨便找一找，就可以發(fā)現(xiàn)非常多的這種設(shè)計(jì)原理，包括蒂姆·伯納斯-李個(gè)人的。當(dāng)然，你還會(huì)看到他從軟件工程學(xué)校里借用的一些口號(hào)：分權(quán)（decentalisation）、容忍（tolerance）、簡易（simplicity）、模塊化（modularity）。這些都是在他發(fā)明新格式的時(shí)候，頭腦中無時(shí)無刻不在想的那些關(guān)鍵詞。
在座各位對蒂姆·伯納斯-李的貢獻(xiàn)都是非常熟悉的，因?yàn)榇蠹颐刻於荚谟?。他發(fā)明了Web，與羅伯特·卡里奧（Robert Cailliau）共同發(fā)明了Web，而且在發(fā)明Web的同時(shí)，也發(fā)明了我們每天都在Web上使用的語言。當(dāng)然，這門語言就是HTML：超文本標(biāo)記語言。

HTML

HTML最早是從2.0版開始的。從來就沒有1.0版。如果有人告訴你說，他最早是從HTML 1.0開始使用HTML的，那他絕對是在忽悠你。從前確實(shí)有一個(gè)名叫HTML Tags的文檔，其中的部分標(biāo)簽一直用到現(xiàn)在，但那個(gè)文檔并非官方的規(guī)范。
使用標(biāo)簽、尖括號(hào)、p或h2，等等，并不是蒂姆·伯納斯-李首創(chuàng)的想法。當(dāng)時(shí)的SGML里就有了這些概念，而且當(dāng)時(shí)的CERN（Conseil Europeen pour la Recherche Nucleaire，歐洲核子研究委員會(huì)）也在使用SGML的一個(gè)特定的版本。也就是說，即便在那個(gè)時(shí)代，他也沒有白手起家；這一點(diǎn)在HTML后來的發(fā)展過程中也體現(xiàn)了出來：繼往開來、承前啟后，而不是另立門戶、從頭開始。
換句話說，這篇名為HTML Tags的文檔可以算作HTML的第一個(gè)版本，但它卻不是一個(gè)正式的版本。第一個(gè)正式版本，HTML 2.0，也不是出自W3C之手。HTML 2.0是由IETF，因特網(wǎng)工程任務(wù)組（Internet Engineering Task Force）制定的。在W3C成立之前，IETF已經(jīng)發(fā)布了不少標(biāo)準(zhǔn)。但從第三個(gè)版本開始往后，W3C，萬維網(wǎng)聯(lián)盟（World Wide Web Consortium）開始接手，并負(fù)責(zé)后續(xù)版本的制定工作。
20世紀(jì)九十年代HTML有過幾次快速的發(fā)展。眾所周知，在那個(gè)時(shí)代要想構(gòu)建網(wǎng)站，可是一項(xiàng)十分復(fù)雜的工程。瀏覽器大戰(zhàn)曾令人頭疼不已。市場競爭的結(jié)果就是各家瀏覽器里都塞滿了各種專有的特性，都試圖在專有特性上勝人一籌。當(dāng)時(shí)的混亂程度不堪回首，HTML到底還重不重要，或者它作為Web格式的前景如何，誰都說不清楚。
從1997年到1999年，HTML的版本從3.2到4.0到4.01，經(jīng)歷了非?？斓陌l(fā)展。問題是到了4.01的時(shí)候，W3C的認(rèn)識(shí)發(fā)生了倒退，他們說“好了，這個(gè)版本就這樣了，HTML也就這樣了；HTML 4.01是HTML的最后一個(gè)版本了，我們用不著HTML工作組了?！?br/>W3C并沒有停止開發(fā)這門語言，只不過他們對HTML不再感興趣了。在HTML 4.01之后，他們提出了XHTML 1.0。雖然聽起來完全不同，但XHTML 1.0與HTML 4.01其實(shí)是一樣的。我的意思是說，從字面上看這兩個(gè)規(guī)范的內(nèi)容是一樣的，詞匯表是一樣的，所有的元素是一樣，所有的屬性也都是一樣的。唯一一點(diǎn)不同之處，就是XHTML 1.0要求使用XML語法。也就是說，所有屬性都必須使用小寫字母，所有元素也必須使用小寫字母，所有屬性值都必須加引號(hào)，你還得記著使用結(jié)束標(biāo)簽，記著對img和br要使用自結(jié)束標(biāo)簽。
從規(guī)范本身的內(nèi)容來看，實(shí)際上是相同的，沒有什么不同。不同之處就是編碼風(fēng)格，因?yàn)閷g覽器來說，讀取符合HTML 4.01、HTML 3.2，或者XHTML 1.0規(guī)范的網(wǎng)頁都沒有問題，對瀏覽器來說這些網(wǎng)頁都是一樣的，都會(huì)生成相同的DOM樹。只不過人們會(huì)比較喜歡XHTML 1.0，因?yàn)椴簧偃苏J(rèn)同它比較嚴(yán)格的編碼風(fēng)格。
到了2000年，Web標(biāo)準(zhǔn)項(xiàng)目（Web Standards Project）的活動(dòng)開展得如火如荼，開發(fā)人員對瀏覽器里包含的那些亂七八糟的專有特性已經(jīng)忍無可忍了。大家都很生氣，就罵那些瀏覽器廠商“遵守個(gè)規(guī)范就他媽的真有那么難嗎？”當(dāng)時(shí)CSS有了長足的發(fā)展，而且與XHTML 1.0結(jié)合得也很緊密，CSS加XHTML 1.0基本上就可以算是“最佳實(shí)踐”了。雖然在我看來HTML 4.01與XHTML 1.0沒有本質(zhì)上的不同，但大家都接受了。專業(yè)的開發(fā)人員能做到元素全部小寫，屬性全部小寫，屬性值也全部加引號(hào)：由于專業(yè)人員起到了模范帶頭作用，越來越多的人也都開始支持這種語法。
我就是一個(gè)例子！過去的10年，我一直都使用XHTML 1.0文檔類型，原因是這樣一來驗(yàn)證器就能給我?guī)蜕虾艽蟮拿Γ瑢Σ粚?？只要我寫的是XHTML 1.0，然后用驗(yàn)證器測試，它就能告訴我是不是忘了給屬性值加引號(hào)，是不是沒有結(jié)束某個(gè)標(biāo)簽，等等等等。而如果我寫的是HTML 4.01，同樣的問題就變成了有效的了，驗(yàn)證器就不一定會(huì)提醒我了。
這就是我一直使用XHTML 1.0的原因。我估計(jì)很多人都……使用XHTML 1.0的朋友，請把手舉起來。好的。HTML 4.01呢？人少多了。一直沒有舉手的呢，大聲點(diǎn)，你們用什么？HTML5，也很好！更早的呢，還有人使用更早的文檔類型嗎？沒有了？
10年來我一直使用XHTML 1.0，就是因?yàn)轵?yàn)證器能夠真正幫到我。有人用XHTML 1.1嗎？你知道有人用嗎？請舉手，別放下。有人把網(wǎng)頁標(biāo)記為XML文檔嗎？有嗎？那你們使用的就不是XHTML 1.1。
這就是個(gè)大問題。XHTML 1.0之后是XHTML 1.1，只是小數(shù)點(diǎn)后面的數(shù)字加了一個(gè)1，而且從詞匯表的角度看，規(guī)范本身沒有什么新東西，元素也都相同，屬性也都相同。但對XHTML 1.1來說，唯一的變化是你必須把自己的文檔標(biāo)記為XML文檔。在使用XHTML 1.0的時(shí)候，還可以把文檔標(biāo)記為HTML，而我們也正是這樣做的，否則把文檔標(biāo)記為XML沒準(zhǔn)真會(huì)把人逼瘋的。
為什么這么說呢？首先，把文檔標(biāo)記為XML后，Internet Explorer不能處理。當(dāng)然，IE9是可以處理了?？峙掠腥藭?huì)講“真是太可愛了”，他們到現(xiàn)在居然都沒有忘了這件事。這艘船終于靠岸了！不過那時(shí)候，作為全球領(lǐng)先的瀏覽器，IE無法處理接收到的XML文檔類型的文檔，而規(guī)范又要求你以XML文檔類型來發(fā)送文檔，這不把人逼瘋才怪呢。
所以說XHTML 1.1有點(diǎn)脫離現(xiàn)實(shí)，而你不想把文檔以XML格式發(fā)送給那些能夠理解XML的瀏覽器，則是因?yàn)閄ML的錯(cuò)誤處理模型。XML的語法，無論是屬性小寫，元素小寫，還是始終要給屬性值加引號(hào)，這些都沒有問題，都很好，事實(shí)上我也喜歡這樣做，但XML的錯(cuò)誤處理模型卻是這樣的：解析器如果遇到錯(cuò)誤，停止解析。規(guī)范里就是這么寫的。如果你把XHTML 1.1標(biāo)記為XML文檔類型，假設(shè)你用Firefox打開這個(gè)文檔，而文檔中有一個(gè)和號(hào)（&）沒有正確編碼，就算整個(gè)頁面中就這一處錯(cuò)誤，你看到的也將是黃屏，瀏覽器死掉了。Firefox會(huì)說：“沒戲了，頁面中有一個(gè)錯(cuò)誤，你看不到這個(gè)網(wǎng)頁了?！备鶕?jù)XML規(guī)范，這樣處理是正確的，對Firefox而言，遇到錯(cuò)誤就停止解析，并且不呈現(xiàn)其他任何內(nèi)容是嚴(yán)格按照XML規(guī)范做的。因?yàn)樗皇荋TML，HTML根本就沒有錯(cuò)誤處理模型，但根據(jù)XML規(guī)范，這樣做沒錯(cuò)。
這就是為什么你不會(huì)把文檔標(biāo)記為XML的另一個(gè)原因。接下來，新的版本是XHTML 2，大家注意后面沒有日期，因?yàn)檫@個(gè)規(guī)范并沒有完成。
現(xiàn)在就說說XHTML 2，我很愿意把問題說清楚，XHTML 2實(shí)際上真是一個(gè)非常非常好的規(guī)范，確實(shí)非常好……從理論的角度來說。我的意思是說，制定這個(gè)規(guī)范的人都是非常非常有頭腦的。直說吧，領(lǐng)導(dǎo)制定這個(gè)規(guī)范的家伙是斯蒂芬·彭伯頓（Stephen Pemberton），他應(yīng)該是本地人，是一個(gè)聰明過人的家伙。規(guī)范本身也很了不起，如果所有人都同意使用的話，也一定是一個(gè)非常好的格式。只不過，還不夠?qū)嶋H。
首先，XHTML 2仍然使用XML錯(cuò)誤處理模型，你必須保證以XML文檔類型發(fā)送文檔；這一點(diǎn)不言自明：沒人愿意這樣做。其次，XHTML 2有意不再向后兼容已有的HTML的各個(gè)版本。他們甚至曾經(jīng)討論過廢除img元素，這對每天都在做Web開發(fā)的人來說確實(shí)有點(diǎn)瘋了的味道。但我們知道，他們之所以這樣做，理論上確實(shí)有充足的理由——使用object元素可能會(huì)更好。
因此，無論XHTML 2在理論上是多么完美的一種格式，但卻從未有機(jī)會(huì)付諸實(shí)踐。而之所以難以將其付諸實(shí)踐，就是因?yàn)橄衲阄疫@樣的開發(fā)人員永遠(yuǎn)不會(huì)支持它，它不向后兼容。同樣，瀏覽器廠商也不會(huì)，瀏覽器廠商必須要保證向后兼容。
為什么XHTML 1.1沒有像XML那樣得到真正廣泛地應(yīng)用，為什么XHTML 2從未落到實(shí)處？因?yàn)樗`反了一條設(shè)計(jì)原理，這條設(shè)計(jì)原理就是著名的伯斯塔爾法則（Postel’s Law）。大家都知道：

發(fā)送時(shí)要保守；接收時(shí)要開放。

沒錯(cuò)，接收的時(shí)候要開放，而這也正是Web得以構(gòu)建的基礎(chǔ)。開發(fā)瀏覽器的人必須敞開胸懷，接收所有發(fā)送給瀏覽器的東西，因?yàn)樗鼈冞^去一直都在接收那些不夠標(biāo)準(zhǔn)的東西，對不對？Web上的很多文檔都不規(guī)范，但那正是Web發(fā)展的動(dòng)力。從某種角度講，Web走的正是一條混沌發(fā)展之路，雖然混沌，但卻非常美麗誘人。在Web上，格式不規(guī)范的文檔隨處可見，但那又怎樣呢？如果所有人都能夠?qū)懗鼍珳?zhǔn)的XML，所有文檔的格式都十分正確，那當(dāng)然好了?？墒牵遣滑F(xiàn)實(shí)?，F(xiàn)實(shí)是伯斯塔爾法則。
作為專業(yè)人士，在發(fā)送文檔的時(shí)候，我們會(huì)盡量保守一些，盡量采用最佳實(shí)踐，盡量確保文檔格式良好。但從瀏覽器的角度說，它們必須以開放的姿態(tài)去接收任何文檔。
有人可能會(huì)說XML有錯(cuò)誤處理模型，XHTML 1.1和XHTML 2都使用該模型，但那個(gè)錯(cuò)誤處理模型太苛刻了。它絕對不符合接收時(shí)開放這個(gè)法則，遇到一個(gè)錯(cuò)誤就停止解析怎么能叫開放呢？我們只能說它與健壯性法則（也就是伯斯塔爾法則）是對立的。

HTML5

之后，就到了HTML5，但HTML5并不是由W3C直接制定的。故事的經(jīng)過是這樣的，到20世紀(jì)末的時(shí)候，還沒有HTML工作組，W3C內(nèi)部的一些人就開始琢磨了，“HTML也許還可以更長壽一點(diǎn)，只要我們對它稍加擴(kuò)展就行了。只要把我們放在XHTML上的時(shí)間和精力拿出一部分來，就可以提升一下HTML中的表單，可以讓HTML更接近編程語言，就可以讓它更上一層樓。”
于是，在2004年W3C成員內(nèi)部的一次研討會(huì)上，當(dāng)時(shí)Opera公司的代表伊恩·?？松↖an Hickson）提出了一個(gè)擴(kuò)展和改進(jìn)HTML的建議。他建議新任務(wù)組可以跟XHTML 2并行，但是在已有HTML的基礎(chǔ)上開展工作，目標(biāo)是對HTML進(jìn)行擴(kuò)展。W3C投票表決的結(jié)果是——“反對”，因?yàn)镠TML已經(jīng)死了，XHTML 2才是未來的方向。然后，Opera、Apple等瀏覽器廠商，以及其他一些成員說：“那好吧，不指望他們了，我們自已一樣可以做這件事，我們脫離W3C?！彼麄兂闪⒘薟eb Hypertext Applications Technology Working Group（Web超文本應(yīng)用技術(shù)工作組，WHATWG）——可巧的是，他們自稱工作組，而不是特別小組（task force），這就為HTML5將來的命運(yùn)埋下了伏筆。
WHATWG決定完全脫離W3C，在HTML的基礎(chǔ)上開展工作，向其中添加一些新東西。這個(gè)工作組的成員里有瀏覽器廠商，因此他們不僅可以說加就加，而且還能夠一一實(shí)現(xiàn)。結(jié)果，大家不斷提出一些好點(diǎn)子，并且逐一做到了瀏覽器中。
WHATWG的工作效率很高，不久就初見成效。在此期間，W3C的XHTML 2沒有什么實(shí)質(zhì)性的進(jìn)展。特別是，如果從實(shí)現(xiàn)的角度來說，用原地踏步形容似乎也不為過。
結(jié)果，一件有意思的事情發(fā)生了。那是在2006年，蒂姆·伯納斯-李寫了一篇博客，說：“你們知道嗎？我們錯(cuò)了。我們錯(cuò)在企圖一夜之間就讓W(xué)eb跨入XML時(shí)代，我們的想法太不切實(shí)際了，是的，也許我們應(yīng)該重新組建HTML工作組了?！鄙圃账寡?，后來的故事情節(jié)果真就是這樣發(fā)展的。W3C在2007年組建了HTML5工作組。這個(gè)工作組面臨的第一個(gè)問題，毫無疑問就是“我們是從頭開始做起呢，還是在2004年成立的那個(gè)叫WHATWG的工作組既有成果的基礎(chǔ)上開始工作呢？”答案是顯而易見的，他們當(dāng)然希望從已經(jīng)取得的成果著手，以之為基礎(chǔ)展開工作。于是他們又投了一次票，同意“在WHATWG工作成果的基礎(chǔ)上繼續(xù)開展工作”。好了，這下他們要跟WHATWG并肩戰(zhàn)斗了。
第二個(gè)問題就是如何理順兩個(gè)工作組之間的關(guān)系。W3C這個(gè)工作組的編輯應(yīng)該由誰擔(dān)任？是不是還讓W(xué)HATWG的編輯，也就是現(xiàn)在Google的伊恩·?？松瓉砑嫒危坑谑撬麄冇滞读艘淮纹?，贊成“讓伊恩·?？松瓝?dān)任W3C HTML5規(guī)范的編輯，同時(shí)兼任WHATWG的編輯，更有助于新工作組開展工作。”
這就是他們投票的結(jié)果，也就是我們今天看到的局面：一種格式，兩個(gè)版本。WHATWG的網(wǎng)站上有這個(gè)規(guī)范，而W3C的站點(diǎn)上同樣也有一份。
如果你不了解內(nèi)情，很可能會(huì)產(chǎn)生這樣的疑問：“哪個(gè)版本才是真正的規(guī)范？”當(dāng)然，這兩個(gè)版本內(nèi)容是一樣的……基本上相同。實(shí)際上，這兩個(gè)版本將來還會(huì)分道揚(yáng)鑣?，F(xiàn)在已經(jīng)有了分道揚(yáng)鑣的跡象了。我的意思是說，W3C最終要制定一個(gè)具體的規(guī)范，這個(gè)規(guī)范會(huì)成為一個(gè)工作草案，定格在某個(gè)歷史時(shí)刻。
而WHATWG呢，他們還在不斷地迭代。即使目前我們說的HTML5，也不能完全涵蓋WHATWG正在從事的工作。最準(zhǔn)確的理解是他們正在開發(fā)一項(xiàng)簡單的HTML或Web技術(shù)，因?yàn)檫@才是他們工作的核心目標(biāo)。然而，同時(shí)存在兩個(gè)這樣的工作組，這兩個(gè)工作組同時(shí)開發(fā)一個(gè)基本相同的規(guī)范，這無論如何也容易讓人產(chǎn)生誤解。誤解就可能造成麻煩。
其實(shí)這兩個(gè)工作組背后各自有各自的流程，因?yàn)樗鼈兊睦砟钔耆煌?。在WHATWG，可以說是一種獨(dú)裁的工作機(jī)制。我剛才說了，伊恩·?？松蔷庉嫛Ｋ麜?huì)聽取各方意見，在所有成員各抒己見，充分陳述自己的觀點(diǎn)之后，他批準(zhǔn)自己認(rèn)為正確的意見。
W3C則截然相反，可以說是一種民主的工作機(jī)制。所有成員都可以發(fā)表意見，而且每個(gè)人都有投票表決的權(quán)利。這個(gè)流程的關(guān)鍵在于投票表決。從表面上看，WHATWG的工作機(jī)制讓人不好接受。豈止是不好接受，簡直是歷史的倒退。相信誰都會(huì)認(rèn)為“運(yùn)作任何項(xiàng)目都不能采取這種方式！”
W3C的工作機(jī)制聽起來讓人很舒服。至少體現(xiàn)了人人平等嘛。但在實(shí)踐中，WHATWG的工作機(jī)制運(yùn)行得非常非常好。我認(rèn)為之所以會(huì)這樣，主要?dú)w功于伊恩·?？松Ｋ牡拇_確是一個(gè)非常稱職的編輯。他在聽取各方意見時(shí)，始終可以做到絲毫不帶個(gè)人感情色彩。
從原理上講，W3C的工作機(jī)制很公平，而實(shí)際上卻非常容易在某些流程或環(huán)節(jié)上卡殼，造成工作停滯不前，一件事情要達(dá)成決議往往需要花費(fèi)很長時(shí)間。那到底哪種工作機(jī)制最好呢？我認(rèn)為，最好的工作機(jī)制是將二者結(jié)合起來。而事實(shí)也是兩個(gè)規(guī)范制定主體在共同制定一份相同的規(guī)范，我想，這倒是非常有利于兩種工作機(jī)制相互取長補(bǔ)短。
兩個(gè)工作組之所以能夠同心同德，主要原因是HTML5的設(shè)計(jì)思想。因?yàn)樗麄儚囊婚_始就確定了設(shè)計(jì)HTML5所要堅(jiān)持的原則。結(jié)果，我們不僅看到了一份規(guī)范，也就是W3C站點(diǎn)上公布的那份文檔，即HTML5語言規(guī)范，還在W3C站點(diǎn)上看到了另一份文檔，也就是HTML設(shè)計(jì)原理。而這份文檔的一位編輯今天也來到了我們大會(huì)的現(xiàn)場，她他就是安妮·奇泰絲（Anne Van Kesteren）。如果大家對這份文檔有問題，可以請教安妮。
這份文檔非常好，真的非常出色。這份文檔，可以說見證了W3C與WHATWG同心協(xié)力共謀發(fā)展的歷程。難道你們不覺得他們像是一對歡喜冤家嗎？那他們還怎么同心同德呢？這份文檔忠實(shí)地記錄了他們一道做了什么，他們共同擁護(hù)什么。
接下來，我想要講的就是這份文檔。因?yàn)?，既然他們能就這份文檔達(dá)成共識(shí)，那么我相信，HTML5必將是一個(gè)偉大的規(guī)范，而他們已經(jīng)認(rèn)可這就是他們的共同行動(dòng)綱領(lǐng)。為此，你才會(huì)看到諸如兼容性、實(shí)用性、互用性之類的概念。即便W3C與WHATWG之間再有多大的分歧——確實(shí)相當(dāng)多——至少他們還有這份文檔中記錄的共識(shí)。這一點(diǎn)才是至關(guān)重要的。正因?yàn)樗麄冇辛斯沧R(shí)，才有了這份基于共識(shí)描述設(shè)計(jì)原理的文檔。

避免不必要的復(fù)雜性

下面我就給大家介紹一些這份文檔中記載的設(shè)計(jì)原理。第一個(gè)，非常簡單：避免不必要的復(fù)雜性。好像很簡單吧。我用一個(gè)例子來說明。

假設(shè)我使用HTML 4.01規(guī)范，我打開文檔，輸入doctype。這里有人記得HTML 4.01的doctype嗎？好，沒有，我猜沒有。除非……我的意思是說，你是傻冒?，F(xiàn)場恐怕真有人背過，這就是HTML 4.01的doctype：

代碼如下:

<!DOCTYPE html PUBLIC "-//W3C/DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

我不記這個(gè)兩行代碼，不然還要記事本、要Google、要模板有什么用呢？

要是我使用XHTML 1.0呢，這個(gè)規(guī)范我都已經(jīng)用了10年了。有誰記得住這個(gè)doctype嗎？沒錯(cuò)，它的長度跟HTML 4.01的差不太多：

代碼如下:

<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

是不是，基本上相同。它要告訴瀏覽器的是：這個(gè)文檔是XHTML 1.0的文檔。那么在HTML 5中，省掉不必要的復(fù)雜性，doctype就簡化成了：

代碼如下:

<!DOCTYPE html>

僅此而已。好了，就連我也能過目不忘了。我用不著把這幾個(gè)字符記在記事本里了。我得說，在我第一次看到這個(gè)doctype的時(shí)候&mdash;&mdash;我當(dāng)然以為這是一個(gè)HTML文檔的doctype&mdash;&mdash;被它嚇了一跳：“是不是還少一個(gè)數(shù)字5啊？”我心里想：“這個(gè)doctype想告訴瀏覽器什么呢？就說這個(gè)文檔是HTML嗎？難道這是有史以來唯一一個(gè)HTML版本嗎，這件事我得首先搞清楚，HTML今后永遠(yuǎn)不會(huì)再有新版本了嗎？”好一副唯我獨(dú)尊的架式！我錯(cuò)了，因?yàn)檫@個(gè)doctype并沒有這個(gè)意思。為此，必須先搞清楚為什么文檔一開頭就要寫doctype。它不是寫給瀏覽器看的。Doctype是寫給驗(yàn)證器看的。也就是說，我之所以要在文檔一開頭寫那行XHTML 1.0的doctype，是為了告訴驗(yàn)證器，讓驗(yàn)證器按照該doctype來驗(yàn)證我的文檔。
瀏覽器反倒無所謂了。假設(shè)我寫的是HTML 3.2文檔，文檔開頭寫的是HTML 3.2的doctype。而在文檔中某個(gè)地方，我使用了HTML 4.01中才出現(xiàn)的一個(gè)元素。瀏覽器會(huì)怎么處理這種情況？它會(huì)因?yàn)檫@個(gè)元素出現(xiàn)在比doctype聲明的HTML版本更晚的規(guī)范中，就不解釋呈現(xiàn)該元素嗎？不會(huì)，當(dāng)然不會(huì)！它照樣會(huì)解釋呈現(xiàn)該元素，別忘了伯斯塔爾法則，別忘了健壯性。瀏覽器在接收的時(shí)候必須要開放。因此，它不會(huì)檢查任何格式類型，而驗(yàn)證器會(huì)，驗(yàn)證器才關(guān)心格式類型。這才是存在doctype的真正原因。
而按照HTML5的另一個(gè)設(shè)計(jì)原理，它必須向前向后兼容，兼容未來的HTML版本&mdash;&mdash;不管是HTML6、HTML7，還是其他什么&mdash;&mdash;都要與當(dāng)前的HTML版本，HTML5，兼容。因此，把一個(gè)版本號(hào)放在doctype里面沒有多大的意義，即使對驗(yàn)器證也一樣。
剛才，我說doctype不是為瀏覽器寫的，這樣說大多數(shù)情況下沒有問題。在有一種情況下，你使用的doctype會(huì)影響到瀏覽器，相信在座諸位也都知道。但在這種情況下，Doctype并非真正用得其所，而只是為了達(dá)到某種特殊的目的才使用doctype。當(dāng)初微軟在引入CSS的時(shí)候，走在了標(biāo)準(zhǔn)的前頭，他們率先在瀏覽器中支持CSS，也推出了自己的盒模型&mdash;&mdash;后來標(biāo)準(zhǔn)發(fā)布了，但標(biāo)準(zhǔn)中使用了不一樣的盒模型。他們怎么辦？他們想支持標(biāo)準(zhǔn)，但也想向后兼容自己過去推出的編碼方式。他們怎么知道網(wǎng)頁作者想使用標(biāo)準(zhǔn)，還是想使用他們過去的方式？
于是，他們想出了一個(gè)非常巧妙的主意。那就是利用doctype，利用有效的doctype來觸發(fā)標(biāo)準(zhǔn)模式，而不是兼容模型（quiks mode）。這個(gè)主意非常巧妙。我們今天也都是這樣在做，在我們向文檔中加入doctype時(shí)，就相當(dāng)于聲明了“我想使用標(biāo)準(zhǔn)模式”，但這并不是發(fā)明doctype的本意。這只是為了達(dá)到特殊的目的在利用doctype。
下面我出一道有獎(jiǎng)?chuàng)尨痤}，聽好：“一分鐘后開始，如果你手快的話，第一個(gè)在文檔前面寫完doctype html，然后我用Internet Explorer打開你的文檔，會(huì)觸發(fā)它的標(biāo)準(zhǔn)模式，還是會(huì)觸發(fā)它的兼容模式？”
答案是，這是在Internet Explorer中觸發(fā)標(biāo)準(zhǔn)模式的最少字符數(shù)目。我認(rèn)為這也說明了HTML5規(guī)范的本質(zhì)：它不追求理論上的完美。HTML5所體現(xiàn)的不是“噢，給作者一個(gè)簡短好記的doctype不好嗎？”，沒錯(cuò)，簡短好記是很好，但如果這個(gè)好記的doctype無法適應(yīng)現(xiàn)有的瀏覽器，還不如把它忘了更好。因此，這個(gè)平衡把握得非常好，不僅理論上看是個(gè)好主意&mdash;&mdash;簡短好記的doctype，而且實(shí)踐中同樣也是個(gè)好主意&mdash;&mdash;仍然可以觸發(fā)標(biāo)準(zhǔn)模式。應(yīng)該說，Doctype是一個(gè)非常典型的例子。
還有一個(gè)例子，同樣可以說明規(guī)范是如何省略不必要的復(fù)雜性，避免不必要的復(fù)雜性的。如果前面的文檔使用的是HTML 4.01，假設(shè)我要指定文檔的字符編碼。理想的方式，是通過服務(wù)器在頭部信息中發(fā)送字符編碼，不過也可以在文檔這個(gè)級(jí)別上指定：

代碼如下:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

同樣，我也不會(huì)把這行代碼背下來。我還想省下自己的腦細(xì)胞去記點(diǎn)別的更有價(jià)值的東西呢。不過，如果我想指定文檔使用UTF-8編碼，只能添加這行代碼。這是在HTML 4.01中需要這樣做。要是你在XHTML 1.0指定同樣的編碼，就得多敲一下鍵盤，因?yàn)槟氵€得聲明meta元素位于一個(gè)開始的XML標(biāo)簽中。

代碼如下:

<?xml version="1.0" encoding="UTF-8" ?>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

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

代碼如下:

<meta charset="utf-8">

簡短好記。我能背下來。

同樣，這樣寫也是有效的。它不僅適用于最新版本的瀏覽器，只要是今天還有人在用的瀏覽器都同樣有效。為什么？因?yàn)樵谖覀儼堰@些meta元素輸入瀏覽器時(shí)，瀏覽器會(huì)這樣解釋它：“元數(shù)據(jù)（meta）點(diǎn)點(diǎn)點(diǎn)點(diǎn)點(diǎn)，字符集（charset）utf-8?！边@就是瀏覽器在解釋那行字符串時(shí)真正看到的內(nèi)容。它必須看到這些內(nèi)容，根據(jù)就是伯斯塔爾法則，對不對？
我多次提到健壯性原理，但總有人不理解。我們換一種說法，瀏覽器會(huì)想“好，我覺得作者是想要指定一個(gè)字符集&hellip;&hellip;看，沒錯(cuò)，utf-8?！边@些都是規(guī)范里明文規(guī)定的。如今，不僅那個(gè)斜杠可以省了，而且總共只要寫meta charset=”utf-8&Prime;就行了。
關(guān)于省略不必要的復(fù)雜性，或者說避免不必要的復(fù)雜性的例子還有不少。但關(guān)鍵是既能避免不必要的復(fù)雜性，還不會(huì)妨礙在現(xiàn)有瀏覽器中使用。比如說，在HTML5中，如果我使用link元素鏈接到一個(gè)樣式表，我說了rel=”stylesheet”，然后再說type=”text/css”，那就是重復(fù)自己了。對瀏覽器而言，我就是在重復(fù)自己。瀏覽器用不著同時(shí)看到這兩個(gè)屬性。瀏覽器只要看到rel=”stylesheet”就夠了，因?yàn)樗梢圆鲁鰜砟阋溄拥氖且粋€(gè)CSS樣式表。所以就不用再指定type屬性了。你不是已經(jīng)說了這是一個(gè)樣式表了嘛；不用再說第二次了。當(dāng)然，愿意的話，你可以再說；如果你想包含type屬性，請便。
同樣地，如果你使用了script元素，你說type=”text/javascript”，瀏覽器差不多就知道是怎么回事了。對Web開發(fā)而言，你還使用其他的腳本語言嗎？如果你真想用其他腳本語言，沒人會(huì)阻攔你。但我要奉勸你一句，任何瀏覽器都不會(huì)支持你。
愿意的話，你可以添加一個(gè)type屬性。不過，也可以什么都不寫，瀏覽器自然會(huì)假設(shè)你在使用JavaScript。避免-不必要的-復(fù)雜性。

支持已有的內(nèi)容

支持已有的內(nèi)容。這一點(diǎn)非常重要，因?yàn)楹芏嗳硕颊J(rèn)為HTML5很新，很閃亮；它應(yīng)該代表著未來發(fā)展的方向，應(yīng)該把Web推向一個(gè)新的發(fā)展階段。這就是HTML5，對嗎？顯然，我們都會(huì)考慮讓W(xué)eb的未來發(fā)展得更好，但他們則必須考慮過去。別忘了W3C這個(gè)工作組中有很多人代表的是瀏覽器廠商，他們肯定是要考慮支持已有內(nèi)容的。只要你想構(gòu)建一款瀏覽器，就必須記住這個(gè)原則：必須支持已有的內(nèi)容。
下面我們就來看一個(gè)HTML5支持已有內(nèi)容的例子。
這個(gè)例子展示了編寫同樣內(nèi)容的四種不同方式。上面是一個(gè)img元素，下面是帶一個(gè)屬性的段落元素。四種寫法唯一的不同點(diǎn)就是語法。把其中任何一段代碼交給瀏覽器，瀏覽器都會(huì)生成相同的DOM樹，沒有任何問題。從瀏覽器的角度看，這四種寫法沒有區(qū)別。因而在HTML5中，你可以隨意使用下列任何語法。

代碼如下:

<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>

好了，看到這幾段代碼，恐怕有人會(huì)說“不對不對不對。其中只有一個(gè)是對的，另外三個(gè)&mdash;&mdash;說不好?！辈粚?，應(yīng)該給屬性值加引號(hào)！拜托，我們可是一直都給屬性值加引號(hào)的！元素名大寫對嗎？這種做法10年不是就被拋棄了嗎？
看到HTML5同時(shí)允許這些寫法，我心里忍不住一陣陣想吐。我寫了10年的XHTML 1.0，已經(jīng)非常適應(yīng)嚴(yán)格的語法了。但你必須明白，站在瀏覽器的角度上，這些寫法實(shí)際上都是一樣的。確實(shí)沒有什么問題。
還有誰也感到不舒服了嗎？有誰看到這些之后想“噢，這不是亂寫嘛，這樣做不對”？只有我這樣想嗎？還有別人嗎？
但是，HTML5必須支持已經(jīng)存在的內(nèi)容，而已有的內(nèi)容就是這個(gè)樣子的。不是嗎？根據(jù)伯斯塔爾法則，瀏覽器沒有別的選擇。
有人可能會(huì)說“這樣不行。我覺得語言本身應(yīng)該提供一種開關(guān)，讓作者能夠表明自己想做什么?！北热缯f，想使用某種特定的語法，像XHTML，而不是使用其他語法。我理解這些人的想法。但我不贊成在語言里設(shè)置開關(guān)。因?yàn)槲覀冇懻摰闹皇蔷幋a風(fēng)格或者寫作風(fēng)格，跟哪種語法正確無關(guān)。對于像我們這樣的專業(yè)人士，我認(rèn)為可以使用lint工具（一種軟件質(zhì)量保證工具，或者說是一種更加嚴(yán)格的編譯器。它不僅可以象普通編譯器那樣檢查出一般的語法錯(cuò)誤，還可以檢查出那些雖然完全合乎語法要求，但很可能是潛在的、不易發(fā)現(xiàn)的錯(cuò)誤），對其他技術(shù)我們不是也在使用lint工具嘛。
比如說對JavaScript使用lint工具。JavaScript同樣也是比較混亂、不嚴(yán)謹(jǐn)?shù)睦樱浅?qiáng)大，原因恰恰是它混亂、不嚴(yán)謹(jǐn)，而且有很多不同的編碼方式。在JavaScript，你可以在每條語句末尾加上分號(hào)，但不是必需的，因?yàn)镴avaScript會(huì)自動(dòng)插入分號(hào)&hellip;&hellip;是不是聽起來有點(diǎn)不好接受？
正因?yàn)槿绱?，才有了像JSlint這樣的工具，在道格拉斯&middot;克勞克福德（Douglas Crockford）的網(wǎng)站jslint.org上面。有個(gè)網(wǎng)頁上寫著“JSlint可能會(huì)傷害你的感情?！钡@確實(shí)是個(gè)非常棒的工具，它可以把JavaScript代碼變得完美無瑕。如果你通過JSlint運(yùn)行JavaScript，它會(huì)告訴你“好，你的JavaScript代碼有效，但寫法不妥。你這種編碼風(fēng)格啊，我不喜歡。不贊成你這樣寫。這樣寫不好?！碧貏e是對團(tuán)隊(duì)，對于要使用統(tǒng)一的編碼風(fēng)格的團(tuán)隊(duì)，JSlint是非常方便的工具。
我個(gè)人認(rèn)為，不僅對團(tuán)隊(duì)來說，就算是你自己寫代碼，也要堅(jiān)持一種語法風(fēng)格。從瀏覽器解析的角度講，不存在哪種語法比另一種更好的問題，但我認(rèn)為，作為專業(yè)人士，我們必須能夠自信地講“這就是我的編碼風(fēng)格?！比欢也徽J(rèn)為語言里應(yīng)該內(nèi)置這種開關(guān)。你可以使用lint工具來統(tǒng)一編碼風(fēng)格。現(xiàn)在就來說說lint工具。大家可以登錄htmllint.com，在其中運(yùn)行你的HTML5文檔，它會(huì)幫你檢查屬性值是否加了引號(hào)，元素是否小寫，你還可以通過勾選復(fù)選框來設(shè)置其他檢查項(xiàng)。
但這不意味著拒絕粗心大意的標(biāo)記，做不做清理完全取決于你自己。我說過，因?yàn)闉g覽器必須支持已有的內(nèi)容，HTML5自然也不能例外。歸根結(jié)底還是伯斯塔爾法則。我們始終離不開伯斯塔爾法則。

解決現(xiàn)實(shí)的問題

HTML5的另一個(gè)設(shè)計(jì)原理是解決現(xiàn)實(shí)的問題。顯而易見的是，解決各種問題的格式和規(guī)范已經(jīng)比比皆是了，因此在我看來，這個(gè)原理其實(shí)是要解決理論問題，而非解決現(xiàn)實(shí)的問題。這條設(shè)計(jì)原理是要從理論上承認(rèn)人們普遍存在的問題，消除敏感問題。但是在我看來，那些格式和規(guī)范要解決的都是理論問題，而非現(xiàn)實(shí)問題。這條設(shè)計(jì)原理才是真正要解決今天的人們所面臨的現(xiàn)實(shí)問題、令人頭疼的問題。
下面我來舉個(gè)例子。相信這個(gè)例子有不少人都遇到過。假設(shè)我使用HTML 4或XHTML 1，頁面中已經(jīng)有了一塊內(nèi)容，我想給整塊內(nèi)容加個(gè)鏈接，怎么辦？問題是這塊內(nèi)容里包含一個(gè)標(biāo)題，一個(gè)段落，也許還有一張圖片。如果我想給它們?nèi)慷伎梢渣c(diǎn)擊，必須使用3個(gè)鏈接元素。于是，我得先把光標(biāo)放在標(biāo)題（比如說h3元素）中，寫一個(gè)鏈接標(biāo)簽，然后再選中所有要包含到鏈接里面來的文本。接著，再把光標(biāo)放在段落里，寫一個(gè)鏈接標(biāo)簽，然后把段落中的文本放在鏈接里&hellip;&hellip;

代碼如下:

<h3><a href="/path/to/resource">Headline text</a></h3>
<p><a href="/path/to/resource">Paragraph text.</a></p>

在HTML5中，我只要簡單地把所有內(nèi)容都包裝在一個(gè)鏈接元素中就行了。

代碼如下:

<a href="/path/to/resource">
<h3>Headline text</h3>
<p>Paragraph text.</p>
</a>

沒錯(cuò)，鏈接包含的都是塊級(jí)元素，但現(xiàn)在我可以用一個(gè)元素包含它們。這樣太好了。因?yàn)槲遗龅竭^類似的情形，必須給幾個(gè)塊級(jí)元素加上相同的鏈接，所有能這樣寫就太好了。為此，我就非常歡迎HTML5這個(gè)新標(biāo)準(zhǔn)。

它解決了一個(gè)現(xiàn)實(shí)的問題。我敢說在座不少朋友都曾遇到過這個(gè)問題。

那這到底解決的是什么問題呢？瀏覽器不必因此重新寫代碼來支持這種寫法。這種寫法其實(shí)早就已經(jīng)存在于瀏覽器中了，因?yàn)樵缇陀腥诉@樣寫了，當(dāng)然以前這樣寫是不合乎規(guī)范的。所以，說HTML5解決現(xiàn)實(shí)的問題，其本質(zhì)還是“你都這樣寫了很多年了吧？現(xiàn)在我們把標(biāo)準(zhǔn)改了，允許你這樣寫了?！?br/>

求真務(wù)實(shí)

在所有設(shè)計(jì)原理中，這一條恐怕是最響亮的了&mdash;&mdash;求真務(wù)實(shí)。不知道大家有沒有在公司里開會(huì)時(shí)聽到過這種口號(hào)：“開拓進(jìn)取，求真務(wù)實(shí)?！睂?shí)際上，除了作為企業(yè)的口號(hào)，它還是一條非常重要的設(shè)計(jì)原理，因?yàn)榍笳鎰?wù)實(shí)對于HTML的含義是：在解決那些令人頭痛的問題之前，先看看人們?yōu)閼?yīng)對這些問題都想出了哪些辦法。集中精力去理解這些“民間的”解決方案才是當(dāng)務(wù)之急。
HTML5中新的語義元素就是遵循求真務(wù)實(shí)原理的反映。新增的元素不算多，談不上無限的擴(kuò)展性，但卻不失為一件好事。盡管數(shù)量屈指可數(shù)，但意義卻非同一般。這些新元素涉及頭部（header）、腳部（footer）、分區(qū)（section）、文章（article）&hellip;&hellip;，相信大家都不會(huì)覺得陌生。我的意思是說，即便你不使用HTML5，也應(yīng)該熟悉這些稱呼，這些都是你曾經(jīng)使用過的類名，比如class=”header”/“head”/“heading”，或class=”footer”/“foot”。當(dāng)然，也可能是ID，id=”header”，id=”footer”。這些不都是我們已經(jīng)司空見慣了的嘛。
好，舉個(gè)例子吧，假設(shè)你今天寫了下面這個(gè)文檔。

代碼如下:

<body>
<div id="header">...</div>
<div id="navigation">...</div>
<div id="main">...</div>
<div id="sidebar">...</div>
<div id="footer">...</div>
</body>

這里有一個(gè)div使用了id=”header”，另一個(gè)div使用了id=”navigation”，&hellip;&hellip;。怎么樣，都輕車熟路了吧？在HTML5中，這些元素都可以換掉。說起新增的語義元素，它們價(jià)值的一方面可以這樣來體現(xiàn)：“嘿，看啊，這樣多好，用HTML5新增的元素可以把這些div都替換掉?！?/p>

代碼如下:

<body>
<header>...</header>
<nav>...</nav>
<div id="main">...</div>
<aside>...</aside>
<footer>...</footer>
</body>

當(dāng)然了，你可以這樣做。在文檔級(jí)別上使用這些元素沒有問題。但是，假如新增這些元素的目的僅僅是為了取代原來的div，那就真有點(diǎn)多此一舉了。
雖然在這個(gè)文檔中，我們用這些新元素來替換的是ID，但在我個(gè)人看來，將它們作為類的替代品更有價(jià)值。為什么這么說呢？因?yàn)檫@些元素在一個(gè)頁面中不止可以使用一次，而是可以使用多次。沒錯(cuò)，你可以為文檔添加一個(gè)頭部（header），再添加一個(gè)腳部（footer）；但文檔中的每個(gè)分區(qū)（section）照樣也都可以有一個(gè)頭部和一個(gè)腳部。而每個(gè)分區(qū)里還可以嵌套另一個(gè)分區(qū)，被嵌套的分區(qū)仍然可以有自己的頭部和腳部，是這樣吧？
這四個(gè)新元素：section、article、aside和nav，之所以說它們強(qiáng)大，原因在于它們代表了一種新的內(nèi)容模型，一種HTML中前所未有的內(nèi)容模型&mdash;&mdash;給內(nèi)容分區(qū)。迄今為止，我們一直都在用div來組織頁面中的內(nèi)容，但與其他類似的元素一樣，div本身并沒有語義。但section、article、aside和nav實(shí)際上是在明確地告訴你&mdash;&mdash;這一塊就像文檔中的另一個(gè)文檔一樣。位于這些元素中的任何內(nèi)容，都可以擁有自己的概要、標(biāo)題，自己的腳部。
其中最為通用的section，可以說是與內(nèi)容最相關(guān)的一個(gè)。而article則是一種特殊的section。Aside呢，是一種特殊的section。最后，Nav也是一種特殊的section。
好，即便是現(xiàn)在，你照樣可以使用div和類來描述頁面中不同的部分，就像下面這樣：

代碼如下:

<div class="item">
<h3>...</h3>
<div class="meta">...</div>
<div class="content">
...
</div>
<div class="links">...</div>
</div>

其中包含可能是有關(guān)內(nèi)容作者的元數(shù)據(jù)，而下面會(huì)給出一些鏈接，差不多就這樣。在HTML5中，我完全可以說這塊內(nèi)容就是一個(gè)文檔，通過對內(nèi)容分區(qū)，使用section或article或aside，我可以說“這一塊完全是可以獨(dú)立存在的。”因此，我當(dāng)然可以使用header和footer。

代碼如下:

<section class="item">
<header><h2>...</h2></header>
<footer class="meta">...</footer>
<div class="content">
...
</div>
<nav class="links">...</nav>
</section>

請注意，即便是footer，也不一定非要出現(xiàn)在下面，不是嗎？這幾個(gè)元素，header、footer、aside、nav，最重要的是它們的語義；跟位置沒有關(guān)系。一想到footer這個(gè)詞，我們總會(huì)不由自主地想，“噢，應(yīng)該放在下面。”同樣，我們把a(bǔ)side想象成一個(gè)側(cè)邊欄?？墒牵绻憧匆豢匆?guī)范，就會(huì)發(fā)現(xiàn)這些元素只跟內(nèi)容有關(guān)。因此，放在footer中的內(nèi)容也可以是署名，文章作者之類的，它只是你使用的一個(gè)元素。這個(gè)元素并沒有說“必須把我放在文檔或者分區(qū)的下面。”
這里，請注意，最重要的還不是我用幾個(gè)新元素替換了原來的div加類，而是我把原來的H2換成了H1&mdash;&mdash;震撼吧，我看到有人發(fā)抖了。我碰到過不少職業(yè)的Web開發(fā)人員，多年來他們一直認(rèn)為規(guī)范里說一個(gè)文檔中只能有一個(gè)H1。還有一些自詡為萬能的SEO秘訣同樣說要這樣。很多SEO的技巧其實(shí)是很教條的。所謂教條，意思就是不相信數(shù)據(jù)。過去，這種教條表現(xiàn)為“不行，頁面中包含兩個(gè)以上的H1，你就會(huì)死掉的?！痹贖TML5中，只要你建立一個(gè)新的內(nèi)容塊，不管用section、article、aside、nav，還是別的元素，都可以在其中使用H1，而不必?fù)?dān)心這個(gè)塊里的標(biāo)題在整個(gè)頁面中應(yīng)該排在什么級(jí)別；H2、H3，都沒有問題。
這個(gè)變化太厲害了。想一想吧，這個(gè)變化對內(nèi)容管理是革命性的。因?yàn)楝F(xiàn)在，你可以把每個(gè)內(nèi)容分區(qū)想象一個(gè)獨(dú)立的、能夠從頁面中拿出來的部分。此時(shí)，根據(jù)上下文不同，這個(gè)獨(dú)立部分中的H1，在整個(gè)頁面中沒準(zhǔn)會(huì)扮演H2或H3的角色&mdash;&mdash;取決于它在文檔中出現(xiàn)的位置。面對這個(gè)突如其來的變化，也許有人的腦子會(huì)暫時(shí)轉(zhuǎn)不過彎來。不要緊，但我可以告訴你，我認(rèn)為這才是HTML5中這些新語義標(biāo)記的真正價(jià)值所在。換句話說，我們現(xiàn)在有了獨(dú)立的元素了，這些元素中的標(biāo)題級(jí)別可以重新定義。
我的文檔中可能會(huì)包含一個(gè)分區(qū)，這個(gè)分區(qū)中可能會(huì)嵌套另一個(gè)分區(qū)，或者一篇文章，然后文章再嵌套分區(qū)，分區(qū)再嵌套文章、嵌套分區(qū)，文章再嵌套文章。而且每個(gè)分區(qū)和文章都可以擁有自己的H1到H6。從這個(gè)意義上講，H元素真可謂“子子孫孫，無窮匱也”了。但是，在你編寫內(nèi)容或者內(nèi)容管理系統(tǒng)的時(shí)候，它們又都是獨(dú)立的，完全獨(dú)立的內(nèi)容塊。這才是真正的價(jià)值所在。
實(shí)際上，這個(gè)點(diǎn)子并不是HTML5工作組拍腦門想出來的，也不是W3C最近才提出來的。下面這幾句話摘自蒂姆&middot;伯納斯-李1991年的一封郵件，郵件是發(fā)給丹&middot;康納利（Dan Connolly）的。他在郵件中解釋了對HTML的理解，他說：“你知道&hellip;&hellip;知道我的想法，我認(rèn)為H1、H2這樣單調(diào)地排下去不好，我希望它成為一種可以嵌套的元素，或者說一個(gè)通用的H元素，我們可以在其中嵌套不同的層次?！钡髞?，我們沒有看到通用的H元素，而是一直在使用H1和H2&mdash;&mdash;那是因?yàn)槲覀円恢痹谥С忠延械膬?nèi)容。20年后的今天，這個(gè)理想終于實(shí)現(xiàn)了。

平穩(wěn)退化

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

代碼如下:

input type="number"
input type="search"
input type="range"
input type="email"
input type="date"
input type="url"

最關(guān)鍵的問題在于瀏覽器在看到這些新type值時(shí)會(huì)如何處理。現(xiàn)有的瀏覽器，不是將來的瀏覽器，現(xiàn)有的瀏覽器是無法理解這些新type值的。但在它們看到自己不理解的type值時(shí)，會(huì)將type的值解釋為text。
無論你寫的是input type=”foo”還是input type=”bar”，現(xiàn)有的任何瀏覽器都會(huì)說：“嗯，也許作者的意思是text。”因而，你從現(xiàn)在開始就可以使用這些新值，而且你也可以放心，那些不理解它們的瀏覽器會(huì)把新值看成type=”text”，而這真是一個(gè)瀏覽器實(shí)踐平穩(wěn)退化原理的好例子。
比如說，你現(xiàn)在輸入了type=”number”。假設(shè)你需要一個(gè)輸入數(shù)值的文本框。那么你可以把這個(gè)input的type屬性設(shè)置為number，然后理解它的瀏覽器就會(huì)呈現(xiàn)一個(gè)可愛的小控件，像帶小箭頭圖標(biāo)的微調(diào)控件之類的。對吧？而在不理解它的瀏覽器中，你會(huì)看到一個(gè)文本框，一個(gè)你再熟悉不過的文本框。既然如此，為什么不能說輸入type=”number”就會(huì)得到一個(gè)帶小箭頭圖標(biāo)的微調(diào)控件呢？
當(dāng)然，你還可以設(shè)置最小和最大值屬性，它們同樣可以平穩(wěn)退化。這是問題的關(guān)鍵。
再看input type=”search”。你也可以考慮一下這種輸入框，因?yàn)檫@種輸入框在Safari中會(huì)被呈現(xiàn)為一個(gè)系統(tǒng)級(jí)的搜索控件，右邊還有一個(gè)點(diǎn)擊即可清除搜索關(guān)鍵詞的X。而在其他瀏覽器中，你得到的則是一個(gè)文本框，就像你寫的是input type=”text”一樣，也就是你已經(jīng)非常熟悉的文本框。那為什么還不使用input type=”search”呢？它不會(huì)有什么副作用，沒有，對不對？
HTML5還為輸入元素增加了新的屬性，比如placeholder（占位符）。有人不知道這個(gè)屬性的用處嗎，沒有吧？沒錯(cuò)，就是用于在文本框中預(yù)先放一些文本。不對，不是標(biāo)簽（label）&mdash;&mdash;占位符和標(biāo)簽完全不是一回事。占位符就是文本框可以接受的示例內(nèi)容，一般顏色是灰色的。只要你一點(diǎn)擊文本框，它就消失了。如果你把已經(jīng)輸入的內(nèi)容全部刪除，然后單擊了文本框外部，它又會(huì)出現(xiàn)。
使用JavaScript編寫一些代碼當(dāng)然也可以實(shí)現(xiàn)這個(gè)功能，但HTML5只用一個(gè)placeholder屬性就幫我們解決了問題。
當(dāng)然，對于不支持這個(gè)屬性的瀏覽器，你還是可以使用JavaScript來實(shí)現(xiàn)占位符功能。通過JavaScript來測試瀏覽器支不支持該屬性也非常簡單。如果支持，后退一步，把路讓開，樂享其成即可。如果不支持，可以再讓你的JavaScript來模擬這個(gè)功能。
現(xiàn)在，我不得不提到另一個(gè)話題了：HTML5對Flash。也許你早聽說過了，或者在哪里看到了這方面的討論。說實(shí)話，我一點(diǎn)也不明白。我搞不懂人們怎么會(huì)僅僅憑自己的推測來展開爭論。
首先，他們所說的HTML5對Flash，并不是指的HTML5，也不是指的Flash。而是指HTML5的一個(gè)子集和Flash的一個(gè)子集。具體來說，他們指的是視頻。因此，不管你在哪里聽到別人說“HTML5對Flash”，那很可能說的只是HTML5視頻對Flash視頻。
其次，一說HTML5對Flash，就好像你必須得作出選擇一樣：你站在哪一邊？實(shí)際上不是這樣的。HTML5規(guī)范的設(shè)計(jì)能夠讓你做到魚和熊掌兼得。
好，下面就來看看這個(gè)新的video元素；真是非常貼心的一個(gè)元素，而且設(shè)計(jì)又簡單，又實(shí)用。一個(gè)開始的video元素，加一個(gè)結(jié)束的video元素，中間可以放后備內(nèi)容。注意，是后備內(nèi)容，不是保證可訪問性的內(nèi)容，是后備內(nèi)容。下面就是針對不支持video元素的瀏覽器寫的代碼：

代碼如下:

<video src="movie.mp4">
<!-- 后備內(nèi)容 -->
</video>

那么，在后備內(nèi)容里面放些什么東西呢？好，你可以放Flash影片。這樣，HTML5的視頻與Flash的視頻就可以協(xié)同起來了。你不用作出選擇。

代碼如下:

<video src="movie.mp4">
<object data="movie.swf">
<!-- 后備內(nèi)容 -->
</object>
</video>

當(dāng)然，你的代碼實(shí)際上并沒有這么簡單。因?yàn)檫@里我使用了H264，部分瀏覽器支持這種視頻格式。但有的瀏覽器不支持。
對不起，請不要跟我談視頻格式，我一聽就心煩。不是因?yàn)榧夹g(shù)。技術(shù)倒無所謂，關(guān)鍵是會(huì)牽扯到一大堆專利還有律師、知識(shí)產(chǎn)權(quán)等等，這些都是Web的天敵，對我建網(wǎng)站一點(diǎn)好處都沒有。
可你實(shí)際上要做的，僅僅就是把后備內(nèi)容放在那而已，后備內(nèi)容可以包含多種視頻格式。如果愿意的話，可以使用source元素而非src屬性來指定不同的視頻格式。

代碼如下:

<video>
<source src="movie.mp4">
<source src="movie.ogv">
<object data="movie.swf">
<a href="movie.mp4">download</a>
</object>
</video>

上面的代碼中包含了4個(gè)不同的層次。
1、如果瀏覽器支持video元素，也支持H264，沒什么好說的，用第一個(gè)視頻。
2、如果瀏覽器支持video元素，支持Ogg，那么用第二個(gè)視頻。
3、如果瀏覽器不支持video元素，那么就要試試Flash影片了。
4、如果瀏覽器不支持video元素，也不支持Flash，我還給出了下載鏈接。

不錯(cuò)，一開始就能考慮這么周到很難得啊。有了這幾個(gè)層次，已經(jīng)夠完善了。

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

為什么要兼顧這兩種技術(shù)呢？假設(shè)你需要面向某些不支持Flash的手持設(shè)備&mdash;&mdash;只是舉個(gè)例子&mdash;&mdash;提供視頻，你當(dāng)然希望手持設(shè)備的用戶能夠看到視頻了，不是嗎？

至于為什么要使用不同的格式，為什么Flash視頻和音頻如此成功，我想可以歸結(jié)為另一個(gè)設(shè)計(jì)原理，即梅特卡夫定律(Metcalfe&rsquo;s Law)：

網(wǎng)絡(luò)價(jià)值同網(wǎng)絡(luò)用戶數(shù)量的平方成正比。

梅特卡夫的這個(gè)定律雖然是針對電話網(wǎng)提出來的，但在很多領(lǐng)域里也是適用的。使用網(wǎng)絡(luò)的用戶越多，網(wǎng)絡(luò)的價(jià)值也就越大。人人都上Facebook，還不是因?yàn)槿巳硕忌螰acebook嘛。雖然Facebook真正的價(jià)值不在于此，但只有人人都上才會(huì)讓它的變得如此有價(jià)值。
梅特卡夫定律也適用于傳真機(jī)。如果只有一個(gè)人購買了傳真機(jī)，當(dāng)然沒有什么用處。但如果其他人也陸續(xù)購買了傳真機(jī)，那么他的投資會(huì)就得到回報(bào)。
當(dāng)然，面對競爭性的視頻格式和不同的編碼方式，你感覺不到梅特卡夫定律的作用，我也很討厭以不同的方式來編碼視頻，但只向?yàn)g覽器發(fā)送用一種方式編碼的視頻是行不通的。而這也正是Flash在視頻/音頻領(lǐng)域如此成功的原因。你只要把Flash影片發(fā)送給瀏覽器就好了，然后安裝了插件的瀏覽器都能正常播放。本質(zhì)上講，F(xiàn)lash利用了梅特卡夫定律。

最終用戶優(yōu)先

今天我要講的最后一個(gè)設(shè)計(jì)原理，也是我個(gè)人最推崇的一個(gè)，但沒有要展示的代碼示例。這個(gè)原理更有哲學(xué)的味道，即最終用戶優(yōu)先。
這個(gè)設(shè)計(jì)原理本質(zhì)上是一種解決沖突的機(jī)制。換句話說，當(dāng)你面臨一個(gè)要解決的問題時(shí)，如果W3C給出了一種解決方案，而WHATWG給出了另一種解決方案，一個(gè)人這么想，另一個(gè)人那么想&hellip;&hellip;這時(shí)候，有人站出來說：“對這個(gè)問題我們這樣來解決。”

一旦遇到?jīng)_突，最終用戶優(yōu)先，其次是作者，其次是實(shí)現(xiàn)者，其次標(biāo)準(zhǔn)制定者，最后才是理論上的完滿。
理論上的完滿，大致是指盡可能創(chuàng)建出最完美的格式。標(biāo)準(zhǔn)制定者，指的是工作組、W3C，等等。實(shí)現(xiàn)者，指的是瀏覽器廠商。作者，就是我們這些開發(fā)人員，對吧？看看我們在這個(gè)鏈條里面的位置多靠上??！我們的地位僅次于最終用戶&mdash;&mdash;事情本來就該這個(gè)樣子。用戶是第一位的。而我們的聲音在標(biāo)準(zhǔn)制定過程中也同樣非常非常重要。
Hixie（即Ian Hickson， Acid2、Acid3的作者及維護(hù)者，HTML5、CSS 2.1規(guī)范的制定者）經(jīng)常說，在有人建議了某個(gè)特性，而HTML5工作組為此爭論不下時(shí)，如果有瀏覽器廠商說“我們不會(huì)支持這個(gè)特性，不會(huì)在我們的瀏覽器中實(shí)現(xiàn)這個(gè)特性”，那么這個(gè)特性就不會(huì)寫進(jìn)規(guī)范。因?yàn)榧词故前烟匦詫戇M(jìn)規(guī)范，如果沒有廠商實(shí)現(xiàn)，規(guī)范不過是一紙空文，對不對？實(shí)現(xiàn)者可以拒絕實(shí)現(xiàn)規(guī)范。
而根據(jù)最終用戶優(yōu)先的原理，我們在鏈條中的位置高于實(shí)現(xiàn)者，假如我們發(fā)現(xiàn)了規(guī)范中的某些地方有問題，我們想“這樣規(guī)定我們不能同意，我們不支持實(shí)現(xiàn)這個(gè)特性”，那么就等于把相應(yīng)的特性給否定了，規(guī)范里就得刪除，因?yàn)槲覀兊穆曇艟哂懈叩臋?quán)重。我覺得這樣挺好！本質(zhì)上是我們擁有了更大的發(fā)言權(quán)，對吧？我認(rèn)為開發(fā)人員就應(yīng)該擁有更多的發(fā)言權(quán)。
我覺得這應(yīng)該是最重要的一條設(shè)計(jì)原理了，因?yàn)樗姓J(rèn)了你的權(quán)利，無論是設(shè)計(jì)一種格式，還是設(shè)計(jì)軟件，這條原理保證了你的發(fā)言權(quán)。而這條原理也正道出了事物運(yùn)行的本質(zhì)。難道還不夠明顯嗎？用戶的權(quán)利大于作者，作者的權(quán)利大于實(shí)現(xiàn)者，實(shí)現(xiàn)者的權(quán)利大于標(biāo)準(zhǔn)制定者。然而，反觀其他規(guī)范，比如XHTML2，你就會(huì)發(fā)現(xiàn)完全相反的做法。把追求理論的完滿放在第一位，而把用戶&mdash;&mdash;需要忍受嚴(yán)格錯(cuò)誤處理帶來的各種麻煩的用戶&mdash;&mdash;放在了鏈條的最底端。我并沒有說這種做法就是錯(cuò)誤的，但我認(rèn)為這是一種完全不同的思維方式。
因此，我認(rèn)為無論你做什么，不管是構(gòu)建像HTML5這樣的格式，還是構(gòu)建一個(gè)網(wǎng)站，亦或一個(gè)內(nèi)容管理系統(tǒng)，明確你的設(shè)計(jì)原理都至關(guān)重要。

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

下面我們講一個(gè)例子。Drupal社區(qū)曾聯(lián)系馬克&middot;博爾頓（Mark Boulton）和麗莎&middot;雷賀特（Leisa Reichilt）設(shè)計(jì)Drupal的界面。他們計(jì)劃遵循一些設(shè)計(jì)原理。為此，他們并沒有紙上談兵，而是經(jīng)過了一段時(shí)間的思考和醞釀，提出指導(dǎo)將來工作的4個(gè)設(shè)計(jì)原理：

簡化最常見的任務(wù)，讓不常見的任務(wù)不至于太麻煩。
只為80%設(shè)計(jì)。
給內(nèi)容創(chuàng)建者最大的權(quán)利。
默認(rèn)設(shè)置智能化。

實(shí)際上，我在跟馬克談到這個(gè)問題時(shí)，馬克說主要還是那兩個(gè)，即“只為80%設(shè)計(jì)。給內(nèi)容創(chuàng)建者最大的權(quán)利?！边@就很不錯(cuò)了，至少它表明了立場，“我們認(rèn)為內(nèi)容創(chuàng)建者比這個(gè)項(xiàng)目中的任何人都重要?！痹谥贫ㄔO(shè)計(jì)原理時(shí)，很多人花了很多時(shí)間都抓不住重點(diǎn)，因?yàn)樗麄兿肴偹腥?。關(guān)鍵在于我們不是要取悅所有人，而是要明確哪些人最重要。他們認(rèn)為內(nèi)容創(chuàng)建者是最重要的。
另一條設(shè)計(jì)原理，只為80%設(shè)計(jì)，其實(shí)是一條常見的設(shè)計(jì)原理，也是一種通用模式，即帕累托原理（Pareto principle）。
帕累托是意大利經(jīng)濟(jì)學(xué)家，他提出這個(gè)比例，80/20，說的是世界上20%的人口擁有80%的財(cái)富。這個(gè)比例又暗合了自然界各個(gè)領(lǐng)域的冪律分布現(xiàn)象。總之，無論你是編寫軟件，還是制造什么東西，都是一樣的，即20%的努力可以觸及80%的用例。最后20%的用例則需要付出80%甚至更多的努力。因此，有時(shí)候據(jù)此確定只為80%設(shè)計(jì)是很合理的，因?yàn)槲覀冎罏榇酥灰冻?0%的努力即可。
再比如，微格式同樣也利用了帕累托原理，只處理常見用例，而沒有考慮少數(shù)情形。他們知道自己不會(huì)讓所有人都滿意；而他們的目標(biāo)也不是讓所有人都滿意。他們遵循的設(shè)計(jì)原理很多，也都非常有價(jià)值，但最吸引人的莫過于下面這條了：

首先為人類設(shè)計(jì)，其次為機(jī)器設(shè)計(jì)。

同樣，你我都會(huì)覺得這是一條再明顯不過的道理，但現(xiàn)實(shí)中仍然有不少例子違反了這條原理：容易讓機(jī)器理解（解析）比容易讓用戶理解更重要。
所以，我認(rèn)為平常多看一看別人推崇的設(shè)計(jì)原理，有助于做好自己手頭的工作。你可以把自己認(rèn)為有道理的設(shè)計(jì)原理貼在墻上。當(dāng)然，你可以維護(hù)一個(gè)URL，把自己認(rèn)為有價(jià)值的設(shè)計(jì)原理分享出來，就像Mozilla基金會(huì)那樣，對不對，以下是Mozilla的設(shè)計(jì)原理：

Internet作為一種公共資源，其運(yùn)作效率取決于互通性（協(xié)議、數(shù)據(jù)格式、內(nèi)容）、變革及全球范圍內(nèi)的協(xié)作。
基于透明社區(qū)的流程有助于增進(jìn)協(xié)作、義務(wù)和信任。

我覺得像這樣的設(shè)計(jì)原理都非常好。而有了設(shè)計(jì)原理，我認(rèn)為才更有希望設(shè)計(jì)出真正有價(jià)值的產(chǎn)品。設(shè)計(jì)原理是Web發(fā)展背后的驅(qū)動(dòng)力，也是通過HTML5反映出來的某種思維方式。我想，下面這條原理你絕對不會(huì)陌生：

大多數(shù)人的意見和運(yùn)行的代碼。[1]

對不對？這句話經(jīng)常在我腦際回響，它囊括了Web的真諦，觸及了HTML5的靈魂。

也許我該把這條原理打印出來貼到辦公室的墻上，讓它時(shí)刻提醒我，這就是Web的設(shè)計(jì)原理：大多數(shù)人的意見和運(yùn)行的代碼。

到此，相信大家對“html5的設(shè)計(jì)原理是什么”有了更深的了解，不妨來實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！