非前端開發的HTML5觀點

也許你的記憶如我一樣，對於HTML，還停留在HTML4配合JavaScript程式庫的年代，而HTML5，不過就是曾在2010左右喧囂一時的話題。實際上，HTML5已在2014年10月28日，由全球資訊網協會（W3C）完成標準制定，目前主流瀏覽器也有高度支援，那麼，在標準完成制定的三年之後，這樣的你，該如何重新認識HTML5呢？

HTML4之後的演化

有日在圖書館不經意看到HTML5的書籍，大致是2011至2013年出版，以電腦書週期來看，都頗有年代，回想上次看HTML5的資料，已是2010年左右。

由於當時標準尚未底定，瀏覽器上實現的功能不算充足，想說API可能還會變動，就沒繼續玩下去，另一方面，前端開發也不是自身熟悉與熱衷的領域，僅保持著關注的狀況，話雖如此，就我既有的印象，在近期談及前端開發的相關資料或書籍，多半還是HTML4.01加上JavaScript程式庫的資料。

當然，瀏覽器支援度應是造成此印象的原因之一，只是不禁好奇起來，當年各界極力吹捧後，HTML5現況到底怎樣？經驗告訴我，身為前端的半調子，從歷史發展重新瞭解會是比較好的切入點，2011年出版的《HTML5 Guidelines for Web Developers》（中文翻譯《現在就開始學HTML5》）有不少資料可參考，基本上HTML5構想起源在2004年左右，當時HTML4的發展已擱置六年之久（而HTML2到4的發展大致是五年）。

在接下來的發展過程，由WHATWG主導且與瀏覽器廠商共同合作的HTML5，以及由W3C主導的XHTML 2.0小組曾經是競爭狀態，在缺乏瀏覽器廠商支持，且未考慮現存的Web內容相容性的情況下，導致了XHTML 2.0的失敗，在2007年W3C成立新的工作小組，並邀請WHATWG的成員參與，後續不斷磨合下，才於2009年公開宣布HTML5草案。

讓HTML5甚囂塵上的原因，也來自於HTML5與Flash的戰爭，代表之一，就是Apple教主Steve Jobs的〈Thoughts on Flash〉，而YouTube也從對HTML5的實驗之後，全面擁抱HTML5，就今日來看，Flash在網頁與影片的開發戰場上，確實是輸了這場戰爭，而曾經有一時，HTML5應用程式也不斷地被拿來與原生App做比較，許多的評論文件中，都畫著一個標準通吃手機、平板、桌機等裝置的大餅。

然而，這塊大餅始終沒有實現，Facebook創辦者Mark Zuckerberg也曾2012年公開表示，以HTML5撰寫Facebook App，是他們犯過最大的策略錯誤，姑且不論這談話後續有些爭議性，這表示HTML5提供的API極為豐富，像是Geolocation、Local Storage、Drag and Drop、Application Cache、Web Workers、Server-Sent Event等（儘管有些後來是獨立於HTML5外的標準了），都是自前端應用程式盛行以來，開發者一直想要的功能特性。

在建立HTML5標準時，一個重大考量就是，新特性須基於既有的HTML、CSS、DOM及JavaScript，與其說是基於技術層面，不如說是基於長久以來的前端開發實作需求。在選擇或觀看HTML5的相關資料時，若是從技術層面著手，很容易因為大量的標籤、API，而落入五里霧之中；若能先思考現有基於HTML4、JavaScript下開發程式時，是怎麼實現相關功能，而在HTML5中會有哪些對應方案，將會有助於掌握相關元素，並暫時忽略那些不重要的細節。

以HTML5新的語意、結構元素來說好了，在這之前總是使用div結合id或class來實現，然而，div實際上是用來管理一組子元素，id與class屬性的特性值名稱可能代表各種需求，像是結構或者是樣式，因此搜尋引擎或者是開發者彼此之間，可能難以理解或誤解其中名稱之意義；Google曾於2005年的〈Web Authoring Statistics〉研究中指出，id與class的名稱會主導網頁結構，基於類似理由，那些經常使用的特性值，後來就成了HTML5的語意、結構元素。

