《SassforWebDesigners》之为什么要使用Sass

本系列由zEx根据DAN CEDERHOLM的新书《SASS FOR WEB DESIGNERS》所译，整个系列共分四章，整个译文带有我们自己的理解与思想，如果译得不好或有不对之处还请同行朋友指点。如需转载此译文，需注明原作者相关信息。

——作者：DAN CEDERHOLM

——译者：zEx

Sass for Web Designers

前言第二章

我不信任Sass。我从来都是手写样式表的！我不需要额外的工具来帮助我简化工作。我不想要把复杂的事物添加到我的工作流程中，不要来烦我。

无论是以上哪种想法，现实是Sass（和其他的CSS预处理器）可以成为一个强有力的助手，一个任何样式书写者都可以轻松把它插入到每日的工作中去的工具。在使用了Sass一段时间后回过头来看，我很庆幸自己这么做了。

我想要分享我是怎么来使用Sass来提高效率的，比我前10年维护CSS的过程要轻松许多，这就是我想要写这本书的理由。最初，由于我对Sass有一些误解导致了我放弃了它。我担心我要完全改变我书写和管理CSS的方法。有时，CSS也是很脆弱的，作者想要保护他们的作品不被轻易复制是可以理解。我能得到保佑吗？阿门。

现在，我将向你展示Sass在不破坏你的工作进程和工作流程中，让你的工作，生活变得简单轻松的。我将向你展示Sass的各个方面，如何安装，如何使用，如何在现有的项目中帮助提高效率。运气好的话，我可能也让你相信Sass会在你的项目中帮到你。

Sass脚手架（the Sass elevator pitch）

以前在样式表中修改一个颜色，传统的做法是找到并替换这个色值，然后再查找下一个需要替换的地方，如此反复多次才能完成。你希望CSS让你这样做吗？

$brand-color: #fc3;
a{ 
    color: $brand-color;
}
nav{ 
    background: $brand-color;
}

假使你通过修改一处，就可以改变样式表中所有需要修改的相同地方吗？使用Sass吧。

或者你在同一个样式表中的好几个class都公用了一些样式。

p{ 
    margin-bottom: 20px; 
    font-size:14px; 
    line-height: 1.5
}
footer{ 
    margin-bottom: 20px; 
    font-size:14px; 
    line-height: 1.5
}

你不想要复用这些重复的样式代码块吗？同样，使用Sass可以只定义一次，然后当你需要使用他们的时候就使用@include指令添加到当前的class中即可。

mixin default-type{
    margin-bottom: 20px; 
    font-size:14px; 
    line-height: 1.5
}
p{ 
    @include  default-type;
}
footer{ 
    @include default-type;
}

这就是Sass。上面这两个极其简单的例子只能很粗浅的展示Sass如何使得你书写样式变得更快捷，更简单，更灵活。在web设计领域非常欢迎这种辅助工具，因为任何一个做网站的都懂的。。。

CSS is hard

其实要学习CSS并不容易。你需要知道每一个属性，他们是如何通过优先级来实现样式的覆盖（或+重写样式），浏览器的兼容性，选择器等，这并不容易。添加一个复杂的接口已经花费了我们很多的时间，并且维护和等待会花费更多的时间，为什么我们还要这样做呢？有些人只享受最后的结果，这是一个矛盾。

CSS的问题是最初的设计并不是今天我们这样使用的。当然，CSS的不断进步是随着浏览器的飞速发展创新和CSS3及以后技术的实行而实现的。但是我们要实现跨平台兼容所有浏览器还是要依赖hacks技术。例如：float这个属性是被设计成一张图片在文本块中简单的定位的。但是现在所有的标签都可以使用这个属性了。

我们的样式表非常的冗余。颜色，字体，经常使用的样式块等。典型的CSS文件是一个非常线性的文档，这就使得面向对象程序员非常抓狂。（尽管我只有很少的头发，但我不是一个面向对象的开发者。正如你读到的。）

因为更多的标签和web应用变得更粗暴和复杂，我们屈服于CSS的原始设计去做事情而从来不梦想它的改变。我们希望它能更灵活。幸运的是，不远的将来浏览器的开发者们接受了更有效率更强大的属性和选择器这些新的CSS特性，解决了造成今天这些问题的问题。CSS3中的布局类的属性，如border-radius,box-shadow,高级选择器，transitions,transforms,动画等等。现在正是时候。但还是有许多CSS遗漏的。这就需要样式作者去花时间填补这个漏洞要容易许多。

the DRY principle（不要重复你自己）

