CSS模块化的几个细节讨论

       CSS模块化不是简单的在CSS文件中分几块，或者把css拆分成几个小css文件。CSS模块化的目的是让css的可复用、可移植、可替换，实现的手段有封装、继承、多态，对于CSS模块化的封装、继承、多态的了解详见 浅谈CSS模块化 。对于大型项目的CSS模块化很重要，做的好以后的维护就很方便。

模块的代码块要独立，只依赖reset和全局样式，不依赖其它模块代码

       有时为了节省代码量多个模块公用背景，把共用一张背景的css放在一起定义背景图片，代码不便于移植和维护。代码块划分要合理，允许合理的代码冗余。

//背景，.mk-dialog input应该放到mk-dialog代码块
.mk-dialog input, .gotop, titlebar{background:url(../img/bg.png) no-repeat}

//其它代码
...

//通用对话框代码
.mk-dialog{}

//功能模块
.module-a{}
.module-b{}

背景图是否需要模块化

       如果页面http请求数不是很多，建议把背景图也做成模块化的，即一个模块是一个sprite，多个模块背景图片别合并成到一起。通用模块背景要独立，例如通用对话框相关的背景和页面其它背景合并在一起就不好，一方面不好维护，另外可能某些页面只用到了对话框，但却要加载一张体积很大的背景图。

模块划分
       对于不是很复杂的项目按照页面区域划分模块已经够了，但是复杂的项目(例如微博)还需要根据功能模块进行细分。
       不按照表现划分模块，例如有四五个浮动层，不能因为样式基本一样把所有的样式混在一起写作为一个模块，如果说某个模块改样式了修改会牵扯到别的模块，就比较麻烦。可以从表现上把通用的部分提取出来，然后分别去写每个模块的代码。

通用模块和功能模块彻底分离，不耦合
       对话框可以看做是一个通用模块，包括了外框、标题栏、按钮等对话框公共元素样式，对话框内容部分的样式交给各个模块去完成。反过来功能模块也不去使用通用模块的样式名。这样保证通用模块是可被替换的，例如对话框改版时只需要重新定义通用模块的样式，如果用脚本封装对话框只需要替换一个脚本即可。

//对话框样式
.mk-dialog{}
//登陆对话框，不使用mk-dialog作为父类去写功能模块的代码
.mk-dialog .login{}
 
//正确的模块定义
.login{}
.login input{}
.login prompt{}