摘要：接下來我們將會更具體的說明是什麼東西和這傢伙會怎麼解決這些問題，並且列出目前開發(fā)中一些令人興奮的功能。這個(gè)功能甚至還沒有一個(gè)瀏覽器支援。完整的清單請查閱目前還未被寫入規(guī)範(fàn)，意思是這邊提到任何內(nèi)容極有可能會改變。

譯者：其實(shí)...我想說這可能是最令我感到興奮..但又害怕頭痛的功能... 附上原文連結(jié)

你曾經(jīng)想要使用某個(gè) CSS 的新功能，但是最後卻因?yàn)檫@個(gè)功能瀏覽器還未全面支援而放棄了嗎？甚至更糟糕的狀況，瀏覽器已經(jīng)支援了但卻充滿問題。我敢打賭這些情況你肯定遇過了。如果上面這種情形你曾經(jīng)遇過，那麼你是應(yīng)該關(guān)心一下 Houdini。

Houdini 是 w3c 新的任務(wù)團(tuán)隊(duì)，他們的終極目標(biāo)就是解決上面這些問題 - 讓瀏覽器更迅速廣泛的支援 CSS 新特性。這個(gè)計(jì)畫試圖透過提供一系列新的 API，也是第一次讓開發(fā)者可以擴(kuò)充 CSS 本身的能力。透過 hook 的方式讓我們可以在瀏覽器渲染的過程動(dòng)點(diǎn)手腳。

Hooks 簡易說明：Hooks 英文翻譯為鉤子，在程式術(shù)語中所表達(dá)的是在程式特定位置埋入一段預(yù)留的程式碼，用來呼叫其他對應(yīng)的程式碼?？梢源舐韵氤稍谀硞€(gè)片段先空出一個(gè)位置，這個(gè)位置可以在事後再放入動(dòng)作，不放也沒關(guān)係。

不過具體來說這到底是什麼意思？這麼做真的好嗎？還有這樣做到底能在我們的開發(fā)過程提供些什麼幫助。

在這篇文章，我將試著回答這些問題。不過在這之前我們必須要先搞清楚，到底我們在今時(shí)今日遇到什麼問題，為什麼我們需要做這些改變。接下來我們將會更具體的說明 Houdini 是什麼東西和這傢伙會怎麼解決這些問題，並且列出目前開發(fā)中一些令人興奮的功能。最後我將提供一些比較具體實(shí)例的說明。

每一次當(dāng)我寫了一篇文章來介紹一些 CSS 的新功能時(shí)總是會有人留言像是 這實(shí)在太棒了! 不過我們可能要再等個(gè) 10 年才能使用 我能體會這種毫無建設(shè)性的留言....從過往的歷史來看，這的確需要花上好幾年的時(shí)間從功能提案到廣泛採用。而其中最關(guān)鍵的原因是唯一讓 CSS 增加新功能的方式就是透過下面這個(gè)標(biāo)準(zhǔn)流程。

因?yàn)闉g覽器本身牽涉太廣泛，對於這樣的流程我本身沒有任何反對意見。當(dāng)然我們也知道這會耗掉很長的時(shí)間。舉例來說 flexbox 首次提案是在 2009 年，而時(shí)至今日我們還是見到開發(fā)者在抱怨支援的瀏覽器不夠。這個(gè)問題正緩慢的解決中，因?yàn)閹缀跛械臑g覽器都會自動(dòng)更新，不過即使是現(xiàn)代瀏覽器(Modern Browser)在功能提案到實(shí)際能使用該功能還是有一段挺長的時(shí)間。

有趣的是並不是所有 Web 領(lǐng)域的東西都處在這樣的情況，看看最近的 Javascript，為什麼 Javascript 可以發(fā)展如此迅速

從上圖這種流程，構(gòu)想提案到實(shí)際用在產(chǎn)品上有時(shí)候只需要幾天的時(shí)間。例如：我已經(jīng)在產(chǎn)品上使用了 async/await 的功能。這個(gè)功能甚至還沒有一個(gè)瀏覽器支援。

你還可以看到兩個(gè)社群截然不同的狀況，在 Javascript 社群你可以聽到人們開始在抱怨更新速度太快，而在 CSS 社群則多是看到一堆人在抱怨學(xué)那麼多東西沒用，還需要非常久的時(shí)間才能使用。

看完 Javascript 的流程第一個(gè)直覺的想法是那我們也來為 CSS 提供 Polyfills，聽起來可能蠻可行的，如果有 Polyfills 那麼 CSS 也可以像 Javascript 一樣快速的演進(jìn)，不是嗎？可惜的是，這並不像想的那麼容易，用舊有技術(shù)實(shí)現(xiàn)新的功能或 API 在 CSS 中異常的困難，在大部分的情況下會整個(gè)犧牲掉效能。

Javascript 是一個(gè)動(dòng)態(tài)語言，意味著我們相對容易用 Javascript 替 Javascript 補(bǔ)上 Polyfills。對 CSS 來說我們相對很少使用 CSS 來做 Polyfills。一般頂多就是使用轉(zhuǎn)譯器來產(chǎn)生 CSS 例如 PostCSS 就是這樣的東西。
如果你想直接對 DOM 結(jié)構(gòu)或者元素的 Layout，位置加上 Polyfills，那麼我們就必須要在客戶端執(zhí)行對應(yīng)的邏輯程式。

不幸的是瀏覽器對於這方面並不提供任何簡單的方式。

下圖我們簡單的歸納瀏覽器從收到 HTML 文件到顯示在螢?zāi)簧细怕缘牧鞒獭Ｋ{(lán)色區(qū)塊就是 Javascript 能夠控制結(jié)果的關(guān)鍵點(diǎn)

在上圖中我們認(rèn)知到身為一個(gè)開發(fā)者，你對於瀏覽器解析 HTML 和 CSS 轉(zhuǎn)換成 DOM, CSSOM 的過程幾乎沒有控制權(quán)，尤其在瀏覽器對元素佈局以及渲染方面。唯一在這個(gè)過程中我們能夠掌握的就是 DOM 的存取，是不是該換 CSSOM 做些開放了。不過這邊先提一下 Houdini 網(wǎng)站上提到的改良 CSSOM的部分：確認(rèn)跨瀏覽器行為不一致以及缺少關(guān)鍵功能的問題。

關(guān)於缺少關(guān)鍵功能部分，舉例來說，瀏覽器中的 CSSOM 並不會顯示跨站存取的樣式規(guī)則，而且會直接忽略那些它看不懂的樣式，這也意味著如果你想增加一個(gè)瀏覽器未支援的功能，你是不可以使用 CSSOM。反而要用 DOM 去找到