本文作者:IMWeb 结一 原文出处:IMWeb社区 未经同意,禁止转载
为什么要用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略强点。
- sass的语法不容易混淆,@mixin,%,@function定义各种用途,很清楚明白
- 原先被人诟病的sass的变量机制也完善了,!default变量和!global变量双剑合璧,解决一切所需。
- 自从map类型数据出现后,sass处理数据方面更加突出。
- 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,用哪个做基础的框架比较合适?
请听下回分解。