修饰打印输出的页面。
g) 包含其他css的css
frontpage.css、list.css、detail.css、register.css等等
根据各种引用去引入相应的css。譬如list页面中没有需要表格的修饰，那就不引入table.css。以节约代码量。
3、css框架文件夹的建立
a) core 主要的
存放reset.css、layout.css、type.css、print.css
b) bud 模块
存放table.css、form.css、album.css等css
c) petal 具体应用
存放封装过的css。frontpage.css、llist.css、detail.css、register.css等css。这个文件夹存放的css都是被直接引用的。
文件夹的命名，按个人喜好啦! :) 我还希望用电子、质子等命名呢。嘿嘿！
4、css框架的优点
a) 提高开发效率。
b) 规范名称定义，便于维护。
c) 规范项目开发流程
d) css代码更清晰、简单。html代码更合理。
5、css框架的弊端。
a) 学习成本提高。你需要了解整个框架，需要阅读框架的文档。
b) css框架对于一个小项目等页面来说很臃肿。框架中可能有大部分你用不到的代码。
c)可能会无法帮助你的技术提高。太依赖框架，以至于很难排除bug。包括框架中本身就带的bug。
d) 选择自己需要的框架与开发框架都很痛苦。写到后面发现越来越不灵活，越来越臃肿。残念 -_-
6、开发及使用css框架中常遇到的问题。
1、页面外部引用样式过多。
譬如关于ul的margin定义,在格式化的css中会声明为0，而在基本样式的css中又可能会声明margin:5px 10px;
所以在Yslow中会出现多次定义。
2、组件复用性的考量。
譬如表单定义的css中定义了所有表单的修饰,而假定在注册这个页面中只是需要这个css的百分之三十。那是否应切割出去那不要的百分之七十?
综合以上的二个问题，个人认为解决的方式便是封装，让该有的有，不该有的没有。尽量减少http连接数和css的大小。但如果彻底是这样做的话，css的复用性又会变得很差，后期手工的封装会很痛苦。只能套用小马的一句话“具体情况，具体分析”。人生真是矛盾啊…
3、到底该不该支持em?
可见如要支持em，最大的目的是为了在浏览器中可以根据用户的分辨率大小自由缩放，对于拥有超大显示器的用户与小显示器的用户是非常有用的。可是在采集我们用户的浏览器数据后，发现分辨处于这二端的用户非常少，可想而知，为这部分的用户多花比正常开发一倍以上的时间显然是件不划算的事情，所以当初在开发tbsp的时候，我们团队就决定了不支持em。当然这是个建议，我们也希望能使用em带给用户最好的感受。
