css框架开发

1、css框架

中国的互联网行业已经发展了10年，浏览器也从最早流行的NS到现在的FF3.IE7等等……前端开发工程师的职位也诞生了。近几年在web开发中，有个非常火的词——“框架”。YUI、JQuery、Prototype这些javascript框架在开发网站时，确实成为前端开发工程师的手中利器。为什么呢？因为框架是包含工具、函数库、约定，以及尝试从常用任务中抽象出可以复用的通用模块，让设计师与程序员避免重复开发。通俗地讲便是把大多数重复工作的时间给节约了。

编写css也是一样，从最初只是定义文字颜色、内容排版，到现在定义所有的表现。css框架也渐渐被重视了，因为大家都认识到：从具象的表现中抽出抽象的模块来重复使用，是减少用户下载、方便团队及个人开发最重要的手段。

2、css框架的开发顺序

a) 格式化 reset.css

格式化css的真正好处是能够快速启动工作，你可以在新的HTML文件里引入框架，不用再处理重置padding 和 margins，实现统一的排版、浏览器下的相同表现。

b) 布局 layout.css

定义页面是二栏还是三栏，是全屏还是1024×768……

一个网站的设计可能有很多种布局，但是大多数都是由几个具有复用性的布局组成，选择性的引入所需要的布局，可以很快地应用所期望的页面布局。

c) 基本样式 type.css

定义body、h1-h6、a:link-a:active、p等的字体大小和颜色。
基本样式的css引用，譬如将ul定义class为“ul-text”，用来展现相同的icon、行间距、链接色彩。
还可以像这样应用：class=”ul-text square”，li前展现的是方型的icon。

d) 表格修饰 table.css

定义table、tr、td、th、thead、tfoot、tbody、caption等标签的表现。
和基本样式一样，但是表格在现有网站的展现形式几乎都是处理数据，所以分开存放引用。譬如在table上应用table-style-1便是黑色边框的表格，table-style-2便是黄色边框的表格。

e) 表单修饰 form.css

定义fieldset、label、button、input 、select、textarea这几个标签的表现。
大多数网站的表单、按钮、输入框几乎都是一样的。之所以引入这个css，是为了便于统一在各个浏览器中的展现。默认的按钮、输入框等在各个浏览器下的展现区别很大，虽然在格式化的css中已经初步的统一，但是输入框的边框，按钮的样式都是需要在这个css中定义的。无奈的是select无法做到统一，如果考虑到用js实现的话，这个成本太大了点。

f) 打印修饰 print.css

修饰打印输出的页面。

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带给用户最好的感受。