项目中选择css框架的苦恼

优点
a) 提高开发效率。
b) 规范名称定义，便于维护。
c) 规范项目开发流程
d)css代码更清晰、简单。html代码更合理。
e) 大规模项目中可以减少用户下载
弊端
a) 学习成本提高。你需要了解整个框架，需要阅读框架的文档。
b)css框架对于一个小项目等页面来说很臃肿。框架中可能有大部分你用不到的代码。
c)可能会无法帮助你的技术提高。太依赖框架，以至于很难排除bug。包括框架中本身就带的bug。
d) 选择自己需要的框架与开发框架都很痛苦。写到后面发现越来越不灵活，越来越臃肿。
常见问题
1、页面外部引用样式过多。
譬如关于ul的margin定义,在格式化的css中会声明为0，而在基本样式的css中又可能会声明margin:5px 10px;
所以在Yslow中会出现多次定义。
2、组件复用性的考量。
譬如表单定义的css中定义了所有表单的修饰,而假定在注册这个页面中只是需要这个css的百分之三十。那是否应切割出去那不要的百分之七十?
综合以上的二个问题，个人认为解决的方式便是封装，让该有的有，不该有的没有。尽量减少http连接数和css的大小。但如果彻底是这样做的话，css的复用性又会变得很差，后期手工的封装会很痛苦。
3、到底该不该支持em?
可见如要支持em，最大的目的是为了在浏览器中可以根据用户的分辨率大小自由缩放，对于拥有超大显示器的用户与小显示器的用户是非常有用的。可是在采集我们用户的浏览器数据后，发现分辨处于这二端的用户非常少，可想而知，为这部分的用户多花比正常开发一倍以上的时间显然是件不划算的事情，所以当初在开发tbsp的时候，我们团队就决定了不支持em。当然这是个建议，我们也希望能使用em带给用户最好的感受。