譯者：其實...我想說這可能是最令我感到興奮..但又害怕頭痛的功能... 附上原文連結
你曾經想要使用某個 CSS 的新功能，但是最後卻因為這個功能瀏覽器還未全面支援而放棄了嗎？甚至更糟糕的狀況，瀏覽器已經支援了但卻充滿問題。我敢打賭這些情況你肯定遇過了。如果上面這種情形你曾經遇過，那麼你是應該關心一下 Houdini。
Houdini 是 w3c 新的任務團隊，他們的終極目標就是解決上面這些問題 - 讓瀏覽器更迅速廣泛的支援 CSS 新特性。這個計畫試圖透過提供一系列新的 API，也是第一次讓開發者可以擴充 CSS 本身的能力。透過 hook 的方式讓我們可以在瀏覽器渲染的過程動點手腳。
Hooks 簡易說明：Hooks 英文翻譯為鉤子，在程式術語中所表達的是在程式特定位置埋入一段預留的程式碼，用來呼叫其他對應的程式碼。可以大略想成在某個片段先空出一個位置，這個位置可以在事後再放入動作，不放也沒關係。
不過具體來說這到底是什麼意思？這麼做真的好嗎？還有這樣做到底能在我們的開發過程提供些什麼幫助。
在這篇文章，我將試著回答這些問題。不過在這之前我們必須要先搞清楚，到底我們在今時今日遇到什麼問題，為什麼我們需要做這些改變。接下來我們將會更具體的說明 Houdini 是什麼東西和這傢伙會怎麼解決這些問題，並且列出目前開發中一些令人興奮的功能。最後我將提供一些比較具體實例的說明。
Houdini 試圖要解決什麼問題？
每一次當我寫了一篇文章來介紹一些 CSS 的新功能時總是會有人留言像是 這實在太棒了! 不過我們可能要再等個 10 年才能使用 我能體會這種毫無建設性的留言....從過往的歷史來看，這的確需要花上好幾年的時間從功能提案到廣泛採用。而其中最關鍵的原因是唯一讓 CSS 增加新功能的方式就是透過下面這個標準流程。
因為瀏覽器本身牽涉太廣泛，對於這樣的流程我本身沒有任何反對意見。當然我們也知道這會耗掉很長的時間。舉例來說 flexbox 首次提案是在 2009 年，而時至今日我們還是見到開發者在抱怨支援的瀏覽器不夠。這個問題正緩慢的解決中，因為幾乎所有的瀏覽器都會自動更新，不過即使是現代瀏覽器(Modern Browser)在功能提案到實際能使用該功能還是有一段挺長的時間。
有趣的是並不是所有 Web 領域的東西都處在這樣的情況，看看最近的 Javascript，為什麼 Javascript 可以發展如此迅速
從上圖這種流程，構想提案到實際用在產品上有時候只需要幾天的時間。例如：我已經在產品上使用了 async/await 的功能。這個功能甚至還沒有一個瀏覽器支援。
你還可以看到兩個社群截然不同的狀況，在 Javascript 社群你可以聽到人們開始在抱怨更新速度太快，而在 CSS 社群則多是看到一堆人在抱怨學那麼多東西沒用，還需要非常久的時間才能使用。
那為什麼我們不可以使用 CSS Polyfills？
看完 Javascript 的流程第一個直覺的想法是那我們也來為 CSS 提供 Polyfills，聽起來可能蠻可行的，如果有 Polyfills 那麼 CSS 也可以像 Javascript 一樣快速的演進，不是嗎？可惜的是，這並不像想的那麼容易，用舊有技術實現新的功能或 API 在 CSS 中異常的困難，在大部分的情況下會整個犧牲掉效能。
Javascript 是一個動態語言，意味著我們相對容易用 Javascript 替 Javascript 補上 Polyfills。對 CSS 來說我們相對很少使用 CSS 來做 Polyfills。一般頂多就是使用轉譯器來產生 CSS 例如 PostCSS 就是這樣的東西。
如果你想直接對 DOM 結構或者元素的 Layout，位置加上 Polyfills，那麼我們就必須要在客戶端執行對應的邏輯程式。
不幸的是瀏覽器對於這方面並不提供任何簡單的方式。
下圖我們簡單的歸納瀏覽器從收到 HTML 文件到顯示在螢幕上概略的流程。藍色區塊就是 Javascript 能夠控制結果的關鍵點
在上圖中我們認知到身為一個開發者，你對於瀏覽器解析 HTML 和 CSS 轉換成 DOM, CSSOM 的過程幾乎沒有控制權，尤其在瀏覽器對元素佈局以及渲染方面。唯一在這個過程中我們能夠掌握的就是 DOM 的存取，是不是該換 CSSOM 做些開放了。不過這邊先提一下 Houdini 網站上提到的改良 CSSOM的部分：確認跨瀏覽器行為不一致以及缺少關鍵功能的問題。
關於缺少關鍵功能部分，舉例來說，瀏覽器中的 CSSOM 並不會顯示跨站存取的樣式規則，而且會直接忽略那些它看不懂的樣式，這也意味著如果你想增加一個瀏覽器未支援的功能，你是不可以使用 CSSOM。反而要用 DOM 去找到