首先，一些事實。
很久很久以前，世上有一門叫做HTML的可愛語言，這門語言簡單易學，用它寫網站真是輕而易舉。因而，所有人都用這門語言，從此，Web也從一堆物理論文的鏈接變成了今天我們所熟知和喜愛的模樣。大多數頁面並不遵循這門語言的簡單規則（因為寫這些網頁的人對內容本身要比媒介形式更為關心），因此所有瀏覽器都必須忽略錯的代碼，盡最大努力猜測作者到底是想怎樣展示內容。
1999年，W3C決定終止HTML的制定工作，轉而制定XHTML。一切都很完美，直到少數人注意到從XHTML升級到XHML2的升級工作幾乎脫離實 際。XML的標準要求瀏覽器一旦碰到錯誤，就停止工作。另外因為W3C正在起草一種比老式、簡陋的HMTL更出色的語言，它不讚成（deprecate） 使用img和a標籤這類元素。
Opera和Mozilla開發人員不認同這種做法，並於2004年給W3C提交了一份報告，該報告稱：“我們認為網頁應用（Web Applications）是一個極為重要的領域，但當前技術並未為這一領域提供充分的支持。在多方制定的規範出來之前，單一廠商的解決方案存在的潛在風險在不斷增大。”（譯註：暗指Adobe的Flash技術？）
這份報告提了7條設計原則
- 向後兼容，並有一個清晰的遷移路線（migration path）
- 明晰（Well-defined）的錯誤處理機制，類似CSS（比如，忽略未知內容，繼續執行），相比之下XML錯誤處理機制過於“苛刻”。
- 編程錯誤不應直接暴露給終端用戶。
- 實用性:所有最終進入網頁應用技術規範的性特性都必須實際的應用案例支撐。但反之則不成立：即所有類似的應用案例並不必然會新特性加入到技術規範中。
- 腳本支持已經已得到公認（但是當有更方便的標籤可滿足需求時，應避免使用腳本。）（譯者：類似表單輸入數據驗證。）
- 避免針對特定設備的規範。
- 制定過程必須開放。（網絡本身從開放式發展中受益頗多。郵件列表，存檔，規範草稿應一直對公眾開放。）
在2006年，W3C終於意識到自己的錯誤，決定重新啟用HTML，向WHATWG所要它的規範，並將其作為HTML5規範的基礎
上面這些是史事資料。現在我們來看看一些流傳甚廣的流言。
流言
“在2012（或2022）年之前，俺是用不上HTML5的了。”
這一流言是從HTML5進入到W3C流程的候選推薦階段（Candidate Recommendation，簡稱REC）的項目日期所誤傳開來的。官方Wiki上寫道：如今一個規範要成為候選推薦標準（REC），它需要具備百分之百的可實施性（interoperable implementations），只有成功通過上萬項的測試案例（Test Case）後才能驗證這點（據保守估計，整個規範可能需要進行2萬項測試）。當你在心裡默算寫這些測試案例需要多少時間，實施每個新特性又需要多少時間 時，你就會明白HTML5規範制定的時間跨度為什麼這麼長了。因此，按此說法，在你能在兩大瀏覽器中用上所有的功能之前，HTML5的規範是沒有最終定稿的。
當然，真正重要的一小部分HTML5的特性已得到瀏覽器的支持，任何瀏覽器的支持情況彙總表單都會在一週之內過時，因為瀏覽器製作廠商的創新速度非常之快。另外，許多HTML5的新特性也通過JavaScript腳本在不支持HTML5的老瀏覽器中得以重現。Canvas屬性在所有新瀏覽器中得到支持，其中包括IE9，另外在老的IE瀏覽器中，通過excanvas庫，我們也可以模擬Canvas的特性。而音頻和視頻標籤效果，我們則可以通過Flash在舊的瀏覽器中實現。
HTML5在設計上就可以優雅降級，因此運用一些JavaScript代碼和創意，HTML5的所有功能都可以在老瀏覽器上實現。
“俺的瀏覽器支持HTML5，你的不支持。”
這一流言認定HTML5是一個整體不可分割的標準。但實際上不是。正如前文所說，HTML5是一組新特性的組合。因此，短期來講，你不能說一個瀏覽器支持 了HTML5的所有內容。而當瀏覽器能做到這點時，瀏覽器本身已經無關緊要了，因為那時我們將被新一代的HTML語言所震撼。感覺HTML5亂的一塌糊塗，是吧？看看CSS2.1，這麼多年了它都是一個尚未最終完成的標準，但是我們每個人無時不在用它。我們用CSS3輕鬆添加圓角，這點很快就會得到所有瀏覽器的支持，雖然CSS3的其他特性尚未得到所有瀏覽器的支持。
要提防那些瀏覽器“評分”網站。這些網站測試的內容經常與HTML5無關，比如CSS，SVG，甚至是網頁字體（web fonts）。你手頭需要完成的工作才是要緊的，你客戶受眾瀏覽器所支持的技術才是用得上的技術。
HTML5實際上正式認可了一些常見的書寫錯誤（Tag Soup）
HTML5在語法方面要比XHTML鬆散很多：比如，你可以用純大寫或小寫字母書寫標籤，甚至大小寫混用也無妨。你無需對img這類的標籤做自封閉處理（self-close），因此下面這兩種寫法都是合法的：1 <img src=”nice.jpg” />
2 <img src=”nice.jpg”>
標籤屬性也無需用雙引號括起來，因此下面這兩種寫法都是合法的：
1 <img src=”nice.jpg”>
2 <img src=nice.jpg>
使用大寫或小寫（甚至混用）字母都可以，所以下面三種寫法也都是合法的:
1 <IMG SRC=nice.jpg>
2 <img src=nice.jpg>
3 <iMg SrC=nice.jpg>
這與HTML4毫無差異，但是如果你用習慣了XHTML，你碰到這種寫法時還是會很震驚的。現實中，如果你使用HTML和文本內容書寫頁面，而非使用 XML（你極有可能是混用文本和HTML書寫頁面的，因為IE8並不能真正的渲染XHTML頁面），那麼上述細微差別也無關緊要：瀏覽器會忽略尾部的斜 槓，雙引號，以及大小寫。
HTML5語法看似松散，但實際的解析規則要嚴格的多。因而HTML5中，常見的書寫錯誤（Tag Soul）將不復存在;HTML5的規範對這些無效標記做精確的描述和定義，因此所有遵循規範的瀏覽器都會生成同樣的文檔對象模型（DOM）。如果你曾寫過JavaScript來遍歷DOM，那麼你就會對DOM不一致所帶的恐怖經歷有所體會。
但這種修正不應導致無效代碼氾濫。HTML5為你創建的DOM可能並不是你想要的那個，因此對書寫的HTML5代碼進行驗證仍然至關重要。隨著新特性的大量湧入，對細小語法錯誤的忽視會讓你的腳本失效，或是CSS樣式出錯，這也是我們為什麼需要HTML5驗證器的原因之所在。
HTML5遠不僅僅只是讓一些常見的書寫錯誤合法化，而且讓這些常見錯誤（Tag soup）成為歷史。贊。
“我需要把我的網站從XHTML轉換HTML5。”
HTML5對鬆散語法的包容性時候敲響的了XHTML的喪鐘嗎？制定XHTML2規範的工作組已經解散，對吧。沒錯，XHTML2的工作組在2009年年末的時候解了。他們起草的這個規範是用來與HTML5競爭的，但尚未得到執行實施，然而，同時保留兩隊人馬是對 W3C組織資源的一種浪費。另外XHTML1已經是一個業已完成的規範，得到所有瀏覽器的廣泛支持，並在必須的時限內仍將得到所有瀏覽器的支持。因此你用 XHTML書寫的網站也將免受折騰之苦。
HTML5將會幹掉XML
根本不會，如果你需要使用XML而是HTML，你可以選用XHTML5，它幾乎包含所有HTML5的優點，只是要必須遵循嚴格XHTML語法（比如，要標籤屬性中的雙引號不能省，自封閉元素的末尾斜槓不可勝，必須用小寫字母書寫標籤等等諸如此類。）現實情況是XHTML5並不完全包含所有HTML5的特性。譬如 <noscript> 就失效了。但你想想，這古董玩意兒還有人在用嗎？
HTML5會幹掉Flash和插件
<canvas> 標籤可以讓腳本根據鍵盤輸入操縱圖像實現動畫效果，因此在一些簡單的應用場景下可以與Adoble Flash競爭。HTML5還有對Video和Audio播放的原生支持。正因為CSS Web字體尚未得到廣泛支持，以Flash為基礎的sIFR技 術將會填補這一空白，Flash也因逆向兼容HTML5視頻內容而挽救局面。因為HTML5設計時“照顧”了老瀏覽器，Video標籤之間的其他標記將會 被支持HTML5的瀏覽器所忽視，因此用老式的<object>或<embed> 標籤可以用Flash嵌入所有瀏覽器支持的視頻內容，克羅克·卡門（ Kroc Camen）在他的《全兼容的視頻》一文中就倡導這種做法。（見下面截圖。）
但也並是不所的應用場合都是可以用HTML5取代Flash的。比如HTML5中就沒辦法進行數字版權的管理。Opera，Firefox和Chrome 這類瀏覽器允許簡單的右鍵點幾下就將視頻保存的本地電腦上。如果你不想用戶保存視頻文件，你就需要使用插件。另外捕捉麥克風或是攝像頭的信號就只能通過 Flash實現。（不過<device> 元素已經出現到HTML5以後的規範中），因此如果你想寫一個可以終結聊天輪盤（Chatroulette）網站的東西來，那麼HTML5並不適合你。
HTML5在可訪問性（Accessibility）方面做得比較差
關於HTML5的討論中有不少是嘮叨HTML5可訪問性的。這點很好，應該歡迎：因為網絡的基礎語言已經做了太多了的改變，因此確保網頁對於那些殘障人士 的易訪問性極其重要。另外，更為重要的是在技術方案的制定過程中就將其考量進入，而非時候修補。畢竟大多數開發人員甚至沒為圖片標籤添加Alt屬性，所以 提供現成可用的易訪問性（accessibility）相比人們手動添加更為易成功。這也是為什麼HTML5添加了類似滑塊（<input type=range>，目前僅Opera和Wbkit內核的瀏覽器支持）原生控件和日期選定控件（<input type=date>，僅Opera支持）——因為之前，我們只能用JavaScript和圖片來模擬，並添加鍵盤支持和WAI-ARIA的Role屬性。
而Canvas標籤則又是另一番情況，該標籤原本是蘋果獨創的，後遭其他瀏覽器廠商的逆向工程破解，繼而被吸納為HTML5規範的一部分，因此 Canvas技術本身在可訪問性方面並未做考量。如果你只是用它製作一些視覺美化，那問題不大，你大可把它看成圖片，，只是不能添加ALt屬性來指定替換 的文本內容（已有人建議在規範中作此增添，但目前尚未得到實施）。因此，確保Canvas著中的信息在頁面的其他地方有替代信息，從而增強頁面的可訪問 性。
Canvas中的文本變成了像素，如圖片中的文本。因此，輔助技術和屏幕閱讀器來可以讀出其中的信息。可考慮用W3C的可縮放適量圖像標準（SVG）替 代，尤其對於動態圖像和文本內容來說。SVG目前得到了主流瀏覽器的支持，其中包括IE9（IE8以及一下的瀏覽器不支持，不過SVGWeb庫通過 Flash技術可以在老式瀏覽器中模仿SVG。）
<video> 和 <audio>標籤也很有前途。儘管這兩個標籤的規範尚未完全確定（而且許多瀏覽器還不支持）。HTML5已經添加了一個新 的<track> 的標籤，可以包含帶時間軸的文本（歌詞和外文媒體的字幕），你可以之間在視頻下面用JavaScript來添加時間軸字幕，並與視頻內容同步。
“當我第一次用HTML5的時候，HTML5的大師會助我一臂之力”
如果是真的那該多好。不過保羅·艾瑞士（Paul Irish）和迪維亞·梅麗亞（ Divya Manian）打造的HTML5模板文件對 你來說就足以很好。模板文件包含一系列的文件，你可以做模板用在你的項目中。模板文件包含了你所必須的JavaScript，方便在IE中添加新元素；它 從Google的CDN上引用jQuery，另外如果Google服務器出問題了，還可降級引用你自己服務器上的JS庫。
它也添加了適用iOS，Android和Opera手機版的標籤，並用一個易於理解的CSS reset文件搭建了一個基本的CSS骨架。它甚至還一個.htaccess文件，以便為HTML5視頻提供正確的MIME類型。如果你不需要全部的內 容，你可刪除對你項目無用的內容，精簡文件。
深入閱讀材料
HTML5的話題很寬泛。下面是是我們手工挑選的幾個鏈接。披露提醒（Disclosure）：本文的作者參與了下面的一些項目。
沒有留言:
張貼留言