繼團隊的CSS3.0中文手冊在國內首發以後，最近風風火火的到處吹起HTML5.0和CSS3.0的春風；似乎在這瀏覽器互相調侃的年代，成就了一大堆業界茶餘飯後的話題。
年前，google的chrome團隊來到公司做相關的交流，公司要求我做個前期討論方案。 於是想了一下，裡面提到了三點：
chrome對於12px以上字體大小支援的問題chrome的開發者工具雖有整合，但不及Firebug一樣的靈活好用。 對於網頁的解釋渲染是否應當配備兩種解釋其內核。前面的兩點對於chrome本身更加較為有針對性，而第三點；我想更多的是針對于我們新時代的瀏覽器編寫程式師，以及我們那些擬定W3C標準的國外友人。
回顧XHTML2.0與HTML5.0之間的戰爭時間跨越了將近4年的時間(2002/8/5–2006/7/26)，而爭鬥的結果當下而見是XHTML2.0敗退而走。
這場戰爭我們在XHTML2.0上面首先值得一說的是他思想當中留下來給我們的反思：（如看過Nicholas Chase大師的《The Web’s future: XHTML 2.0》可點擊跳過前戲。 ）將如b、i等純粹關於表現性質的標籤而採用帶有語義化取而代之。 （結構、行為、表現三者分離） <i>強調</i>, <b>更強調</b>.和
<em>強調</em>, <strong>更強調</strong>. 將img等內容圖片採用src屬性取而代之，並使用srctype進行類型定義。 （使得外部資源未能載入時展示文字說明，解除alt的限制性） <object>使用物件引入蘋果的介紹音訊</object><img src="apple.png" alt="這是一張蘋果的圖片" /><p> 這是一段蘋果這種水果的解說文字。 </p>和
<p src="apple.mp3" srctype="audio/x-mpeg"><span src="apple.png" srctype="image/png">這是一張蘋果的圖片</span >這是一段蘋果這種水果的解說文字。 </p> 將「沒層級性」的文章採用<h>、<p>與<section>的組合取而代之。 （使用模組化的大局觀思維進行編碼） <html><head> <title>網頁模組化</title></head><body> <h1>網頁模組化思維</h1> <p>2010年v2.0版本</p> <h2>什麼是模組化？ </h2> <p>模組化是指解決一個複雜問題時自頂向下逐層把軟體系統劃分成若干模組的過程。 每個模組完成一個特定的子功能，所有的模組按某種方法組裝起來，成為一個整 體，完成整個系統所要求的功能。 </p> <h3>什麼是前端的當中的模組？ </h3> <p>頁面當中的每一個有獨立內容並且能賦予標題命名的片段。 </p> <h2>為什麼要做模組化？ </h2> <p>多人協同開發的同時能有一部分總體把控，但是每個人又可以獨立的處理自己部分的代碼，同時不會干擾到其他的成員的代碼，高度提升效率。 修改時只需要處理獨立的需要修改的模組，對其餘模組不會影響；出錯時定位到具體模組，直接對於這一塊進行版本回滾。 高度降低風險。 </p> <h2>怎麼做模組化？ </h2> <p>先按照主內容再細化內容兩種方式分離出區塊，由PM進行命名規則約定，分派至各人手中進行代碼編寫。 最後由PM進行代碼片段合併。 </p> <h2>模組化需要注意什麼？ </h2> <p>公共部分的代碼許可權需要回歸至PM手上管理；允許代碼階段性的臃腫，定期進行公共部分的版本整合。 </p></body></html>和
<html><head> <title>網頁模組化</title></head><body> <section> <h> 網頁模組化思維</h> <p>2010年v2.0版本</p> <section> <h>什麼是模組化？ </h> <p>模組化是指解決一個複雜問題時自頂向下逐層把軟體系統劃分成若干模組的過程。 每個模組完成一個特定的子功能，所有的模組按某種方法組裝起來，成為一個整 體，完成整個系統所要求的功能。 </p> <section> <h>什麼是前端的當中的模組？ </h> <p>頁面當中的每一個有獨立內容並且能賦予標題命名的片段。 </p> </section> </section> <section> <h>為什麼要做模組化？ </h> <p>多人協同開發的同時能有一部分總體把控，但是每個人又可以獨立的處理自己部分的代碼，同時不會干擾到其他的成員的代碼，高度提升效率。 修改時只需要處理獨立的需要修改的模組，對其餘模組不會影響；出錯時定位到具體模組，直接對於這一塊進行版本回滾。 高度降低風險。 </p> </section> <section> <h>怎麼做模組化？ </h> <p>先按照主內容再細化內容兩種方式分離出區塊，由PM進行命名規則約定，分派至各人手中進行代碼編寫。 最後由PM進行代碼片段合併。 </p> </section> <section> <h>模組化需要注意什麼？ </h> <p>公共部分的代碼許可權需要回歸至PM手上管理；允許代碼階段性的臃腫，定期進行公共部分的版本整合。 </p> </section> </section></body></html> 將原有的<ul>或者<ol>濫用的導航清單功能表使用<nl>取而代之。 （這裡前提是清單都最好都有個說明的原則） <h5>導航功能表</h5><ul> <li><a href="index.html">首頁</a></li> <li> <h6><a href="#">音樂庫</a></h6> <ul> <li><a href="cn.html">華語</a>< /li> <li><a href="jk.html">日韓</a></li> <li><a href="eu.html">歐美</a> </li> </ul> </li> <li><a href="bbs.html">論壇</a></li></ul>和
<nl> <label>導航功能表</label> <li href="index.html">首頁</li> <nl> <label> 音樂庫</label> <li href="cn.html">華語</li> <li href="jk.html">日韓</li> <li href="eu.html ">歐美</li> </nl> <li href="bbs.html">論壇</li></nl> 還有上例當中的「無處不在的連結」。 （將多餘的不必要的標籤去除）當然，明眼人一看就能看出來是來自Nicholas Chase大師的《The Web’s future: XHTML 2.0》裡面談及的內容（針對最後一份，HTML5.0的草案有所更新）。 他的文章裡面有一一的解釋好處在於哪裡，我這裡就不做一一的解釋了。
OK，或者這個前期鋪墊過於太長了；我們速度回歸一下主題。 諸如上述我們提到的XHTML2.0的幾大優點均可以在新的HTML5.0的草案當中找到同樣的配同。 不過，Twinsen一直認為XHTML是HTML與XML的交集（當然也可以看作業界常說的是一個過渡產品）；XHTML應當是一種以內容以及資訊架構為核心的類資料庫框架（即XHTML可作為單純表現，而其修飾外觀在於CSS ；另一方面又可以像XML一樣作為資料被引用；）。 隨後在Jeremy Keith的《Misunderstanding Markup》、《標記語言之亂》（翻譯）一文當中我們可以看到了一個新的思路。 Jeremy用牛奶比喻HTML4.0，而用乳酪比喻XHTML1.0，再用豆奶比喻XHTML2.0；這裡Twinsen再放膽的將HTML5.0比喻成優酪乳。 這裡大家就可以想像， 乳酪和優酪乳是來自于牛奶提煉與乳酸菌發酵作用（XHTML1.0與HTML5.0來自于HTML4.0的提煉與發酵），而豆奶卻有本質上的差別（XHTML2.0從成分而言與三者都毫無關系），當然這裡不同味道的優酪乳也是加入了味料（canvas）等新的元 素；這樣就可以很清晰的將幾種語言標準作一個重新的梳理。 而Twinsen要強調Jeremy的文章當中也有提到的HTML與XHTML的區別：
所有標籤必須進行閉合（或自閉合）屬性必須使用引號括起來嚴禁標籤進行錯位嵌套標籤屬性統一採用小寫可能Jeremy走了一種比較委婉的技術引導方式；但也許他沒有來到中國，意識到中國網站重構的歷史以及發展。 中國有一句現代俗話：「一個中國人是一條龍，一群中國人是一條蟲。 」而這句從中國最有大志的魯迅先生開始，一直思維流傳至今。 我們可以回想撥號上網的年代，Twinsen從那時走過來；看到的是一堆混雜著CGI的HTML3.0，然後是混雜著Table和ASP或PHP的HTML4.0。 時代一直延續到了阿捷的出現，網站重構一書配同那個讓無數中國互聯網Boss都看過的PPT；這徹底顛覆了過往的思維，引導了一個新的潮流。 在他們的帶領下，人們以通過標準驗證為榮；每一個網站的下方都要出現「Valid XHTML 1.0 Strict」。 而這段標記的真正意義又是多少人能夠明白呢？ 如同佛洛伊德說的：「人們的戀母情結最後會演變成為一種偶像崇拜。 」。 也就等同于毛爺爺，還有後面的春哥的出現，阿捷成為了一代的偶像；但可悲的是阿捷激流勇退的走出了重構的世界。 在這個時候很多新進的重構工程師加入，他們開始質問；還有一部分老的重構工程師開始迷茫。 中國開始流傳了一個不要為了過標準驗證而做頁面的說法，接著就開始弄虛作假（標記錯亂照樣用XHTML1.0嚴格型的doctype）。 從偶像崇拜，演變為跟風，到後面的弄虛作假。 這當然存在它的歷史必然性和偶然性。
此時我們也不妨引用Twinsen的第一偶像的一些話來看看我們自身：
引用內容
茅于軾談中國房價
我們現在大家的議論就是房價高，這個也是事實，房價為什麼高？ 我覺得有它是需求拉動，不是成本推動；不是因為成本高。 什麼是需求拉動呢？ 就是很多人願意買，你價格貴他也買，這就是需求拉高。 大家知道經濟學裡頭，不問你買不買房，是問你嫌不嫌貴。 社會學用問卷的辦法，經濟學用市場的行為的考核，你儘管說貴你又掏錢買了，就說明你不嫌貴，你嫌貴就不買了。
大家可以算算，IE6多大，FF多大，CH多大，OP多大，SA多大...... ；全都清清楚楚地，根本不需要質疑。 我們天天的討厭IE6，但是我們還在做IE6的相容。 那是不是可以說明你根本沒有討厭IE6。 從技術思維，這是徹底矛盾的；因為這裡沒有宏觀調控，是需求拉動IE6的存活，而並非成本拉動IE6的存活。
引用內容
茅于軾談誰妨礙了我們致富？
——你跑步追上一輛公共汽車，可是剛要邁步上車時售票員把車門關上，按鈴啟動，揚長而去；
——你寫信時忘了寫上對方的郵遞區號，雖然你知道這個編碼；
——你不知道郵遞區號，因而沒有寫，結果信被郵局退了回來；
——馬路上有人吵架，大家駐足觀望，抱著無窮的興趣，必欲窮其所以才肯走；
——紅燈搶行，十字路口亂作一團，彼此擠得動彈不得；
——員警把亂設攤位的小販的貨物掀翻在地，甚至把小販的三輪板車扔上卡車拉走；
——開會時間某人未到，大家等上十幾分鐘。
......
這些現象是我們每天能見到的，已經司空見慣，誰也沒有想到它們之間有什麼關係。 但是從經濟學家的眼光看來，這些現象是不利於中國發展的重要原因。
從經濟學的基本觀點來分析，窮是因為許多生產潛力不能發揮，因為人們的勞動沒有用在生產上，甚至用在了抵消別人勞動成果的努力上；更因為各式各樣的浪費普遍存在，耗掉了社會巨大財富，可是每個人對此又無能為力。
還有另外的總結性的很經典的一段。
引用內容
茅于軾談誰妨礙了我們致富？
它並不屬於法律管轄的範圍，人們這樣做並不犯法，甚至也談不上是道德問題，可是大量這類事件的最終結果是不利於社會發展的。 這類事情的起因，責任在於我們每個老百姓，不論你是一名售貨員、司機、教師、電話接線員、政府辦事員，改變一下你辦事的原則都可能使社會 的財富有所增加，當每個人都這樣想時，國家就富起來了，你所支付的同樣的勞動就會得到更高的報酬。
你們這樣的做WEB，並不會出錯，甚至談不上讀取不了，但是大量這類事件的最終結果是瀏覽器就要為了你的標籤沒有封口，屬性沒有寫雙引號；而去編寫更加累贅的代碼，耗費更大量的CPU運算。 綜上三段引用所述，大家是否明白你所天天討厭的IE6為什麼會這麼大？ 為什麼會至今還存在？ 都是我們——這些網站重構人員一手一腳造成的！！
回過頭來看，文章的標題叫《走有中國特色的網站重構道路》。 RMB升值，中國的綜合國力提升，全世界都在往中國靠攏。 而HTML5.0的誕生，他又回歸到了HTML4.0擊敗HTML3.0的年代，一個新技術誕生的年代，一個宣揚自由應用的年代；在中國無數剛出道的「頁面仔」又會在這樣的年代興風作浪（200塊錢建站、 直接fireworks切圖生成頁面...... ）；而此時，我們一直崇拜的FF、CH、OP、SA...... 是否又要像IE6一樣走回老路子呢？ 然後我們是否也是要同樣的開始討厭和憎恨他們呢？ 而此過程我們作為一個綜合國力的強國是否在這個時候應當不再是「一條蟲」？
當然Twinsen不是單單的提出質疑和批判，更不是要反對HTML5.0；我們可以想一個較為合乎常理的解決方案：
自身使用XHTML的要求（前面說的4點）來編寫HTML5.0。 推薦瀏覽器使用雙解析內核，一個給標準頁面的，一個給非標準的。 （當非標準的頁面使用標準的doctype時，解析給他錯位或者直接關閉或不解析；同時這個也是我給chrome團隊的建議。 ）教導你身邊每一個人，維持標準的目的和重要性。 時刻銘記你不是一個「頁面仔」，是一個重構工程師；或者更進一層，你在影響人類資訊化社會的發展。也給大家帶來一個疑問，沒有經過「ISO9002」驗證的產品你敢用麼？ 那麼沒有經過「W3C」驗證的網頁呢？ 那驗證又是為了什麼呢？ （感謝一直以來教導我ISO9000體系重要性的卿姐）或者我們再設想一下你出差的時候，酒店的網線介面不是RJ45，然後你插不進去上不了網（每個瀏覽器都有對CSS3的私有屬性）；再或者酒店的網線介面是一排，分別對應RJ42、 RJ43、RJ44、RJ45、RJ46...... 從門口一直佈線到窗臺（瀏覽器為了相容多種雜亂頁面帶來的代碼臃腫）。
末了，我引用Jeremy文章的一些話：「只要你願意，HTML5.0馬上可以變成XHTML5.0」；「XHTML2.0翹辮子了，XHTML和HTML5才是王道。 」。
來源：HTTP://www.twinsenliang.net/skill/20100406.html
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
