[转载]SCSS 和 SASS 和 HAML 和CoffeeScript
原文链接: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
- width: (500px/2);
- .content{ width: 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