【51CTO觀察】你對一門Web前端技術抱有怎樣的期待？
除了簡單易用，它還要完美支持媒體元素、可以實現網頁的3D化效果、可以操作本地文件、具有足夠的安全性、能做一些數據存儲工作，另外，如果能從底層改變當前Web的通信機制就更好了。
注意，這裡提到的是“一門”技術，而不是很多種技術的綜合，不是JavaScript、不是RIA、不是某種網絡協議。這是目前我們所能看到的還處於草案階段的Html 5。
作為最基礎的Web技術，HTML語言已經10年沒有過大范圍的改變，這十年間互聯網從技術到應用都已滄海桑田；與紛繁的服務器端技術的進化相比，人們甚至已經淡忘Html還需要升級，還可以增添更多的屬性和功能。
Html版本歷史
◆超文本標記語言（第一版）——在1993年6月由互聯網工程工作小組（IETF）工作草案發布（並非標准）
◆Html 2.0——1995年11月作為RFC 1866發布，在RFC 2854於2000年6月發布之後被宣布已經過時
◆Html 3.2——1996年1月14日，W3C推薦標准
◆Html 4.0——1997年12月18日，W3C推薦標准
◆Html 4.01（微小改進）——1999年12月24日，W3C推薦標准
◆ISO HTML（“ISO/IEC 15445:2000”）——2000年5月15日發布，基於嚴格的Html 4.01語法，是國際標准化組織和國際電工委員會的標准
51CTO第一次關注Html 5標准是在2008年的一篇文章《Html 5正式標准恐2022年才能正式發布》。這篇報道中，HTML 5標准的編著者Ian Hickson為HTML 5的推出列出了一個時間表。他假定各個浏覽器開發商會在HTML 5處於最後起草階段時開始全面支持HTML 5，而這就將Html5的廣泛應用推後到了2012年。更糟糕的是，最終的推薦性正式標准直到2022才會發布。
當時，這篇報道並沒有引起人們太多的注意；關於HTML 5，國內媒體也沒有太多關注。但51CTO認為，作為一項重要的基礎性技術標准，Html 5有必要被我們關注和熟知，隨後我們陸續推出了
◆Html 5指引下一代網絡應用開發標准
◆Html 5標准緣何如此重要？從浏覽器與Google談起
◆從零開始構建Html 5 Web頁面
等介紹Html 5的技術概覽和入門文章。隨後，這個未來的web開發標准開始漸漸被人們注意，並在Youtube正式開放Html 5視頻功能、iPad不支持Flash等消息被廣泛傳播後開始迅速升溫。
Html 5 vs Flash
有時，媒體的放大器作用也需要時機。iPad不支持Flash（蘋果官方的說法是資源占用和耗電量等原因），引發了一場Html 5與Flash的技術論戰。一時間，不明就裡的媒體開始瘋炒Html 5來臨 Flash死亡倒計時 。人們將視線聚焦在Html 5的視頻功能上，並開始與其他RIA技術相提並論，比如：
◆Html 5會為Flash和Silverlight送終嗎？
◆Html 5真的能戰勝Flash和Silverlight？
◆Html 5怎麼就成了RIA“殺手”？
這些文章用疑問句和危機感引起了多數讀者的注意，Adobe CEO甚至親自站出來反駁。事實上，HTML 5與Flash等RIA技術並不是一個層面的技術。雖然在相同的應用需求下（Web視頻方面），Html 5可以用自身的標簽（主要是和）代替Flash的部分功能，但也僅僅是“代替”和“部分”而已。
以Flash在這個領域多年積累的優勢，幾年內少有技術能夠撼動；何況2022年才發布的HTML 5標准給Adobe留下了足夠的時間拉開距離。更重要的是，Html 5是Web前端的實現技術，它更專注與內容的格式與輸出；而Adobe的Flash卻有一套完整的RIA技術解決方案。
另外，看看《Html 5視頻音頻元素全解析》一文我們就會知道，作為一門標記型語言，HTML 5在實現Web視頻方面稍顯無力，Flash開發者無法再使用他們熟悉的ActionScript腳本來控制頁面的交互邏輯和功能。習慣於DIV+CSS的前端工程師們也未必接受Html變的更復雜。
HTML 5與Flash的可笑對決因為媒體的放大而被大家熟知並談論；某種程度上，這成為樹立HTML 5彪悍形象的強大推力，Html 5正在被神化，我們似乎忘記了，它只是一門標記語言，只是鋪在浏覽器裡等待被解析的一堆尖括號。
對Web視頻的支持只是Html 5眾多“神奇”功能中的一個，它還有更神奇的地方。
法力無窮的Html 5
Html 5 File API，有關文檔操作的API，改善基於浏覽器的Web應用程序處理文件上傳的方式，使文件直接拖放上傳成為可能。目前，草案定義了新的輸入選項 ﹤input type=”file”﹥ 來處理文件上傳。
安全沙箱機制，針對iframe元素增加sandbox屬性，可以防止不信任的Web頁面執行某些操作。可以有效防止訪問父頁面的DOM、讀寫CookIE、本地存儲或本地SQL數據庫等。
Html 5 Web SQL Database，使用本地和會話存儲實現簡單的對象持久化，對簡單的關鍵值對（比如應用程序設置）或簡單對象（如應用程序狀態）進行存儲，使用本地和會話存儲能夠很好地完成。
Html5 3D技術標准，內建3D技術的支持，無需插件即可將網頁3D化；不僅可以簡化開啟顯卡3D網頁硬加速功能的操作步驟，而且還規定了一套適合網頁使用的3D圖形接口界面，支持腳本化運行。
改變Web通信機制！定義在Html 5規范的通信章節Html 5 Web Socket可以通過一個單一的Socket實現一個全雙工，雙向通信的信道。Html 5 Web Socket提供的標准可以使用它構建可擴展的實時Web應用程序。
以上所提到的功能特性存在於目前的Html 5草案中，我們可以想象正式標准公布之時會有怎樣一串長長的特性列表。而在正式標准公布之前，關於未來web開發標准的神化運動會一直進行下去。
本來這篇文章寫到這裡就可以收尾，但想起了一位51CTO網友對HTML Web Socket一文的評論，也許可以從一個側面反映出人們對Html 5的無奈、憤怒和期待：“真正應該關心的技術，是屏蔽各代技術之間差異的庫或者框架，比如Flash，sliverlight，Java applet，甚至各種JS庫”，該評論的完全版請點這裡。
新特性“威武”
這是個新功能新特性“論斤稱”的時代。我們經常看到某種技術（或軟件）在更新版本時都會附上一堆強悍的功能列表；並在大家爭相傳頌之後，被視為神跡。而之前的Bug修正列表在近幾年很少被提及。技術造神論在廠商和媒體的不斷炒作中漸漸神化得無比強大，哪怕它現在只是個草案或者概念。但當這些技術真正來到我們面前時，我們卻只能以一種仰視的角度無奈的看待它們。
這其中所隱含的是技術更新與實際需求的不對稱；廠商的技術競爭策略與真實應用開發環境的不對稱。技術的演進不在我們觸手可及的地方，你需要在一堆新概念新噱頭中學會疲憊的跳躍。
這其中的關鍵是開發者應用需求與廠商商業策略的背離：我們和技術廠商都期望的太多，卻很少重合。
我們對一門新技術抱有怎樣的期待？以下是51CTO的觀點，不足之處請留言補充。
新技術應該在現有技術的基礎上對不足之處提供足夠的調整和優化；這需要對開發者和社區有足夠的敬意和耐心。
新技術應該專注當前的應用場景（范圍），而不是太過“貪婪”於其他熱門領域，不然很容易“跑偏”；
新技術的目標應該是所謂的“裡程碑”版本，它為開發者或使用者提供足夠的理由轉換到新版本，並維持這個版本足夠長的時間，不會因更新過快導致兼容性和學習成本過高的問題。