团队开发中的CSS规范建议
2011-03-17 00:00
1551 查看
互联网上有许多通用的方案,下面总结一下一些方法。
我认为一个项目的CSS可以拆分成2部分:公共CSS和业务CSS。我们在项目中抽出的这部分可以模块化的CSS就可以归类为公共CSS。这部分的代码命名不应涉及到具体的业务,只应对其在模块中负责的具体逻辑负责。
对于业务CSS,我们需要有统一的命名。如一个网站中有如下几个栏目:文件,社区,社交关系等,在项目规划时,就需要把这块模块的名称定好,比如 文件-files,社区-cmty(community简写),这样开发人员在写样式时,就可以使用公用的前缀,.cmty-cmtydetail,而不会根据各自的想法,写成.community或是.commu,这一点对于统一风格是尽为重要的,也方便备用人员接手工作。
关于这方面,可以看看网上关于 面向对象的CSS / OOCSS。
目前互联网上对CSS合并的处理有两种:静态合并和动态合并。静态合并是指在网站部署上线前,已经完成了CSS的合并,并生成一个静态文件,动态合并是配合后端文件而实现的合并,既请求CSS时,把需要合并的所有CSS名称做为参数,传给一个后端文件(asp,php,aspx等),由该后端文件动态的生成合并后的样式并输出。两种方案各有利弊。
我在这里想表达的是,我们在项目中应根据项目的类型,应用不同的合并方案,门户型网站对首次加载速度要求较高,我们并不需要合并所有的CSS进来,而社区型的网站,用户需要登录才可以访问,那么就可以利用用户输入的时间加载所有的CSS进来,在以后的访问中都可以省去CSS请求的时间。
一律使用小字字母
尽量使用ShortHand形式,在font,margin,padding,background中
处理父子关系的节点时,使用 .parent-child-grandson(大多时候parent名称与具体业务的模块名称相关) 写法 ,而不使用 .parent .child .grandson,事实证明后者在在团队开发中更容易造成模块间的样式覆盖,同时也更不易于阅读。一个简单的例子:在模块一中有一列表,用第二种写法大致如下:
而同时,在模块二中也存在一列表,开发者正好也用到了.listitem,而且认为这个命名不常见,前面没有加上限定,直接使用了.listitem ,这样就极容易造成了样式冲突。或许您提出不同意见:我们强制让所有的样式前面都加一个关于其模块名的限定,把模块二中的.listitem改成 .module2 .listitem,不就ok了?但这样并不好,因为在实际应用中,不能要求所有的样式写法一定要加上模块限定,比如在body节点下的某个浮动节点,我们就不能这样处理。
同时,针对第一种写法,我们还可以很轻松开发出一个CSS的检测软件,用来检测语法,判断覆盖。(我们知道判断出.a .b, .a>b,.b的覆盖关系远比.a-b复杂的多)。
模块化CSS,提高代码重用
我们知道,一个成熟的网站需要有统一的风格,一致的用户体验,比如:网站的配色,字体的大小,交互行为一致等应该在设计之初就得到确定,而不是由个体开发者来自由的定义。网站同时应存在可以提取出来公用的样式部分(如人人网中个人主页右侧的"最近来访","推荐"等处的容器和标题都是相同的展示效果)。那么我们就可以把网站的字体大小,公共控制,共用模块的样式都抽离出来,作为单独的模块来处理。这样,团队中的每个人如果需要这样的样式,都可以用这种公共样式,以此提高代码的重用率。我认为一个项目的CSS可以拆分成2部分:公共CSS和业务CSS。我们在项目中抽出的这部分可以模块化的CSS就可以归类为公共CSS。这部分的代码命名不应涉及到具体的业务,只应对其在模块中负责的具体逻辑负责。
对于业务CSS,我们需要有统一的命名。如一个网站中有如下几个栏目:文件,社区,社交关系等,在项目规划时,就需要把这块模块的名称定好,比如 文件-files,社区-cmty(community简写),这样开发人员在写样式时,就可以使用公用的前缀,.cmty-cmtydetail,而不会根据各自的想法,写成.community或是.commu,这一点对于统一风格是尽为重要的,也方便备用人员接手工作。
关于这方面,可以看看网上关于 面向对象的CSS / OOCSS。
CSS合并、压缩
顾名思义,在团队开发中,开发者会分别处理各自单元的样式,网站上线了,为了减少http连接数,我们需要把这些CSS合并起来做为一个文件来加载,同时,我们在开发时可能会加入一些注释和行缩进,这些都会浪费我们的带宽,我们需要把合并后的CSS文件再进行压缩,事实上,这样的优化效果也是十分明显的,文件大小会节约至少20%。目前互联网上对CSS合并的处理有两种:静态合并和动态合并。静态合并是指在网站部署上线前,已经完成了CSS的合并,并生成一个静态文件,动态合并是配合后端文件而实现的合并,既请求CSS时,把需要合并的所有CSS名称做为参数,传给一个后端文件(asp,php,aspx等),由该后端文件动态的生成合并后的样式并输出。两种方案各有利弊。
我在这里想表达的是,我们在项目中应根据项目的类型,应用不同的合并方案,门户型网站对首次加载速度要求较高,我们并不需要合并所有的CSS进来,而社区型的网站,用户需要登录才可以访问,那么就可以利用用户输入的时间加载所有的CSS进来,在以后的访问中都可以省去CSS请求的时间。
统一CSS书写规范
好处是不言而喻的,无论是后台前台,统一的代码规范是必须的。一律使用小字字母
尽量使用ShortHand形式,在font,margin,padding,background中
处理父子关系的节点时,使用 .parent-child-grandson(大多时候parent名称与具体业务的模块名称相关) 写法 ,而不使用 .parent .child .grandson,事实证明后者在在团队开发中更容易造成模块间的样式覆盖,同时也更不易于阅读。一个简单的例子:在模块一中有一列表,用第二种写法大致如下:
.informationlist{} .informationlist .listitem{}
而同时,在模块二中也存在一列表,开发者正好也用到了.listitem,而且认为这个命名不常见,前面没有加上限定,直接使用了.listitem ,这样就极容易造成了样式冲突。或许您提出不同意见:我们强制让所有的样式前面都加一个关于其模块名的限定,把模块二中的.listitem改成 .module2 .listitem,不就ok了?但这样并不好,因为在实际应用中,不能要求所有的样式写法一定要加上模块限定,比如在body节点下的某个浮动节点,我们就不能这样处理。
同时,针对第一种写法,我们还可以很轻松开发出一个CSS的检测软件,用来检测语法,判断覆盖。(我们知道判断出.a .b, .a>b,.b的覆盖关系远比.a-b复杂的多)。
相关文章推荐
- 简明 HTML CSS 开发规范
- 团队协同动态CSS开发[个人觉得比less方便]
- 团队项目开发"编码规范"系列文章
- Android 项目开发建议标准规范
- 前端开发中觉得有必要规范CSS书写顺序
- iOS开发编码建议与规范(持续更新中)
- 关于团队合作的CSS命名规范
- 团队开发规范(MSF)以及基于.Net的需求分析和解决方案设计
- 团队项目开发"编码规范"系列文章
- (zz)简明HTML CSS 开发规范
- Web前端开发规范文档(css/javascript)
- 开发规范3:CSS
- 前端开发规范:命名规范、html规范、css规范、js规范
- 团队项目开发"编码规范"之一:概述
- 关于团队合作的css命名规范
- 团队项目开发"编码规范"之九: 代码分析
- Discuz!开发之模板制作CSS扩展规范与语法规范
- 【收藏】关于团队合作的css命名规范
- 打造最佳开发团队的几点建议
- CSS那些事!这个篇幅是我特意开的,不是因为帮助小菜之类的,而是在多人的团队配合中各种命名冲突的规范让人蛋疼