为什么要使用Sass

发表于 分类于 阅读次数： Waline：

本文由 若强 根据 DAN CEDERHOLM 的《Why Sass?》所译，整个译文带有我们自己的理解与思想，如果译得不好或不对之处还请同行朋友指点。如需转载此译文，需注明英文出处：http://alistapart.com/article/why-sass，以及作者相关信息

——作者：DAN CEDERHOLM ——译者：若强

小提示：我们很高兴为你提供一个摘录，它是由 Dan Cederholm 写的一本叫做 Sass For Web Designers 的书。你可以快速在一个叫 A Book Apart 的书城找到它们。

我 Sass 对略微有点抵触，我更喜欢直接写 css 样式！我不需要使用它！此外，我确实不想给我的工作流程中增加额外的复杂的部分，因此我选择远离它。

这就我们的常规想法，但是 Sass（以及其他 css 预处理程序）确实是一个强大的工具，它可以让任何形式的样式都能够方便的引入开发工作中去。虽然他会花费我一些时间去熟悉、适应，但是我依然很乐于这样做。

这就是我打算写本小篇幅的书来介绍它的原因。为了分享一下，在过去的十年中，当我在维护的过程中我是多么愉快的编写 css 的，并且同时是怎样提高效率的。曾经我也困惑过：Sass 会不会令我不敢去尝试怎么使用它。最初，我担心我得完全改变我编写和管理样式表的方式。CSS 有时是脆弱的，这是可以理解的，原因是其编写者或多或少出于对它的保护导致的。Can I get an amen?

现在，让我来向您展示如何让 Sass 不干扰你的工作流程，以及如何让您的工作更便利。下面，我将演示 Sass 的各个方面：怎样安装，怎样使用以及在项目中怎样提供给我们最大的帮助。但愿你将也会想我一样深深的爱上它的。

Sass 逐步解说

是否需要每一处都要改变，比方说，你的样式表里需要换一套颜色，你必须要找到好几处地方，并且替换好几次颜色属性值。那么你希望这样处理 css 吗？

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

如果你能够在只改变某一处的属性值，其他地方的属性也会随之相应改变？那么你可以使用 sass！

或者是在整个样式表里，重复的风格在不同地点使用呢?

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

岂不是很神奇?把那些共用的东西，规划成一个可重用块，只需要定义一次，然后引用到你需要的地方即可。

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

这也是 Sass 可以做到的，这两个非常简单的、几乎只是涉及点 Sass 皮毛的例子，向您展示了使用 Sass 编写的样式，是怎样把 css 样式写得如何更快，更容易，更灵活。这是在网页设计的世界里，一个非常受欢迎的助手。因为创建过一个网站的人都知道这样将会带来怎样的好处的…。

学习 Css 的困难之处

真的面对它时，你会发现学习 css 也不是一件很容易的事。你要了解每个属性的作用、当他们层叠在一起时又是怎么工作的、在不同浏览器下支持什么属性与标签以及会出现一些怎样的怪异现象等等。这确实是一件不容易的事啊！再加上对一些复杂模块的反复维护，我们有必要这样做吗?可是很奇怪的是，居然有人还会当做一种享受 (脑袋被门挤了吧……).

还有一个问题在于，CSS 最初设计出来不是为了做我们今天做所做的这些事情的。由于浏览器的不断创新和 CSS3 的出现，极大的促进了 css 的发展的，并完全超出了其被设计出来的初衷（据说 css 被设计出来之初主要是用来布局的）。但是，现在我们依然需要依赖一些特殊技术来实现我们的目的，比如 css hacks 就是其中的一种。再比如，我们想通过 float 属性来实现简单的图片与一段文本的对齐。就这种情况下，我们似乎更趋向于选择 float 属性来布局整个模块。

我们的样式表也极大地重复。颜色、字体都经常分组属性等。典型的 CSS 文件是一个非常线性的东西，使得面向对象的程序员抓破他们的脑袋也很难适应。(我不是一个面向对象编程的程序员，但我脑袋也快被抓破了。正如你可能读到)。

