結構化，樣式脫離的 HTML 文檔，極大提高了文檔的表達力，不管是機器還是人類都能更快的理解文檔的結構，這種文檔就被稱為語義化文檔。

語義化主要體現在以下幾個方面：

寫過 HTML5 的都知道大概有哪些標簽新加了進來，這里大致羅列一下

可能有些朋友會納悶，這些東西其實吧，也不是那么的重要，用 div + css 也都能實現，而且各個瀏覽器上表現的還都一致，還不用考慮兼容問題。那么為什么這里還提呢？

試想一個問題？

如果你是瀏覽器，或者說是解析 HTML5 文本內容的程序，你會怎么看待 HTML4 與 HTML5 ？

首先第一個需要解決的問題：顯示頁面，兩者都能解析，生成樹狀結構，并成功的顯示頁面，這也是大部分用戶所需要的。在這方面兩者平局，HTML5 沒有任何的優勢。

那么現在第二個問題，識別該文檔，這或許不是大部分用戶的需求，但小部分用戶并不意味著人數少。

相信大部分朋友都有使用搜索引擎的習慣，那么搜索引擎是如何幫你找到這個網頁的呢？

搜索引擎通過適當的策略解析通過爬蟲抓取到的網頁內容，將該文章進行分類，通過用戶給的搜索詞進行匹配，最終將結果呈現給用戶，爬蟲的解析策略，面對 HTML4 時，需要識別出特定的 div 而這個特定的 div 該如何去找呢？經驗？特定字符串？面對 HTML4 ，只能得到一個個的 div 而哪個 div ，emmm... 不好找。面對 HTML5 呢？程序從結構就能大致理解文檔的結構，進而識別出該篇文章的大體內容。

問題二可以簡單認為：我們需要生成文章大綱，一篇文章可以有幾部分的內容組成，而規范這些內容的就是大綱，相信有寫過文章的都知道大綱的作用，可以清醒的表達出內容，那么 HTML4 呢，一堆 div 分不清哪個是主體，哪個是次要內容，但 HTML5 呢，結構清晰，解析程序也能很快的生成文檔的大綱。

大綱只能用在搜索引擎嗎？并不是，閱讀設備就很需要大綱生成目錄，無障礙設備可以識別到文檔的主體內容等等。

看到這里，相信大家對于語義化標簽的重要性也有了了解，使用成本幾乎為 0，但文檔的清晰程度卻上了一個層級，干嘛不用呢？

表單類型（type）代表了改表單內容的類型，新增了以下幾個

tel

search

url

email

date

time

number

range

color

以上為 HTML5 語義化的具體呈現，希望大家擁抱并使用 HTML5 的新標簽。

HTML5 的上一代標準 HTML4 于 1999 年發布，當時互聯網還處于圖文混排的時代，通訊也不是很發達，數據的交互受限于網速，但是近 20 年來數據通訊的高速發展圖文混排已經不能滿足用戶的需求了，由于瀏覽器并不支持視頻促成了 Flash/ActionScript 的發展，但是由于 Flash 的繁瑣（需要裝插件）以及安全問題，Apple 拒絕使用 Flash，之后各大瀏覽器廠商也開始重視 Flash 的安全問題，提出了多媒體標簽，直到 HTML5 規范化了多媒體應用。

相關多媒體標簽

Audio

Video

建議查看英文的相關文檔，中文的翻譯文檔好像還沒有及時跟進。

除了多媒體標簽的更新，這里同時還列舉下一些與顯示相關的內容：

Canvas

畫布，可以使用 JavaScript 在改元素規定的區域內進行繪畫，文檔說明。

WebGL

光柵化的圖片繪畫引擎，主要用于 3D 制作，文檔說明，以及WebGL 理論基礎

Camera API

通過Camera API，你可以使用手機的攝像頭拍照，然后把拍到的照片發送給當前網頁。

SVG

現在可以直接在 HTML5 文檔中寫 SVG（可縮放矢量圖形），一種用于描述基于二維的矢量圖形的，基于 XML 的標記語言。文檔說明。

MathML

MathML（Mathematical Markup Language），是一種基于 XML 的標記語言，用以描述數學公式，但目前瀏覽器的支持力度有點低。具體可以查看文檔說明

HTML5 之前，JavaScript 只能通過 XMLHttpRequest 與后端程序進行交互，隨著 HTML5 標準的提出，前端可以使用各種各樣的姿勢與后端進行溝通，數據的交互變的簡單，靈活。

XMLHttpRequest，雖然在實際開發中幾乎很難使用到它，但是對于它的封裝庫我們卻經常使用，比如 axios $.ajax 。雖然說封裝的庫降低使用成本，但源頭是復雜的，而且 XMLHttpRequest 是基于回調的異步模式，雖然 axios 進行了 Promise 化，但畢竟不是原生支持。因此一個基于 Promise 的請求 API 于 HTML5 標準內提出：fetch。

一個簡單的 fetch 例子

fetch("http://example.com/movies.json")
  .then(function(response) {
    return response.json();
  })
  .then(function(myJson) {
    console.log(myJson);
  });

fetch 支持兩個參數，

