結(jié)構(gòu)化，樣式脫離的 HTML 文檔，極大提高了文檔的表達(dá)力，不管是機(jī)器還是人類都能更快的理解文檔的結(jié)構(gòu)，這種文檔就被稱為語義化文檔。

語義化主要體現(xiàn)在以下幾個方面：

寫過 HTML5 的都知道大概有哪些標(biāo)簽新加了進(jìn)來，這里大致羅列一下

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

試想一個問題？

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

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

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

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

搜索引擎通過適當(dāng)?shù)牟呗越馕鐾ㄟ^爬蟲抓取到的網(wǎng)頁內(nèi)容，將該文章進(jìn)行分類，通過用戶給的搜索詞進(jìn)行匹配，最終將結(jié)果呈現(xiàn)給用戶，爬蟲的解析策略，面對 HTML4 時，需要識別出特定的 div 而這個特定的 div 該如何去找呢？經(jīng)驗(yàn)？特定字符串？面對 HTML4 ，只能得到一個個的 div 而哪個 div ，emmm... 不好找。面對 HTML5 呢？程序從結(jié)構(gòu)就能大致理解文檔的結(jié)構(gòu)，進(jìn)而識別出該篇文章的大體內(nèi)容。

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

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

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

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

tel

search

url

email

date

time

number

range

color

以上為 HTML5 語義化的具體呈現(xiàn)，希望大家擁抱并使用 HTML5 的新標(biāo)簽。

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

相關(guān)多媒體標(biāo)簽

Audio

Video

建議查看英文的相關(guān)文檔，中文的翻譯文檔好像還沒有及時跟進(jìn)。

除了多媒體標(biāo)簽的更新，這里同時還列舉下一些與顯示相關(guān)的內(nèi)容：

Canvas

畫布，可以使用 JavaScript 在改元素規(guī)定的區(qū)域內(nèi)進(jìn)行繪畫，文檔說明。

WebGL

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

Camera API

通過Camera API，你可以使用手機(jī)的攝像頭拍照，然后把拍到的照片發(fā)送給當(dāng)前網(wǎng)頁。

SVG

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

MathML

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

HTML5 之前，JavaScript 只能通過 XMLHttpRequest 與后端程序進(jìn)行交互，隨著 HTML5 標(biāo)準(zhǔn)的提出，前端可以使用各種各樣的姿勢與后端進(jìn)行溝通，數(shù)據(jù)的交互變的簡單，靈活。

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

一個簡單的 fetch 例子

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

fetch 支持兩個參數(shù)，

資源地址

請求參數(shù)，用于設(shè)置請求方式，請求頭，請求體等內(nèi)容，一個 JavaScript 對象。

學(xué)習(xí)資源：

MDN 使用 Fetch

WHATWG Fetch

在 HTML5 出現(xiàn)之前，做一個實(shí)時聊天的 web 項(xiàng)目是極其困難的，由于之前的版本僅支持瀏覽器主動向服務(wù)器進(jìn)行發(fā)送內(nèi)容，必須先有請求才能有服務(wù)器響應(yīng)的數(shù)據(jù)，簡單的來說服務(wù)器并不能主動將數(shù)據(jù)提交給客戶端。

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

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

WebSocket 的客戶端代碼示例

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

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

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

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

一些資源

WHATWG Web sockets

websocket.org HTML5 WebSocket

MDN WebSockets

fetch 實(shí)現(xiàn)了請求的 Promise 化，WebSocket 實(shí)現(xiàn)了雙工通信，那么 EventSource 又是什么？

簡單的來說，EventSource 實(shí)現(xiàn)了服務(wù)端對客戶端的單向通信，可以理解為客戶端是訂閱者，服務(wù)端是內(nèi)容發(fā)布者，也就是發(fā)布訂閱模式的實(shí)現(xiàn)。

一個簡單的例子

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

// 服務(wù)端發(fā)布數(shù)據(jù)回調(diào)
evtSource.onmessage = function(event) {
    // event.data 即為服務(wù)端發(fā)布的數(shù)據(jù)
    console.log("Message from server ", event.data);
}

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

WHATWG EventSource

MDN EventSource

see.php 編寫

WebRTC（網(wǎng)頁即時通信），是一個支持網(wǎng)頁瀏覽器進(jìn)行實(shí)時語音對話或視頻對話的 API。由于該 API 目前并未納入標(biāo)準(zhǔn)中，這里就不過多的深入了，可以通過以下文檔進(jìn)行了解：

MDN WebRTC API

W3C WebRTC 1.0

在 HTML5 出現(xiàn)之前，前端開發(fā)者僅能通過 cookie 來存儲用戶在不同頁面之間跳轉(zhuǎn)的數(shù)據(jù)，但使用 cookie 來存儲數(shù)據(jù)其意義上是不對的，不能說 cookie 可以在同域名下通用，就讓它來攜帶各種各樣的數(shù)據(jù)，cookie 應(yīng)該是用來標(biāo)志用戶身份的。HTML5 出現(xiàn)之后，規(guī)范了數(shù)據(jù)的存儲，cookie 也回到了原始的用途。

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

setItem

getItem

removeItem

clear

localStorage 會將數(shù)據(jù)永久的存儲下來（當(dāng)然用戶可以主動清楚），sessionStorage 中設(shè)置的數(shù)據(jù)當(dāng)用戶關(guān)閉頁面后會清除。

