1. Typed OM API
2. Properties & Values API
3. Paint API
4. Layout API
5. Animation worklet
6. Parser API
7. Font Metrics API

Mmmm，雖然是有7個API（Houdini drafts上還有一些），但瀏覽器實際的支持情況其實是這樣的：

CSS Houdini的工作流程如下：

1. 鉤子進入渲染的進程中
2. JS是這個鉤子的核心
3. 使用JS的Typed OM，可以掛載自定義的屬性，繪製圖形，佈局以及動畫
4. 還有其他兩個API：Parser API 和 Font Metrics API。它們用於註冊CSS相關的新事物

一些示例

本篇不打算細講CSS Houdini，所以不會畫出所有的DEMO，有興趣的可以查看底部的“資料來源”，從而獲取更加詳細的信息。

Typed OM

上面就是Typed OM的示例，這裡值得一提的就是，如果我們用getComputedStyle去獲取transform的值，最終結果是個矩陣，這其實不太方便我們做二次操作，但是用Typed OM的JS API computedStyleMap，去取的結果就是一個具體屬性的集合，這是非常有利於我們進行二次操作的。

Paint API

Paint API就是允許你例如Canvas的屬性來編寫CSS樣式，使用方法也很簡單，我們可以看看slides.iamvdo.me/waq19/#/35上的示例

首先我們新建個文件叫registerPaint.js，在裡面寫下以下代碼：

registerPaint('circle-ripple', class {
 static get inputProperties() { return [ '--circle-color',
 '--circle-radius', '--circle-x', '--circle-y'
 ]}
 paint(ctx, geom, props, args) {
 const x = props.get('--circle-x').value;
 const y = props.get('--circle-y').value;
 const radius = props.get('--circle-radius').value;
 }
}

然後再新建一個index.html，並且在JS代碼裡註冊上面寫好的registerPaint.js，方式如下：CSS.paintWorklet.addModule('registerPaint.js');

具體代碼如下：

所以我們有以下的效果：

CSS屆的Babel —— PostCSS

說到底CSS Houdini其實也只是JS IN CSS，並不是純正的CSS，那麼對於一些新的CSS屬性，我們相用的話，真的還得等5年後嗎？還有即便是有各種工具，但是像一些兼容性寫法，廠商前綴，循環，原生CSS也沒有，我們不是還得需要依賴CSS預處理器嗎？

其實也不是，這時候我們可以利用CSS屆的Babel —— PostCSS

PostCSS是什麼？

簡單來說PostCSS就是可以讓開發者使用JS來處理CSS的處理器，它分了以下5大類功能：

增強代碼的可讀性

利用從 Can I Use 網站獲取的數據為 CSS 規則添加特定廠商的前綴。Autoprefixer 自動獲取瀏覽器的流行度和能夠支持的屬性，並根據這些數據幫你自動為 CSS 規則添加前綴。

例如我們輸入以下代碼：

:fullscreen {
}

那麼就會輸出：

:-webkit-:full-screen {
} 

:-moz-:full-screen {
}
:full-screen {
}

將未來的 CSS 特性帶到今天！

PostCSS Preset Env 幫你將現代 CSS 語法轉換成大多數瀏覽器都能理解的東西，根據你的目標瀏覽器或運行時環境來確定你需要的 polyfills，基於 cssdb 實現。

例如我們輸入以下代碼：

@custom-media --med (width <= 50rem);

@media (--med) {
 a { 
 &:hover {
 color: color-mod(black alpha(54%));
 }
 }
}

就會輸出：

@media (max-width: 50rem) {
 a:hover { 
 color: rgba(0, 0, 0, 0.54);
 }
} 

終結全局 CSS

CSS 模塊 就是說你永遠不用擔心命名太大眾化而造成衝突太普通，只要用最有意義的名字就行了。

例如我們輸入以下代碼：

.name {
 color: gray;
}
複製代碼

就會輸出：

.Logo__name__SVK0g {
 color: gray;
}

避免 CSS 代碼中的錯誤

通過使用 stylelint 強化一致性約定並避免樣式表中的錯誤，stylelint 是一個現代化 CSS 代碼檢查工具。它支持最新的 CSS 語法，包括類似 CSS 的語法，例如 SCSS 。

例如我們輸入以下代碼：

a { 
 color: #d3;
}

那麼控制檯會拋出錯誤：

app.css
2:10 Invalid hex color

強大的網格系統

LostGrid 利用 calc() 和你所定義的分割方式來創建網格系統，無需傳遞大量參數。

例如我們輸入以下代碼：

div {
 lost-column: 1/3 
} 

就會輸出：

div {
 width: calc(99.9% * 1/3 - 
 (30px - 30px * 1/3)); 
}
div:nth-child(1n) {
 float: left; 
 margin-right: 30px; 
 clear: none; 
}
div:last-child {
 margin-right: 0; 
}
div:nth-child(3n) {
 margin-right: 0; 
 float: right; 
}
div:nth-child(3n + 1) {
 clear: both; 
}

可窺探的未來 —— cssdb

cssdb是postcss-preset-env的實現基準，主要就是CSS的新功能功能及這些功能從提出到成為標準時所在的進程。

cssdb跟ecma一樣，對新屬性分了不同的進程，具體的進程如下：

1. Stage 0：腦袋風暴階段。高度不穩定，可能會發生變化。
2. Stage 1：實驗階段。也非常不穩定，可能會發生變化，但是該提案已得到W3C成員的認可。
3. Stage 2：承認階段。高度不穩定並且可能會發生變化，但是正在積極研究中。
4. Stage3：擁抱階段。穩定且變化不大，此功能可能會成為標準。
5. Stage4：標準階段。最終的解決方案，所有主流瀏覽器都支持。

這就是postcss-preset-env依賴的實現基準，那麼如果我們想要在我們的代碼裡使用這些Stage，該怎麼做呢？

以我的腳手架ying-template為例，我們來查看在webpack中的實際配置：

首先我們先安裝postcss以及其相應的插件：

npm install postcss postcss-loader postcss-preset-env postcss-nesting --save-dev

然後我們在webpack的config配置module中輸入以下配置：

module: {
 rules: [
 {
 test: /\\.css$/,
 include,
 exclude,
 use: [/* 你其它的loader */ 'postcss-loader']
 }
 ]
}

然後在根目錄新建一個postcss.config.js

const postcssConfig = {
 plugins: {
 precss: {},
 'postcss-preset-env': {
 browsers: 'last 2 versions', // 瀏覽器兼容的版本 

 stage: 3 // 你用的屬性所在的階段
 },
 'postcss-nesting': {} // 這裡就是你所使用的插件
 }
};
module.exports = postcssConfig

這樣就完成了，如果想看完整的配置，可以clone我的腳手架：github.com/KRISACHAN/y…

（這是個多頁面的webpack4腳手架，集成了babel 7，precss 4，typescript3.7，karma以及eslint等現代前端開發所需常用的東西，有興趣的可以去看看。）

我們可以通過preset-env.cssdb.org/playground這個網站來查看具體的編譯結果。

編譯結果圖如下：

閱讀更多 程序員的枯燥生活 的文章

關鍵字: 瀏覽器 HTML 轉自