html与css架构的一点体验_html/css_WEB-ITnose

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下的文件。