浅谈html的模块化布局_html/css_WEB-ITnose
在网站的初始开发阶段，当你拿到最初的psd设计稿时，你是如何下手开始的呢？
你是依据什么划分网页的结构的？
你将依据什么如何提取网页内部的公用样式呢？
模块化的布局，最大的好处，便是易于开发和维护。更好的响应需求的变更。模块之间不相互依赖，又有一定的共性。
模块化的布局通常应用在大型的互联网网站开发中。
它的网站架构更需要的是在合理的嵌套中保持最好的健壮性，可拓展，易维护性。
例如：
你是否曾经经历改版时部分功能的删除与修改，而此时你将要费心费力的去寻找此部分功能的htm和css代码，而css又有可能分布在不同的css文件中。你从不敢轻易删除一段样式的代码，因为你怕别的功能也应用了此段代码。
如果，你接受的是另一个人开发的项目，那么恭喜你，你每删除一段代码都将战战兢兢。。如果你不删除此段代码，长此以往将留下一大段的“历史遗留问题”。
例如：
你是否曾经经历在开发过程中，一个class的类名被命名的又臭又长，因为如果不这样的话，你将有可能跟其他的部分的class产生冲突，或者样式被覆盖。
你是否曾经看到过一段样式的代码。如.title 。你有点记不起它在什么地方应用过，却又不得不留着它，并且在你以后的开发过程中，绕开.title的命名。
………
而对于我们这些有代码洁癖的的程序猿们，都希望看到整齐，有序的代码。并且希望我们的代码，每一行都不需要冥思苦想而能够轻松的知道它的作用和应用场景。
在模块化的布局中，有模块文件和模板文件。
在开发的过程中，将把这些模块提取出来。为其单独建立一个文件，为模块文件，而引入了这些模块的页面，为模板文件。。
请看下图示例：
模板文件
模块文件：
这些模块将有一个唯一的id属性是模块名，一般为文件名。
在网页开发过程中，非常不推荐id使用在除文档架构层以及除标识模块名之外的地方。因为除模块名之外，基本没有永远唯一的，不变的功能。
这些模块将有一个公用的class标识”g-mod”来标识他是一个独立的模块。
g-mod可以没有任何样式，它的存在仅仅是在网页结构中标识一个模块。
那么一个模块内部的结构又是什么样的呢？
首先，模块必定要有头部，我们为头部起一个名字叫.hd 。
头部中必定有一个title。有人会问，如果没有title该怎么办，没有title只是在页面的展示中没有一个明显的标题，但是模块本身是要有标题的。
我们可以将此标题写在页面中，并且用css将其隐藏，这样做的好处是在某些辅助阅读工具在抓取我们的网页时，文档的大纲会清晰明了。也会使我们的网页更加语义化。
其次，便是模块的主体部分 ，我们为其起一个名字叫 .bd。
我们会将模块的大部分内容写在此处。
然后，是模块的尾部，我们可以把模块的一些次要内容，花边类的东西放在这个地方。 我们给它起名字叫 .ft。
如果没有这部分，我们可以不要模块的尾部。
那么，一个模块的结构图如下
这个时候，可能会有同学觉得，如果所有的模块都这样命名，是否会有样式冲突？
我们在写css的样式的时候，每个模块的样式，都会在样式前声明自己的“命名空间”。所以不同模块内部的相同命名的元素样式不会相互覆盖与干扰。
例：
说到命名，又想絮叨几句，
模块的ID名，通常要完整，最起码通过模块的ID命，可以定位到是哪个模块。是做什么的。
而样式的class名，最好是要多简洁有多简洁，不要带上位置，模块的信息，避免一切的冗余。在命名的过程中不必担心与其他模块的命名相冲突，又有那么一点点语义化。
这样我们可以通过阅读一行css，而快速的在脑海中知道，这一行的css是对应哪里的样式。
如#apprise .list{}，我们通过读这一行样式，就会知道，此页面中有一个“评价”功能的模块，有一个列表。而#apprise li .date{},我们就会知道这行css是为了“评价”模块的列表中的时间信息所写。
在上面的图中，我们会看到，在模块化的布局中，css的写法也会实现类似“封装”的视觉效果。在我们需要更改某个地方的时候，也会更加快速的定位到这个地方的样式。
换一种说法就是我们不希望直接出现
.bd{} ;
.title{};
.name{};
这样的样式。因为这样的写法让我们茫然，让我们不知道他被哪些地方用到过。而且占用了.title,.bd这样的命名，会让我们下次不敢随意在页面制作的过程中使用这几个类名。
而我们希望的是
#crumb .bd{}
#curmb .title{}
#newslist .name{}
这样的方式，让我们一看就知道他大概会出现在什么位置。
有人会说，这样会平白无辜的在每一行样式前面多了一层深度。影响性能的。
但是，我们现在的电脑，已经不是N年前的486，我们现在的浏览器，已经不是N年前的IE5。多这样的一层嵌套。根本不会影响多少性能，却使我们的代码具有更好的健壮性和阅读性，在大型的互联网站开发中，版本不停的升级迭代。代码的可维护性需求远远高于性能。
如果是模块和模块之间有很大的相似度，我们可以直接写一个公用的模块。如：
/* g-newlist for module news1 , news2 */
.g-newlist{};
.g-newlist .hd{};
.g-newlist .bd{};
.g-newlist .ft{};
在模块文件中我们可以如此使用。
其中g-newlist 中的“g-”为global的缩写。当我们看到”g-”的时候，我们马上会知道，它是一个全局的样式。基础的类。
注释不可丢，一个公用的模块样式，要注释他为哪几个模块服务。
如果这两个模块有相似，又有所不同，都带了一点点个性化的东西，该怎么办呢？
大家知道，id的优先级是比class高出一个山坡的。
公用部分：
.g-newlist{};
.g-newlist .hd{};
.g-newlist .bd{};
.g-newlist .ft{};
个性化部分：
#news1 .ft{}
#news1 .ft .link{}
#news2 .bd{}
是不是完美解决了呢？
如果不是模块和模块之间有很大相似度，而只是一个小小的地方，如icon，在到处被用到。
我们可以写
.g-ico{}
.g-ico-sina{}
.g-ico-pptv{}
等等。。。。
具体公用样式的粒度大小，可以在开发的过程中自己掌控，不过，最好是在并非整个模块都十分相似的条件下，粒度越小，越少的依赖父级结构越好。
使用模块化的开发方式，使得一个团队内部每个人的代码都几乎是一样的，这样改起别人的代码来就像改自己的代码一样，改起自己的代码来更加的快速和得心应手。
让每个人都能读懂我们的代码。无论经过多少版本的迭代，我们只需要增，删，改对应的模块文件与其对应的样式，不会遗留一坨坨不知所云的代码。