Houdini：也許是你從未聽過的在CSS領域最使人興奮的發展（有點長）

你是否曾經試過想使用某個CSS特性可是卻由於他沒有被全部瀏覽器支持而不能用？又或者更糟糕的，他被所有瀏覽器支持，可是這種支持充滿了bug、表現不一致甚至是不徹底兼容的？若是這些事情曾經在你身上發生過——而且我打賭他們絕對發生過——那麼你就須要關注一下。

 

Houdini是一個新的W3C工做組，他們致力於讓這些問題永遠消失。他們計劃經過引入一整套API來讓開發者首次擁有擴展CSS的權利，而且會提供出一套工具來與瀏覽器的渲染引擎的樣式與佈局進行掛鉤。

 

可是這意味着什麼呢？這是一個好的提議嗎？這會如何幫助咱們開發者在現今與將來構建網頁呢？

 

在這篇文章裏，我將嘗試去回答這些問題。可是在我回答以前，弄清楚今天咱們遇到了什麼問題和爲何須要這樣的變革是很重要的。而後我會更詳盡地去解釋Houdini如何去解決這些問題，而且列出一些在現今開發上十分使人振奮的特徵。最後，我會提供一些具體的，咱們的開發者如今能夠去完成的事情來讓Houdini變成現實。

 

Houdini嘗試解決什麼問題呢

每次我爲一些全新的CSS特徵編寫文章或者構建一個demo，必然會有人在評論或者推特上說，「這真的很棒！不過咱們可能將來十年都不會用到它們。」

 

像這些煩人且毫無建設性的評論，我能夠理解那種情緒。從歷史上來看，一個功能建議要花費數年才能被普遍使用。其緣由在於，縱觀整個web的歷史，惟一能讓一個新特徵加入CSS的方法就是走完整個標準過程。

固然我不是反對標準過程，可是不能否認的是他花費太多時間了。

 

例如，[url=]flexbox[/url]在2009年第一次被提出，然而直至今天，開發者仍然抱怨由於缺少瀏覽器的支持而不能使用它。固然，這個問題正在慢慢的被解決由於如今幾乎全部現代瀏覽器都會自動更新；可是即便是現代瀏覽器，從功能提議到全面上市仍然會有延遲。

 

有趣的是，並非全部web的領域都是這樣。看一下在JavaScript上事情最近是怎麼發生的：

在這種狀況下，可能只須要花費幾天就能把一個想法運用到生產中去。個人意思是，我已經在生產中使用async/await了，可是這個功能仍然未被加入到任何一個瀏覽器中。

 

你還能夠看到這兩個社區的廣泛情緒上的巨大差別。在JavaScript社區，你會閱讀到人們抱怨變化太快的文章。而在CSS社區，相反你聽到的是人們哀嘆學習新東西的徒勞由於他們不知道何時才能使用他們。

 

因此爲何咱們不編寫更多的CSSPolyfills呢？

 

第一個想法就是，編寫更多CSSpolyfills彷佛是解決問題的方法。若是有了良好的polyfills，CSS就能夠像JavaScript那樣快速前進了，不是嗎？

 

而後悲傷的是，並無那麼簡單。對CSS進行polyfill是難以置信的困難，大部分狀況下，你不能在徹底不破壞性能的狀況下去完成polyfill。

 

JavaScript是一個動態語言，這意味着你可使用JavaScript來polyfill JavaScript。又由於他是動態的，因此他特別容易被拓展。反之，CSS很難被用來polyfill CSS。某些狀況下，你能夠在編譯步驟裏面轉化編譯CSS（[url=]PostCSS[/url]負責這種工做）；可是若是你想polyfill任何基於DOM結構的或者是元素佈局位置的屬性，你必需要在客戶端運行你的polyfill邏輯。

 

不幸的是，在瀏覽器上完成這項任務並不容易。

 

下圖勾勒出了你的瀏覽器如何把一個HTML文件展示到屏幕上的過程。用藍色標註的部分是JavaScript有權利控制的部分：

