翻译于 2015/08/04 08:42
1 人 顶 此译文
It's Time for Everyone to Learn About PostCSS
—— What It Really Is; What It Really Does
A while ago, I wrote “I’m Excited About PostCSS, But I’m Scared to Leave Sass”. Since then, I have wholeheartedly embraced PostCSS (and left Sass, at least temporarily). I’ve been using PostCSS on large-scale projects, contributing to and authoring plugins, communicating with the maintainers to learn more about what’s possible; and that’s all gone swimmingly. Just swimmingly.
Meanwhile, the buzz around PostCSS has increased, provoking all kinds of reactions — curiosity, excitement, suspicion, confusion, weariness, bitterness, defensiveness, vitriol, exhiliration, flippant indifference, smug disdain, cheerful fist-pumping, and so on.
是时候每个人都来了解一下 PostCSS 了
一阵子前，我写过 “见到 PostCSS 很兴奋, 但是我害怕离开 Sass”。从那时起，我已经全心全意拥抱了（并且离开了 Sass，至少是暂时性的）。我已经将 PostCSS 用到了大项目上，向其贡献代码并写作了插件，同项目的维护者交流，以了解更多可能有用的信息；而这全都是顺顺当当的。只是顺顺当当的。
同时, 围绕 PostCSS 的议论和态度各种各样 —— 好奇，兴奋，怀疑，困惑，疲倦，痛苦，防御，刻薄，高兴，轻率冷漠，不屑一顾，摩拳擦掌，等等等等。
I have two points I’d like to contribute to the fuss:
Everybody who writes CSS should learn what PostCSS is — what it really is, and what it can be used for (not just what some choleric, reactive Tweeter said about it) — whether or not you end up using it right now. Because if you think PostCSS is simply an alternative to Sass and Less, you’re misinformed.
I don’t know what I can do to encourage #1 … Some blend of comforting words, coach-like encouragement, gentle prodding, and perspective? I’m probably not the best counselor in this case.
So I’ll skip to #2, where I may be able to help. Having worked with PostCSS for a little while now, I think I’ve learned some things about it that are worth sharing.
每一个要编写 CSS 的人都要了解一下 PostCSS 是什么 — 它到底是什么，还有它可以被用来做什么 (不仅仅像一些高调冲动的推文中那样描述的) — 不管结果是不是你会立刻用上它。因为如果你把 PostCSS 想成是 Sass 和 Less 的简单替代的话，那你就弄错了。
因此我会跳到第二点，在这儿我可能会对你有所帮助。因为已经用过 PostCSS 一段时间，我想我已经对它有所了解，并值得同你们分享一下。
With the word “PostCSS” we might alternately refer to two things:
There is PostCSS, the tool itself — what you get when you run
npm install postcss — and
The PostCSS plugin ecosystem powered by that tool.
The tool itself is a Node.js module that parses CSS into an abstract syntax tree (AST); passes that AST through any number of “plugin” functions; and then converts that AST back into a string, which you can output to a file. Each function the AST passes through may or may not transform it; sourcemaps will be generated to keep track of any changes.
provides a straightforward API that developers can use to write
plugins. For example, you can cycle through each rule set in a file with
css.eachRule(), or each declaration in a rule with
rule.eachDecl(). You can get the selector of a rule with
rule.selector, or the name of an at-rule with
atRule.name. From these few examples you can see that the PostCSS API makes it pretty easy to work with CSS source code (much easier and more accurately than if you were to rely on regular expressions, like a chump).
1. 存在 PostCSS 的情况下，那么就是指工具本身——当你运行指令
npm install postcss 时你将获得的——和
2. 工具强化后的 PostCSS 插件系统。
这个工具本身是一个能够将 CSS 解析成抽象语法树（abstract syntax tree(AST)）的 Node.js 模型；通过“插件”方程的任何元素来传递 AST；然后将 AST 反向转换为一个串，你可以将其输出为一个文件。对于每一个方程，AST 可能通过转换进行传递，也可能不通过转换就传递；通过追踪任何一个改变来产生资料图。
atRule.name）”的名字。从这几个例子你就可以看出 PostCSS 的 API 能让使用 CSS 源代码的工作变得相当容易（这比你依赖于正则表达式，如 chump，要容易的多准确的多）。
That’s all that PostCSS currently does: it does not alter your CSS. A plugin might do that. Or maybe it won’t. PostCSS plugins can do pretty much whatever they want with the parsed CSS. One plugin could enable variables, or some other useful language extension. Another could change all of your
Another could log a warning whenever you use an ID selector. Another
could add Masonic ASCII art to the top of your stylesheets. Another
could count all the times you use
float declarations. And so on, forever.
PostCSS can power an unlimited variety of plugins that read and manipulate your CSS. These plugins have no unifying agenda, except to solve problems.
Note that neither the tool itself nor the plugin ecosystem are direct analogues to Sass and Less. However: bundle up a set of related plugins that transform author-friendly stylesheets into browser-friendly CSS, and then you have something analogous to the good ol’ “preprocessors.”
这就是目前 PostCSS 所做的一切：它不会更改你的 CSS。然而插件可能会更改你的 CSS，也可能不会。使用解析过的 CSS 时 PostCSS 可以为你做很多你想要做的事。一个插件可能使变量有效，或者使一些其它的有用的语言扩展有效。另一个插件可能改变你的所有的‘a’变成 'k'。另一个插件可能记录一个警告只要你使用了ID选择器。另一个插件可能会添加神秘的 ASCII 码图案到你的样式表的顶部。另一个插件可能会记录你使用过浮点类型声明的次数。诸如此类，永远如此。
PostCSS 可以强化几乎无限的各种各样的插件来读取或操作你的 CSS。这些插件除了能解决问题之外并没有一个统一的调度。
需要注意的是不管是工具本身还是插件系统，它们都直接与 Sass 和 Less 相类似。然而：捆绑一系列相关的插件使得它能够将作者友好型的样式表改换成读者友好型的 CSS，然后你便有了一个与良好的“处理器”相类似的东西。
Buuuut keep in mind that these “plugin packs” are just additional members of the ecosystem, like all the non-packaged plugins. No given plugin or plugin pack is or represents “PostCSS”: instead, we have a growing ecosystem that consists of many individual modules (powered by PostCSS).
☞ Attempts to maintain that PostCSS is (or should be) a “postprocessor”, as opposed to the “preprocessors” Sass and Less, are misguided.
your definitions of “postprocessor” and “preprocessor”, there will be
PostCSS plugins that fall into both camps. According to most
definitions, Autoprefixer is the iconic “postprocessor”; but there’s also stuff like
postcss-each, which is very “preprocessor”-y.
但是一定要记住的是这些“插件包”和其它非打包形式的插件一样，是系统环境的外加成员。任何给定的插件或插件包都不能够代表"PostCSS"：相反，我们有一个正在发展壮大的包含很多个性化模型（经过 PostCSS 强化后的）的系统环境。
☞试图保持 PostCSS 是（或应该是）一个与“前处理器”Sass 和 Less 相对的“后处理器”的想法定是被误导了的。
If you want to maintain some pure distinction in your own build process, only using PostCSS plugins for what you think of as “postprocessing” — well that’s just fine: select your plugins with care.
Building on that …
☞ Attempts to tie “PostCSS” to specific syntax extensions or transformations are misguided.
PostCSS is a low-level module that facilitates the creation of other tools; and there are no limits on what those higher-level tools (the plugins) might do.
So PostCSS is not “about” allowing you write CSS Of The Future (syntax and functions from spec drafts) any more that it is “about” providing loops and conditionals and other Sass-like features. There are individual plugins that do both, and plugin packs that do both (cssnext and precss); but none of these represents the extent of PostCSS.
All this means that …
如果你想在自己的构建过程中保持纯粹的区别，只有使用 PostCSS 插件才能实现你所想的 “后处理器” — 好吧，真的很好：小心选择你的插件。
☞ 试图把 “PostCSS” 绑定到特定的语法扩展或者转换是一种误解
When people think they are criticizing “PostCSS,” they are probably
criticizing some particular plugin, or plugin pack, or particular way to
use a particular plugin.
Which is fine — criticize away — but don’t trick yourself into dismissing other PostCSS-based tools because one of them rubs you the wrong way.
Which leads to the next point …
☞ You can opt into or out of any PostCSS plugin at any time.
Each plugin is only part of your build process because you put it there. If a plugin displeases you, remove it. Nobody is going to stop you.
Keep in mind, though, that some plugins can be used in a variety of ways, and maybe your displeasure can be appeased by using the plugin differently.
Maybe you, like Chris Eppstein, don’t like that with
you can create new properties that look exactly like real, standard
properties. Well, there’s a very simple solution for that: make new
properties that don’t look exactly like real, standard properties.
And if you think a plugin needs better examples or new options, you can contribute, because …
☞ Plugins are relatively small modules, so they should be responsive to feedback and easy to contribute to.
And if you don’t see a plugin that does what you want, the way you want to do it …
☞ You can always build your own plugin to satisfy your own desires.
This is one of the most important points. It’s worth repeating …
☞ You can always build your own plugin to satisfy your own desires.
That makes PostCSS new and fantastic — the ease with which you can try something totally different.
Or you can slightly tweak what’s there. If some plugin uses syntax you like but functionality you hate, create a spin-off with the “right” functionality. If some other plugin provides functionality you love but syntax you abhor, create a spin-off with the “right” syntax. And when people see what you’ve wrought and complain about your plugin, you can always suggest they write their own, their way.
(At the risk of sounding ridiculous and grandiose …) I’d suggest that, for many designers and frontend developers, really learning about PostCSS should demystify the realm of CSS processing. All that functionality that Sass and Less provide — it’s not magic: it doesn’t have
to be that way: those are just people behind the curtain, and though
they may be smart and hard-working, you don’t have to assume that they
know better than you what’s best for your situation.
Working with PostCSS has reminded me that CSS processing exists to solve problems; that pretty much all problems have multiple solutions; and that I might be qualified to pick between alternative solutions, or even construct my own.
（为了避免听起来扯淡又浮夸）我得说，对于许多设计师和前端开发工程师来说，学习 PostCSS 应该是对 CSS 处理有许多启发的。其实所有 Sass 和 Less 提供的函数，其实并不那么有魔力，或者说非得那么做：那只不过是一帮躲在幕后的人，觉着自己又聪明又能干。你没必要觉着他们比你就强那么多。
在使用 PostCSS 的时候，也提醒了我 CSS 是用来解决问题的。所有的问题都有许多种解决问题的方式。也许我们在选择解决方式的同时，也被诸多的解决方案所限制，甚至在解决问题的同时又制造了新的问题。