CSS预处理语言的模块化实践

编写css是前端工作中，一项普通而又频繁的劳动，由于css并不是一门语言，所以在程序设计上显得有些简陋。对于小型项目来说，css的量还不至于庞大，问题没有凸显，而如果要开发和持续维护一个较为大型的项目，那就需要对css进行管理和规范了，否则会发生不可挽回的后果（吓唬谁呢？？）。

背景

上一节【从css谈模块化】我们通过规范的约束，将css的编写方式进行了优化和改进，形成一种可持续发展的路线。但还是遗留了一些问题：冗余。虽然我们通过定义公共模块和私有模块，来委婉地分担common的体积，但common的体积还是太大了，而且从设计上考虑，我们应该尽量多地提炼公共模块，以便更好地实现复用。最理想的情况是，所有的模块都寄存在一个公共的库里，哪里需要用到就从库中直接调过来。这个美好的愿望不是不可实现的，借助预处理语言，我们可以很轻易地完成这事情。

预处理语言是一种类css的语言，我们知道css本身不是语言，而预处理语言的诞生，就是为填补这一部分语言功能。它实现了变量、函数、混合的定义，以及文件的引用、合并、压缩功能，使得css也能面向对象，应付复杂庞大的业务。

目前流行的预处理语言主要有两种：less和sass。作为学习，两者都可以入门一下，而作为工作，尽量熟悉一种。我比较常用sass，所以以下内容都是以sass为基本语言做介绍，两者在特性上有很多相似的地方，所以大家不必担心实现上有什么千差万别。

sass

基本语法可以到官网（英语）或者w3cplus sass guide（中文）查看学习，我们这里只简单地过一遍，讲一些我们需要用到的内容，不会面面俱到。

sass有两种后缀名文件：一种后缀名为sass，不使用大括号和分号；另一种就是我们这里使用的scss文件，这种和我们平时写的css文件格式差不多，使用大括号和分号。而本教程中所说的所有sass文件都指后缀名为scss的文件。在此也建议使用后缀名为scss的文件，以避免sass后缀名的严格格式要求报错。 ——摘自w3cplus sass guide

1、嵌套（非常重要的特性）

sass的嵌套包括两种：一种是选择器的嵌套；另一种是属性的嵌套。我们一般说起或用到的都是选择器的嵌套。 ——摘自w3cplus sass guide
选择器嵌套 所谓选择器嵌套指的是在一个选择器中嵌套另一个选择器来实现继承，从而增强了sass文件的结构性和可读性。在选择器嵌套中，可以使用&表示父元素选择器。 ——摘自w3cplus sass guide

 
 
  
  // index.scss   
     
  .g-index {   
    ...   
     
    .g-hd {   
      ...   
     
      .m-nav { ... }   
    }   
     
    .g-bd {   
      ...   
     
      .m-news { ... }   
    }   
     
    .g-ft {   
      ...   
     
      .m-copy_right { ... }   
    }   
     
    .m-dialog {   
      display: none;   
     
      &.z-active {  // 留意此处&的用法   
        display: block;   
      }   
    }   
  }

编译后：

 
 
  
  /* index.css */   
     
  .g-index { ... }   
  .g-index .g-hd { ... }   
  .g-index .g-hd .m-nav { ... }   
     
  .g-index .g-bd { ... }   
  .g-index .g-bd .m-news { ... }   
     
  .g-index .g-ft { ... }   
  .g-index .g-ft .m-copy_right { ... }   
     
  .g-index .m-dialog {   
    display: none;   
  }   
     
  .g-index .m-dialog.z-active {  // 留意此处&的编译结果   
    display: block;   
  }

是不是爽歪歪？再也不用一遍一遍地去复制和修改一大堆的选择器，也不需要去整理它们之间的关系，只需要嵌套一下，所有的关系就如同直接看dom一样简单明了了！解放双手，解放双眼，同时还提高效率。值得留意的是，我们书写sass的时候，应该尽量保持sass的嵌套顺序与dom一致，注意，是嵌套顺序一致，而不是层次一致，因为并不是dom里的所有元素都需要写样式。

我们再来提一个场景，说明sass的嵌套写法利于维护，假设g-bd下原本有个模块m-article_box，现在我们要把m-article_box从g-bd迁移到g-hd中（当然这个需求有些不合理～），我们来看原始代码：

文章标题

.g-bd { ... }
.g-bd .m-article_box { ... }
.g-bd .m-article_box .hd { ... }
.g-bd .m-article_box .bd { ... }
.g-bd .m-article_box .bd .list { ... }
.g-bd .m-article_box .bd .list .item { ... }
.g-bd .m-article_box .bd .list .item .cover { ... }
.g-bd .m-article_box .bd .list .item .info { ... }
.g-bd .m-article_box .bd .list .item .info .title { ... }
.g-bd .m-article_box .bd .list .item .info .desc { ... }
.g-bd .m-article_box .ft { ... }
.g-bd .m-article_box .ft .page { ... }
.g-bd .m-article_box .ft .page .pg { ... }

// 修改前
.g-hd { ... }
.g-bd {
.m-article_box {
.hd { ... }
.bd {
.list {
.item {
.cover {
...
}
.info {
.title {
...
}
.desc {
...
}
}
}
}
}
.ft {
.page {
.pg { ... }
}
}
}
}
// 修改后
.g-hd {
.m-article_box {
.hd { ... }
.bd {
.list {
.item {
.cover {
...
}
.info {
.title {
...
}
.desc {
...
}
}
}
}
}
.ft {
.page {
.pg { ... }
}
}
}
}
.g-bd { ... }

// common.scss
@mixin m-nav {
.m-nav { ... }
}
@mixin m-news {
.m-news { ... }
}
@mixin m-copy_right {
.m-copy_right { ... }
}
// index.scss
.g-index {
@include m-nav;
@include m-news;
@include m-copy_right;
}

// common.scss
@mixin m-nav {
.m-nav { ... }
}
@mixin m-news {
.m-news { ... }
}
@mixin m-copy_right {
.m-copy_right { ... }
}

// index.scss
@import 'common'; // 记得先引入common
.g-index {
@include m-nav;
@include m-news;
@include m-copy_right;
}

// index.scss
@import 'common'; // 引入common，如果有需要，common里一样可以引入mixin
@import 'mixin'; // 引入mixin
.g-index {
...
}

// index.scss
@import './common';
@import './mixin';
@include m-nav;
@include m-news;
@include m-copy_right;
.g-index {
...
}

// index.scss
@import './common';
@import './mixin';
.g-index {
@include m-nav;
@include m-news;
@include m-copy_right;
...
}