資源地址

請求參數，用于設置請求方式，請求頭，請求體等內容，一個 JavaScript 對象。

學習資源：

MDN 使用 Fetch

WHATWG Fetch

在 HTML5 出現之前，做一個實時聊天的 web 項目是極其困難的，由于之前的版本僅支持瀏覽器主動向服務器進行發送內容，必須先有請求才能有服務器響應的數據，簡單的來說服務器并不能主動將數據提交給客戶端。

面對這些需求，大家的做法通常是輪詢，通過前端設置一個定時器，每隔固定的時間去請求服務器資源，即使服務器并沒有發生數據更新。這浪費了極大的服務器資源，那么有沒有一種方式支持服務器推送呢？

有！WebSocket 是 HTML5 新增的一種協議，目的是在瀏覽器和服務器之間建立一個雙向數據通道，瀏覽器可以推送數據到服務端，服務端也可以推送數據到客戶端。WebSocket 對于前端來說僅是一個簡單的 API，最重要的是服務端的支持。

WebSocket 的客戶端代碼示例

// 創建鏈接
const socket = new WebSocket("ws://localhost:8080");

// 鏈接開啟事件
socket.addEventListener("open", function (event) {
    // 向服務端推送數據
    socket.send("Hello Server!");
});

// 服務端推送事件，event.data 即為服務端推送的數據
socket.addEventListener("message", function (event) {
    console.log("Message from server ", event.data);
});

至于服務端如何實現，不同的語言有不同的實現，比較出名的是 Node 下的 Socket.IO，如果擔心服務端語言實現困難，不妨用 Node 搭建中間層，使用 Node 進行與客戶端的溝通，并將數據交由服務端程序處理。當然也可以查看 MDN 的文章：編寫 WebSocket 服務器

一些資源

WHATWG Web sockets

websocket.org HTML5 WebSocket

MDN WebSockets

fetch 實現了請求的 Promise 化，WebSocket 實現了雙工通信，那么 EventSource 又是什么？

簡單的來說，EventSource 實現了服務端對客戶端的單向通信，可以理解為客戶端是訂閱者，服務端是內容發布者，也就是發布訂閱模式的實現。

一個簡單的例子

// 開始訂閱
var evtSource = new EventSource("sse.php");
var eventList = document.querySelector("ul");

// 服務端發布數據回調
evtSource.onmessage = function(event) {
    // event.data 即為服務端發布的數據
    console.log("Message from server ", event.data);
}

同樣的前端代碼很簡單，服務端需要實現該通信方式需要有一定的成本。具體可以查看一下文檔

WHATWG EventSource

MDN EventSource

see.php 編寫

WebRTC（網頁即時通信），是一個支持網頁瀏覽器進行實時語音對話或視頻對話的 API。由于該 API 目前并未納入標準中，這里就不過多的深入了，可以通過以下文檔進行了解：

MDN WebRTC API

W3C WebRTC 1.0

在 HTML5 出現之前，前端開發者僅能通過 cookie 來存儲用戶在不同頁面之間跳轉的數據，但使用 cookie 來存儲數據其意義上是不對的，不能說 cookie 可以在同域名下通用，就讓它來攜帶各種各樣的數據，cookie 應該是用來標志用戶身份的。HTML5 出現之后，規范了數據的存儲，cookie 也回到了原始的用途。

相信大家對于該 API 已經熟悉的不能在熟悉了，storage 分為兩部分，sessionStorage 與 localStorage，擁有同樣的方法：

setItem

getItem

removeItem

clear

localStorage 會將數據永久的存儲下來（當然用戶可以主動清楚），sessionStorage 中設置的數據當用戶關閉頁面后會清除。

WHATWG Web storage

MDN Storage

小型的數據有 storage 已經夠用，那么瀏覽器端如何進行大量數據的存儲呢？IndexedDB 就是 HTML5 給出的答案。IndexedDB 是瀏覽器內置的一個數據庫，用于存儲結構化數據。但這個數據庫是異步存取數據的，說實話有點難使用，如果使用他，那基本上所有的代碼都在 then 方法里了。考慮使用吧。

可以通過使用 IndexedDB進行學習和使用。

querySelector 使用 CSS 選擇器進行選擇元素，僅選取匹配元素中的第一個。

querySelectorAll 使用 CSS 選擇器進行選擇元素，返回所有匹配的元素。

可以通過在標簽上使用 data-* 設置與元素綁定的數據，JavaScript 可以通過 dataset 獲取或設置。

const p = document.querySelector("#title");
p.dataset.text // hello

prepend 在規定標簽的最前面添加元素

append 在規定標簽最后面添加元素

firstElementChild 獲取規定標簽中的第一個子元素

lastElementChild 獲取規定標簽中的最后一個子元素

previousElementSibling 獲取前一個兄弟元素

nextElementSibling 獲取后一個兄弟元素

Node.classList.add 添加類名

Node.classList.remove 移除類名

Node.classList.toggle 切換類名

Node.classList.contains 檢測是否有類名

在 HTML4 中想實現元素拖拽，我們需要這樣一個過程，獲取元素，設置元素定位，與需要被拖入的元素進行碰撞檢測，檢測完成后進行拖入操作。在 HTML5 中規范了這一過程。