WHATWG Web storage

MDN Storage

小型的數(shù)據(jù)有 storage 已經(jīng)夠用，那么瀏覽器端如何進(jìn)行大量數(shù)據(jù)的存儲呢？IndexedDB 就是 HTML5 給出的答案。IndexedDB 是瀏覽器內(nèi)置的一個數(shù)據(jù)庫，用于存儲結(jié)構(gòu)化數(shù)據(jù)。但這個數(shù)據(jù)庫是異步存取數(shù)據(jù)的，說實(shí)話有點(diǎn)難使用，如果使用他，那基本上所有的代碼都在 then 方法里了?？紤]使用吧。

可以通過使用 IndexedDB進(jìn)行學(xué)習(xí)和使用。

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

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

可以通過在標(biāo)簽上使用 data-* 設(shè)置與元素綁定的數(shù)據(jù)，JavaScript 可以通過 dataset 獲取或設(shè)置。

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

prepend 在規(guī)定標(biāo)簽的最前面添加元素

append 在規(guī)定標(biāo)簽最后面添加元素

firstElementChild 獲取規(guī)定標(biāo)簽中的第一個子元素

lastElementChild 獲取規(guī)定標(biāo)簽中的最后一個子元素

previousElementSibling 獲取前一個兄弟元素

nextElementSibling 獲取后一個兄弟元素

Node.classList.add 添加類名

Node.classList.remove 移除類名

Node.classList.toggle 切換類名

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

在 HTML4 中想實(shí)現(xiàn)元素拖拽，我們需要這樣一個過程，獲取元素，設(shè)置元素定位，與需要被拖入的元素進(jìn)行碰撞檢測，檢測完成后進(jìn)行拖入操作。在 HTML5 中規(guī)范了這一過程。

相關(guān)事件

dragstart 設(shè)置在拖動元素上，標(biāo)志拖動開始

dragenter 設(shè)置在拖入元素上，標(biāo)志有元素開始拖入到該元素內(nèi)

dragover 設(shè)置在拖入元素上，標(biāo)志元素完全拖入該元素

dragleave 設(shè)置在拖入元素上，標(biāo)志元素即將離開該元素

drop 設(shè)置在拖入元素上，標(biāo)志拖動元素放下

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

MutationObserver 字面意思為變動觀察器，用來觀察文檔節(jié)點(diǎn)的變動。相關(guān)文章

了解 HTML5 中的 MutationObserver

MutationObserver

DOM 中，接觸最多的也就這些內(nèi)容了，更為詳細(xì)的內(nèi)容可以通過DOM STANDARD查看。

在什么是 JAVASCRIPT中，我們提到過 BOM 并沒有相關(guān)的標(biāo)準(zhǔn)去規(guī)范它，HTML5 中一些沒有歸到 DOM 中 API 更新就歸到這。

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

一個簡單的例子

// 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);
};

相關(guān)資源：

WHATWG Worker

MDN Worker

目前大火的 PWA 應(yīng)用，其核心 Service Worker 其實(shí)也是 Web Workers 的一個實(shí)現(xiàn)。 Service Worker 使用編程的方式來進(jìn)行資源的緩存，與后臺進(jìn)行數(shù)據(jù)同步等內(nèi)容。雖然該內(nèi)容已在不少的瀏覽器上實(shí)現(xiàn)，但標(biāo)準(zhǔn)仍在草案階段，等出標(biāo)準(zhǔn)規(guī)范在詳細(xì)介紹。

相關(guān)資源

W3C Service Workers

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

pushState 不刷新頁面導(dǎo)航到指定 URL 并產(chǎn)生歷史記錄。

replaceState 不刷新頁面并將頁面當(dāng)前 URL 替換為指定 URL，不產(chǎn)生歷史記錄。

popstate 事件 在當(dāng)前頁面點(diǎn)擊返回時，window 對象會觸發(fā)該事件，可以使用 addEventListener 進(jìn)行監(jiān)聽。

相關(guān)資源

MDN Drag and Drop API

WHATWG Drag and drop

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

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

requestAnimationFrame(callback)

如果想實(shí)現(xiàn)類似定時器的效果，只需要在 callback 中再次調(diào)用 requestAnimationFrame 即可。

相關(guān)資源

MDN requestAnimationFrame

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

Document.exitFullscreen() 取消全屏顯示

相關(guān)資源

MDN 全屏 API

navigator.geolocation.watchPosition() 監(jiān)聽地理位置信息，當(dāng)發(fā)生改變時，觸發(fā)回調(diào)

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

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

相關(guān)資源

MDN 使用地理位置定位

在什么是 CSS？中，我們提到過，CSS 標(biāo)準(zhǔn)被 W3C 采納，并最終成為 HTML 標(biāo)準(zhǔn)的一部分，因此 CSS 內(nèi)容的更新也算是 HTML5 更新的一部分。

這部分多帶帶說吧。

慣例，問幾個問題

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

通信方式有什么新姿勢？

語義化的體現(xiàn)，以及語義化的作用？

js 如何更好的處理數(shù)據(jù)而不影響頁面渲染？

單頁應(yīng)用的 history 是基于那些 api 實(shí)現(xiàn)的？

談?wù)劯惺?/p>

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

HTML5

HTML5 Differences from HTML4

HTML 5.1 2nd Edition

HTML 5.2

WHATWG

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