- 相關(guān)推薦
HTML5設計原理
HTML 5的設計主要分兩個(gè)方面：一方面，當然了，就是HTML 5。我可以站在這兒只講HTML 5，但我并不打算這樣做，因為如果你想了解HTML 5的話(huà)，你可以Google，可以看書(shū)，甚至可以看規范。
實(shí)際上，確實(shí)有人會(huì )談到規范的內容。史蒂夫·�？思{(Steve Faulkner)會(huì )講HTML 5與可訪(fǎng)問(wèn)性。而保羅·艾里什(Paul Irish)則會(huì )講HTML 5提供的各種API。因此，我今天站在這里，不會(huì )光講一講HTML 5就算完事了。
說(shuō)老實(shí)話(huà)，在正式開(kāi)始之前，我想先交待清楚我所說(shuō)的HTML 5到底是什么意思。這話(huà)聽(tīng)起來(lái)有點(diǎn)搞笑：這會(huì )子你一直在說(shuō)HTML 5，難道我們還不知道什么是HTML 5嗎?大家知道，有一個(gè)規范，它的名字叫HTML 5。我所說(shuō)的HTML 5，指的就是這個(gè)規范。但問(wèn)題是，有些人所說(shuō)的HTML 5，指的不僅僅是這個(gè)規范，還有別的意思。比如說(shuō)，用HTML 5來(lái)代指CSS3就是一種常見(jiàn)的叫法。我可不是這樣的。我所說(shuō)的HTML 5，不包含CSS3，就是HTML 5。
類(lèi)似的術(shù)語(yǔ)問(wèn)題以前也有過(guò)。Ajax本來(lái)是一種含義明確的技術(shù)，但過(guò)了不久，它的含義就變成了“用JavaScript來(lái)做一切好玩的東西"。這就 是Ajax，對不對?今天，HTML 5也面臨同樣的問(wèn)題，它本來(lái)指的是一個(gè)特定的規范，但如今含義卻成了“在Web上做一切好玩的事。"我說(shuō)的不是這種HTML 5，不是這種涵蓋了最近剛剛出現的各種新東東的HTML 5。我說(shuō)的僅僅是規范本身：HTML 5。
剛才已經(jīng)說(shuō)了，我今天想要講的內容不多，也沒(méi)有打算介紹HTML 5都包含什么。今天我要講的是它的另一方面，即HTML 5的設計。換句話(huà)說(shuō)，我要講的不是規范里都包含什么，而是規范里為什么會(huì )包含它們，以及在設計這個(gè)規范的時(shí)候，設計者們是怎么看待這些東西的。
設計原理
設計原理本質(zhì)上是一種信念、一種想法、一個(gè)概念，是你行動(dòng)的支柱。不管你是制定規范，還是制造一種有形的物品，或者編寫(xiě)軟件，甚至發(fā)明編程語(yǔ)言。你 都能找到背后的一個(gè)或者多個(gè)設計原理，多人協(xié)作的任何成果都是例證。不僅僅Web開(kāi)發(fā)領(lǐng)域是這樣�？v觀(guān)人類(lèi)歷史，像國家和社會(huì )這樣大規模的構建活動(dòng)背后， 同樣也有設計原理。
就拿美國為例吧，美國的設計原理都寫(xiě)在了《獨立宣言》中了。
我們認為這些真理是不言而喻的，人人生而平等，造物主賦予了每個(gè)人不可剝奪的權利，包括生存、自由和追求幸福。
這里有一句口號：生存、自由和追求幸福。這是被寫(xiě)進(jìn)憲法中的核心理念，它關(guān)系到我們所有人的一切，也就是我們構建自己社會(huì )的原則。
還有一個(gè)例子，就是卡爾·馬克思(Karl Marx)，他的著(zhù)作在20世紀曾被奉為建設社會(huì )主義的圭臬。其基本思想大致可以歸結為下面這條設計原理：
各盡所能，各取所需。
這其實(shí)就是一種經(jīng)濟體系背后的設計原理。
還有一個(gè)例子，比前面兩個(gè)的歷史更久遠一些，不過(guò)大同小異：
人人為我，我為人人。
這個(gè)極為簡(jiǎn)單的設計原理，是兩千年前的拿撒勒猶太人耶穌基督提出來(lái)的。而這條原則成為了后來(lái)許多宗教的核心教義。原理與實(shí)踐有時(shí)候并不是同步的。
下面是小說(shuō)中的一個(gè)例子。英國小說(shuō)家喬治·奧威爾(George Orwell)筆下的《動(dòng)物莊園》，就是在一條設計原理的基礎上構建起來(lái)的虛擬社會(huì )。這條設計原理是：
四條腿的都是好人，兩條腿的都是壞蛋!
《動(dòng)物莊園》中有意思的是，隨著(zhù)社會(huì )的變遷——變得越來(lái)越壞，這條設計原理也跟著(zhù)發(fā)生了改變，變成了“四條腿的都是好人，兩條腿的就更好了。"最關(guān)鍵的是，即使是在虛構的作品里，設計原理都是存在的。
還有一套虛構的作品是以三條設計原理為基礎構建起來(lái)的，那就是美國著(zhù)名小說(shuō)家艾薩克·阿西莫夫(Issac Asimov)的機器人經(jīng)典系列。阿西莫夫發(fā)明了機器人學(xué)這個(gè)術(shù)語(yǔ)，并提出了機器人學(xué)三大法則，然后在這三個(gè)簡(jiǎn)單的設計原理基礎上創(chuàng )作了一系列經(jīng)典作品 ——大約有50本書(shū)。無(wú)論作品的情節如何變化，實(shí)際上都是從不同的角度來(lái)闡釋這三大設計原理。我想，在座各位對機器人三大法則都不應該陌生。
機器人不得傷害人類(lèi)，或袖手旁觀(guān)人類(lèi)受傷害。
機器人必須服從人類(lèi)命令，除非命令違反第一法則。
機器人必須自衛，只要不違背第一和第二法則。
這些恐怕是第一次出現在小說(shuō)中的針對軟件的設計原理了。雖然基于這三個(gè)設計原理的軟件運行在虛構的機器人的“正電子腦"中，但我想這應該是軟件設計原理的事實(shí)開(kāi)端。從此以后，我們才看到大量?jì)?yōu)秀軟件背后的設計原理。
蒂姆·伯納斯-李(Tim Berners-Lee)，Web的發(fā)明者，在W3C的網(wǎng)站上發(fā)表過(guò)一份文檔，其中有一個(gè)URL給出了他自己的一套設計原理。這些設計原理并不那么容易理 解，不僅多，而且隨著(zhù)時(shí)時(shí)間推移，他還會(huì )不斷補充、修改和刪除。不過(guò)我還是覺(jué)得把自己認同的設計原理寫(xiě)出來(lái)放在某個(gè)地方真是個(gè)不錯的主意。
實(shí)際上，CSS的發(fā)明人之一伯特·波斯(Bert Bos)，也在W3C的網(wǎng)站上放著(zhù)一份文檔，其中講的都是基本的設計原理，比如怎樣設計并構建一種格式，無(wú)論是CSS還是其他格式。推薦大家看一看。
只要你在W3C的站點(diǎn)中隨便找一找，就可以發(fā)現非常多的這種設計原理，包括蒂姆·伯納斯-李個(gè)人的。當然，你還會(huì )看到他從軟件工程學(xué)校里借用的一些 口號：分權(decentalisation)、容忍(tolerance)、簡(jiǎn)易(simplicity)、模塊化(modularity)。這些都是 在他發(fā)明新格式的時(shí)候，頭腦中無(wú)時(shí)無(wú)刻不在想的那些關(guān)鍵詞。
在座各位對蒂姆·伯納斯-李的貢獻都是非常熟悉的，因為大家每天都在用。他發(fā)明了Web，與羅伯特·卡里奧(Robert Cailliau)共同發(fā)明了Web，而且在發(fā)明Web的同時(shí)，也發(fā)明了我們每天都在Web上使用的語(yǔ)言。當然，這門(mén)語(yǔ)言就是HTML：超文本標記語(yǔ)言。
HTML
HTML最早是從2.0版開(kāi)始的。從來(lái)就沒(méi)有1.0版。如果有人告訴你說(shuō)，他最早是從HTML 1.0開(kāi)始使用HTML的，那他絕對是在忽悠你。從前確實(shí)有一個(gè)名叫HTML Tags的文檔，其中的部分標簽一直用到現在，但那個(gè)文檔并非官方的規范。
使用標簽、尖括號、p或h1，等等，并不是蒂姆·伯納斯-李首創(chuàng )的想法。當時(shí)的SGML里就有了這些概念，而且當時(shí)的CERN(Conseil Europeen pour la Recherche Nucleaire，歐洲核子研究委員會(huì ))也在使用SGML的一個(gè)特定的版本。也就是說(shuō)，即便在那個(gè)時(shí)代，他也沒(méi)有白手起家;這一點(diǎn)在HTML后來(lái)的發(fā)展 過(guò)程中也體現了出來(lái)：繼往開(kāi)來(lái)、承前啟后，而不是另立門(mén)戶(hù)、從頭開(kāi)始。
換句話(huà)說(shuō)，這篇名為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ā)布了不少標準。但從第三個(gè)版本開(kāi)始往后，W3C，萬(wàn)維網(wǎng)聯(lián)盟(World Wide Web Consortium)開(kāi)始接手，并負責后續版本的制定工作。
20世紀九十年代HTML有過(guò)幾次快速的發(fā)展。眾所周知，在那個(gè)時(shí)代要想構建網(wǎng)站，可是一項十分復雜的工程。瀏覽器大戰曾令人頭疼不已。市場(chǎng)競爭的 結果就是各家瀏覽器里都塞滿(mǎn)了各種專(zhuān)有的特性，都試圖在專(zhuān)有特性上勝人一籌。當時(shí)的混亂程度不堪回首，HTML到底還重不重要，或者它作為Web格式的前 景如何，誰(shuí)都說(shuō)不清楚。
從1997年到1999年，HTML的版本從3.2到4.0到4.01，經(jīng)歷了非�？斓陌l(fā)展。問(wèn)題是到了4.01的時(shí)候，W3C的認識發(fā)生了倒退， 他們說(shuō)“好了，這個(gè)版本就這樣了，HTML也就這樣了;HTML 4.01是HTML的最后一個(gè)版本了，我們用不著(zhù)HTML工作組了。"
W3C并沒(méi)有停止開(kāi)發(fā)這門(mén)語(yǔ)言，只不過(guò)他們對HTML不再感興趣了。在HTML 4.01之后，他們提出了XHTML 1.0。雖然聽(tīng)起來(lái)完全不同，但XHTML 1.0與HTML 4.01其實(shí)是一樣的。我的意思是說(shuō)，從字面上看這兩個(gè)規范的內容是一樣的，詞匯表是一樣的，所有的元素是一樣，所有的屬性也都是一樣的。唯一一點(diǎn)不同之 處，就是XHTML 1.0要求使用XML語(yǔ)法。也就是說(shuō)，所有屬性都必須使用小寫(xiě)字母，所有元素也必須使用小寫(xiě)字母，所有屬性值都必須加引號，你還得記著(zhù)使用結束標簽，記著(zhù) 對img和br要使用自結束標簽。
從規范本身的內容來(lái)看，實(shí)際上是相同的，沒(méi)有什么不同。不同之處就是編碼風(fēng)格，因為對瀏覽器來(lái)說(shuō)，讀取符合HTML 4.01、HTML 3.2，或者XHTML 1.0規范的網(wǎng)頁(yè)都沒(méi)有問(wèn)題，對瀏覽器來(lái)說(shuō)這些網(wǎng)頁(yè)都是一樣的，都會(huì )生成相同的DOM樹(shù)。只不過(guò)人們會(huì )比較喜歡XHTML 1.0，因為不少人認同它比較嚴格的編碼風(fēng)格。
到了2000年，Web標準項目(Web Standards Project)的活動(dòng)開(kāi)展得如火如荼，開(kāi)發(fā)人員對瀏覽器里包含的那些亂七八糟的專(zhuān)有特性已經(jīng)忍無(wú)可忍了。大家都很生氣，就罵那些瀏覽器廠(chǎng)商“遵守個(gè)規范 就他媽的真有那么難嗎?"當時(shí)CSS有了長(cháng)足的發(fā)展，而且與XHTML 1.0結合得也很緊密，CSS加X(jué)HTML 1.0基本上就可以算是“最佳實(shí)踐"了。雖然在我看來(lái)HTML 4.01與XHTML 1.0沒(méi)有本質(zhì)上的不同，但大家都接受了。專(zhuān)業(yè)的開(kāi)發(fā)人員能做到元素全部小寫(xiě)，屬性全部小寫(xiě)，屬性值也全部加引號：由于專(zhuān)業(yè)人員起到了模范帶頭作用，越來(lái) 越多的人也都開(kāi)始支持這種語(yǔ)法。
我就是一個(gè)例子!過(guò)去的10年，我一直都使用XHTML 1.0文檔類(lèi)型，原因是這樣一來(lái)驗證器就能給我幫上很大的忙，對不對?只要我寫(xiě)的是XHTML 1.0，然后用驗證器測試，它就能告訴我是不是忘了給屬性值加引號，是不是沒(méi)有結束某個(gè)標簽，等等等等。而如果我寫(xiě)的是HTML 4.01，同樣的問(wèn)題就變成了有效的了，驗證器就不一定會(huì )提醒我了。
這就是我一直使用XHTML 1.0的原因。我估計很多人都……使用XHTML 1.0的朋友，請把手舉起來(lái)。好的。HTML 4.01呢?人少多了。一直沒(méi)有舉手的呢，大聲點(diǎn)，你們用什么?HTML 5，也很好!更早的呢，還有人使用更早的文檔類(lèi)型嗎?沒(méi)有了?
10年來(lái)我一直使用XHTML 1.0，就是因為驗證器能夠真正幫到我。有人用XHTML 1.1嗎?你知道有人用嗎?請舉手，別放下。有人把網(wǎng)頁(yè)標記為XML文檔嗎?有嗎?那你們使用的就不是XHTML 1.1。
這就是個(gè)大問(wèn)題。XHTML 1.0之后是XHTML 1.1，只是小數點(diǎn)后面的數字加了一個(gè)1，而且從詞匯表的角度看，規范本身沒(méi)有什么新東西，元素也都相同，屬性也都相同。但對XHTML 1.1來(lái)說(shuō)，唯一的變化是你必須把自己的文檔標記為XML文檔。在使用XHTML 1.0的時(shí)候，還可以把文檔標記為HTML，而我們也正是這樣做的，否則把文檔標記為XML沒(méi)準真會(huì )把人逼瘋的。
為什么這么說(shuō)呢?首先，把文檔標記為XML后，Internet Explorer不能處理。當然，IE9是可以處理了�？峙掠腥藭�(huì )講“真是太可愛(ài)了"，他們到現在居然都沒(méi)有忘了這件事。這艘船終于靠岸了!不過(guò)那時(shí)候， 作為全球領(lǐng)先的瀏覽器，IE無(wú)法處理接收到的XML文檔類(lèi)型的文檔，而規范又要求你以XML文檔類(lèi)型來(lái)發(fā)送文檔，這不把人逼瘋才怪呢。
所以說(shuō)XHTML 1.1有點(diǎn)脫離現實(shí)，而你不想把文檔以XML格式發(fā)送給那些能夠理解XML的瀏覽器，則是因為XML的錯誤處理模型。XML的語(yǔ)法，無(wú)論是屬性小寫(xiě)，元素 小寫(xiě)，還是始終要給屬性值加引號，這些都沒(méi)有問(wèn)題，都很好，事實(shí)上我也喜歡這樣做，但XML的錯誤處理模型卻是這樣的：解析器如果遇到錯誤，停止解析。規 范里就是這么寫(xiě)的。如果你把XHTML 1.1標記為XML文檔類(lèi)型，假設你用Firefox打開(kāi)這個(gè)文檔，而文檔中有一個(gè)和號(&)沒(méi)有正確編碼，就算整個(gè)頁(yè)面中就這一處錯誤，你看到 的也將是黃屏，瀏覽器死掉了。Firefox會(huì )說(shuō)：“沒(méi)戲了，頁(yè)面中有一個(gè)錯誤，你看不到這個(gè)網(wǎng)頁(yè)了。"根據XML規范，這樣處理是正確的，對 Firefox而言，遇到錯誤就停止解析，并且不呈現其他任何內容是嚴格按照XML規范做的。因為它不是HTML，HTML根本就沒(méi)有錯誤處理模型，但根 據XML規范，這樣做沒(méi)錯。
這就是為什么你不會(huì )把文檔標記為XML的另一個(gè)原因。接下來(lái)，新的版本是XHTML 2，大家注意后面沒(méi)有日期，因為這個(gè)規范并沒(méi)有完成。
現在就說(shuō)說(shuō)XHTML 2，我很愿意把問(wèn)題說(shuō)清楚，XHTML 2實(shí)際上真是一個(gè)非常非常好的規范，確實(shí)非常好……從理論的角度來(lái)說(shuō)。我的意思是說(shuō)，制定這個(gè)規范的人都是非常非常有頭腦的。直說(shuō)吧，領(lǐng)導制定這個(gè)規范的 家伙是斯蒂芬·彭伯頓(Stephen Pemberton)，他應該是本地人，是一個(gè)聰明過(guò)人的家伙。規范本身也很了不起，如果所有人都同意使用的話(huà)，也一定是一個(gè)非常好的格式。只不過(guò)，還不 夠實(shí)際。
首先，XHTML 2仍然使用XML錯誤處理模型，你必須保證以XML文檔類(lèi)型發(fā)送文檔;這一點(diǎn)不言自明：沒(méi)人愿意這樣做。其次，XHTML 2有意不再向后兼容已有的HTML的各個(gè)版本。他們甚至曾經(jīng)討論過(guò)廢除img元素，這對每天都在做Web開(kāi)發(fā)的人來(lái)說(shuō)確實(shí)有點(diǎn)瘋了的味道。但我們知道，他 們之所以這樣做，理論上確實(shí)有充足的理由——使用object元素可能會(huì )更好。
因此，無(wú)論XHTML 2在理論上是多么完美的一種格式，但卻從未有機會(huì )付諸實(shí)踐。而之所以難以將其付諸實(shí)踐，就是因為像你我這樣的開(kāi)發(fā)人員永遠不會(huì )支持它，它不向后兼容。同樣，瀏覽器廠(chǎng)商也不會(huì )，瀏覽器廠(chǎng)商必須要保證向后兼容。
為什么XHTML 1.1沒(méi)有像XML那樣得到真正廣泛地應用，為什么XHTML 2從未落到實(shí)處?因為它違反了一條設計原理，這條設計原理就是著(zhù)名的伯斯塔爾法則(Postel’s Law)。大家都知道：
發(fā)送時(shí)要保守;接收時(shí)要開(kāi)放。
沒(méi)錯，接收的時(shí)候要開(kāi)放，而這也正是Web得以構建的基礎。開(kāi)發(fā)瀏覽器的人必須敞開(kāi)胸懷，接收所有發(fā)送給瀏覽器的東西，因為它們過(guò)去一直都在接收那 些不夠標準的東西，對不對?Web上的很多文檔都不規范，但那正是Web發(fā)展的動(dòng)力。從某種角度講，Web走的正是一條混沌發(fā)展之路，雖然混沌，但卻非常 美麗誘人。在Web上，格式不規范的文檔隨處可見(jiàn)，但那又怎樣呢?如果所有人都能夠寫(xiě)出精準的XML，所有文檔的格式都十分正確，那當然好了�？墒�，那不 現實(shí)�，F實(shí)是伯斯塔爾法則。
作為專(zhuān)業(yè)人士，在發(fā)送文檔的時(shí)候，我們會(huì )盡量保守一些，盡量采用最佳實(shí)踐，盡量確保文檔格式良好。但從瀏覽器的角度說(shuō)，它們必須以開(kāi)放的姿態(tài)去接收任何文檔。
有人可能會(huì )說(shuō)XML有錯誤處理模型，XHTML 1.1和XHTML 2都使用該模型，但那個(gè)錯誤處理模型太苛刻了。它絕對不符合接收時(shí)開(kāi)放這個(gè)法則，遇到一個(gè)錯誤就停止解析怎么能叫開(kāi)放呢?我們只能說(shuō)它與健壯性法則(也就是伯斯塔爾法則)是對立的。
HTML 5
之后，就到了HTML 5，但HTML 5并不是由W3C直接制定的。故事的經(jīng)過(guò)是這樣的，到20世紀末的時(shí)候，還沒(méi)有HTML工作組，W3C內部的一些人就開(kāi)始琢磨了，“HTML也許還可以更 長(cháng)壽一點(diǎn)，只要我們對它稍加擴展就行了。只要把我們放在XHTML上的時(shí)間和精力拿出一部分來(lái)，就可以提升一下HTML中的表單，可以讓HTML更接近編 程語(yǔ)言，就可以讓它更上一層樓。"
于是，在2004年W3C成員內部的一次研討會(huì )上，當時(shí)Opera公司的代表伊恩·�？松�(Ian Hickson)提出了一個(gè)擴展和改進(jìn)HTML的建議。他建議新任務(wù)組可以跟XHTML 2并行，但是在已有HTML的基礎上開(kāi)展工作，目標是對HTML進(jìn)行擴展。W3C投票表決的結果是——“反對"，因為HTML已經(jīng)死了，XHTML 2才是未來(lái)的方向。然后，Opera、Apple等瀏覽器廠(chǎng)商，以及其他一些成員說(shuō)：“那好吧，不指望他們了，我們自已一樣可以做這件事，我們脫離 W3C。"他們成立了Web Hypertext Applications Technology Working Group(Web超文本應用技術(shù)工作組，WHATWG)——可巧的是，他們自稱(chēng)工作組，而不是特別小組(task force)，這就為HTML 5將來(lái)的命運埋下了伏筆。
WHATWG決定完全脫離W3C，在HTML的基礎上開(kāi)展工作，向其中添加一些新東西。這個(gè)工作組的成員里有瀏覽器廠(chǎng)商，因此他們不僅可以說(shuō)加就加，而且還能夠一一實(shí)現。結果，大家不斷提出一些好點(diǎn)子，并且逐一做到了瀏覽器中。
WHATWG的工作效率很高，不久就初見(jiàn)成效。在此期間，W3C的XHTML 2沒(méi)有什么實(shí)質(zhì)性的進(jìn)展。特別是，如果從實(shí)現的角度來(lái)說(shuō)，用原地踏步形容似乎也不為過(guò)。
結果，一件有意思的事情發(fā)生了。那是在2006年，蒂姆·伯納斯-李寫(xiě)了一篇博客，說(shuō)：“你們知道嗎?我們錯了。我們錯在企圖一夜之間就讓W(xué)eb跨 入XML時(shí)代，我們的想法太不切實(shí)際了，是的，也許我們應該重新組建HTML工作組了。"善哉斯言，后來(lái)的故事情節果真就是這樣發(fā)展的。W3C在2007 年組建了HTML 5工作組。這個(gè)工作組面臨的第一個(gè)問(wèn)題，毫無(wú)疑問(wèn)就是“我們是從頭開(kāi)始做起呢，還是在2004年成立的那個(gè)叫WHATWG的工作組既有成果的基礎上開(kāi)始工 作呢?"答案是顯而易見(jiàn)的，他們當然希望從已經(jīng)取得的成果著(zhù)手，以之為基礎展開(kāi)工作。于是他們又投了一次票，同意“在WHATWG工作成果的基礎上繼續開(kāi) 展工作"。好了，這下他們要跟WHATWG并肩戰斗了。
第二個(gè)問(wèn)題就是如何理順兩個(gè)工作組之間的關(guān)系。W3C這個(gè)工作組的編輯應該由誰(shuí)擔任?是不是還讓W(xué)HATWG的編輯，也就是現在Google的伊 恩·�？松瓉�(lái)兼任?于是他們又投了一次票，贊成“讓伊恩·�？松瓝蜽3C HTML 5規范的編輯，同時(shí)兼任WHATWG的編輯，更有助于新工作組開(kāi)展工作。"
這就是他們投票的結果，也就是我們今天看到的局面：一種格式，兩個(gè)版本。WHATWG的網(wǎng)站上有這個(gè)規范，而W3C的站點(diǎn)上同樣也有一份。
如果你不了解內情，很可能會(huì )產(chǎn)生這樣的疑問(wèn)：“哪個(gè)版本才是真正的規范?"當然，這兩個(gè)版本內容是一樣的……基本上相同。實(shí)際上，這兩個(gè)版本將來(lái)還 會(huì )分道揚鑣�，F在已經(jīng)有了分道揚鑣的跡象了。我的意思是說(shuō)，W3C最終要制定一個(gè)具體的規范，這個(gè)規范會(huì )成為一個(gè)工作草案，定格在某個(gè)歷史時(shí)刻。
而WHATWG呢，他們還在不斷地迭代。即使目前我們說(shuō)的HTML 5，也不能完全涵蓋WHATWG正在從事的工作。最準確的理解是他們正在開(kāi)發(fā)一項簡(jiǎn)單的HTML或Web技術(shù)，因為這才是他們工作的核心目標。然而，同時(shí) 存在兩個(gè)這樣的工作組，這兩個(gè)工作組同時(shí)開(kāi)發(fā)一個(gè)基本相同的規范，這無(wú)論如何也容易讓人產(chǎn)生誤解。誤解就可能造成麻煩。
其實(shí)這兩個(gè)工作組背后各自有各自的流程，因為它們的理念完全不同。在WHATWG，可以說(shuō)是一種獨裁的工作機制。我剛才說(shuō)了，伊恩·�？松蔷庉�。他會(huì )聽(tīng)取各方意見(jiàn)，在所有成員各抒己見(jiàn)，充分陳述自己的觀(guān)點(diǎn)之后，他批準自己認為正確的意見(jiàn)。
W3C則截然相反，可以說(shuō)是一種民主的工作機制。所有成員都可以發(fā)表意見(jiàn)，而且每個(gè)人都有投票表決的權利。這個(gè)流程的關(guān)鍵在于投票表決。從表面上 看，WHATWG的工作機制讓人不好接受。豈止是不好接受，簡(jiǎn)直是歷史的倒退。相信誰(shuí)都會(huì )認為“運作任何項目都不能采取這種方式!"
W3C的工作機制聽(tīng)起來(lái)讓人很舒服。至少體現了人人平等嘛。但在實(shí)踐中，WHATWG的工作機制運行得非常非常好。我認為之所以會(huì )這樣，主要歸功于伊恩·�？松�。他的的確確是一個(gè)非常稱(chēng)職的編輯。他在聽(tīng)取各方意見(jiàn)時(shí)，始終可以做到絲毫不帶個(gè)人感情色彩。
從原理上講，W3C的工作機制很公平，而實(shí)際上卻非常容易在某些流程或環(huán)節上卡殼，造成工作停滯不前，一件事情要達成決議往往需要花費很長(cháng)時(shí)間。那 到底哪種工作機制最好呢?我認為，最好的工作機制是將二者結合起來(lái)。而事實(shí)也是兩個(gè)規范制定主體在共同制定一份相同的規范，我想，這倒是非常有利于兩種工 作機制相互取長(cháng)補短。
兩個(gè)工作組之所以能夠同心同德，主要原因是HTML 5的設計思想。因為他們從一開(kāi)始就確定了設計HTML 5所要堅持的原則。結果，我們不僅看到了一份規范，也就是W3C站點(diǎn)上公布的那份文檔，即HTML 5語(yǔ)言規范，還在W3C站點(diǎn)上看到了另一份文檔，也就是HTML設計原理。而這份文檔的一位編輯今天也來(lái)到了我們大會(huì )的現場(chǎng)，她他就是安妮·奇泰絲 (Anne Van Kesteren)。如果大家對這份文檔有問(wèn)題，可以請教安妮。
這份文檔非常好，真的非常出色。這份文檔，可以說(shuō)見(jiàn)證了W3C與WHATWG同心協(xié)力共謀發(fā)展的歷程。難道你們不覺(jué)得他們像是一對歡喜冤家嗎?那他們還怎么同心同德呢?這份文檔忠實(shí)地記錄了他們一道做了什么，他們共同擁護什么。
接下來(lái)，我想要講的就是這份文檔。因為，既然他們能就這份文檔達成共識，那么我相信，HTML 5必將是一個(gè)偉大的規范，而他們已經(jīng)認可這就是他們的共同行動(dòng)綱領(lǐng)。為此，你才會(huì )看到諸如兼容性、實(shí)用性、互用性之類(lèi)的概念。即便W3C與WHATWG之 間再有多大的分歧——確實(shí)相當多——至少他們還有這份文檔中記錄的共識。這一點(diǎn)才是至關(guān)重要的。正因為他們有了共識，才有了這份基于共識描述設計原理的文 檔。
避免不必要的復雜性
下面我就給大家介紹一些這份文檔中記載的設計原理。第一個(gè)，非常簡(jiǎn)單：避免不必要的復雜性。好像很簡(jiǎn)單吧。我用一個(gè)例子來(lái)說(shuō)明。
假設我使用HTML 4.01規范，我打開(kāi)文檔，輸入doctype。這里有人記得HTML 4.01的doctype嗎?好，沒(méi)有，我猜沒(méi)有。除非……我的意思是說(shuō)，你是傻冒�，F場(chǎng)恐怕真有人背過(guò)，這就是HTML 4.01的doctype：
"http://www.w3.org/TR/html4/strict.dtd">
我不記這個(gè)兩行代碼，不然還要記事本、要Google、要模板有什么用呢?
要是我使用XHTML 1.0呢，這個(gè)規范我都已經(jīng)用了10年了。有誰(shuí)記得住這個(gè)doctype嗎?沒(méi)錯，它的長(cháng)度跟HTML 4.01的差不太多：
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
是不是，基本上相同。它要告訴瀏覽器的是：這個(gè)文檔是XHTML 1.0的文檔。那么在HTML 5中，省掉不必要的復雜性，doctype就簡(jiǎn)化成了：
>
僅此而已。好了，就連我也能過(guò)目不忘了。我用不著(zhù)把這幾個(gè)字符記在記事本里了。我得說(shuō)，在我第一次看到這個(gè)doctype的時(shí)候——我當然以為這是 一個(gè)HTML文檔的doctype——被它嚇了一跳：“是不是還少一個(gè)數字5啊?"我心里想：“這個(gè)doctype想告訴瀏覽器什么呢?就說(shuō)這個(gè)文檔是 HTML嗎?難道這是有史以來(lái)唯一一個(gè)HTML版本嗎，這件事我得首先搞清楚，HTML今后永遠不會(huì )再有新版本了嗎?"好一副唯我獨尊的架式!我錯了，因 為這個(gè)doctype并沒(méi)有這個(gè)意思。為此，必須先搞清楚為什么文檔一開(kāi)頭就要寫(xiě)doctype。它不是寫(xiě)給瀏覽器看的。Doctype是寫(xiě)給驗證器看 的。也就是說(shuō)，我之所以要在文檔一開(kāi)頭寫(xiě)那行XHTML 1.0的doctype，是為了告訴驗證器，讓驗證器按照該doctype來(lái)驗證我的文檔。
瀏覽器反倒無(wú)所謂了。假設我寫(xiě)的是HTML 3.2文檔，文檔開(kāi)頭寫(xiě)的是HTML 3.2的doctype。而在文檔中某個(gè)地方，我使用了HTML 4.01中才出現的一個(gè)元素。瀏覽器會(huì )怎么處理這種情況?它會(huì )因為這個(gè)元素出現在比doctype聲明的HTML版本更晚的規范中，就不解釋呈現該元素 嗎?不會(huì )，當然不會(huì )!它照樣會(huì )解釋呈現該元素，別忘了伯斯塔爾法則，別忘了健壯性。瀏覽器在接收的時(shí)候必須要開(kāi)放。因此，它不會(huì )檢查任何格式類(lèi)型，而驗證 器會(huì )，驗證器才關(guān)心格式類(lèi)型。這才是存在doctype的真正原因。
而按照HTML 5的另一個(gè)設計原理，它必須向前向后兼容，兼容未來(lái)的HTML版本——不管是HTML6、HTML7，還是其他什么——都要與當前的HTML版本，HTML 5，兼容。因此，把一個(gè)版本號放在doctype里面沒(méi)有多大的意義，即使對驗器證也一樣。
剛才，我說(shuō)doctype不是為瀏覽器寫(xiě)的，這樣說(shuō)大多數情況下沒(méi)有問(wèn)題。在有一種情況下，你使用的doctype會(huì )影響到瀏覽器，相信在座諸位也 都知道。但在這種情況下，Doctype并非真正用得其所，而只是為了達到某種特殊的目的才使用doctype。當初微軟在引入CSS的時(shí)候，走在了標準 的前頭，他們率先在瀏覽器中支持CSS，也推出了自己的盒模型——后來(lái)標準發(fā)布了，但標準中使用了不一樣的盒模型。他們怎么辦?他們想支持標準，但也想向 后兼容自己過(guò)去推出的編碼方式。他們怎么知道網(wǎng)頁(yè)作者想使用標準，還是想使用他們過(guò)去的方式?
于是，他們想出了一個(gè)非常巧妙的主意。那就是利用doctype，利用有效的doctype來(lái)觸發(fā)標準模式，而不是兼容模型(quiks mode)。這個(gè)主意非常巧妙。我們今天也都是這樣在做，在我們向文檔中加入doctype時(shí)，就相當于聲明了“我想使用標準模式"，但這并不是發(fā)明 doctype的本意。這只是為了達到特殊的目的在利用doctype。
下面我出一道有獎?chuàng )尨痤}，聽(tīng)好：“一分鐘后開(kāi)始，如果你手快的話(huà)，第一個(gè)在文檔前面寫(xiě)完doctype html，然后我用Internet Explorer打開(kāi)你的文檔，會(huì )觸發(fā)它的標準模式，還是會(huì )觸發(fā)它的兼容模式?"
答案是，這是在Internet Explorer中觸發(fā)標準模式的最少字符數目。我認為這也說(shuō)明了HTML 5規范的本質(zhì)：它不追求理論上的完美。HTML 5所體現的不是“噢，給作者一個(gè)簡(jiǎn)短好記的doctype不好嗎?"，沒(méi)錯，簡(jiǎn)短好記是很好，但如果這個(gè)好記的doctype無(wú)法適應現有的瀏覽器，還不 如把它忘了更好。因此，這個(gè)平衡把握得非常好，不僅理論上看是個(gè)好主意——簡(jiǎn)短好記的doctype，而且實(shí)踐中同樣也是個(gè)好主意——仍然可以觸發(fā)標準模 式。應該說(shuō)，Doctype是一個(gè)非常典型的例子。
還有一個(gè)例子，同樣可以說(shuō)明規范是如何省略不必要的復雜性，避免不必要的復雜性的。如果前面的文檔使用的是HTML 4.01，假設我要指定文檔的字符編碼。理想的方式，是通過(guò)服務(wù)器在頭部信息中發(fā)送字符編碼，不過(guò)也可以在文檔這個(gè)級別上指定：
<metahttp-equiv="Content-Type"content="text/html;charset=utf-8">
同樣，我也不會(huì )把這行代碼背下來(lái)。我還想省下自己的腦細胞去記點(diǎn)別的更有價(jià)值的東西呢。不過(guò)，如果我想指定文檔使用UTF-8編碼，只能添加這行代 碼。這是在HTML 4.01中需要這樣做。要是你在XHTML 1.0指定同樣的編碼，就得多敲一下鍵盤(pán)，因為你還得聲明meta元素位于一個(gè)開(kāi)始的XML標簽中。
xmlversion="1.0"encoding="UTF-8"?><metahttp-equiv="Content-Type"content="text/html;charset=utf-8"/>
在HTML 5中，你要敲的字符只有：
<metacharset="utf-8">
簡(jiǎn)短好記。我能背下來(lái)。
同樣，這樣寫(xiě)也是有效的。它不僅適用于最新版本的瀏覽器，只要是今天還有人在用的瀏覽器都同樣有效。為什么?因為在我們把這些meta元素輸入瀏覽 器時(shí)，瀏覽器會(huì )這樣解釋它：“元數據(meta)點(diǎn)點(diǎn)點(diǎn)點(diǎn)點(diǎn)，字符集(charset)utf-8。"這就是瀏覽器在解釋那行字符串時(shí)真正看到的內容。它 必須看到這些內容，根據就是伯斯塔爾法則，對不對?
我多次提到健壯性原理，但總有人不理解。我們換一種說(shuō)法，瀏覽器會(huì )想“好，我覺(jué)得作者是想要指定一個(gè)字符集……看，沒(méi)錯，utf-8。"這些都是規范里明文規定的。如今，不僅那個(gè)斜杠可以省了，而且總共只要寫(xiě)meta charset="utf-8″就行了。
關(guān)于省略不必要的復雜性，或者說(shuō)避免不必要的復雜性的例子還有不少。但關(guān)鍵是既能避免不必要的復雜性，還不會(huì )妨礙在現有瀏覽器中使用。比如說(shuō)，在 HTML 5中，如果我使用link元素鏈接到一個(gè)樣式表，我說(shuō)了rel="stylesheet"，然后再說(shuō)type="text/css"，那就是重復自己了。 對瀏覽器而言，我就是在重復自己。瀏覽器用不著(zhù)同時(shí)看到這兩個(gè)屬性。瀏覽器只要看到rel="stylesheet"就夠了，因為它可以猜出來(lái)你要鏈接的 是一個(gè)CSS樣式表。所以就不用再指定type屬性了。你不是已經(jīng)說(shuō)了這是一個(gè)樣式表了嘛;不用再說(shuō)第二次了。當然，愿意的話(huà)，你可以再說(shuō);如果你想包含 type屬性，請便。
同樣地，如果你使用了script元素，你說(shuō)type="text/javascript"，瀏覽器差不多就知道是怎么回事了。對Web開(kāi)發(fā)而言，你還使用其他的腳本語(yǔ)言嗎?如果你真想用其他腳本語(yǔ)言，沒(méi)人會(huì )阻攔你。但我要奉勸你一句，任何瀏覽器都不會(huì )支持你。
愿意的話(huà)，你可以添加一個(gè)type屬性。不過(guò)，也可以什么都不寫(xiě)，瀏覽器自然會(huì )假設你在使用JavaScript。避免-不必要的-復雜性。
支持已有的內容
支持已有的內容。這一點(diǎn)非常重要，因為很多人都認為HTML 5很新，很閃亮;它應該代表著(zhù)未來(lái)發(fā)展的方向，應該把Web推向一個(gè)新的發(fā)展階段。這就是HTML 5，對嗎?顯然，我們都會(huì )考慮讓W(xué)eb的未來(lái)發(fā)展得更好，但他們則必須考慮過(guò)去。別忘了W3C這個(gè)工作組中有很多人代表的是瀏覽器廠(chǎng)商，他們肯定是要考慮 支持已有內容的。只要你想構建一款瀏覽器，就必須記住這個(gè)原則：必須支持已有的內容。
下面我們就來(lái)看一個(gè)HTML 5支持已有內容的例子。
這個(gè)例子展示了編寫(xiě)同樣內容的四種不同方式。上面是一個(gè)img元素，下面是帶一個(gè)屬性的段落元素。四種寫(xiě)法唯一的不同點(diǎn)就是語(yǔ)法。把其中任何一段代 碼交給瀏覽器，瀏覽器都會(huì )生成相同的DOM樹(shù)，沒(méi)有任何問(wèn)題。從瀏覽器的角度看，這四種寫(xiě)法沒(méi)有區別。因而在HTML 5中，你可以隨意使用下列任何語(yǔ)法。
<imgsrc="foo"alt="bar"/><pclass="foo">Helloworldp><imgsrc="foo"alt="bar"><pclass="foo">Helloworld <IMGSRC="foo"ALT="bar"><PCLASS="foo">HelloworldP><imgsrc=fooalt=bar><pclass=foo>Helloworldp>
好了，看到這幾段代碼，恐怕有人會(huì )說(shuō)“不對不對不對。其中只有一個(gè)是對的，另外三個(gè)——說(shuō)不好。"不對，應該給屬性值加引號!拜托，我們可是一直都給屬性值加引號的!元素名大寫(xiě)對嗎?這種做法10年不是就被拋棄了嗎?
看到HTML 5同時(shí)允許這些寫(xiě)法，我心里忍不住一陣陣想吐。我寫(xiě)了10年的XHTML 1.0，已經(jīng)非常適應嚴格的語(yǔ)法了。但你必須明白，站在瀏覽器的角度上，這些寫(xiě)法實(shí)際上都是一樣的。確實(shí)沒(méi)有什么問(wèn)題。
還有誰(shuí)也感到不舒服了嗎?有誰(shuí)看到這些之后想“噢，這不是亂寫(xiě)嘛，這樣做不對"?只有我這樣想嗎?還有別人嗎?
但是，HTML 5必須支持已經(jīng)存在的內容，而已有的內容就是這個(gè)樣子的。不是嗎?根據伯斯塔爾法則，瀏覽器沒(méi)有別的選擇。
有人可能會(huì )說(shuō)“這樣不行。我覺(jué)得語(yǔ)言本身應該提供一種開(kāi)關(guān)，讓作者能夠表明自己想做什么。"比如說(shuō)，想使用某種特定的語(yǔ)法，像XHTML，而不是使 用其他語(yǔ)法。我理解這些人的想法。但我不贊成在語(yǔ)言里設置開(kāi)關(guān)。因為我們討論的只是編碼風(fēng)格或者寫(xiě)作風(fēng)格，跟哪種語(yǔ)法正確無(wú)關(guān)。對于像我們這樣的專(zhuān)業(yè)人 士，我認為可以使用lint工具(一種軟件質(zhì)量保證工具，或者說(shuō)是一種更加嚴格的編譯器。它不僅可以象普通編譯器那樣檢查出一般的語(yǔ)法錯誤，還可以檢查出 那些雖然完全合乎語(yǔ)法要求，但很可能是潛在的、不易發(fā)現的錯誤)，對其他技術(shù)我們不是也在使用lint工具嘛。
比如說(shuō)對JavaScript使用lint工具。JavaScript同樣也是比較混亂、不嚴謹的例子，但它非常強大，原因恰恰是它混亂、不嚴謹， 而且有很多不同的編碼方式。在JavaScript，你可以在每條語(yǔ)句末尾加上分號，但不是必需的，因為JavaScript會(huì )自動(dòng)插入分號……是不是聽(tīng) 起來(lái)有點(diǎn)不好接受?
正因為如此，才有了像JSlint這樣的工具，在道格拉斯·克勞克福德(Douglas Crockford)的網(wǎng)站jslint.org上面。有個(gè)網(wǎng)頁(yè)上寫(xiě)著(zhù)“JSlint可能會(huì )傷害你的感情。"但這確實(shí)是個(gè)非常棒的工具，它可以把 JavaScript代碼變得完美無(wú)瑕。如果你通過(guò)JSlint運行JavaScript，它會(huì )告訴你“好，你的JavaScript代碼有效，但寫(xiě)法不 妥。你這種編碼風(fēng)格啊，我不喜歡。不贊成你這樣寫(xiě)。這樣寫(xiě)不好。"特別是對團隊，對于要使用統一的編碼風(fēng)格的團隊，JSlint是非常方便的工具。
我個(gè)人認為，不僅對團隊來(lái)說(shuō)，就算是你自己寫(xiě)代碼，也要堅持一種語(yǔ)法風(fēng)格。從瀏覽器解析的角度講，不存在哪種語(yǔ)法比另一種更好的問(wèn)題，但我認為，作 為專(zhuān)業(yè)人士，我們必須能夠自信地講“這就是我的編碼風(fēng)格。"然而，我不認為語(yǔ)言里應該內置這種開(kāi)關(guān)。你可以使用lint工具來(lái)統一編碼風(fēng)格�，F在就來(lái)說(shuō)說(shuō) lint工具。大家可以登錄htmllint.com，在其中運行你的HTML 5文檔，它會(huì )幫你檢查屬性值是否加了引號，元素是否小寫(xiě)，你還可以通過(guò)勾選復選框來(lái)設置其他檢查項。
但這不意味著(zhù)拒絕粗心大意的標記，做不做清理完全取決于你自己。我說(shuō)過(guò)，因為瀏覽器必須支持已有的內容，HTML 5自然也不能例外。歸根結底還是伯斯塔爾法則。我們始終離不開(kāi)伯斯塔爾法則。
解決現實(shí)的問(wèn)題
HTML 5的另一個(gè)設計原理是解決現實(shí)的問(wèn)題。顯而易見(jiàn)的是，解決各種問(wèn)題的格式和規范已經(jīng)比比皆是了，因此在我看來(lái)，這個(gè)原理其實(shí)是要解決理論問(wèn)題，而非解決現實(shí)的問(wèn)題。這條設計原理是要從理論上承認人們普遍存在的問(wèn)題，消除敏感問(wèn)題。
下面我來(lái)舉個(gè)例子。相信這個(gè)例子有不少人都遇到過(guò)。假設我使用HTML 4或XHTML 1，頁(yè)面中已經(jīng)有了一塊內容，我想給整塊內容加個(gè)鏈接，怎么辦?問(wèn)題是這塊內容里包含一個(gè)標題，一個(gè)段落，也許還有一張圖片。如果我想給它們全部都可以點(diǎn) 擊，必須使用3個(gè)鏈接元素。于是，我得先把光標放在標題(比如說(shuō)h2元素)中，寫(xiě)一個(gè)鏈接標簽，然后再選中所有要包含到鏈接里面來(lái)的文本。接著(zhù)，再把光標 放在段落里，寫(xiě)一個(gè)鏈接標簽，然后把段落中的文本放在鏈接里……
<h2><ahref="/path/to/resource">Headlinetexta>h2><p><ahref="/path/to/resource">Paragraphtext.a>p>
在HTML 5中，我只要簡(jiǎn)單地把所有內容都包裝在一個(gè)鏈接元素中就行了。
<ahref="/path/to/resource"><h2>Headlinetexth2><p>Paragraphtext.p>a>
沒(méi)錯，鏈接包含的都是塊級元素，但現在我可以用一個(gè)元素包含它們。這樣太好了。因為我碰到過(guò)類(lèi)似的情形，必須給幾個(gè)塊級元素加上相同的鏈接，所有能這樣寫(xiě)就太好了。為此，我就非常歡迎HTML 5這個(gè)新標準。
它解決了一個(gè)現實(shí)的問(wèn)題。我敢說(shuō)在座不少朋友都曾遇到過(guò)這個(gè)問(wèn)題。
那這到底解決的是什么問(wèn)題呢?瀏覽器不必因此重新寫(xiě)代碼來(lái)支持這種寫(xiě)法。這種寫(xiě)法其實(shí)早就已經(jīng)存在于瀏覽器中了，因為早就有人這樣寫(xiě)了，當然以前這 樣寫(xiě)是不合乎規范的。所以，說(shuō)HTML 5解決現實(shí)的問(wèn)題，其本質(zhì)還是“你都這樣寫(xiě)了很多年了吧?現在我們把標準改了，允許你這樣寫(xiě)了。"
求真務(wù)實(shí)
在所有設計原理中，這一條恐怕是最響亮的了——求真務(wù)實(shí)。不知道大家有沒(méi)有在公司里開(kāi)會(huì )時(shí)聽(tīng)到過(guò)這種口號：“開(kāi)拓進(jìn)取，求真務(wù)實(shí)。"實(shí)際上，除了作 為企業(yè)的口號，它還是一條非常重要的設計原理，因為求真務(wù)實(shí)對于HTML的含義是：在解決那些令人頭痛的問(wèn)題之前，先看看人們?yōu)閼獙@些問(wèn)題都想出了哪些 辦法。集中精力去理解這些“民間的"解決方案才是當務(wù)之急。
HTML 5中新的語(yǔ)義元素就是遵循求真務(wù)實(shí)原理的反映。新增的元素不算多，談不上無(wú)限的擴展性，但卻不失為一件好事。盡管數量屈指可數，但意義卻非同一般。這些新 元素涉及頭部(header)、腳部(footer)、分區(section)、文章(article)……，相信大家都不會(huì )覺(jué)得陌生。我的意思是說(shuō)，即 便你不使用HTML 5，也應該熟悉這些稱(chēng)呼，這些都是你曾經(jīng)使用過(guò)的類(lèi)名，比如class="header"/“head"/“heading"，或 class="footer"/“foot"。當然，也可能是ID，id="header"，id="footer"。這些不都是我們已經(jīng)司空見(jiàn)慣了的 嘛。
好，舉個(gè)例子吧，假設你今天寫(xiě)了下面這個(gè)文檔。
<body><pid="header">...p><pid="navigation">...p><pid="main">...p><pid="sidebar">...p><pid="footer">...p>body>
這里有一個(gè)p使用了id="header"，另一個(gè)p使用了id="navigation"，……。怎么樣，都輕車(chē)熟路了吧?在HTML 5中，這些元素都可以換掉。說(shuō)起新增的語(yǔ)義元素，它們價(jià)值的一方面可以這樣來(lái)體現：“嘿，看啊，這樣多好，用HTML 5新增的元素可以把這些p都替換掉。"
<body><header>...header><nav>...nav><pid="main">...p><aside>...aside><footer>...footer>body>
當然了，你可以這樣做。在文檔級別上使用這些元素沒(méi)有問(wèn)題。但是，假如新增這些元素的目的僅僅是為了取代原來(lái)的p，那就真有點(diǎn)多此一舉了。
雖然在這個(gè)文檔中，我們用這些新元素來(lái)替換的是ID，但在我個(gè)人看來(lái)，將它們作為類(lèi)的替代品更有價(jià)值。為什么這么說(shuō)呢?因為這些元素在一個(gè)頁(yè)面中不 止可以使用一次，而是可以使用多次。沒(méi)錯，你可以為文檔添加一個(gè)頭部(header)，再添加一個(gè)腳部(footer);但文檔中的每個(gè)分區 (section)照樣也都可以有一個(gè)頭部和一個(gè)腳部。而每個(gè)分區里還可以嵌套另一個(gè)分區，被嵌套的分區仍然可以有自己的頭部和腳部，是這樣吧?
這四個(gè)新元素：section、article、aside和nav，之所以說(shuō)它們強大，原因在于它們代表了一種新的內容模型，一種HTML中前所 未有的內容模型——給內容分區。迄今為止，我們一直都在用p來(lái)組織頁(yè)面中的內容，但與其他類(lèi)似的元素一樣，p本身并沒(méi)有語(yǔ)義。但section、 article、aside和nav實(shí)際上是在明確地告訴你——這一塊就像文檔中的另一個(gè)文檔一樣。位于這些元素中的任何內容，都可以擁有自己的概要、標 題，自己的腳部。
其中最為通用的section，可以說(shuō)是與內容最相關(guān)的一個(gè)。而article則是一種特殊的section。Aside呢，是一種特殊的section。最后，Nav也是一種特殊的section。
好，即便是現在，你照樣可以使用p和類(lèi)來(lái)描述頁(yè)面中不同的部分，就像下面這樣：
<pclass="item"><h2>...h2><pclass="meta">...p><pclass="content">... p><pclass="links">...p>p>
其中包含可能是有關(guān)內容作者的元數據，而下面會(huì )給出一些鏈接，差不多就這樣。在HTML 5中，我完全可以說(shuō)這塊內容就是一個(gè)文檔，通過(guò)對內容分區，使用section或article或aside，我可以說(shuō)“這一塊完全是可以獨立存在的。" 因此，我當然可以使用header和footer。
<sectionclass="item"><header><h1>...h1>header><footerclass="meta">...footer><pclass="content">... p><navclass="links">...nav>section>
請注意，即便是footer，也不一定非要出現在下面，不是嗎?這幾個(gè)元素，header、footer、aside、nav，最重要的是它們的語(yǔ) 義;跟位置沒(méi)有關(guān)系。一想到footer這個(gè)詞，我們總會(huì )不由自主地想，“噢，應該放在下面。"同樣，我們把aside想象成一個(gè)側邊欄�？墒�，如果你看 一看規范，就會(huì )發(fā)現這些元素只跟內容有關(guān)。因此，放在footer中的內容也可以是署名，文章作者之類(lèi)的，它只是你使用的一個(gè)元素。這個(gè)元素并沒(méi)有說(shuō)“必 須把我放在文檔或者分區的下面。"
這里，請注意，最重要的還不是我用幾個(gè)新元素替換了原來(lái)的p加類(lèi)，而是我把原來(lái)的H2換成了H1——震撼吧，我看到有人發(fā)抖了。我碰到過(guò)不少職 業(yè)的Web開(kāi)發(fā)人員，多年來(lái)他們一直認為規范里說(shuō)一個(gè)文檔中只能有一個(gè)H1。還有一些自詡為萬(wàn)能的SEO秘訣同樣說(shuō)要這樣。很多SEO的技巧其實(shí)是很教條 的。所謂教條，意思就是不相信數據。過(guò)去，這種教條表現為“不行，頁(yè)面中包含兩個(gè)以上的H1，你就會(huì )死掉的。"在HTML 5中，只要你建立一個(gè)新的內容塊，不管用section、article、aside、nav，還是別的元素，都可以在其中使用H1，而不必擔心這個(gè)塊里 的標題在整個(gè)頁(yè)面中應該排在什么級別;H2、H3，都沒(méi)有問(wèn)題。
這個(gè)變化太厲害了。想一想吧，這個(gè)變化對內容管理是革命性的。因為現在，你可以把每個(gè)內容分區想象一個(gè)獨立的、能夠從頁(yè)面中拿出來(lái)的部分。此時(shí)，根 據上下文不同，這個(gè)獨立部分中的H1，在整個(gè)頁(yè)面中沒(méi)準會(huì )扮演H2或H3的角色——取決于它在文檔中出現的位置。面對這個(gè)突如其來(lái)的變化，也許有人的腦子 會(huì )暫時(shí)轉不過(guò)彎來(lái)。不要緊，但我可以告訴你，我認為這才是HTML 5中這些新語(yǔ)義標記的真正價(jià)值所在。換句話(huà)說(shuō)，我們現在有了獨立的元素了，這些元素中的標題級別可以重新定義。
我的文檔中可能會(huì )包含一個(gè)分區，這個(gè)分區中可能會(huì )嵌套另一個(gè)分區，或者一篇文章，然后文章再嵌套分區，分區再嵌套文章、嵌套分區，文章再嵌套文章。 而且每個(gè)分區和文章都可以擁有自己的H1到H6。從這個(gè)意義上講，H元素真可謂“子子孫孫，無(wú)窮匱也"了。但是，在你在編寫(xiě)內容或者內容管理系統的時(shí)候， 它們又都是獨立的，完全獨立的內容塊。這才是真正的價(jià)值所在。
實(shí)際上，這個(gè)點(diǎn)子并不HTML 5工作組拍腦門(mén)想出來(lái)的，也不是W3C最近才提出來(lái)的。下面這幾句話(huà)摘自蒂姆·伯納斯-李1991年的一封郵件，郵件是發(fā)給丹·康納利(Dan Connolly)的。他在郵件中解釋了對HTML的理解，他說(shuō)：“你知道……知道我的想法，我認為H1、H2這樣單調地排下去不好，我希望它成為一種可 以嵌套的元素，或者說(shuō)一個(gè)通用的H元素，我們可以在其中嵌套不同的層次。"但后來(lái)，我們沒(méi)有看到通用的H元素，而是一直在使用H1和H2——那是因為我們 一直在支持已有的內容。20年后的今天，這個(gè)理想終于實(shí)現了。
平穩退化
下一條原理大家應該都很熟悉了，那就是平穩退化。畢竟，我們已經(jīng)遵守這條規則好多年了。漸進(jìn)增強的另一面就是平穩退化。
有關(guān)HTML 5遵循這條原理的例子，就是使用type屬性增強表單。下面列出了可以為type屬性指定的新值，有number、search、range，等等。
inputtype="number"inputtype="search"inputtype="range"inputtype="email"inputtype="date"inputtype="url"
最關(guān)鍵的問(wèn)題在于瀏覽器在看到這些新type值時(shí)會(huì )如何處理�，F有的瀏覽器，不是將來(lái)的瀏覽器，現有的瀏覽器是無(wú)法理解這些新type值的。但在它們看到自己不理解的type值時(shí)，會(huì )將type的值解釋為text。
無(wú)論你寫(xiě)的是input type="foo"還是input type="bar"，現有的任何瀏覽器都會(huì )說(shuō)：“嗯，也許作者的意思是text。"因而，你從現在開(kāi)始就可以使用這些新值，而且你也可以放心，那些不理 解它們的瀏覽器會(huì )把新值看成type="text"，而這真是一個(gè)瀏覽器實(shí)踐平穩退化原理的好例子。
比如說(shuō)，你現在輸入了type="number"。假設你需要一個(gè)輸入數值的文本框。那么你可以把這個(gè)input的type屬性設置為 number，然后理解它的瀏覽器就會(huì )呈現一個(gè)可愛(ài)的小控件，像帶小箭頭圖標的微調控件之類(lèi)的。對吧?而在不理解它的瀏覽器中，你會(huì )看到一個(gè)文本框，一個(gè) 你再熟悉不過(guò)的文本框。既然如此，為什么不能說(shuō)輸入type="number"就會(huì )得到一個(gè)帶小箭頭圖標的微調控件呢?
當然，你還可以設置最小和最大值屬性，它們同樣可以平穩退化。這是問(wèn)題的關(guān)鍵。
再看input type="search"。你也可以考慮一下這種輸入框，因為這種輸入框在Safari中會(huì )被呈現為一個(gè)系統級的搜索控件，右邊還有一個(gè)點(diǎn)擊即可清除搜 索關(guān)鍵詞的X。而在其他瀏覽器中，你得到的則是一個(gè)文本框，就像你寫(xiě)的是input type="text"一樣，也就是你已經(jīng)非常熟悉的文本框。那為什么還不使用input type="search"呢?它不會(huì )有什么副作用，沒(méi)有，對不對?
HTML 5還為輸入元素增加了新的屬性，比如placeholder(占位符)。有人不知道這個(gè)屬性的用處嗎，沒(méi)有吧?沒(méi)錯，就是用于在文本框中預先放一些文本。 不對，不是標簽(label)——占位符和標簽完全不是一回事。占位符就是文本框可以接受的示例內容，一般顏色是灰色的。只要你一點(diǎn)擊文本框，它就消失 了。如果你把已經(jīng)輸入的內容全部刪除，然后單擊了文本框外部，它又會(huì )出現。
使用JavaScript編寫(xiě)一些代碼當然也可以實(shí)現這個(gè)功能，但HTML 5只用一個(gè)placeholder屬性就幫我們解決了問(wèn)題。
當然，對于不支持這個(gè)屬性的瀏覽器，你還是可以使用JavaScript來(lái)實(shí)現占位符功能。通過(guò)JavaScript來(lái)測試瀏覽器支不支持該屬性也非常簡(jiǎn)單。如果支持，后退一步，把路讓開(kāi)，樂(lè )享其成即可。如果不支持，可以再讓你的JavaScript來(lái)模擬這個(gè)功能。
現在，我不得不提到另一個(gè)話(huà)題了：HTML 5對Flash。也許你早聽(tīng)說(shuō)過(guò)了，或者在哪里看到了這方面的討論。說(shuō)實(shí)話(huà)，我一點(diǎn)也不明白。我搞不懂人們怎么會(huì )僅僅憑自己的推測來(lái)展開(kāi)爭論。
首先，他們所說(shuō)的HTML 5對Flash，并不是指的HTML 5，也不是指的Flash。而是指HTML 5的一個(gè)子集和Flash的一個(gè)子集。具體來(lái)說(shuō)，他們指的是視頻。因此，不管你在哪里聽(tīng)到別人說(shuō)“HTML 5對Flash"，那很可能說(shuō)的只是HTML 5視頻對Flash視頻。
其次，一說(shuō)HTML 5對Flash，就好像你必須得作出選擇一樣：你站在哪一邊?實(shí)際上不是這樣的。HTML 5規范的設計能夠讓你做到魚(yú)和熊掌兼得。
好，下面就來(lái)看看這個(gè)新的video元素;真是非常貼心的一個(gè)元素，而且設計又簡(jiǎn)單，又實(shí)用。一個(gè)開(kāi)始的video元素，加一個(gè)結束的video元 素，中間可以放后備內容。注意，是后備內容，不是保證可訪(fǎng)問(wèn)性的內容，是后備內容。
【HTML5設計原理】相關(guān)文章：
FPGA的原理和設計09-23
臥室裝修設計原理10-18
室內設計的原理09-22
HTML5的發(fā)展08-15
原理圖設計基礎簡(jiǎn)介09-25
淺談室內設計的原理07-18
平面設計編排構成原理09-14
設計師必看的10個(gè)HTML5動(dòng)畫(huà)工具08-05
塑料模具設計原理08-11
人力資源中薪酬設計原理08-11