還不會 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 發推特給我，我會回覆你的。