通过宜家的家具设计方法学习CSS模块化

去过宜家的同学应该都有注意到，宜家的家具基本都是组合的，可拆装。模块化的特点也是这样，可以组合，相对独立，在需要的时候可以很方便的加上。那怎么写可以基本实现这种方式呢？
很久之前就知道 宜家 ，以前在广州的时候也去过一次，给我的印象就是：大、贵、巧。地方很大，东西很贵，设计很巧。现在住的地方离宜家不远，这个月找时间去逛了下，地方还是那么大，东西还是那么贵，设计还是那么的巧。虽然没有买什么东西，不过也还是有所收获的，通过宜家的家具设计方法，我们可以聊聊模块化。
去过宜家的同学应该都有注意到，宜家的家具基本都是组合的，可拆装。模块化的特点也是这样，可以组合，相对独立，在需要的时候可以很方便的加上。那怎么写可以基本实现这种方式呢？给个简单的例子：

对应的CSS可以这么写：
.mode-a{...}
.mode-a h3{...}
.mode-a p{...}
其中“mode-a”就是这个模块的名称，表示这是名为“a”的模块，现在这个模块可以被放到你所需要的地方。既然是做模块，就不会只有一个，我们再加一个“mode-b”：

对应的CSS可以这么写：
.mode-b{...}
.mode-b h3{...}
.mode-b div{...}
.mode-b h4{...}
.mode-b ul li{...}
实际应用中大多需要加一些classname来减少类定义的复杂度，这个例子比较简单，但足以说明模块化的特点。上面两个模块可同时被使用到一个或多个页面中。
在宜家的卖场中，也许你也注意到了，基本是以设计师来划分商品区的，特别是那些小件的商品。模块化后的代码也可以被分配给不同的人进行编写，提高效率。当然要实现这种方式，我们也需要做些工作，如模块的命名规范、模块中哪些地方是需要留接口的等等。如上面的例子中可以约定的就有：命名以“mode”开头，模块标题使用h3标签。这样不管是哪个人写出来的模块都可兼容项目中的页面。
看到这你可能会发现，既然上面已经约定了模块固定的结构，每个模块的样式定义中所写的这一部分不就是冗余的吗？是的。如果已经形成相关的约定，这部分的样式定义可以被提出来放到项目的公共定义中，减少代码的冗余。如上面的例子可以变成：
/* =S global */
h3{
/* 第一种写法 */
...
}
.mode-a h3,
.mode-b h3{
/* 第二种写法 */
...
}
/* =E global */
/* =S mode-a */
.mode-a{...}
.mode-a p{...}
/* =E mode-a */
/* =S mode-b */
.mode-b{...}
.mode-b div{...}
.mode-b h4{...}
.mode-b ul li{...}
/* ==E mode-b */
不知你有没注意到宜家那些小件的商品，往往可以组合到不同的其它商品上面。这也带出了模块化的另一个话题：模块中的模块。即在模块中可以存在其它的模块，也很好理解，就像我们做网站的时候，整个页面的结构就像是一个大的模块，而上面所讲的例子就是模块中的模块了，只不过我们把这个定义缩小一层。上面例子中对h3的定义，就可以看成是一个模块，它在“mode-a”、“mode-b”两个模块中都出现，并且结构表现相对固定。
OK，这只是对一个标签的定义，如果不只一个标签呢？我们重新改下例子：


/* =S mode-a */
.mode-a{...}
.mode-a h3{...}
.mode-a p{...}
/* =E mode-a */
/* =S mode-b */
.mode-b{...}
.mode-b h4{...}
.mode-b .cont{...}
.mode-b .cont ul li{...}
/* =E mode-b */
/* =S mode-c */
.mode-c{...}
.mode-c h4{...}
.mode-c .cont{...}
.mode-c .cont p{...}
/* =E mode-c */
从上面可以看到，“mode-a”是一个独立的模块，当它作为“mode-b”和“mode-c”的一部分时，就成了模块中的模块了。抛下砖，希望能引出更多相关的讨论。