認識這些元素的起點，其實在於須審視自己曾撰寫的頁面，有著何種結構或語意。若發現<div id="header">，可用<header>取代，<div id="menu">也許就是<nav>，<div id="footer">可考量用<footer>，轉換方式並沒有一定，重點是如何運用這些元素，讓搜尋引擎或開發者彼此理解這個頁面。

觸發這類思考的有趣主題是，想想看<section>與<article>的不同？在HTML5中，<section>中可以是一組相關元素，而<article>是用來含括一組完整、自備的相關元素，有確實定義可指出<section>與<article>到底誰才能包含誰嗎？沒有！實際上，<section>可包含<article>，而<article>也可包含<section>，像是〈HTML5 Semantic Elements〉（https://goo.gl/MXZ4xz），就有個例子：「在體育section的體育article裏，可以有科技的section」。

有了統一名稱，搜尋引擎或開發者會比較容易識別出網頁中的元素，各是代表什麼，那麼，該將<div class="xxx">之類的，都改成<section>或<article>嗎？不是！在〈HTML5 Migration〉（https://goo.gl/Axij2i）就有幾個例子，同時運用<div>、<section>與<article>，當然那只是範例，你的頁面不一定要這麼使用，先想清楚自己頁面想傳達什麼，才是重點。

讓瀏覽器做該做的事

如果想在頁面上實作郵件驗證、進度列、拉桿，或者是有個日期選擇器，在HTML4的基礎上，基本上，需要撰寫JavaScript操作DOM、CSS等來達成，當然，現今有不少JavaScript程式庫都提供便於使用的實作，只是HTML5認為，畢竟從1999年發展到現在了，網頁應用程式幾乎都需要這些功能，那麼，就該由瀏覽器本身提供，而非把責任丟給開發者。

因此，HTML5中就有了新的input類型，像是email、url、number、range等，想要有個日期選擇器，也只需要在input的type指定date、month等特性值，如果想要自定驗證規則，也可以在pattern上定義Regular expression，其他如必填欄位等需求，過去必須自行撰寫程式才能擁有，現在，都只需要定義相關的HTML元素就可以了。

播放影片、音訊用的<video>、<video>，當然也要可以透過JavaScript來控制，API也是在提及HTML5時必然要涉及的課題。HTML5考量了過去前端開發的需求，提供了一些API，讓開發者在實作相關功能時，更為輕鬆。以元素的拖放為例，在過去若不依賴jQuery UI draggable()之類的程式庫，想要自行實作的話，絕對不是件簡單的事情，而HTML5本身就提供了Drag and Drop API來實現拖放的需求。

HTML5也提供Canvas API來解決繪圖需求，這是當年我接觸HTML5時唯一認真玩弄過的API，我還曾經將自己網站上〈電腦圖學入門〉中古老的Applet繪圖與動畫，重新使用Canvas API實現；其他如localStorage、sessionStorage，解決客戶端儲存資料的需求，Server-Sent Event可在一個連線中持續獲取伺服端更新等。若開發者撰寫過類似功能，看到這些現在都由瀏覽器處理時，都會覺得十分驚奇。

針對需求去瞭解HTML5

對我來說，HTML5是涵蓋極廣的規格，想要全面瞭解，就像試圖嘗握整個Java EE。想到過去拿起HTML5的書籍閱讀，不到三分之一就令我昏昏欲睡，應是這個原因，相關書籍總是試圖寫入HTML5的種種技術細節（多半還包括Geolocation、Web Workers、Web Sockets等獨立於HTML5之外的API），而少於說明這些技術的由來與思考重點。

我想，前端開發的發展至今，開發者也有著各自不同的角色吧！全面掌握HTML5，應該沒必要（更何況，還是有些瀏覽器支援度問題需要考量），如果想要大致瞭解HTML5的功能輪廓，〈HTML 5 教程〉（https://goo.gl/VxpfmV）與〈HTML5 Introduction〉（https://goo.gl/nZ3Z6w）應該就足夠了，接下來，需要的是依自身需求，針對專門主題去認識與瞭解，決定該使用HTML5，還是以傳統的HTML結合JavaScript程式庫！