還不會 PostCSS？你 OUT 啦！

是時候每個人都來了解一下 PostCSS 了 

—— 它是什么；它實際能做什么

一陣子前，我寫過 “見到 PostCSS 很興奮, 但是我害怕離開 Sass”。從那時起，我已經全心全意擁抱了（并且離開了 Sass，至少是暫時性的）。我已經將 PostCSS 用到了大項目上，向其貢獻代碼并寫作了插件，同項目的維護者交流，以了解更多可能有用的信息；而這全都是順順當當的。只是順順當當的。

同時, 圍繞 PostCSS 的議論和態度各種各樣 —— 好奇，興奮，懷疑，困惑，疲倦，痛苦，防御，刻薄，高興，輕率冷漠，不屑一顧，摩拳擦掌，等等等等。

針對這種混亂情況我想要指出兩點：

1. 你不必害怕。外頭現有的處理樣式代碼的工具數量實際上相當少（或者對我而言看起來是如此，因為我也寫點 JavaScript）。有更多的可能性并不會對任何人或任何事有所傷害。

2. 每一個要編寫 CSS 的人都要了解一下 PostCSS 是什么 — 它到底是什么，還有它可以被用來做什么 (不僅僅像一些高調沖動的推文中那樣描述的) — 不管結果是不是你會立刻用上它。因為如果你把 PostCSS 想成是 Sass 和 Less 的簡單替代的話，那你就弄錯了。

針對第一點，我并不知道能做些什么，用安慰的話語、像教練一樣的鼓勵、輕微的刺激或者什么觀點來鼓勵你？在這種情況下我可能不是最好的顧問。

因此我會跳到第二點，在這兒我可能會對你有所幫助。因為已經用過 PostCSS 一段時間，我想我已經對它有所了解，并值得同你們分享一下。

當我們說“PostCSS”時指的是什么

用到“PostCSS”這個詞匯我們也許指的是以下兩種說法的一種：

    1. 存在 PostCSS 的情況下，那么就是指工具本身——當你運行指令 npm install postcss  時你將獲得的——和

    2. 工具強化后的 PostCSS 插件系統。

 這個工具本身是一個能夠將 CSS 解析成抽象語法樹（abstract syntax tree(AST)）的 Node.js 模型；通過“插件”方程的任何元素來傳遞 AST；然后將 AST 反向轉換為一個串，你可以將其輸出為一個文件。對于每一個方程，AST 可能通過轉換進行傳遞，也可能不通過轉換就傳遞；通過追蹤任何一個改變來產生資料圖。

AST 提供一個直接的應用程序編程接口（API）讓開發者能夠使用它開發插件。比方，你可以重復循環每一條設定在文件 css.eachRule() 中的任何規則，或者文件 rule.eachDecl()中的任何聲明。你可以從rule.selector 中獲得規則選擇器，或者從 atRule.name 中獲得每一個“@規則（atRule.name）”的名字。從這幾個例子你就可以看出 PostCSS 的 API 能讓使用 CSS 源代碼的工作變得相當容易（這比你依賴于正則表達式，如 chump，要容易的多準確的多）。

這就是目前 PostCSS 所做的一切：它不會更改你的 CSS。然而插件可能會更改你的 CSS，也可能不會。使用解析過的 CSS 時 PostCSS 可以為你做很多你想要做的事。一個插件可能使變量有效，或者使一些其它的有用的語言擴展有效。另一個插件可能改變你的所有的‘a’變成 'k'。另一個插件可能記錄一個警告只要你使用了ID選擇器。另一個插件可能會添加神秘的 ASCII 碼圖案到你的樣式表的頂部。另一個插件可能會記錄你使用過浮點類型聲明的次數。諸如此類，永遠如此。

PostCSS 可以強化幾乎無限的各種各樣的插件來讀取或操作你的 CSS。這些插件除了能解決問題之外并沒有一個統一的調度。

需要注意的是不管是工具本身還是插件系統，它們都直接與 Sass 和 Less 相類似。然而：捆綁一系列相關的插件使得它能夠將作者友好型的樣式表改換成讀者友好型的 CSS，然后你便有了一個與良好的“處理器”相類似的東西。

但是一定要記住的是這些“插件包”和其它非打包形式的插件一樣，是系統環境的外加成員。任何給定的插件或插件包都不能夠代表"PostCSS"：相反，我們有一個正在發展壯大的包含很多個性化模型（經過 PostCSS 強化后的）的系統環境。

PostCSS 模塊化幾個含義

?試圖保持 PostCSS 是（或應該是）一個與“前處理器”Sass 和 Less 相對的“后處理器”的想法定是被誤導了的。

不管你是怎樣定義“后處理器”和“前處理器”的，一定會有 PostCSS 插件既是”前處理器“也是”后處理器“。依據大多數的定義，Autoprefixer 是一個標志性的"后處理器“；但是也存在著像 postcss-each,這類正是由”前處理器“組成的插件。

也有一些插件壓根就不會轉換你的 CSS，比方像 styleint、postcss-bem-linter 和 list-selectors。

如果你想在自己的構建過程中保持純粹的區別，只有使用 PostCSS 插件才能實現你所想的 “后處理器” — 好吧，真的很好：小心選擇你的插件。

