保持Sass的简单 | Sass中文网

本文由大漠根据Hugo Giraudel的《Understanding Reference Boxes for CSS Shapes》所译，整个译文带有我们自己的理解与思想，如果译得不好或有不对之处还请同行朋友指点。如需转载此译文，需注明原作者相关信息http://www.sitepoint.com/keep-sass-simple/。

——作者：Hugo Giraudel
——译者：大漠

还有两个月时间，我使用Sass就有两年时间了。几乎每一天，在工作中，在家里，在项目中，都有人问我，怎么更好使用Sass。很高兴他们这么相信我，每天能为他们提供帮助，我感到非常高兴。

有些需求是合理的，有些需求是烦死人的。嘿嘿，我们可以从任何地方开始。也有些是抽象的。每个人都希望使用Sass能变得更简单（其他预处理器也在做这样的事情）。包括我在内，我也一直在这么做。

让我们来优化

那天我被问及到如何做到这点：

.class {
  width: 20px;
}

.other-class {
  width: em(.class:width);
}

基本上,使用em()函数将.class宽度转换到.other-class。仔细想想，在Sass中如果离开上下文，要将px单位转换成em单位，其实蛮困难的，而且这里还要从一个选择器引值到另一个选择器中。

甚至Stylus——这是很出名，非常强大的一款预处理器。他也做不到。充其量，只能在相同的代码块中引用值(也就是属性查找)。显然Sass要保守得多，他是做不到的。

注：如果你曾经也想要这样做，这并不是一件什么坏事。因为有很多人都有过这样的想法，你只不过是其中的一位而以。

我们可以做的

好吧，让我们接受上面的需求在Sass中使用确实是一个错误。你想看一个更有争议性的示例吗？Sass 3.4新增了一个新的功能特性，就是促进选择器传递的函数。这些特性注定了Sass能像处理list一样处理选择器，比如selector-nest()，selector-replace()等等。

尽管如何努力，至今我还没有找到一个合理的用例来说明选择器函数。有很多人在Twitter上用这些示例试图来说服我：

//Sass 3.40.rc.3 
@mixin context($old-context, $new-context) {
    @at-root #{selector-replace(&, $old-context, $new-context)} {
        @content;
    }
}

li {
  float: left;

  ul {
    display: none;

    @include context('li', 'li:hover') {
      display: block;
    }
  }
}

编译出来的CSS:

li {
  float: left;
}
li ul {
  display: none;
}
li:hover ul {
  display: block;
}

我同意这么做是一个很聪明的方法，但我并不觉得这是一个简单的方法。我认为他把事情整得更为复杂。我觉得不应该在任何地方让代码变得复杂化。

为什么不像这样写呢？

li {
  float: left;

  ul {
    display: none;
  }

  &:hover ul {
    display: block
  }
}

现在这样就简单了。这样是可以理解的。我觉得有时候我们用的东西，我们只知道他的存在，并不是因为我们应该使用它们。

我们怎么在这里

在某种程度上，我觉得非常惭愧。我使用Sass做了一些疯狂的事情(例如这里和这里)。向大家推荐他的特性，可能没有足够掌握好这些技术，这些技术大多是都还只是实验阶段。

我是这不是很明显。当你写了十几于的Sass代码，却只输出了几行的CSS代码，你应该觉得这个Sass是有问题的。让人觉得意外的是，这种带有凝问的Sass代码依然还在生产中使用。

就像你给人太多权利，他就会滥用这些权利。更糟糕的是，他可能还会想要更多的权利。就像我们使用CSS预处理器一样，变量不够用，就有了混合宏mixin。有了函数。也有了数组。我们还在想要更多。但从未停下脚步来思考我们在做什么，我们为什么要这么做。

我也没有停下脚步来做思考，直到我将以前用到的CSS经验与一些没有开发经验的人员共享时，我才发现，我这样疯狂的做法并不是一个很好的选择。很高兴，我意识到了这点。

我们应该一起放弃Sass？

这一点不是这篇文章要说的，特别是Sass有什么毛病。你应该听说过这么一句话：

Preprocessors do not output bad code. Bad developers do.

当你知道如何使用Sass和如何不使用Sass时，Sass是一个有用的工具。在使用混合宏或函数数，有一些人认为使用Sass绝对没有错。即使是复杂的，只要他们不要搞得太复杂，那么复杂就变得不复杂了。

只要你控制的妥当，嵌套并没有什么不好。就我个人而言，我并不太喜欢嵌套，因为他让代码变得更难阅读。

当伪类和伪元素出现时，我非常的喜欢他们，但我认为，很快他们就会在嵌套中乱用，像下面的示例，摘自这篇文章：

.tabs {
  .tab {
    background: red;
    &:hover {
      background: white;
      .tab-link {
        color: red;
      }
    }
    .tab-link {
      color: white;
    }
  }
}

对于我来说，我宁愿多写一点：

.tabs .tab {
  background: red;

  &:hover {
    background: white;
  }
}

.tab-link {
  color: white;

  .tabs .tab:hover & {
    color: red;
  }
}

而且你知道吗？第一个示例用了176个字符，而第二个示例只用了152个字符。所以深层嵌套并不一定适合。

它的乐趣

是的，它是非常有趣的，我也知道这点。我写了一个Json解析器，输出Sass，可以按位运算字符，只不过不是SCSS。做这个事情的过程，它是非常有趣的。

做这样的工程不仅有趣，而且也很有用。在做这些事情的时候，我意外的发现了Sass的一些小Bug(#1090、#1265)。此外，我理擅长用Sass做一些意想不到的事情。每个项目只定义三个变量并不是件好事。但你推动的事情变得更有意义。

但你需要在哪里结束。你需要知道，你做的事情走得有多远，怎么控制你的代码。我差不多花了两年的时间和在一个大型的项目中实践自己的想法。一切注定了不是什么都能用，在生产环境上并不是可以让你来做实验。这样不只是带来错误，还会带来很大的危险。

比如，我在考虑使用@extend来控制跨Media Queries，我们应该要学会变通。我把这一部分做为DoCSSa的一部分。可以做到自行引用。的确是这样，除了打破层级，使用%placeholder来做扩展是最好的，因为CSS的移来移去难免会出问题。

这种技术是一种实验。它不是用于一个大型的框架中，我想可以帮助大家解决一些实际需求。用于生产这是不应该的，至少还没有考虑周全，没有意识到用上将产生的后果。然而，这种方式还是用上去了。

结论

保持不断地去实验。不要停止对Sass的学习，他是令人敬畏的。只要在真实的项目中，你知道自己在做什么。最重要的是保持事情的简单。少即是多。

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

出处：

英文原文：http://www.sitepoint.com/keep-sass-simple/

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