Sass Guidelines中文版本
有一份規范的指南能協助您更理智的，更好維護和更好擴展Sass。
Sass指南已經翻譯成好幾種語言，感謝這些貢獻者。你可以在控制面板中切換需要的語言。
關于作者
我是Hugo Giraudel，一名即將遷居柏林的法國前端工程師。到目前為止，我已經使用Sass兩年多了，并開發了一些與之相關的項目，比如:SassDoc 和 Sass-Compatibility。
我也寫了幾個關于Sass的庫,主要是想把玩、探究它：SassyJSON、SassyLists、SassySort、 SassyCast、SassyMatrix、 SassyBitwise、SassyIteratorsGenerators、SassyLogger、SassyStrings 和 SassyGradients。
可以通過推ter聯系我。
貢獻
Sass指南是我利用空暇時間維持的一個免費項目。不用多說,相信你也能夠理解，持續更新、編寫文檔和其他相關事宜是一件工作量不小的事情。不過，知道你喜歡這個指南我已經很滿足了。
現在，如果你想要為它做些貢獻，一個很好的建議是：使用社交網絡分享它，也可以在GitHub repository上提交修正錯誤的issue或者pull-request。
在開始之前最后但不是最終的一句話：如果你喜歡這份樣式指南，如果它對你或你的團隊大有裨益，請考慮支持它！
關于Sass
Sass是CSS的一個擴展,它使CSS的使用起來更加優雅和強大。
Sass的終極目標是解決CSS的缺陷。如我們所知，CSS并不是一個完美的語言。CSS雖然簡單易學，卻也能迅速制造嚴重的混淆，尤其是在工程浩大的項目中。
這就是Sass出現的契機，作為一種元語言，通過提供額外的功能和工具可以改善CSS的語法。同時，保留了CSS的原有特性。
Sass存在的關鍵不是將CSS變成一種全功能編程語言，它只是想修復缺陷。正因如此，學習Sass如同學習CSS一樣簡單：它只在CSS的基礎上添加了幾個額外功能。
話雖如此，使用這些功能的方式卻是多種多樣的。有一些是好的，有一些是壞的，還有一些令人費解。這份樣式指南就是為了給你一個統一的和歷經實踐的方式來編寫Sass代碼。
擴展閱讀
Ruby Sass or LibSass
Sass的第一次提交還要追溯到距今八年之久的2006年底——可見它已經走過了一段漫長的道路。最開始是基于Ruby，隨后便各種版本滋生。其中最成功的要屬LibSass（使用C語言編寫），它與Ruby原生版本具有最佳兼容性。
在2014年， Ruby Sass和LibSass團隊決定同步推出下一個版本。從那時起，LibSass開始積極釋放版本以校驗與Ruby Sass的不同，最后剩下的不一致之處被匯總在Sass-Compatibility 項目中。如果你知道兩個版本中尚未被發現的不一致之處，請提交一個issue使更多開發者了解。
回到選擇編譯器的問題上來。實際上，這只取決于你。如果是在一個Ruby on Rails的項目中，最好使用Ruby Sass，它在這種情況下是最合適的。當然你也要知道，在未來Ruby Sass會一直引領LibSass的開發并作為其開發參考。
另一方面，LibSass更關注于自身與項目之間的整合。如果你想在非Ruby項目中使用，比如NodeJS，node-sass 會是個不錯的選擇。使用LibSass最主要的優勢還是因為它的速度，而且比Ruby Sass更快。
擴展閱讀
Sass或SCSS
有一個劇烈的爭論關于Sass名字中的含義，并對此有充足的理由：Sass意味著一個預處理器和它獨有的語法。這樣很不方便，不是嗎？
如你所知，Sass最初定義的語法，其中決定性的特征是縮進敏感。很快，Sass的維護者決定提供一個被稱為SCSS（Sassy CSS）的語法以弱化Sass和CSS之間的差異。
從那時起，Sass（預處理器）開始提供兩種不同的語法：Sass（非全大寫，please），也被稱為縮進語法，和SCSS。使用哪一種語法完全取決于你，兩者在功能上是完全等同的，只是在審美上有所偏頗。
Sass的空白敏感語法通過縮進以擺脫大括號、分號和其他符號，從而實現了簡潔凝練的語法格式。與之相比，SCSS則更容易學習，因為它只是在CSS上添加了一點點額外的功能。
我自己更喜歡SCSS，因為它更接近CSS的原生面貌，對開發者來說具有友好性。因此，樣式指南全文將使用SCSS而不是Sass語法格式來演示。
擴展閱讀
其他預編譯器
忽略其他特性，Sass對自己的定位首先是一個預處理器。其最主要的競爭對手包括LESS，一個基于NodeJS的預處理器，因著名CSS框架Bootstrap的使用而聲名鵲起。此外還有Stylus ，一種對形式無所限制的LESS版本。它是一種無論你想怎么樣使用，大都能順利轉換成CSS的程序語言。
為什么選擇Sass勝過LESS以及其他預處理器？，這始終是一個待解決的問題。就在剛剛，我們還建議在Ruby項目中使用Sass，因為Sass初創于Ruby并且在Ruby on Rails中運行良好。現在隨著LibSass與Sass的逐步接近，上述建議顯然已經不再絕對和必須。
我之所以喜歡Sass源于它最大程度保留了CSS的原生特性。Sass的設計基于非常堅實的設計原則：大部分的設計順其自然的來源于核心設計師們的信條，比如添加額外的功能會增加語言的復雜度，但以實用性衡量極具價值的話便得以保留；同時，使用Sass來美化一個塊級元素，那么美化前后的效果應該是可預見和可推理的。同時，Sass比其他預處理器更加關注細節。據我所知，核心設計者們非常關心Sass與CSS在細節上的一致性，并確保所有的常用方式具有高度一致的表現。
換言之，Sass并不想成為一個通過在編程語言頂層添加特殊功能實現有關用戶邏輯處理的預處理器，以取悅于像我一樣喜歡傻瓜式編程的程序員。它更準確的定位是一款軟件，旨在解決實際問題。通過提供實用功能改善CSS的短板。
預處理器之外，我們還需要提及一下后處理器。得益于postCSS和CSSNext項目，后處理器最近幾個月得到了顯著曝光。后處理器幾乎等同于預處理器，稍有不同的是它并不支持即將發布的CSS語法。
你可以認為預處理器是膩子腳本，用來支持尚未實現的CSS功能。舉例來說，你可能會像CSS 規范中描述的一樣使用變量，然后用預處理器編譯樣式表，在這個過程中后處理器只會找出變量出現的地方并替換成真實值——Sass就是這么做的。
后處理器背后的思維是，一旦瀏覽器支持了新的特性（比如CSS變量），后處理器就不再做這方面處理，而是讓瀏覽器執行相關處理。
雖然在當下提供對未來語法功能的支持是一件很了不起的事情，但我還是喜歡在大多數的工作中使用Sass。當然，在一些情況下我認為后處理器比Sass更適合，比如CSS前綴。稍后我們會講到這個問題。
擴展閱讀
簡介
為什么需要一個樣式指南?
一個樣式指南并不是一份便于閱讀并使代碼處于理想狀態的文檔。它在一個項目的生命周期中是一份關鍵文檔，描述了編寫代碼的方式和采用這樣方式的原因。它可能在小項目中顯得有些矯枉過正，但卻能在保持代碼庫整潔，提高可擴展性和可維護性上提供諸多便利。
不用多說相信你也可以理解，參與項目的開發者越多，代碼樣式指南就越顯的必要。與之相同，項目的規模越大，代碼樣式指南也會越加重要。
Harry Roberts的CSS Guidelines就非常好:
樣式指南（注意不是視覺風格指南）用于團隊是一個很有價值工具：
- 長時間內便于創建和維護項目
- 便于不同能力的和專業的開發使用
- 便于任何時間加入團隊的不同開發人員
- 便于新員工培訓
- 便于開發人員創建代碼庫
免責聲明
首先第一件事是：這不是一份CSS樣式指南。本文檔不會討論諸如約定CSS類名、模塊化開發模式和有關ID的疑惑等CSS范疇內的問題。本文檔中的準則只著眼于處理Sass的專有內容。
此外，這份樣式指南是我獨創的，所以會顯得有些個人主觀傾向。你可以將它看成是我通過多年實踐研究出的方法和建議的集合。這也讓我有機會接觸到少數極具見地的資源，所以一定要瀏覽一下擴展閱讀。
顯然，這里講的肯定不是進行Sass編程的唯一方式，而且它是否符合你的項目要求還有待檢驗。你可以隨意選擇，并使其適應需求。正如我們所說的，具體情況具體分析。
核心原則
最后，如果有一件事是我想從整個樣式指南中傳授的，那就是：Sass以簡為美，簡約至上。
感謝我過去使用Sass時傻傻的嘗試，比如 bitwise operators、iterators and generators 和 a JSON parser，從而認識到了可以用預處理器來做什么。
同時，CSS是一門簡單的語言，那么Sass在書寫常規CSS的時候就不應該更復雜。KISS principle (Keep It Simple Stupid)在這里是一個核心原則，甚至在有些情況下要優先于DRY principle (Don't Repeat Yourself)。
有時候，一點點重復可以更好的保持代碼的可維護性，而不是建立一個頭重腳輕、臃腫復雜、不可維護的系統。
此外，請允許我再一次引用Harry Roberts的觀點，實用勝過完美。有些時候，你可能會發現自己違背了這里所描述的規則。如果感覺自己的方式有道理，感覺很正確，那就繼續做吧。編寫代碼從來都不是一家之言。