由于接口程序和 web 应用程序的更加健全化和更加复杂化，正如 css 正在做着最初被设计出来时从未想过做过的事情。这源于我们的想法总是这样的似乎可耻（css 可不可以多做点别的呢?）。幸运的是， 浏览器制造商采用新的 CSS 特性还是比较快速的，更高效更强大的属性和选择器，解决今天的网络带来的新的需求问题。比如 CSS3 的一些特性：、高级选择器、新的布局选项、border-radius, box-shadow、transitions, transforms, animation 等属性。这是多么的让人感到兴奋啊。然而，还有许多属性没有完全的得到支持，如果将来这些属性都被支持了的话，相信写 css 时会变的轻松的多了。

不重复原则

如果我们比较一下同行软件工程们的世界（我们比他们悠闲与舒适的多了），我们可以很快的看到他们是如何组织变量、常量、模块，等等，。他们用他们固有的，以及他们感觉非常必要的模式去为人们构建一些复杂的系统。

你也许听过不重复原则，它是由 Andy Hunt 和 Dave Thomas 在他们所著的一本叫《程序员修炼之道》的书里所定义出来的。据不重复原则的描述：

在一个体系中 ，每条知识必须有一个明确的，典型的代表。

不断地复制代码的方法可能会让开发者很困惑与感到失败（http://bkaprt.com/sass/2/）。因为常识是：我们只需写相同的代码段一次就够了，然后只需重用他们就行了。这才是比较有效、容易维护代码的方法。

css 不遵守不重复原则。有时候，它充满了重复的规则、申明、属性等。在我们整个样式文件中，我们总是在不断地写着相同片段的代码。通过查看一个正规的 css 文件，「不重复软件「开发者将会哭的。首先他们会困惑，然后就是沮丧。

他们将会问：「你们是怎么维护其中的!@#$ 的？「。

他们将会不耐烦的会回应：「我不是已经告诉过你了吗，这是 IE 的 bug」。

为什么 CSS 这么难以处理?

通过一篇 CSS 发明者们所写过的文章，我们可以略微了解到， 这些年来 CSS 的一些语法局限 (请参看的 Bert Bos 所写的一些 论述)。

文中大致是这样的说的：CSS 突然停止，编程语言的程序员使用: 宏命令、变量、符号常量，条件变量表达式，等等更强大的功能。这是因为这些事情给开发人员带来了很多束缚。对缺乏经验的人来说，不经意的便会把自己弄晕，或者，更有可能的是，被吓坏了，以至于他们甚至不会碰 CSS。这是一个平衡，CSS 的平衡是不同于其他一些事情。

css 的最初的设计者考虑到了它的可扩展性，他们明智的选择了希望更多的人能够一起创造、推动互联网的发展。他们希望 css 能够足够强大，能够做到网站风格的表现与内容相分离，并且很容易理解与使用。这一点我是非常赞同他们的。与此同时，对于怎样维护，我们还有很多事要做。这些事是很复杂、有着很微妙差别、很具有挑战性的。

幸运的是，有许多其他选择可以帮忙解决我们所遇到得为问题。其中 sass 就是一种。

什么是 Sass

Sass 是一个你所写的 CSS 样式表和 css 文件浏览器之间的预处理。Sass（Syntactically Awesome Stylesheets 的缩写）弥补了 css 语言的一点不足之处。它允许你写 css 代码不需要重复。这对于创造可维护的样式将是非常有效的。

你可以在 Sass 网站 上看到 sass 怎样描述它自身的简洁性的。

Sass 是一种元语言的 CSS，用它描述的文档具有干净风格和结构。与传统的 css 语法相比它能够做更多的事情。Sass 都提供了一个更简单、更优雅的语法 CSS，实现各种功能，是比较有用的管理 css 样式的一种新方式。

常规的 css 是不能够适应变量、mixin 还有其他的好东西的，sass 与其相比，sass 提供了一种语法能够把一些强大的函数功能加入到你的 css 中去。然后它能通过一个命令行程序或某种 web 架构插件将该语法编译为常规的 CSS 文件。

