也許你的記憶如我一樣,對於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程式庫!

作者簡介


Advertisement

更多 iThome相關內容