保持Sass的简单

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


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


——作者:Hugo Giraudel

——译者:大漠


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

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

##让我们来优化

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

1
2
3
4
5
6
7
.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上用这些示例试图来说服我:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
//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:

1
2
3
4
5
6
7
8
9
li {
float: left;
}
li ul {
display: none;
}
li:hover ul {
display: block;
}

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

为什么不像这样写呢?

1
2
3
4
5
6
7
8
9
10
11
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绝对没有错。即使是复杂的,只要他们不要搞得太复杂,那么复杂就变得不复杂了。

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
.tabs {
.tab {
background: red;
&:hover {
background: white;
.tab-link {
color: red;
}
}
.tab-link {
color: white;
}
}
}

对于我来说,我宁愿多写一点:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
.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