Rumah >hujung hadapan web >html tutorial >css预处理器和后处理器
因为我是前端刚入门,昨天看了一个大神写的的初级前端需要掌握的知识,然后我就开始一一搜索,下面是我对css预处理器和后处理器的搜索结果,一是和大家分享下这方面的知识,另一方面方便自己以后翻阅。所以感兴趣的可以看下。
转载自"赵雷的博客",原文地址:http://zhaolei.info/2014/01/04/css-preprocessor-and-postprocessor/
说到 CSS 预处理器,大家都很熟悉了,本文的重点是介绍从中抽出的 CSS 后处理器,这也是近一年多以来,前端社区的一些新趋势。
将 CSS 后处理器 抽象出来之后,会对 CSS 的 开发模式 带来一些变化,下面从概念开始说起。
广义上说,目标格式为 CSS 的 预处理器 是 CSS 预处理器,但本文 特指 以最终生成 CSS 为目的的 领域特定语言。Sass
、LESS
、Stylus
是目前最主流的 CSS 预处理器。
下面以 LESS
为例:
LESS
1
2
3
4
5
6
7
|
.opacity(@opacity: 100) {
opacity: @opacity / 100;
filter: ~"alpha(opacity=@{opacity})";
}
.sidebar {
.opacity(50);
}
|
将以上 DSL 源代码 (LESS
),编译成 CSS:
1
2
3
4
|
.sidebar {
opacity: 0.5;
filter: alpha(opacity=50);
}
|
可以看到,编译前 与 编译后 是完全不同的语言。
现实中的 CSS 预处理器 更复杂一点儿,因为大多功能要同时支持 特有 DSL 与 原生 CSS,一件事情要同时考虑两种情况下的处理。
CSS 后处理器 是对 CSS 进行处理,并最终生成 CSS 的 预处理器,它属于广义上的 CSS 预处理器。
我们很久以前就在用 CSS 后处理器 了,最典型的例子是 CSS 压缩工具(如 clean-css
),只不过以前没单独拿出来说过。
还有最近比较火的 Autoprefixer
,以 Can I Use 上的 浏览器支持数据 为基础,自动处理兼容性问题。
以 Autoprefixer
为例:
1
2
3
4
5
6
|
.container {
display: flex;
}
.item {
flex: 1;
}
|
将以上 标准 CSS,编译为处理了兼容性的 生产环境 CSS:
1
2
3
4
5
6
7
8
9
10
11
12
|
.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
插件体验一下。
原来的开发模式是这样的:
<code><span class="input"><span class="prompt">DSL 源代码 -> 生产环境 <span class="constant">CSS </span></span></span></code>
与原来相比,新的 开发模式 最大的变化是面向 标准 CSS 编程,将 兼容性、优化 部分交给 CSS 后处理器 自动完成:
<code><span class="input"><span class="prompt">DSL 源代码 -> 标准 <span class="constant">CSS -> 生产环境 <span class="constant">CSS </span></span></span></span></code>
等到众多 CSS 未来标准 在 CSS 后处理器 层面实现之后,部分项目甚至可以回归到使用 标准 CSS 编程的模式:
<code><span class="input"><span class="prompt">标准 CSS(包含未来标准的后处理器实现)-> 生产环境 <span class="constant">CSS </span></span></span></code>
以下有一些简单对比:
对比项 | 预处理器 | 后处理器 | 两者同时使用 |
---|---|---|---|
语言学习成本 | DSL | CSS √ | DSL |
目标输出结果 | 生产环境 CSS | 标准 CSS √ | 标准 CSS √ |
兼容性处理耦合度 | 高,依赖 DSL 框架 | 低,依赖后处理器 √ | 低,依赖后处理器 √ |
可编程性 | 高,语言级逻辑处理 √ | 中,扩展 CSS 语法 | 高,语言级逻辑处理 √ |
现在我推荐 CSS 预处理器 与 CSS 后处理器 同时使用,各自做他们最擅长的部分。
我当回神棍,预计以后会有这样的趋势:
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
的特点:
Rework
还很年轻,还需要更多的时间积累。
PostCSS
是一个 CSS 后处理器 框架,允许你通过 JavaScript 对 CSS 进行修改。
它的第一个版本发布于 2013 年 11 月,是从 Autoprefixer
项目中抽象出的框架。
PostCSS
有以下特点:
Rework
非常相似,但提供了 更高级的 API,更易扩展Rework
更年轻,还只有 Autoprefixer
一个成功案例其实 Autoprefixer
最初是基于 Rework
做的,但后来作者有更多需求(上面的列表),就造了 PostCSS
这个轮子。
CSS 后处理器 的出现让 CSS 工作流 更清晰,但现在他们还远未成熟,还有很多地方能够做的更好。
比如 Autoprefixer
只做语法 Prefix 层面的兼容,还需要一些专门处理如 IE 滤镜兼容 这些问题的小模块配合使用。
比如可以针对 CSS 中单独使用的 图片 自动做 CSS Sprites 归类与合并 的工作。
比如可以根据项目对 图标字体 字形的实际使用情况自动对字体进行 体积优化。
当每个模块都专注于特定的问题时,那他多数情况下要比一个大而全的集中式框架更靠谱。
或许你也可以考虑基于 Rework
或 PostCSS
写个 CSS 后处理器 玩玩?