如果我们关注软件工程这个领域（我不仅仅关注而且还很享受在里面闲逛）,我们可以很快明白建立复杂系统的人们对于如何组织，变量，恒量，局部变量等等这些重要方法是根深蒂固的。

你可能听过不要重复你自己这种说法。在Andy Hunt和Dave Thomas他俩写的《实用程序员》书中给出了DRY的解释：

“每个知识的价值必须在一个体系中是独立的，清晰的，具有代表性的”

这个观点的意思是复制代码会导致开发者开发失败和混淆。共同的想法是，写一次公用的，可重复实用的模块，然后再其他地方调用。这是更有效也更轻松的维护代码的方法。

CSS可以做任何事，除了不能复用。有时CSS充满了重复的规则，声明，和属性值。我们不断的在我们的样式表中书写相同的代码片段只是为了颜色，字体和重复的样式模块。一个善用复用代码的开发者看到一个正统大小的CSS文件，首先感到困惑进而挫败的想哭。

“你怎么维护!@#$这些？！”他们会这样问。

“这可能是一个IE的bug？”你可以用这种自我恶心的方式回答。

所以为什么用CSS干活会这么难？

我们可以从CSS的联合发明者Bert Bos多年前的随笔中收集一些线索来理解CSS的语法限制：

程序员使用CSS这种简短，得力的特性在他们的程序语言中：宏，变量，符号常量，条件语句，变量表达式等等，那是因为它们给骨灰级用户许多便利，但是初级用户会纠结死，或者更有可能这些初级用户会被吓到不敢再接触CSS。这是一个平衡。并且和其他语言相比，CSS更难取得这种高手和初级用户都感觉使用的舒服的平衡点。

CSS的缔造者很关心使用情况，他们希望尽可能多的人来建造站点。他们想要CSS变得更得力，将网站的样式和内容从展示上分割开来，让人们易于理解和使用。我当然也很同意这样做。同时，我们也有工作要做，维护工作变得更复杂，更精细，更富有挑战，并且是不会过时的技术。

幸运的是，有很多选项帮助我们摆脱困境，其中就有Sass。

前言第二章

什么是Sass（what is Sass）

Sass是CSS预处理器-在你书写的样式和.css文件中间的一个层，Sass（Syntactically Awesome Stylesheets的缩写）作为CSS的一个扩展，可以允许你调用重复的代码，来更快，更有效率，更轻松的维护你的CSS。

Sass for Web Designers

.scss文件经过Sass的编译转换成.css的文件。

Sass的站点上有简单的描述Sass是什么：

Sass是在熟练掌握CSS之后演变的一种语言，它可以清晰的在CSS中展示文档结构，比用直接书写CSS要更明确的反映出html的结构。Sass为CSS提供了更简洁，更优雅的语法，并且使用多种特性来辅助创建可维护的样式表。

因此当正常书写的CSS不能允许变量，mixins（可复用的样式块），或其他一些特性的时候，Sass提供了一种语法来做这些，并且不仅仅是这些–相当于为你正常书写CSS开启了一个“超级功能”插件。然后通过命令行程序或web框架的插件按照CSS的语法顺序进行翻译（或编译）。

更特别的是，Sass是CSS3的扩展子集，并且有一个叫SCSS（“Sassy CSS”）的语法，它是CSS3的超集，我们过一会再讨论。这就意味着，任何有效的CSS3文档也就是一个有效的SCSS的文档。这样你就可以慢慢的过渡到Sass了。你可以随你的喜好或多或少的使用Sass的语法标准，这样就不会有一下子转变到使用Sass的痛苦了。也就是说你可以在学习和挖掘更多Sass函数和功能的阶段完成将CSS向SCSS的转换。

再经过一段时间后，你已经可以流畅的使用Sass（不会花费很长时间），真的感觉它就像CSS的自然扩展一样–好像我们希望它完善的功能都实现了。这就是为什么我一旦开始使用Sass，我就再也感觉不到尴尬和费劲了–它只是想CSS所想。一旦你试过使用哪个Sass，你将可能长期坚持用下去。

此外，Sass还会帮助CSS变得更好。通过快速追踪CSS书写者在实际工作中去解决实现某些当前不能使用预处理器的特性和经验。不论以后是否有意义，这些Sass函数可以提供给未来的CSS作为很好的改进参考。

Sass语法（Sass syntax）

实际在Sass里有两种不同的语法规则。在上一小节最后提到的SCSS的语法是使用.scss的文件扩展名。我更喜欢使用这个语法，提倡使用这个语法是因为：

一个简单的SCSS例子

下面有一个如何使用SCSS语法的例子。例子展示了定义一个变量和在CSS中使用这个变量。

