互联网上有许多通用的方案,这里我着重提三点:
1.模块化CSS,提高代码重用 我们知道,一个成熟的网站需要有统一的风格,一致的用户体验,比如:网站的配色,字体的大小,交互行为一致等应该在设计之初就得到确定,而不是由个体开发者来自由的定义。网站同时应存在可以提取出来公用的样式部分(如人人网中个人主页右侧的”最近来访“,”推荐“等处的容器和标题都是相同的展示效果)。那么我们就可以把网站的字体大小,公共控制,共用模块的样式都抽离出来,作为单独的模块来处理。这样,团队中的每个人如果需要这样的样式,都可以用这种公共样式,以此提高代码的重用率。 我认为一个项目的CSS可以拆分成2部分:公共CSS和业务CSS。我们在项目中抽出的这部分可以模块化的CSS就可以归类为公共CSS。这部分的代码命名不应涉及到具体的业务,只应对其在模块中负责的具体逻辑负责。
对于业务CSS,我们需要有统一的命名。如一个网站中有如下几个栏目:文件,社区,社交关系等,在项目规划时,就需要把这块模块的名称定好,比如 文件-files,社区-cmty(community简写),这样开发人员在写样式时,就可以使用公用的前缀,.cmty-cmtydetail,而不会根据各自的想法,写成.community或是.commu,这一点对于统一风格是尽为重要的,也方便备用人员接手工作。
关于这方面,可以看看网上关于 面向对象的CSS / OOCSS
2.CSS合并、压缩 顾名思义,在团队开发中,开发者会分别处理各自单元的样式,网站上线了,为了减少http连接数,我们需要把这些CSS合并起来做为一个文件来加载,同时,我们在开发时可能会加入一些注释和行缩进,这些都会浪费我们的带宽,我们需要把合并后的CSS文件再进行压缩,事实上,这样的优化效果也是十分明显的,文件大小会节约至少20%。 目前互联网上对CSS合并的处理有两种:静态合并和动态合并。静态合并是指在网站部署上线前,已经完成了CSS的合并,并生成一个静态文件,动态合并是配合后端文件而实现的合并,既请求CSS时,把需要合并的所有CSS名称做为参数,传给一个后端文件(asp,php,aspx等),由该后端文件动态的生成合并后的样式并输出。两种方案各有利弊。
我在这里想表达的是,我们在项目中应根据项目的类型,应用不同的合并方案,门户型网站对首次加载速度要求较高,我们并不需要合并所有的CSS进来,而社区型的网站,用户需要登录才可以访问,那么就可以利用用户输入的时间加载所有的CSS进来,在以后的访问中都可以省去CSS请求的时间。
3.统一CSS书写规范 好处是不言而喻的,无论是后台前台,统一的代码规范是必须的。1.一律使用小字字母2.尽量使用ShortHand形式,在font,margin,padding,background中3.处理父子关系的节点时,使用 .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复杂的多)
中国足彩网信息请查看IT技术专栏