因為用戶體驗對於 網頁設計 、SEO都是很重要的事，所以，每個人都在談論HTML 5，畢竟這可能是 網站設計 的趨勢甚至主流。自眾人開始濫用圓角和漸變效果以來，HTML5或許是最熱炒的技術。然而，許多人眼中所謂的HTML5實際上只是老式的DHTML和 Ajax。有關HTML5的諸多資訊中魚目混珠，因此,JavaScript專家Remy Sharp和Opera公司的Bruce Lawson著眼這些流言，對其中的常見謬誤和事實做了分類整理。
首先，一些事實。
很久很久以前，世上有一門叫做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錯誤處理機制過於“苛刻”。
◆ 程式設計 錯誤不應直接暴露給終端使用者。
◆ 實用性:所有最終進入網頁應用技術規範的性特性都必須實際的應用案例支撐。但反之則不成立：即所有類似的應用案例並不必然會新特性加入到技術規範中。
◆ 腳本支持已經已得到公認(但是當有更方便的標籤可滿足需求時，應避免使用腳本。)(譯者：類似表單輸入資料驗證。)
◆ 避免針對特定設備的規範。
◆ 制定過程必須開放。(網路本身從開放式發展中受益頗多。郵寄清單，存檔，規範草稿應一直對公眾開放。)
該 報告遭W3C的拒絕，因此Opera和Mozilla以及後來的蘋果繼續維護著一個叫做網路超文字應用程式技術工作組(Web Hypertext Application Technology Working Group，簡稱WHATWG)的郵寄清單(Mail list)，繼續制定他們用以驗證概念( proof-of-concept)的規範內容。這份規範對HTML4表單規範進行了擴充，在Ian Hickson的不斷校訂中，這份規範最終成為一份名叫網頁應用程式1.0(Web Applications 1.0)的規範。後來伊恩 •希克森離開Opera，加入Google。
在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)成為歷史。
參考文獻：
1. 黃映瑀（2005）。體驗行銷、體驗價值、顧客滿意、品牌形象與行為意向關係之研究。大葉大學事業經營研究所碩士論文，未出版。
2.黃中杰，2002，JAVA 與XML 技術手冊，台北：碁峰資訊股份有限公司。
3.楊宗誌，2002，JBuildert 程式設計實務，台北：文魁資訊股份有限公司。
資料來源：SeoHouse
留言列表
