原文链接：http://hlee.iteye.com/blog/1236971
Asset Pipeline 提供了内建直接使用 Sass 撰写 CSS 的功能。
你也许会生出这样的疑惑：什么是 Sass？ Why should I care?
Sass (Syntactically Awesome Stylesheets) 原先是内建在 Haml 中的一个副功能。
利用缩排设计避免製造难以 debug 的 syntax error
Haml
要谈 Sass，就不得不先来谈 Haml 这个 project。 Haml 全名为 HTML Abstract Markup Language，它是提供网页设计师撰写 HTML 的另外一条途径。
透过 Haml，你可以很快的使用它的 syntax 写出结构稳固的 HTML。
网页设计师经常有一个烦恼：在撰写 HTML 时要是忘记关一个 TAG，在浏览器中整个版面可能就会大爆炸，而这样的 Bug 却是很难被抓出来的。
Haml 主要就是让开发者，能够使用缩排的方式撰写 HTML，轻鬆做到永不忘记关 Tag 的效果。以下是 Haml 范例：
- %h1= "Hello World"
产生出来的 HTML 就会长这样
- <h1>Hello World</h1>
而
- %ul{:id => "list", :class => "menu"}
- %li= "Item 1"
- %li= "Item 2"
- %li= "Item 3"
会产生出来这样的 HTML
- <ul id="list" class="menu">
- <li>Item 1</li>
- <li>Item 2</li>
- <li>Item 3</li>
- </ul>
使用 Haml 撰写 HTML 的好处
Haml 是需要使用缩排撰写，再行 compile 的 markup language。它可以让你：
阻绝撰写出错误结构的 HTML TAG 的机会
只要 syntax 一错误，编译就无法成功。利用这样的特性，很容易阻绝写出会在浏览器因为 TAG 结构错误而难以 debug 出的 HTML。
轻鬆调整排版
在网页设计开发阶段，若要大幅调整 HTML 结构，对网页设计师也是很伤脑筋的一件事。因为大幅的搬动 HTML，通常有时候会造成：「少剪到一个 TAG」或 「改了开头 TAG ，却忘了改关闭 TAG 」的憾事。
在 Haml 中，这些状况都不会发生。因为 Haml 本身就属于「块状结构」、「自我 close」。因此不论怎样搬动和调整，只要符合缩排，几乎都不会爆炸。
使用 Haml 撰写 HTML 的坏处
如此 powerful 的 markup language 为何没有风行？反倒是原先属于副功能的 Sass 大红特红。
原因就在于 Haml 的特性：不只需要被机器 compile，它也需要被人脑 compile。
HTML 本身就是一门相当直观的 markup language。
在撰写 Haml 时，排版虽然相当轻鬆。但接手维护 Haml 版面的人，却通常痛苦不堪。因为「非常不直观」。
这也是 Haml 的反对者，批评最力的地方。
多数人无法接受维护不直观的「任何东西」，加上撰写 Haml 需要另外学习特殊的 syntax。没有压倒性的好处，一般人是不会贸然进行技术投资的。这也是为什么 Haml 始终处是小众技术的主要原因。
Sass / SCSS
拉回来谈 Sass，Sass 原先是附属在 Haml 裡面的一个副功能。这也是 sass-convert 这个指令必须要安装 haml 这个 gem 才能使用的原因。
Sass 的原理，是让开发者可以透过「缩排」的方式去撰写维护 CSS，同样可以避免忘记关 TAG 而大爆炸的糗事。
而因为 CSS 的结构特性，造成了 Sass 与 Haml 截然不同的命运。多数人反对 Haml，是因为 Haml 反而造成了 HTML 在阅读上的不直观。
而 Sass 的语法
- .content
- margin: 2em 0
- h1
- font-size: 2em
产生出
- .content{
- margin: 2em 0;
- }
- .content h1{
- font-size: 2em;
- }
反倒让 CSS 的维护变得直观了。
接触 Sass / SCSS 后的不少开发者甚至认为，缩排 block 的撰写方式才是 CSS 在被发明时应该被设计出来的样子。
现在撰写 CSS 的方式，有一个绝大缺点：只要在结构上涉及巢状或多个 class，维护者就必须複製贴上 style。不少人认为这真是愚蠢至极且烦人透顶的设计。
内建 Killer features 让维护 CSS 变得更简单
Sass 也提供了其他便利功能，如变数、函数、数学、继承、mixin …等等功能。
在进行网页 protyping 时，更改全站配色或者是直接提供两个以上的设计，对设计师来说是家常便饭的事。
但更改全站配色却是相当麻烦的一件事，因为「寻找 + 全数取代」，并不能保证最后会有正确的结果。很有可能：你更改了所有 CSS 中涉及连结的颜色，却发现在全数取代的过程中，不小心也改到边框的颜色。
若能使用变数去指定特定 style 的颜色，该有多好。
变数 ( Variables )
- $border-color: #3bbfce
- $link-color: #3bbfcf
- .content
- border-color: $border-color
- a
- color: $link-color
CSS
- .content{ border-color: #3bbfce; }
- .content a{color: #3bbfcf; }
数学
在调整区块宽度时，你也希望：每次调整宽度时，可不可以不要每次都按计算机，再全数手动修改…
- .content
- (500px/2);
- .content{ 250px; }
内建函式
在调整颜色亮度时，你希望可否无需再开调色盘，直接改 CSS 就让 style 暗一点？
- $color = darken(#800, 20%)
- .content
- $color
- .content{ #200; }
这都还只是 Sass 所提供的当中一小部分基础功能而已，却足以让网页设计师惊艳十足了。加上撰写维护时十分直观，这也难怪为何 Sass 只是 Haml 中的副功能，后继的声势浪头却远高于 Haml 本身。
SCSS
那 SCSS 又与 Sass 有什么差别，他们看起来好像是类似的东西？
是这样的，Sass 原先使用的缩排，对于网页设计师来说，还是相当不直观。而且实务上也不能直接将旧有的 CSS 直接贴进 Sass 中。其实还是存在一定的不方便度。也因此 Sass 进行了进化，改良了 syntax，而 Sass 3 后来就被称为 SCSS ( Sassy CSS)。
它的 syntax 与 CSS 原有的 syntax 完全 compatible，使用了 { } 去取代原先的缩排方式。
比如说原有的
- .content
- margin: 2em 0
- h1
- font-size: 2em
在 SCSS 中变成了
- .content{
- margin: 2em 0;
- h1 {font-size: 2em }
- }
在撰写上，更加无比的直观，同时也能将旧有的 CSS 直接贴进去，完全没问题！SCSS 更新增了不少关于 CSS3 的 feature 函式。
就拿我最爱的背景渐变色来说好了，原先要做渐变色，CSS 必须要这样写：
- #linear-gradient {
- background-image: -webkit-gradient(linear, 0% 0%, 100% 100%, color-stop(0%, #ffffff), color-stop(100%, #dddddd));
- background-image: -webkit-linear-gradient(left top, #ffffff, #dddddd);
- background-image: -moz-linear-gradient(left top, #ffffff, #dddddd);
- background-image: -o-linear-gradient(left top, #ffffff, #dddddd);
- background-image: -ms-linear-gradient(left top, #ffffff, #dddddd);
- background-image: linear-gradient(left top, #ffffff, #dddddd);
- }
因为你必须支援所有的 Browser。
但在 SCSS 中，一行就搞定了！
- #linear-gradient { @include background-image(linear-gradient(left top, white, #dddddd)); }
小结
为什么 Rails 3.1 鼓励推行 Sass？因为 Sass / SCSS 实在可以大幅节省 网页设计师 / 开发者维护网站程式的功夫。
而在这章中，其实我还没讲到 Rails 3.1 真正整合 Sass 的重点：「Compass」。「Compass」是一套 SCSS 的 Framework。它才是最强大的工具。images