實際上，確實有人會談到規范的內容。史蒂夫·?？思{（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開發領域是這樣?？v觀人類歷史，像國家和社會這樣大規模的構建活動背后，同樣也有設計原理。
就拿美國為例吧，美國的設計原理都寫在了《獨立宣言》中了。
我們認為這些真理是不言而喻的，人人生而平等，造物主賦予了每個人不可剝奪的權利，包括生存、自由和追求幸福。
這里有一句口號：生存、自由和追求幸福。這是被寫進憲法中的核心理念，它關系到我們所有人的一切，也就是我們構建自己社會的原則。
還有一個例子，就是卡爾·馬克思（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，經歷了非?？斓陌l展。問題是到了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是可以處理了?？峙掠腥藭v“真是太可愛了”，他們到現在居然都沒有忘了這件事。這艘船終于靠岸了！不過那時候，作為全球領先的瀏覽器，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更接近編程語言，就可以讓它更上一層樓。”
于是，在2004年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的伊恩·?？松瓉砑嫒?？于是他們又投了一次票，贊成“讓伊恩·?？松瓝蜽3C HTML5規范的編輯，同時兼任WHATWG的編輯，更有助于新工作組開展工作。”
這就是他們投票的結果，也就是我們今天看到的局面：一種格式，兩個版本。WHATWG的網站上有這個規范，而W3C的站點上同樣也有一份。
如果你不了解內情，很可能會產生這樣的疑問：“哪個版本才是真正的規范？”當然，這兩個版本內容是一樣的……基本上相同。實際上，這兩個版本將來還會分道揚鑣?，F在已經有了分道揚鑣的跡象了。我的意思是說，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嗎？好，沒有，我猜沒有。除非……我的意思是說，你是傻冒?，F場恐怕真有人背過，這就是HTML 4.01的doctype：

發表評論 共有條評論 用戶名: 密碼: 驗證碼: 匿名發表