更具体地说，Sass 是 CSS3 的扩展，其 SCSS(Sassy CSS) 语法，稍微过一会，我们将讨论 CSS3 的超级集合。这意味着，任何有效的 CSS3 文件是有效 SCSS 文档。如果你有你一点点的 css3 的基础，对于 Sass 你可以很轻松的入门。你可以用他尝试着写一点东西试试看。这也意味着将一个现有样式表从 CSS 变成 SCSS 可以分阶段完成，当你在学习和知道更多 Sass 的功能时。

不久之后，你将能够很流畅的使用 Sass（它不会花费你太多时间的），感觉起来它就是一种专门为了 css 而生的扩展，它似乎填补了 css 本身的一些不足之处。这就是为什么当我一开始使用 Sass 之后就没有那种不爽的感觉，就像写 css 一样的爽。我想一旦你尝试着使用了它，你肯定也会无法自拔的。

而且，Sass 还能够帮助我们的 css 代码写得更好。通过确认某些特性 – 目前不可能没有预处理程序的帮助下，给 CSS 书写者实际的实现和功能试验。如果它是合理的，某一 Sass 函数特性推动未来 css 的规范。

关于对 Sass 的误解与疑惑

我早前提到过。开始时我是很不情愿尝试 Sass 的，这是使用之前对他的一些误解导致的。我必须要知道 ruby 与其高级命令行？

我需要完全改变一下我以前写 css 的方式吗？Sass 编译输出的 css 代码会臃肿吗？输出的代码可读性又是怎么样的呢？

幸运的是：以上所有疑惑都是多虑的。

当然了，我时常还是仍然能够在一些网络媒体渠道了解到一些人对他还是产生怀疑的。然我们来消除对它的一些误解吧。。。。

我害怕命令行怎么办！！

我绝不是一个命令行专家，但也不算是菜鸟了吧！我不害怕遍历文件系统或使用 Git 命令。我同情那些不愿使用命令行的设计师和前端开发人员，他们或许有一点命令行恐惧症吧。然而实际上，对于 Sass 来说少量的命令行还是存在的，一些比较基本的一些命令行你还是要掌握的。

然而，有一些 app 应用与 web 框架可以避免命令行的使用（下一章我将向你们介绍）。所以呢，即使你不会使用命令行，也不要因它的存在而影响到你对 Sass 的学习。

我不想改变我写 Css 的方式

这是由于对 Sass 的误会导致的。我特别在意样式表文件的设置与组织，引入了许多好东西在文档里面。但是请明确一下，SCSS 语法是支持 css3 的，你不需要改变任何关于你写 CSS 的方式。注释、缩进等所有默认格式，可以保持不变在你的 SCSS 文档里。当我知道这样居然都可以时，我勒个去！那赶快学 Sass 吧！

我不想改变我设计的方式

另一方面，Sass 不能解决你所有的问题或改掉你的一些不好的习惯。在 css 的工作过程中，如果没有好的规划与构思，即使你使用了 Sass 也一样会让你的代码感觉起来是那么的臃肿与低效。一个好的组织方式与构思方案，在 Sass 里面依然是很有用的。事实上，有时候，Sass 可以把我们一些不好的方式极大的放大，可能也会让我们患上严重的错误。但是如果使用的恰当好处将会给我们的网站开发带来极大的便利。

好吧，，，既然现在我们已经详细了解了 Sass，就让我们开始了解一些有趣的事吧。我相信你一定会惊叹 Sass 所能做的事的。

下一章节，我想为你们展示我们的工作流程，在流程中怎么让你快速适应他的，以及它怎样轻松的使用命令行与应用程序的。让我们开始使用 sass 吧。。。

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

英文原文：http://alistapart.com/article/why-sass

中文译文：http://www.w3cplus.com/preprocessor/why-sass.html

via:http://www.w3cplus.com/preprocessor/why-sass.html

The Why·Liam·Blog by WhyLiam is licensed under a Creative Commons BY-NC-ND 4.0 International License.

由WhyLiam创作并维护的Why·Liam·Blog采用创作共用保留署名-非商业-禁止演绎4.0国际许可证。

本文首发于Why·Liam·Blog (https://blog.naaln.com)，版权所有，侵权必究。

本文永久链接：https://blog.naaln.com/2014/11/why-use-sass/