$pink: #ea4c89;
p{
    font-size: 12px;
    color: $pink;
}
p strong{
    text-transform: uppercase;
}

经过编译之后呈现出来的是：

p{
    font-size: 12px;
    color: #ea4c89;
}
p strong{
    text-transform: uppercase;
}

上下两段代码除了$pink这个变量，其他的看起来差不多，在这本书的后面我们会更深入的讲解变量。现在你已经知道如何围绕着CSS开展SCSS的书写工作了。正是基于上述原因，我非常喜欢使用SCSS。

SASS的语法结构采用的是缩进式

对比SCSS的语法，Sass的语法格式完全是另外一回事了。有一些人喜欢没有任何修饰，没有大括号或者分号的缩进式语法。如果你习惯使用类似Ruby或者Python这种简洁的开发语言，那么Sass的语法和这些很像，会让你书写起来感觉更行云流水。

下面是一个Sass的语法的例子，编译后的结果和前面SCSS的片段编译后的结果完全一样。

$pink: #ea4c89
p
    font-size: 12px
    color: $pink
p strong
    text-transform: uppercase

去掉了大括号和分号，只在样式的属性键值结构中采用空格和缩进。有些人更倾向于这种保证显示更清爽更简单的语法结构。这种语法会对刚开始书写和清除 多余代码起到加速作用。但对我来说，我仍然倾向于选择和正常书写方式相近的SCSS，理由就是我写起来更得心应手。

在接下来的章节中，我们都会使用SCSS的语法来举例。如果你更喜欢Sass的语法，那么它们之间的转换也很容易。我们钻研的Sass的所有函数都可以应用到任意一种语法中。使用哪种语法，完全看个人喜好。

对于Sass的误解（SASS misconception）

我在之前提到我也是不情愿之下试用的Sass。这在一定程度上要归咎于我之前对于Sass的很多的误解。我需要知道Ruby或者一些高级的命令行的技巧吗？我以后是不是要完全改变我现在书写CSS的方式，这种学习成本大吗？将来css的输出会变得臃肿，可读性变差吗？

感谢上帝，对于这些问题的答案都是“不”，当然，在很多网站上无论什么时候，只要有人提及Sass就会出现上面提到的问题。让我们放下这些顾虑吧。

我害怕使用命令行

我并不是一个使用命令行的高手，只是在这一年多的时间里多多少少的学习了一些，仅够我解决遇到的问题的。我并不害怕跨系统，或者是使用git命令等等。

说实在的，我很同情设计师和前端开发人员，知道他们不想要使用这些。这些人中存在命令行恐惧症。对于Sass，只需要知道很少的命令行语句，实际上你只需要掌握一个单行命令就可以了。此外，有一些应用和web框架会需要知道多一些的命令行命令。（我会在下一个章节进行介绍）。

所以，如果你一直在抗拒使用命令行，那么现在不要让这个障碍阻止你尝试使用Sass！

我不想要改变我写css的方式

对于使用Sass就需要经过痛苦的转变书写CSS方式的过程其实是一种误解。我一直都很严格的按照条理来建立我的样式表文件。大部分代码都需要手工来向文档中添加。但是请记住，因为SCSS语法是CSS3的超集，你不需要改变任何书写CSS的方式。像注释，缩进或不缩进，这些你的书写格式的偏好可以在.SCSS文件中得以保留。一旦我这样做了就没有什么可怕的了。

我不想Sass改变我设计的方式

另一方面，Sass不会解决你所有的问题或帮你改掉不好的习惯。当你使用Sass书写一个效率低下的，臃肿的样式文件，那么编译完等到的也将会是一个效率低下，臃肿的样式文件。合理的组织和周密的思考在使用Sass书写样式时，仍然适用。事实上，有很多实例表明，当我们深入的去研究使用Sass的时候，它会将我们不好的习惯放大，变得更加突出。但是，当我们正确灵活的使用Sass时，它也会在建站时提供给我们大量的便利和帮助。

好的，现在让我们开始愉快的开展Sass的学习吧。我想你将会惊奇的发现Sass居然可以做这些。在下一章节中，我们将建立工作流程–看Sass是如何在你的工作过程中和你配合的，并且还将向你展示如何简单的使用Sass的命令行或者应。让我们开始学习之旅吧！

译者手语：整个翻译依照原文线路进行，并在翻译过程略加了个人对技术的理解。如果翻译有不对之处，还烦请同行朋友指点。谢谢！

出处：

中文出处：http://zciwp.github.io/c1/

w3cplus地址：http://www.w3cplus.com/preprocessor/sass-for-web-designers-chapter-1.html