对于css模块化不知大家是否有概念?下面且听我一一道来:
其实,css规范里面就已经提到模块化相关内容了,就是@import语法。这个语法是被当前主流浏览器(当然包括ie6)原生支持的,属于Css基础最基础的部分。为啥大家很少用呢,大概是因为在生产环境单独去用@import,会有较为严重的性能问题,而且不同的浏览器以及不同的用法下也有不同的表现,比较让人郁闷。但是,这并不妨碍@import成为 CSS模块化 的利器。
也许@import诞生就是为了解决css模块化的问题吧。我们先来举一个例子看看CSS模块化的优势:
传统的开发
假如你要开发某大型网站首页,那html的head里面应该是这样引用样式的:
为了页面上比较好的性能,减少创建http请求的消耗,我们一般会选择尽量减少link的css文件数量,假如本例中,页面上所有的样式都写在了style.css里面。可想而知对于一个大型网站来讲,这个文件会有多长。如果出现bug或者想改个东西,需要的成本会比较大;而且现在业界内对于CSS开发并没有很成熟的最佳实践或者约定可循,很多时候,前端为了加快进度,可能会把某一个功能的代码放在css不同的地方,如果想去掉某个功能,肯定不敢轻易删除页面Css代码。
这时候,CSS模块化的优势就体现出来了!
模块化开发
页面不改,我们还是只引用那一个样式,style.css,但是文件内容改成如下样式:
/*xxx页面入口样式文件style.css*/
@import './css/base.css';/*页面基础样式*/
@import './css/index.css';
@import './css/header.css';
@import './css/footer.css';
……
以上为多个模块的样式文件
这里,我们把style.css中混乱的样式划分成了一个一个的子文件,作为模块。可以看到,作为示例,我把页面的一些reset样式以及一些站点公用样式放在了css目录下的base.css中,把页头拆分成header.css,把页面的基础布局都放在了index.css这个文件中,底部的样式放在了footer.css。然后相应的代码就在对应的模块中写,是不是看起来简洁、好维护很多呢?
不光是简洁,使用@import形式的模块化还有下列好处:
1. 浏览器原生支持
这点是这个工具或者这种模块化形式的亮点。对于less,想要在开发环境下方便地修改,还需要额外引入一个js文件,或者采取 less实时编译之类的方法。而采用这种 @import xxx.css文件的方法,我们可以很方便地在开发阶段,直接调试。不需要引入额外的js文件去解析style.css文件。页面中直接引入style.css文件,通过http瀑布图可以看到,base.css、index.css等被一个一个加载进来了。
2. 方便删除某个模块
这个是所有语言模块化的优势,比如哪天PD说,首页底部那个地方我想换个样式,以往,我们很多都是直接在html里面改掉原 来的class,然后在style.css里面直接加上新的样式,老的也不敢删,怕删错了,即使删了也可能会漏,因为不停的bugfix可能会导致代码乱写。而采用模块化的方案,我直接把@import ‘./css/footer.css’这一行注释掉,然后再@import新的样式,这样,即使上线了,PD说效果不好,想换回原来的,只要改一下注释,重新打包,岂不是很方便?
3. 便于管理各种日常需求
好,页面做好了,上线了,PD今天脑袋抽风,说我要加一个功能,首页右侧加一个建议反馈入口,以往,我们要打开 style.css,想想在哪儿加好,或者直接加在最后,也不管最后的地方是放什么的。采用模块化之后,我们在style.css的最后再@import ‘./css/feedback.css’即可,然后加上注释:/* 2012-12-06 PD要求加上建议反馈 */,这样以后其他修改者也能快速知道你这个模块是干神马的。
4. 方便合作开发
这也是所有语言模块化的优势。对于一个大型项目,往往共同开发一个文件,冲突的可能性非常大,很多情况下,我改了一个小地方,提交上去就冲突了,然后再花费比bugfix多10倍的时间去解决冲突,然后还不知道会不会产生另外10个新bug,而模块化,每个人负责哪些模块,职责非常明确,不容易出现问题。
5. 方便多人协作
依赖写在入口文件,而不是打包脚本的配置文件。这样开发和打包分离,新加、减少模块不需要去修改打包配置,方便多人协作。
OK,说完CSS模块化,以及如何利用@import形式来组织自己的模块,大家是不是感觉这种形式让你眼前一亮呢?但是,如果这样开发完直接上线的话,页面会有一些问题。我就挑一些比较明显的问题说一下:
1. 因为@import的文件是额外请求的,所以页面加载的时候会有一小会儿的裸体(样式没加载进来),要等这些模块一个一个加载
2. 请求数太多,页面性能不佳,对服务器压力也会相对大一些。
3. 不同的浏览器以及不同的书写形式可能会有不同的加载顺序。
所以,最好的办法就是把模块打包!这和js模块化一样的,模块化开发,然后上线之前打包,线上完美使用。
CSS Combo:CSS模块打包利器
像js打包,一般都会有配备的打包工具。对于css,很多人是用ant的concat或者grunt的concat,这样做的不利的一面就是要把css模块依赖写在打包脚本的配置文件中,很不利于维护。很多时候,你新增了模块,忘记了修改打包脚本的配置,然后发上去发现我的脚本怎么没生效?查了半天才发现是没打包进去。
如果你利用我上面介绍的@import形式来组织你的css,那么你就可以用配套打包工具CSS Combo了:
首先安装css combo:
npm install -g css-combo
然后进入你所在的入口文件(本例为style.css)目录,输入:
csscombo style.css style.combo.css
这样就会把style.css文件打包成style.combo.css文件。很简单吧。当然也可以结合gulp一起用,更方便哦。
一些最佳实践
首先,我务必要提醒大家,@import语法一定要仔细看。
@import "./css/style1.css";
这里我个人建议就用相对路径就好了,当然也支持线上和本机绝对路径,只不过想对路径有利于团队协作。
一定要注意,CSS规范中,@import必须放在其他样式之前,比如:
@import "./css/style.css";
@import "./css/style2.css";
body{
margin:0px;
padding:0px;
}
而下面这种写法:
@import "./css/style.css";
body{
margin:0px;
padding:0px;
}
@import "./css/style2.css";
mod2.css是无法被浏览器@import进来的。所以我们推荐的最佳实践就是把所有的模块import都放在入口文件的最开始,方便管理。
为啥不直接用less
团队里面不是每人都会less,也不是每个人都喜欢less。而且less不支持gbk编码,还有上面提到的,调试需要引入一段js,很多情况下,开发套页面的时候都保留了。。。其实,最根本的原因就是less和css combo解决的不是一类问题,less更多的是把css编程化,css combo只专注css模块打包。