欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  web前端

浅谈html的模块化布局_html/css_WEB-ITnose

程序员文章站 2022-04-30 10:56:47
...

在网站的初始开发阶段,当你拿到最初的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{}

等等。。。。

具体公用样式的粒度大小,可以在开发的过程中自己掌控,不过,最好是在并非整个模块都十分相似的条件下,粒度越小,越少的依赖父级结构越好。

使用模块化的开发方式,使得一个团队内部每个人的代码都几乎是一样的,这样改起别人的代码来就像改自己的代码一样,改起自己的代码来更加的快速和得心应手。

让每个人都能读懂我们的代码。无论经过多少版本的迭代,我们只需要增,删,改对应的模块文件与其对应的样式,不会遗留一坨坨不知所云的代码。