日期:2014-05-17  浏览次数:20618 次

html与css架构的一点体验

css本身,可以说是一门非常简单而容易入门的语言。制作一个页面,或者制作一个小企业站,对于css的要求都是非常低的。只要熟悉语法,通过英文单词的含义猜,都基本可以拼出一套样式。更何况市面上还有各种各样的辅助软件。

?

如果是一个比较大的网站,对css架构的要求就会相对高一些。比如,有一些可以公用的部分,可以提取出做模块。这个就是所谓的模块化。

?

模块化有什么优点呢?

?

在不去google各种结果的情况下,我脑袋中能反应到的主要有以下几点:

1,减少无意义的开发工作量——不需要复制粘贴某段样式代码到其他文件。

2,代码容易维护。如果模块样式有变更,只需要修改一个css文件即可。

3,配合对应的注释和目录结构,会让整个项目的html和css代码看起来更清晰。

?

但是模块化有时候就很纠结了。

在实际开发维护一个网站的过程中,html提供的模块,通常是按照功能来维护的。但是一般所谓css的模块化,是按照UI呈现来做的模块,模块的划分标准并不统一。

对于css本身的整理,我们会希望按照css来划分模块。但是对于html,包括提供给下游部门进行开发时,当然要提供html模块。他们并不关心css具体是如何划分和整合的。

?

于是,有了下面这种想法:

css分为5层结构

?

base层——是一些全站公用的基础样式和基础模块样式层(我把清0包括在这里了)。这个层相当于按照UI呈现来划分了模块。如果配合良好的UI规范,也可以保证整站的基础模块UI呈现一致。在大网站来说,这点应该是专业UI设计需要保证的。如果靠谱的话,base层甚至可以开发成一个网站的样式核心包。

?

module层——是功能模块样式层。这部分的css是由基础模块样式和非公用样式2部分组合而成的。

?

patch层—— 是补丁层。在用功能模块拼合页面的时候,将边距和其他一些模块中无法包含的样式放在patch中。(比如某个页面突然要求增加一个banner之类的)

?

pages层——是个是用import方式将module层和patch层的东西引入到页面的样式表文件。配合可以合并css的软件(可以google下关键字Merge可以搜到一些),将所有import的文件压缩在这个pages文件中上线。

?

tag层 —— 最上面的tag相当于实际压缩后上线的css代码,并不消耗开发成本。这样基本可以保证每个页面css的http请求只有1个。又可以满足本地模块化开发。

?

html对应的结构

?

html相当于分为4层。

base层 —— 对应css的base层。是整个UI规范样式和规范样式html代码的一个参考文件。

module层——对应css的module层。可以提供给其他开发人员,里面要写全该模块的所有状态。这样既可以保证后台开发人员很方便的找到某个功能的代码,又解决了有时候提供一个完整页面要牺牲掉部分状态的情况。比如一个按钮有2种状态,如果都放在页面上,页面就容易走样。如果不放在页面上,又不方便后台工程师开发。当然之前我是把其他状态写注释的方式写在页面上的,但是仍然有问题,就是经常需要去重复 注释/取消注释 这种无意义的劳动。

pages层——就是拼好的页面。module既然已经提供了具体的代码给后台的工程师们,那pages干啥呢?它存在的意义是告诉自己和其他人,每个模块需要放置的位置。还有提供宏观的预览。没有预览,总是不爽的吧!

?

dev层——其实这个是个纯开发用的。各种后台语言都有include可以用来管理公用模块。但是html却没有。为此DW还提供了个既强大又坑爹的模板功能。但是感觉很少有人用。不知道是因为操作复杂?不灵活?还是因为生成了一坨一坨注释?看起来很低级?不知道,反正我也没有。有幸的是xxx人帮忙开发了一个本地程序用来解决html的include问题。dev目录下的文件是按照此程序语法要求来写的。给定一个module下的url地址,然后自动合并html代码,生成pages下的文件。

?

?