圖片顯示的結果至關慘淡。做爲一個開發者，你並不能控制你的瀏覽器如何解析HTML和CSS也不能控制他如何把HTML和CSS轉化成[url=]DOM[/url]和[url=]CSS對象模型[/url](CSSOM)。你沒法控制級聯。你沒法掌控瀏覽器如何在DOM里布局元素，如何在屏幕上繪製元素。你也沒法控制合成器。

 

惟一一個你能夠所有控制的進程就是DOM。CSSOM部分開放；然而，引述自Houdini的網站，這種開放是「還沒有被確認的，在瀏覽器上是不一致的，而且缺乏關鍵功能。」

 

例如，現在的瀏覽器的CSSOM不會展現你的跨域樣式表，並且他會輕易丟棄掉任何他不認識的CSS規則或者聲明，這意味着若是你想polyfill一個瀏覽器尚不支持的功能，你不能使用CSSOM。相反，你必須經過DOM，找到and/or標記，拿到CSS樣式，解析、重寫再把它添加到DOM上。

 

固然，更新DOM一般意味着整個瀏覽器必須從新完成全部的級聯、佈局、繪製和合成的步驟。

儘管徹底重繪一個頁面對性能的影響看起來並不會特別大（特別是某些網站），可是思考一下這種事情發生的頻率。若是你的polyfill邏輯是須要對滾動事件、窗口大小調整、鼠標動做、鍵盤事件進行響應的話——基本至關於任什麼時候候都在改變——那麼事情將會十分明顯，有的時候甚至是接近極限，十分緩慢。

 

當你意識到今天絕大部分的CSSpolyfill包含他們本身的CSS解析器和他們本身的級聯邏輯，你會發現情況變得更加的糟糕。又由於解析和級聯都是十分複雜的事情，這些polyfills一般不是太大就是充滿了bug。

 

簡單的總結一下剛纔我所說的：若是你想讓你的瀏覽器（由於你給予的CSS）作一些它自身不支持的事情，那麼你必需要親自經過更新和修改DOM來僞造出這種效果。你在其他的渲染步驟裏沒有權限。

 

可是爲何我會想改變瀏覽器的內部渲染引擎呢？

 

這對於我來講，絕對是整篇文章中最重要的問題。因此若是你一直都是快速瀏覽的話，這部分必須緩慢並且仔細的閱讀！

 

在看到最後一節後，我相信部分人會認爲「我不須要這些！我只是想構建一個正常的網頁。我並不想侵入個人瀏覽器內部去創造一些十分花哨的、試驗性的甚至可能會形成問題的效果。」

 

若是你是這麼想的話，我強烈建議你先退一步而後認真思考一下咱們這些年用在網站建設上面的技術。想要訪問或者和瀏覽器的樣式化過程掛鉤並不僅是去建設花哨的樣例——這是爲開發者和框架做者提供動力去完成兩件重要的事情：

• 正常化瀏覽器之間的差別
• 發明而且polyfill一些新功能讓人們可使用。

 

若是你曾經使用一些JavaScript庫諸如jQuery，那麼你會從這種能力裏面獲益良多！事實上，這是現今幾乎全部前端庫或者框架的主要賣點。五個Github上面最流行的JavaScript和DOM資料庫——AngularJS, D3, jQuery, React和Ember——都在減小跨瀏覽器間的差別上作了不少工做因此你不用去考慮他們。他們都只暴露出一個API，而後這個API正常工做。

 

如今，回想一下CSS和他那些跨瀏覽器問題。即便是最流行的CSS框架如Bootstrap和Foundation，儘管他們生成本身具備跨平臺的兼容性，可是他們並無消除跨瀏覽器的bug——他們只是避免觸發bug的作法。而CSS跨瀏覽器bug並不只僅是過去的問題。甚至在擁有新的佈局模式的如[url=]flexbox[/url]的今天，咱們仍然會面對不少[url=]跨瀏覽器不兼容的問題[/url]。

 

