浅谈css预处理器与 CSS 后处理器

　　说到 CSS 预处理器，大家都很熟悉了，本文的重点是介绍从中抽出的 CSS 后处理器，这也是近一年多以来，前端社区的一些新趋势。

　　将 CSS 后处理器 抽象出来之后，会对 CSS 的 开发模式 带来一些变化，下面从概念开始说起。

　　CSS 预处理器

　　广义上说，目标格式为 CSS 的 预处理器 是 CSS 预处理器，但本文 特指 以最终生成 CSS 为目的的 领域特定语言。

　　Sass、LESS、Stylus 是目前最主流的 CSS 预处理器。

　　示例

　　下面以 LESS 为例：

　　LESS

　　.opacity(@opacity: 100) {

　　opacity: @opacity / 100;

　　filter: ~"alpha(opacity=@{opacity})";

　　}

　　.sidebar {

　　.opacity(50);

　　}

　　将以上 DSL 源代码 (LESS)，编译成 CSS：

　　.sidebar {

　　opacity: 0.5;

　　filter: alpha(opacity=50);

　　}

　　可以看到，编译前 与 编译后 是完全不同的语言。

　　实现原理

　　取到 DSL 源代码 的 分析树

　　将含有 动态生成 相关节点的 分析树 转换为 静态分析树

　　将 静态分析树 转换为 CSS 的 静态分析树

　　将 CSS 的 静态分析树 转换为 CSS 代码

　　现实中的 CSS 预处理器 更复杂一点儿，因为大多功能要同时支持 特有 DSL 与 原生 CSS，一件事情要同时考虑两种情况下的处理。

　　优缺点

　　优点：语言级逻辑处理，动态特性，改善项目结构

　　缺点：采用特殊语法，框架耦合度高，复杂度高

　　CSS 后处理器

　　CSS 后处理器 是对 CSS 进行处理，并最终生成 CSS 的 预处理器，它属于广义上的 CSS 预处理器。

　　我们很久以前就在用 CSS 后处理器 了，最典型的例子是 CSS 压缩工具（如 clean-css），只不过以前没单独拿出来说过。

　　还有最近比较火的 Autoprefixer，以 Can I Use 上的 浏览器支持数据 为基础，自动处理兼容性问题。

　　示例

　　以 Autoprefixer 为例：

　　.container {

　　display: flex;

　　}

　　.item {

　　flex: 1;

　　}

　　将以上 标准 CSS，编译为处理了兼容性的 生产环境 CSS：

　　.container {

　　display: -webkit-box;

　　display: -webkit-flex;

　　display: -ms-flexbox;

　　display: flex;

　　}

　　.item {

　　-webkit-box-flex: 1;

　　-webkit-flex: 1;

　　-ms-flex: 1;

　　flex: 1;

　　}

　　可以看到，编译前 与 编译后 的代码都是 CSS。

　　如果你使用 Sublime Text，可以通过 Package Control 安装 Autoprefixer 插件体验一下。

　　实现原理

　　将 源代码 做为 CSS 解析，获得 分析树

　　对 CSS 的 分析树 进行 后处理

　　将 CSS 的 分析树 转换为 CSS 代码

　　优缺点

　　优点：使用 CSS 语法，容易进行模块化，贴近 CSS 的未来标准

　　缺点：逻辑处理能力有限

　　开发模式的变化

　　原来的开发模式是这样的：

　　DSL 源代码 -> 生产环境 CSS

　　与原来相比，新的 开发模式 最大的变化是面向 标准 CSS 编程，将 兼容性、优化 部分交给 CSS 后处理器 自动完成：

　　DSL 源代码 -> 标准 CSS -> 生产环境 CSS

　　等到众多 CSS 未来标准 在 CSS 后处理器 层面实现之后，部分项目甚至可以回归到使用 标准 CSS 编程的模式：

　　标准 CSS（包含未来标准的后处理器实现）-> 生产环境 CSS

　　以下有一些简单对比：

