拥抱sass，抛弃compass

2017-12-29 17:11:35 浏览数 (1)

为什么要用sass

在选择sass之前，我们先说下为什么要使用CSS Preprocessor。

大概两年前，CSS Preprocessor其实没有这么热，而了解sass，less，stylus的人也还没那么多（当时三者占比less还是拥有绝对优势的），但很多时候就是那么duang的一下，然后改变就发生了，就如html5&css3，仿佛一夜之间就遍地开花。当然这其中质变肯定是有道理值得去说道说道的。下面我们一起来对比下css和CSS Preprocessor（以sass为例），了解下其中的优劣。

CSS无层级嵌套机制

因为css无嵌套机制，所以造成层级方面的阅读及折叠方面极为不便，如下代码，使用scss就能更好的管理代码层级关系

代码语言：javascript复制
// css
.parent{}
.parent .child{}

// scss
.parent{
    .child{}
}

css本身缺少变量机制

举个最简单的例子，每个站点都有个主色，如果没有变量的话，我们只能每次使用都拷贝颜色，当然也有神人是可以把颜色的六位数记住，但多数肯定是记不住。下面以文本色及链接色为例：

代码语言：javascript复制
// css
body{
    color:#333;
}
a{
    color: #188eee;
}
.dark a{
    color: #333;
}
.dark a:hover{
    color: #188eee;
}

有了变量呢，那就简单了，直接定义一个变量，然后需要的时候调用变量即可:

代码语言：javascript复制
// scss
$textColor: #333 !default;
$lickColor: #188eee !default;

body{
    color:$textColor;
}
a{
    color: $lick-color;
}
.dark a{
    color: $textColor;
}
.dark a:hover{
    color: $lickColor;
}

注：css变量已经正在开发中，现在的火狐其实已经支持最新的css变量了，而且比所有的CSS Preprocessor都好用，感兴趣的同学可以去尝个鲜。

@import不是我们所期望的功能

随着业务功能增加及复杂性增强，多人员合作及组件开发模式是必然的。而现有的CSS的[@import](/user/import)与我们所要的[@import](/user/import)不是一个概念。为了表示两者的区别，我们直接在page.scss中导入一个css文件和一个scss文件：

page.scss

代码语言：javascript复制
[@import](/user/import) "reset.css";
[@import](/user/import) "mod-a";
p{
  background: #0982c1;
}

_mod-a.scss

代码语言：javascript复制
//_mod-a.scss
//-------------------------------
.hello {
  color: #eee;
}

最终编译出来的page.css文件：

代码语言：javascript复制
[@import](/user/import) "reset.css";
.hello {
  color: #eee;
}
p{
  background: #0982c1;
}

可以看到，[@import](/user/import) "reset.css"没有发生改变，而moda-a的scss文件则被合进了page.css，这才是我们需要的结果，需要的时候调用想用的scss文件，然后最终合并到一个css文件中。

对可重用的代码缺少重复使用机制

css对于相同或相似的代码，除了一遍遍的拷贝复制或组合申明之外，不可以定义一些规则或函数，去简单重复使用，如下：

代码语言：javascript复制
// 组合申明
.center-block,
.container{
    margin-left: auto;
    margin-right: auto;
}
.container{
    margin-bottom: 20px;
    width: 1200px;
}

// 拷贝使用
.fixed-top{
    position: fixed;
    left: 0;
    right: 0;
    top: 0;
}
.fixed-bottom{
    position: fixed;
    left: 0;
    right: 0;
    bottom: 0;
}

而使用scss之后则如下：

代码语言：javascript复制
// %，解析后组合申明样式
�nter-block{
    margin-left: auto;
    margin-right: auto;
}

.center-block{
    [@extend](/user/extend) �nter-block;
}
.container{
    [@extend](/user/extend) �nter-block;        
    margin-bottom: 20px;
    width: 1200px;
}

// [@mixin](/user/mixin), 解析后拷贝样式 
[@mixin](/user/mixin) fixed($pos: 0) {
    position: fixed;
    left: 0;
    right: 0;
    [@if](/user/if) $pos == bottom {
        bottom: 0;
    }
    [@else](/user/else) {
        top: $pos;
    }
}
.fixed-top{
    [@include](/user/include) fixed;
}
.fixed-bottom{
    [@include](/user/include) fixed(bottom);
}

除此之外，CSS Preprocessor还有条件判断，循环等高大上的东西，这些都是css目前不具备的，当然CSS也正在一步步变化，为更好而革新，相信在不久的将来，CSS也会duang的一下，给你眼前一亮。

说完为什么要选择CSS Preprocessor，接下来我们说下为什么选择sass吧。

其实几个CSS Preprocessor的基本功能都差不多，都能胜任日常的开发，但如果是做基础的css框架及组件开发的话还是sass略强点。

  1. sass的语法不容易混淆，@mixin，%，@function定义各种用途，很清楚明白
  2. 原先被人诟病的sass的变量机制也完善了，!default变量和!global变量双剑合璧，解决一切所需。
  3. 自从map类型数据出现后，sass处理数据方面更加突出。
  4. sass的函数多多，应有尽有，各种选择器函数，颜色函数，判断条件，循环函数等，是你构建基础框架的得力助手

总之，就目前来说sass是个很好的选择。当然也许有一天less或其他的会超越它，或者直接到了某一天css本身就有了这些功能，根本不需要这些CSS Preprocessor。而所有这些都是有极可能的。

为什么要抛弃compass

用雕爷的一个字评价compass就是——学习成本比较高，更新太慢，东西太多，实用的却很少。

作为以sass为基础构建的css框架，compass还是非常优秀的，其思想及设计都值得借鉴。但是鉴于它的更新频率及里面的css代码，还是不得不吐槽下：

跟不上sass的更新节奏

sass之所以能够在2年内反超less，成为现在的首选，就是因为从版本3.2.0之后，不断更新，开发并优化更好的功能，吸引更多的关注。而compass却迟迟跟不上sass的脚步，严重影响sass的体验。

跟不上css的脚步

看下compass的重置，html5的几乎没有，现在框架几乎都是normalize reset的天下了；再看下其inline-block的mixin居然还有display: -moz-inline-stack;，虽然穿着的是sass前沿的华衣，走的却是怀旧风格，怎么着都有点诡异。

CSS3 mixin

相信很多人用compass是奔着这烦人的css3前缀来的，可是弱弱的说句，它也过时了，现在都是基于can i use的数据来自动生成前缀或兼容了，各大自动化工具如grunt/gulp都有其相应的插件autoprefixer，就算是不用这些自动的前缀，也有很多专门针对css3前缀的scss文件供调用，如css3-scss

sprite自动生成雪碧图

当然还有更大部分使用者是朝着这个功能来的，如果你仅是为了使用这个功能呢，替代的工具同样有的是，同样配置下自动化工具生成sprite分分钟搞定。

所以你为什么还在坚持使用compass？

最后问题来了，如果选择了sass，抛弃了compass，用哪个做基础的框架比较合适？

请听下回分解。

sass

0 人点赞