底線是，想像一下若是你可使用任何CSS屬性，而且知道他們必定會生效，在每一個瀏覽器裏面表現都是同樣，那麼你的開發工做會變得多輕鬆。再想象一下，你在其餘blog文章上面或者在會議上知道的新特性——如[url=]CSS grids[/url], [url=]CSS snap points[/url]和[url=]stickypositioning[/url]。若是你今天就可使用它們而且它們的性能表現的就像原生的CSS功能同樣。而你全部須要作的就是從Github上面獲取代碼。

 

這就是Houdini的夢想。這就是他們指望的將來。

 

因此，即便你並不打算去寫一個CSSpolyfill或者開發一個實驗性的功能，你可能會想讓其餘人能夠這麼作——由於一旦這些polyfill存在，每一個人均可以從中獲益。

 

Houdini有什麼功能正在被研發中呢？

我在上面提到開發者對於瀏覽器的渲染過程沒有什麼控制權。事實上，惟一能夠控制的是DOM而且一部分的CSSOM。

 

爲了解決這個問題，Houdini工做組引入了幾個新規範。這將會首次讓開發者對渲染過程裏的其餘部分擁有訪問的權利。下表展現了在新規範中渲染過程哪部分能夠被修改。（注意灰色的規範是在計劃中可是還沒有被編寫。）

下面幾個部分將會簡短地瀏覽一下每個新規範，介紹他們提供了什麼。我應該注意到在這篇文章中有另一個規範未被說起;你能夠從[url=]GitHubrepository of Houdini’s drafts[/url]上面觀看完整的列表。

 

CSS解析器API

[url=]CSS解析器API[/url]還沒有被編寫；因此我所說的大部分都很容易被改變。可是基本想法是讓開發者拓展CSS解析器而且告知他們新的結構——例如新的媒體規則、新的僞類、嵌套、@extends、@apply等等。

 

一旦解析器知道這些新的結構，它就能夠把它們放到CSSOM裏面的正確位置上去，而不是拋棄掉他們。

 

CSS屬性和值API

CSS已經具備自定義屬性了，就像[url=]我以前提到的那樣[/url]，我對他們被解開的可能性感到十分興奮。而[url=]CSS屬性和值API[/url]則在自定義屬性上更進一步，經過添加類型讓他變得更加有用。

 

在自定義屬性上添加類型會帶來不少好處，不過最大的賣點或許就是這些類型會讓開發者能夠爲自定義屬性添加transition和animate這些咱們今天不能使用的功能。

 

看一下如下例子：

 

<ignore_js_op>

在上面的代碼中，若是night-theme類別添加到`元素上，頁面上每一個具備--primary-theme-color屬性的元素的值都會慢慢的從tomato轉變成darkred`。若是你想在今天完成這些，你必需要手動地爲每一個元素寫transition，由於你不能對自定義屬性進行transition變換。

 

這個API另外一個十分有但願的特色是能夠註冊一個「應用鉤」（apply hook），這讓開發者能夠在級聯步驟完成後仍然能夠修改一個自定義屬性的值，這對於polyfill多是一個十分有用的功能。

 

CSS Typed OM

[url=]CSS Typed OM[/url]能夠被認爲是如今使用的CSSOM的第二個版本。他的目標是解決不少現有模型的問題而且會引入新的CSS解析器API和CSS屬性和值API的特性。

 

Typed OM的另外一個主要目標是改進性能。將當前CSSOM的字符串值轉化成有意義的類型化的JavaScript表達式會產生顯著的性能提高。

 

CSS佈局API

[url=]CSS佈局API[/url]讓開發者能夠編寫他們本身的模型。經過「佈局模型」，基本上全部東西都能被傳入到CSSdisplay屬性中。這會讓開發者第一次能夠像原生的佈局模型display:flex和display:table那樣高效地進行佈局。

 

做爲一個示例，[url=]Masonry佈局庫[/url]展現了開發者開發者有多願意去完成僅依靠CSS沒法搭建的佈局。儘管這些佈局使人印象深入，可是不幸的是，他們充滿了性能問題，特別是那些不那麼強勁的設備上。

 