構建在 …

? 試圖把 “PostCSS” 綁定到特定的語法擴展或者轉換是一種誤解

PostCSS 是底層模塊，有助于其他工具的創建；沒有那些高層工具（插件）的限制。

所以 PostCSS 并不再是 “關于” 允許你編寫未來的 CSS（語法和功能規范草案），而是 “關于” 提供循環，條件和其他類似 Sass 的特性。有一些獨立的插件可以同時實現這兩者，或者是一些插件包也可以實現這兩個功能 (cssnext 和 precss)；但是這些都不足以代表 PostCSS。

所有的這些意味著...

? 當人們認為他們是在批評“PostCSS”時，他們可能是在批評一些特定的插件，或插件包，或是特定方式使用的特定插件。

批評很好，但是不要欺騙自己不去理會其他基于 PostCSS 的工具，那樣會讓你以錯誤的方式錯過那些工具。

這就引出了下一個點 …

? 你可以在任何時候選擇或者不選擇任何的 PostCSS 插件。

因為你把它放在那里，每個插件僅僅是你創建過程的一部分。如果一個插件使你不滿意，那就移除它。沒有人會阻止你去移除它。

記住，那些插件可以通過很多種方式被使用，可能你會因為使用這些不同的插件而感到不悅。

可能你就像 Chris Eppstein 那樣不喜歡（postcss 定義的屬性）postcss-define-property，你可以創建新的，看起來真正喜歡的，標準的屬性。同樣地，這也意味著：創建那些看起來不好的，不標準的屬性也很容易。

如果你希望一個插件需要更好的例子或者新的選擇，你可以貢獻你的一份力量，因為……

? 插件是相對較小的模塊，因此人們樂于響應反饋并做出貢獻。

如果你沒有查到你想要的插件，你可以通過這個方式去做你想要的……

?你總是可以構建自己的插件來滿足自己的需求.

這是最重要的一點,重要的事情要說兩遍 ...

?你總是可以構建自己的插件來滿足自己的需求.

這使得 PostCSS 變得新奇和奇妙 — 它的易用性使你可以嘗試一些完全不同的東西。

或者你可以稍微調整里面的東西。如果一些插件使用了你非常喜歡的語法但是功能你很討厭，可以用它好的語法去寫一個衍生插件。如果一些插件提供了你很喜歡的功能但是采用了你痛恨的語法，可以用它好的功能去寫一個衍生插件。當其他人抱怨你寫的插件時，你能做的是建議他們用自己的喜歡的方式去寫自己的插件。

（為了避免聽起來扯淡又浮夸）我得說，對于許多設計師和前端開發工程師來說，學習 PostCSS 應該是對 CSS 處理有許多啟發的。其實所有 Sass 和 Less 提供的函數，其實并不那么有魔力，或者說非得那么做：那只不過是一幫躲在幕后的人，覺著自己又聰明又能干。你沒必要覺著他們比你就強那么多。

通過 PostCSS 來解決問題

在使用 PostCSS 的時候，也提醒了我 CSS 是用來解決問題的。所有的問題都有許多種解決問題的方式。也許我們在選擇解決方式的同時，也被諸多的解決方案所限制，甚至在解決問題的同時又制造了新的問題。

自從得到了 PostCSS 的幫助, 我就以問題出發來處理 CSS 方面的工作需求 —— 跟我如何處理 JavaScript 相似。并不同于在我真正了解發生了什么之前就急著去找大量的庫，首先我會想想實際要解決的問題是什么；然后我會考慮考慮現有的方案；然后我會使用現有方案，或者開始嘗試我自己的方案。

我覺得這個過程是愉快而有樂趣的。

而且，我想它也幫助我簡化了處理 CSS 的方式。記住——盡管看起來很久之前——許多的開發者拒絕采用 Sass 和 Less，因為他們擔心這些”預處理器“并不足以解決實際的問題，來適應他們可能會向其作品中加入的復雜性。我從來沒有真正認同過這種見解（可能因為我從來沒有在意過我的構建過程中那一點點復雜度）；但我確實得承認那些批評和建議中所認為的，如果你并不認為工具能解決問題，那你就必須強迫自己使用那個工具。

我構建過（并且仍在維護著）一個 重要的 Sass 工具庫，因為在我以前的工作中，它為我解決了那些重要的問題，在那些問題中我必須快速地寫出一大堆 CSS。現在我有了一個新的工作，面對同以往不同的一些問題 (例如 可擴展性， 以及一些古怪的，單一化主題的需求）； 而且為了滿足當前的需要，我發現自己更偏好用簡約的方式處理 CSS，涉及到的分析工作至少同處理工作一樣的多。我也想要限制團隊的處置權利，只包含非標準功能特性的選擇。PostCSS，它的工具和生態系統，對我當前的需求而言是一個很好的滿足。

這就夠了

我本準備著寫另外一節叫做“現在，先別忙著歡呼高興，讓我們先解決一些針對 PostCSS 居心不良的吐槽。” 但我想到這篇文章已經足夠長了。而且我也想過精明的讀者自會明白我想要針對這些吐槽進行的辯駁是什么。如果你真的想了解這些東西，可以在 @davidtheclark 發推特給我，我會回復你的。