相關事件

dragstart 設置在拖動元素上，標志拖動開始

dragenter 設置在拖入元素上，標志有元素開始拖入到該元素內

dragover 設置在拖入元素上，標志元素完全拖入該元素

dragleave 設置在拖入元素上，標志元素即將離開該元素

drop 設置在拖入元素上，標志拖動元素放下

拖動元素與拖入元素可以通過 e.dataTransfer.getData(xxx) e.dataTransfer.setData(xxx, xxx) 進行數據交互。

MutationObserver 字面意思為變動觀察器，用來觀察文檔節點的變動。相關文章

了解 HTML5 中的 MutationObserver

MutationObserver

DOM 中，接觸最多的也就這些內容了，更為詳細的內容可以通過DOM STANDARD查看。

在什么是 JAVASCRIPT中，我們提到過 BOM 并沒有相關的標準去規范它，HTML5 中一些沒有歸到 DOM 中 API 更新就歸到這。

我們都知道 JavaScript 是以單線程的形式運行在客戶端，這就避免不了當進行大規模的數據運算時所帶來的堵塞問題，為解決這一問題 HTML5 提出了 Web Workers 的概念，并最終納入規范。使用 Web Workers 可以將于頁面渲染無關的數據運算代碼放入另一個線程，線程間通過 postMessage 發送數據，通過 onmessage 回調獲取數據。

一個簡單的例子

// workers.js
let i = 0;

function timedCount() {
    i = i + 1;
    postMessage(i);
    setTimeout(timedCount, 500);
}
timedCount();

const w = new Worker("workers.js");
w.onmessage=function(event){
    console.log("Message from worker ", event.data);
};

相關資源：

WHATWG Worker

MDN Worker

目前大火的 PWA 應用，其核心 Service Worker 其實也是 Web Workers 的一個實現。 Service Worker 使用編程的方式來進行資源的緩存，與后臺進行數據同步等內容。雖然該內容已在不少的瀏覽器上實現，但標準仍在草案階段，等出標準規范在詳細介紹。

相關資源

W3C Service Workers

在 HTML5 之前，前端開發者只能通過 history 對象進行前進后退的動作，但卻不能在不刷新當前頁面的情況下進行 url 修改，在 HTML5 之前，單頁應用僅能通過 hash 模式進行路由管理，但通過 HTML5 新提出的 history API ，單頁應用就能像正常應用那樣管理頁面的 url 了。通過以下 3 個方法即可：

pushState 不刷新頁面導航到指定 URL 并產生歷史記錄。

replaceState 不刷新頁面并將頁面當前 URL 替換為指定 URL，不產生歷史記錄。

popstate 事件 在當前頁面點擊返回時，window 對象會觸發該事件，可以使用 addEventListener 進行監聽。

相關資源

MDN Drag and Drop API

WHATWG Drag and drop

Drag Drop---API---拖拽事件

通知瀏覽器，在下一次重繪之前調用指定 callback。由于重繪與屏幕刷新率掛鉤，因此該 API 的調用也與屏幕刷新率掛鉤，可以使用該 API 進行一些復雜運算的分解，將任務放在每次刷新的間隔中，這樣就不會產生屏幕要刷新了但瀏覽器卻能及時繪制出頁面的尷尬情況出現，使得頁面顯示平滑，不掉幀。因此該 API 的出現促進了 Canvas 的發展，而 Canvas 的發展又促進了頁游的發展。

requestAnimationFrame(callback)

如果想實現類似定時器的效果，只需要在 callback 中再次調用 requestAnimationFrame 即可。

相關資源

MDN requestAnimationFrame

Element.requestFullscreen() 將當前元素全屏展示

Document.exitFullscreen() 取消全屏顯示

相關資源

MDN 全屏 API

navigator.geolocation.watchPosition() 監聽地理位置信息，當發生改變時，觸發回調

navigator.geolocation.getCurrentPosition() 獲取地理位置信息

以上兩方法都需要傳入，成功回調和失敗回調，分別為參一和參二。

相關資源

MDN 使用地理位置定位

在什么是 CSS？中，我們提到過，CSS 標準被 W3C 采納，并最終成為 HTML 標準的一部分，因此 CSS 內容的更新也算是 HTML5 更新的一部分。

這部分多帶帶說吧。

慣例，問幾個問題

HTML5 涵蓋了那幾方便面的更新？

通信方式有什么新姿勢？

語義化的體現，以及語義化的作用？

js 如何更好的處理數據而不影響頁面渲染？

單頁應用的 history 是基于那些 api 實現的？

談談感受

隨著 HTML5 的更新，前端在也不是切圖仔，瀏覽器也開始做為了一個 GUI 工具存在，而不僅是為了展示頁面。相信隨著技術的發展，當通訊延遲降低到一定程度后，喬幫主的設想 all in browser 將會成為現實。

HTML5

HTML5 Differences from HTML4

HTML 5.1 2nd Edition

HTML 5.2

WHATWG

該系列所有問題由 minimo 提出，愛你喲~~~