　　对比项 预处理器 后处理器 两者同时使用

　　语言学习成本 DSL CSS √ DSL

　　目标输出结果 生产环境 CSS 标准 CSS √ 标准 CSS √

　　兼容性处理耦合度 高，依赖 DSL 框架 低，依赖后处理器 √ 低，依赖后处理器 √

　　可编程性 高，语言级逻辑处理 √ 中，扩展 CSS 语法 高，语言级逻辑处理 √

　　现在我推荐 CSS 预处理器 与 CSS 后处理器 同时使用，各自做他们最擅长的部分。

　　预计以后会有这样的趋势：

　　越来越多专注于 单一功能 的小型 CSS 工具库

　　CSS 样式库 从 整体方案 到 模块化组合方案 转变

　　部分 CSS 未来标准 在 CSS 预处理器 中得到支持

　　原生 CSS 和 CSS 后处理器 的组合成为新选择

　　优秀的 CSS 后处理器框架

　　Rework

　　Rework 是一个 高效、简单、易扩展 并且 模块化 的 CSS预处理器。

　　它在 2012 年 9 月才发布了第一个版本，是 Stylus 的作者 TJ Holowaychuk 大神挖的新坑。

　　实际上，他采用的是 CSS 后处理器 的模型，在其之上有一个模仿 Stylus 风格缩进嵌套的工具 styl，其 CSS 预处理器 部分功能是在 Rework 开始工作之前通过 css-whitespace 实现的。

　　有一些基于 Rework 的样式库，参考了 CSS 标准草案 或 CSS 标准提案，相当于支持了 CSS 的未来标准，如 rework-vars、rework-font-variant、rework-calc、rework-color-function 等。

　　是不是听起来有点晕？这正说明它的买手游平台模块化做的非常好，你可以按照实际需要，组合 CSS 框架，比如 Myth。

　　概括一下 Rework 的特点：

　　javascript 中直接操作 CSS 解析对象，扩展方便

　　可以 *组合模块，按需定制 CSS 工具库

　　CSS 后处理器 的模型决定它的模块倾向 CSS 未来标准

　　除 服务器 端外，也支持在 浏览器 环境运行

　　Rework 还很年轻，还需要更多的时间积累。

　　PostCSS

　　PostCSS 是一个 CSS 后处理器 框架，允许你通过 JavaScript 对 CSS 进行修改。

　　它的第一个版本发布于 2013 年 11 月，是从 Autoprefixer 项目中抽象出的框架。

　　PostCSS 有以下特点：

　　它和 Rework 非常相似，但提供了 更高级的 API，更易扩展

　　它可以在现有 Source Map 的基础上生成新的 Source Map

　　在 原有 CSS 格式 的保留方面做的更好，便于开发 编辑器插件

　　比 Rework 更年轻，还只有 Autoprefixer 一个成功案例

　　其实 Autoprefixer 最初是基于 Rework 做的，但后来作者有更多需求（上面的列表），就造了 PostCSS 这个*。

　　最后

　　CSS 后处理器 的出现让 CSS 工作流 更清晰，但现在他们还远未成熟，还有很多地方能够做的更好。

　　比如 Autoprefixer 只做语法 Prefix 层面的兼容，还需要一些专门处理如 IE 滤镜兼容 这些问题的小模块配合使用。

　　比如可以针对 CSS 中单独使用的 图片 自动做 CSS Sprites 归类与合并 的工作。

　　比如可以根据项目对 图标字体 字形的实际使用情况自动对字体进行 体积优化。

　　当每个模块都专注于特定的问题时，那他多数情况下要比一个大而全的集中式框架更靠谱。

　　或许你也可以考虑基于 Rework 或 PostCSS 写个 CSS 后处理器 玩玩？

　　文章地址：peixun.qietu

　　文/丁向明

　　做一个有博客的web前端自媒体人，专注web前端开发，关注用户体验，加我qq/微信交流：6135833

　　dingxiangming