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