CSS佈局API會給予開發者一個registerLayout方法來接受佈局名稱（這在稍後的會被用到）和一個JavaScript類來引入全部佈局邏輯。下面是一個基本例子告訴你如何經過registerLayour來定義masonry：

 

<ignore_js_op>

 

若是你看不懂上面的例子，不要擔憂。主要須要關心的是下面的代碼。一旦你下載了masonry.js文件，而且將它添加到你的網站上，你能夠像下面那樣編寫CSS而後他們就會工做：

<ignore_js_op> 

CSS繪製API

CSS繪製API和上面的佈局API十分類似。它提供了一個registerPatint方法，操做方式和registerLayout方法同樣。開發者而後能夠在CSS中任何地方須要CSS圖像的地方使用paint()函數，只要傳入他們註冊的名稱就好。

 

下面是一個簡單繪製有顏色的圓的例子：

 

<ignore_js_op>

 

在CSS中它能夠這樣使用

<ignore_js_op> 

}如今，.bubble元素會展現一個藍色的圓形做爲背景。圓形自身會被放置在中間，而且大小回合元素自己同樣，不管發生什麼事。

 

Worklets

上面列舉的許多規範都展現了代碼示例（例如，registarLayout和registerPaint）。若是你好奇你應該在哪裏放置這些代碼，答案就是[url=]worklet[/url]腳本。

 

Worklets和web workers十分類似，他們都容許你引入腳本文件而且運行JavaScript代碼。並且他能夠在渲染過程當中的不一樣地方被調用，而且獨立於主線程。

 

Worklet腳本會爲了保證高性能嚴重限制你能夠用的操做類型。

 

合成滾動和動畫

儘管仍然沒有官方的[url=]合成滾動和動畫[/url]規範，這仍然是實際上比較知名和高度受關注的Houdini功能。最終的API會容許開發者在合成worklet中執行邏輯運算，並且這是獨立於主線程的，能夠去修改一些指定的DOM元素屬性。這些屬性只會是那些能夠在不須要重繪的狀況下進行更改的屬性。（如transform、opacity、scroll offset）。

 

這會讓開發者能夠創造高效的滾動動畫或者基於輸入的動畫，如粘滾動的標題和時差效果。你能夠在Github上掛看更多這個API嘗試去解決的[url=]樣例[/url]。

 

儘管還沒有有官方的文檔，Chrome上已經開始了實驗性的開發。事實上，Chrome團隊正在使用這個API最終會暴露的方法來添加[url=]CSS捕捉點（CSS snappoints）[/url]和[url=]粘定位（stickypositioning）[/url]。這是十分驚人的，由於這意味着Houdini的API足夠高效，以致於新的Chrome特性依據他們來構建。若是你仍然懼怕Houdini不如原生的快，這個事實會說服你。

 

[url=]Surma[/url]錄製了一個在Chrome上運行[url=]視頻樣例[/url]。這個demo模仿了Twitter原生移動應用的滾動標題欣慰。能夠點擊[url=]源碼[/url]查看他是怎麼工做的。

 

你如今能夠作什麼？

就像我以前提到的那樣，我認爲每一個網站構建的人都應該關注Houdini；他將會在將來讓咱們生活的更加方便。即時你歷來沒有直接使用過Houdini規範，你也必然會使用一些基於他們完成的模塊。

 

儘管這個將來不是立刻就到來，可是他會比不少人想象想的要接近。全部的主要瀏覽器廠商都參加了今年稍早時候悉尼舉辦的最新Houdini面對面會議。他們對於要作什麼如何構建這些問題產生的分歧仍是比較少。

 

我認爲的是，問題不是Houdini會否被實現，而是何時被實現。這也是須要大家的地方。

 

瀏覽器廠商，就像軟件開發商同樣，會對新功能進行分級。而這些優先級則通常都是用戶對其的渴望程度。

 

因此，若是你關注web上面的樣式和佈局的拓展性。若是你但願之後你能夠不用等待漫長標準過程就能使用新的CSS功能。那麼就和你使用的瀏覽器的開發者們說，告訴他們你想要這個功能。

原文連接：http://www.369cloud.com/devservce/index.html