CSS预处理器Sass(Scss)、Less、Stylus

         CSS 预处理编译器能让我成程序化其的方式编写CSS代码，能够引入CSS中没有的变量、条件、函数等特性，从而让代码更简单易维护，但通常按预处理器语法编写的代码没法直接在浏览器中运行，需用经过工具好比gulp转换成标准的CSS语法，从而在浏览器中运行。我的理解它是标准CSS语法的扩展及加强，能在必定程度上提升编码效率。

三种预处理器的对比：

Sass诞生是最先也是最成熟的CSS预处理器，有Ruby社区和Compass支持；安装、编译依赖Ruby环境；

Stylus早期服务器Node JS项目，在该社区获得必定支持者， 安装、编译依赖NodeJs环境 ；

LESS出现于2009年，支持者远超于Ruby和Node JS社区 ， 安装、编译依赖NodeJs环境 ，表明bootstrap；

Sass和LESS语法较为严谨、严密，而Stylus语法相对散漫（借鉴python），其中LESS学习起来更快一些，由于他更像CSS的标准；

Sass和LESS相互影响较大，其中Sass受LESS影响，已经进化到了全面兼容CSS的SCSS；

Sass和LESS都有第三方工具提供转译，特别是Sass和Compass是绝配；

Sass、LESS和Stylus都具备变量、做用域、混合、嵌套、继承、运算符、颜色函数、导入和注释等基本特性，并且以“变量”、“混合”、“嵌套”、“继承”和“颜色函数”称为五大基本特性，各自特性实现功能基本类似，只是使用规则上有所不一样；

Sass和Stylus具备相似于语言处理的能力，好比说条件语句、循环语句等，而LESS须要经过When等关键词模拟这些功能，在这一方面略逊一层；

最后摘录一下为何要用CSS预处理器

1# CSS没法递归式定义

CSS语法不支持递归定义的表达式，因此你没有办法用一个语句定义一个启发式的规则。

好比这样的需求：“.w后面跟着一个数字，这个数字表明着width为百分之多少”（bootstrap的栅格系统就包含12种相对父级宽度的类定义）。
尽管彻底是一个规则里定义出的，但你只能这样写CSS：

.w1 { width: 1% }
.w2 { width: 2% }
/** .w3 ... ... .w99 **/.w100 { width: 100% }

这样将形成很大的冗余，修改费时费力。但若是预编译CSS，就很是简单了：

@maxnumber : 100 ;
.makeWidthRules(@number) when(@number <= @maxnumber ){
  .w@{number}{ width: 1% * @number ;
  }
  .makeWidthRules(@number + 1) ;
}
.makeWidthRules(1) ;

2# CSS的mixin式复用性支持不够

使用纯CSS，咱们能够抽象出一些经常使用的布局CSS属性组合，经过CSS的类组合来达成常见的mixin式复用。
好比这样：

<style>.tc { text-align: center; }.m { margin-left: auto; margin-right: auto; }.w50p { width: 50%; }.db { display: block; }</style><div class="tc m w50p"><img class="db"></div>

这种方案有几个问题：

• 页面重构时，须要频繁修改class name；
  这个问题在后端人员掌握着视图层的时候格外突出，先后端耗费不少沟通成本。
• 要约束上下文的时候很是无力
  好比“只有在ul下面的img.db容许是display:block”的规则，写成ul img.db { display: block; }就彻底跑偏了——它违背了你建立这个.db类时的本意，形成了代码的可读性和可维护性降低。若是你要改动规则，须要同时修改HTML和CSS，也可能形成新的样式问题。

若是咱们想要创建一种代码风格，只容许CSS Class表明UI模块的抽象——改动样式时不至于通知后端改模板——咱们就要将上面这个例子的tc m w50p换用一个有实际语义的类名如headwrap，而后在CSS内部实现mixin。
——而这正是CSS的短板，CSS体系内的用法只有复制粘贴。

至于如何用预编译语言作mixin，一个很是好的SASS示例由 @nightire 在这个回答里给出，容我摘录一小段：

.btn-standout {
    @extend .btn;
    @extend .btn-block;

    @media (max-width: $screen-xs-max) {
        @include button-size(
            $padding-large-vertical,
            $padding-large-horizontal,
            $font-size-large,
            $line-height-large,
            $border-radius-large
        );
    }

    &.sell {
        @extend .btn-primary;
    }
}

3# 预编译可缓解多浏览器兼容形成的冗余

进入CSS3的时代，旧式CSS hack如filter，新式兼容前缀如-webkit-等，都是冗余，修改的时候也须要修改多处，不容易维护。

好比对rgba背景的兼容：

.bg { filter: progid:DXImageTransform.Microsoft.gradient(startcolorstr=#ccff825b,endcolorstr=#ccff825b); }:root .bg { -ms-filter: none; background: rgba(255,130,91,0.8) }

在LESS里面，写个函数就能解决，屡次复用也不须要看到如此之多的hack：

.rgbaBG(@c , @a){
    @rgba : rgba(red(@c),green(@c),blue(@c),@a);
    @shim : argb(@rgba) ;
    filter: ~"progid:DXImageTransform.Microsoft.gradient(startcolorstr=@{shim},endcolorstr=@{shim})" ;
    :root & {
        -ms-filter: none ;
        background: @rgba ;
    }
}
.bg {
    .rgbaBG(#ff825b, 0.8) ;
}

此外，使用LESS时，能够很方便地使用base64 data uri的方案。不须要直接面临在CSS中一大坨字符：

.bg { background: data-uri('../data/image.jpg'); }

SASS的相似方案见评论。

N# 预编译不是万金油

预编译不是万金油，CSS的好处在于简便、随时随地被使用和调试。预编译CSS步骤的加入，让咱们开发工做流中多了一个环节，调试也变得更麻烦了。

举个例子：原先咱们只须要在chrome/firebug里面找到相应的选择器，如.popup .popup-wrap .head，源文件里面ctrl+F查找.popup .popup-wrap .head就能够快速定位语句。如今咱们没法直接在预编译文件中查找，而须要寻找上下文，由于它在LESS中一般是这样被定义的:

.popup {
    .popup-wrap {
        .head { }
    }
}

更大的问题在于，预编译很容易形成后代选择器的滥用。
曾经有一个观点是预编译能够解决样式覆写的问题，而我以为，正是预编译语言模糊了样式覆写的问题，而致使要解决样式相互覆写的问题时，问题已经变得规模庞大而难以解决。

举个极端的例子：

.popup {
    font-size: 12px;
    a { font-size: 13px; }
    .head { font-size: 18px; }
}
.informative {
    font-size: 14px;
    .head { font-size: 16px; }
}

若是我有这么一个文档结构.popup.informative > .head > a，须要a的font-size为17px，你能快速想明白怎么改吗？叠罗汉式地再叠一层？仍是再糊一层墙皮，加一行样式？仍是干脆用!important轰炸一番？

所以，实际项目中衡量预编译方案时，仍是得想一想，比起带来的额外维护开销，预编译有没有解决更大的麻烦。

来源： <https://segmentfault.com/q/1010000002527156/a-1020000002527759>

 

来自为知笔记(Wiz)