vnsc5858威尼斯城官网 > 澳门威斯尼斯人网址 > 【澳门威斯尼斯人网址】谈CSS的设计模式,没那

原标题:【澳门威斯尼斯人网址】谈CSS的设计模式,没那

浏览次数:76 时间:2019-09-16

没那么难,谈CSS的设计模式

2016/08/13 · CSS · 1 评论

原文出处: 灵感的小窝   

谈CSS的设计模式

2016/08/11 · CSS · 设计模式

原文出处: 灵感的小窝   

什么是设计模式?

曾有人调侃,设计模式是工程师用于跟别人显摆的,显得高大上;也曾有人这么说,不是设计模式没用,是你还没有到能懂它,会用它的时候。

先来看一下比较官方的解释:”设计模式(Design pattern)是一套被反复使用、多数人知晓的、经过分类的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问,设计模式于己于他人于系统都是多赢的;设计模式使代码编制真正工程化;设计模式是软件工程的基石脉络,如同大厦的结构一样。”

今天我们来聊聊CSS的设计模式。

设计模式,这个词汇我们常见,几乎所有的编程语言都会有几套,但深入研究的人不多,原因如下:

1、似乎没有太大必要性去强调它,有问题了改一下或者按团队规范来就行;
2、不去使用一些既有的模式也无伤大雅;
3、不少人所接触的业务量级还没有达到需要规划和组织的程度,光写布局,写特效,照顾兼容,就够喝一壶的了,没有意识去思考一些方法论的问题。

当然,这三者都是我经历过的,相信你也是~

我们都会长大,都会慢慢的做更多、更大、更复杂的项目,这个时候,就需要自上而下,全流程的去思考一些问题,后台不说,只讲前端,比如:风格的制定、色调、模块、布局方式、交互方式、逻辑等等,如果再加上团队合作,若再没有一个规划的话,要不了多久,那些看起来没问题的代码,就会暴露出各种问题,模块命名、类的命名、文件的组织、共用模块的提取、代码的复用、可读性、扩展性、维护性。它们看起来只是一些简单的小动作,却需要你看得更远,避免将来出问题需要付出更大的代价,甚至被迫整个项目重构,可谓,功在当代,利在千秋~

既然要对CSS进行设计,那么肯定是它本身存在一些问题或者缺陷,其中,一个最明显的就是,它的任何一个规则,都是全局性的声明,会对引入它的页面当中所有相关元素起作用,不管那是不是你想要的。而独立及可组合的模块是一个可维护系统的关键所在。下面,我们就从多个层面来探讨一下,到底该怎样写CSS,才是更科学的。

什么是设计模式?

曾有人调侃,设计模式是工程师用于跟别人显摆的,显得高大上;也曾有人这么说,不是设计模式没用,是你还没有到能懂它,会用它的时候。

先来看一下比较官方的解释:”设计模式(Design pattern)是一套被反复使用、多数人知晓的、经过分类的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问,设计模式于己于他人于系统都是多赢的;设计模式使代码编制真正工程化;设计模式是软件工程的基石脉络,如同大厦的结构一样。”

今天我们来聊聊CSS的设计模式。

设计模式,这个词汇我们常见,几乎所有的编程语言都会有几套,但深入研究的人不多,原因如下:

1、似乎没有太大必要性去强调它,有问题了改一下或者按团队规范来就行;
2、不去使用一些既有的模式也无伤大雅;
3、不少人所接触的业务量级还没有达到需要规划和组织的程度,光写布局,写特效,照顾兼容,就够喝一壶的了,没有意识去思考一些方法论的问题。

当然,这三者都是我经历过的,相信你也是~

我们都会长大,都会慢慢的做更多、更大、更复杂的项目,这个时候,就需要自上而下,全流程的去思考一些问题,后台不说,只讲前端,比如:风格的制定、色调、模块、布局方式、交互方式、逻辑等等,如果再加上团队合作,若再没有一个规划的话,要不了多久,那些看起来没问题的代码,就会暴露出各种问题,模块命名、类的命名、文件的组织、共用模块的提取、代码的复用、可读性、扩展性、维护性。它们看起来只是一些简单的小动作,却需要你看得更远,避免将来出问题需要付出更大的代价,甚至被迫整个项目重构,可谓,功在当代,利在千秋~

既然要对CSS进行设计,那么肯定是它本身存在一些问题或者缺陷,其中,一个最明显的就是,它的任何一个规则,都是全局性的声明,会对引入它的页面当中所有相关元素起作用,不管那是不是你想要的。而独立及可组合的模块是一个可维护系统的关键所在。下面,我们就从多个层面来探讨一下,到底该怎样写CSS,才是更科学的。

从需求出发


我们刚开始学习写字的时候,是不会去考虑,写出来的某句话好不好,文章结构合适不合适,因为我们是意识不到的。写代码也一样,刚开始,我们只是去定义规则,能用对了属性,语法正确,把页面实现出来了,就好。慢慢地,就会发现,页面也是有结构的,我们按照页面的结构去组织代码,会不会更好?比如,分成头部、导航、侧边栏、banner区、主内容区、底部等。

然而这样貌似还是不够,因为还有一些东西,复用度是很高的,又不好把它归为任何一个固有模块,比如:面包屑、分页、弹窗等,它们不适合被放到某一个固有模块的代码中,就可以单独的分出一段专属的css和js,或许,这就是组件化的由来~


在分了之后,我们的代码看起来已经比之前好很多了,组织清晰,维护性大幅提高,但是,好像还是不够,我们会发现另外一些东西,很细小,但复用度也很高,它们同样不适合被放到模块中去,比如,边框、背景、图标、字体、边距、布局方式等等。如果我们在每个需要它们的地方,都定义一次,它们会被重复很多次,显然,这背离好的实践,会造成代码冗余和维护困难。所以,我们需要“拆”。拆过之后会怎样?我们想在哪里用可以直接加,需要改的时候统一改。


经过了“分”、“拆”,我们的代码结构已经十分清晰,各个内容模块,功能模块,UI模块都乖巧的等待召唤,那么还差什么?是的,还差有序的组织,分类清晰之后,还需要排列有序,从不同纬度去考量,我们总能精益求精。举个栗子,我们可能会看到像这样:

@import “mod_reset.css”;
@import “ico_sprite.css”;
@import “mod_btns.css”;
@import “header.css”;
澳门威斯尼斯人网址 ,@import “mod_tab.css”;
@import “footer.css”;

我们将不同的部分按照一定的顺序去摆放,能让我们的代码看起来更加有序,易于维护,同时,有利于进行继承或层叠覆盖。不要小看这一步,看似可有可无,实际要求比较高的统筹规划能力,可以减少冗余代码和快速定位问题位置等。

除此之外,我们依然可以有其他的方法来帮助我们进行区分代码范围,比如:

1、在文件头部建立一个简要的目录

澳门威斯尼斯人网址 1

2、使用区块注释

澳门威斯尼斯人网址 2

在注释中,应该尽量详细的写清楚该段代码的目的,状态切换,调整原因,交互逻辑等等,这样不仅利于自己的维护,更加利于别人接手维护你的代码。

从需求出发


我们刚开始学习写字的时候,是不会去考虑,写出来的某句话好不好,文章结构合适不合适,因为我们是意识不到的。写代码也一样,刚开始,我们只是去定义规则,能用对了属性,语法正确,把页面实现出来了,就好。慢慢地,就会发现,页面也是有结构的,我们按照页面的结构去组织代码,会不会更好?比如,分成头部、导航、侧边栏、banner区、主内容区、底部等。

然而这样貌似还是不够,因为还有一些东西,复用度是很高的,又不好把它归为任何一个固有模块,比如:面包屑、分页、弹窗等,它们不适合被放到某一个固有模块的代码中,就可以单独的分出一段专属的css和js,或许,这就是组件化的由来~


在分了之后,我们的代码看起来已经比之前好很多了,组织清晰,维护性大幅提高,但是,好像还是不够,我们会发现另外一些东西,很细小,但复用度也很高,它们同样不适合被放到模块中去,比如,边框、背景、图标、字体、边距、布局方式等等。如果我们在每个需要它们的地方,都定义一次,它们会被重复很多次,显然,这背离好的实践,会造成代码冗余和维护困难。所以,我们需要“拆”。拆过之后会怎样?我们想在哪里用可以直接加,需要改的时候统一改。


经过了“分”、“拆”,我们的代码结构已经十分清晰,各个内容模块,功能模块,UI模块都乖巧的等待召唤,那么还差什么?是的,还差有序的组织,分类清晰之后,还需要排列有序,从不同纬度去考量,我们总能精益求精。举个栗子,我们可能会看到像这样:

@import “mod_reset.css”;
@import “ico_sprite.css”;
@import “mod_btns.css”;
@import “header.css”;
@import “mod_tab.css”;
@import “footer.css”;

我们将不同的部分按照一定的顺序去摆放,能让我们的代码看起来更加有序,易于维护,同时,有利于进行继承或层叠覆盖。不要小看这一步,看似可有可无,实际要求比较高的统筹规划能力,可以减少冗余代码和快速定位问题位置等。

除此之外,我们依然可以有其他的方法来帮助我们进行区分代码范围,比如:

1、在文件头部建立一个简要的目录

澳门威斯尼斯人网址 3

2、使用区块注释

澳门威斯尼斯人网址 4

在注释中,应该尽量详细的写清楚该段代码的目的,状态切换,调整原因,交互逻辑等等,这样不仅利于自己的维护,更加利于别人接手维护你的代码。

从结论出发

除了需求当中一些通用部分,另外一些也是需要注意,但不会被正式定义的东西,它们来源于我们的实践经验,比如:

层级嵌套不要太深

稍微了解一些浏览器渲染原理的都知道,它在解析CSS规则的时候,是从右向左,一层层的去遍历寻找,如果层级太多,必然增加了渲染时间,影响渲染速度。另外,如果选择器层级过多,也就间接反应了,你的HTML结构可能写得不够简洁。

那么具体多少层合适?一般建议是不超过4层,但话又说回来,超过4层会怎样吗?不会有多明显的影响,除非你写到很恐怖的数量,或者项目极其庞杂,可能能看出来影响,其实从我们日常需求来看,4层以内足可以解决绝大多数问题,故而,是合理的。

避免使用元素选择器

出于两点考虑:

第一点,和上一段提到的相关,在HTML中,有很多常用的高频元素,比如,div、p、span、a、ul等,如果,你在多层选择器的最内层使用了元素选择器,那么,在开始寻找时,浏览器就会遍历HTML中的所有该元素,显然,这是没有必要的。

第二点,我们的需求和代码结构都是存在着潜在变化的,今天写好了一个页面,明天可能就要再加进去一个按钮,再加进去一句话,再加进去一个图标。我们写好的一个结构,也随时可能被复用到别的结构中去,所以,如果,你使用了元素选择器去定死某个东西,不论是新加进来的东西,还是被复用的东西加到别的结构里去,都极有可能产生样式的冲突,这个时候,你又不得不写多余的样式进行覆盖修正,或者重新定义类。

所以,出于以上考虑,在具体的代码模块中,尽量不要使用元素选择器,使用元素选择器的前提是,你完全的确定,不会导致出现问题。注意,我用的限定范围是“具体的代码模块”,那么用于定义通用规则的样式,是可以的,也是推荐使用的,比如,reset。也可以是别的地方,这就需要我们自行考量。

避免使用群组选择器

群组选择器会有什么问题?直接上图吧。

澳门威斯尼斯人网址 5

图中这种情况不多见,此处只是举个例子,这里写了三组选择器,用来定义不同地方的同一种样式,其明显的缺陷是,如果有第四个地方需要使用到,你不得不再往里加一组选择器,如果有10个不同的地方,你就写10个?这对于维护来说,是很痛苦的,聪明的我们,怎能被如此繁复又不必要的劳动所困扰,故而,墙裂不推荐此种做法,完全可以提取出来一个公用类,定义统一样式,然后,哪里需要放哪里,复用和维护都会更加方便。

当然,你可能会说,我在写第一个的时候,不会知道后面还有那么多,有没有必要提取是不知道的,是的,所以,需要你根据经验去判断,也需要在项目推进过程中,适时的对代码进行整理和重构。

文件引入的数量和顺序

对于刚接触网页的朋友来说,这两点也是容易忽视的,因为它们看起来没什么大影响,多几次请求,样式是否已经加载,都没那么容易把人逼疯,但是出于对用户体验的极致追求,我们还是希望文件请求次数尽量少,内容的显示有个优先顺序,文件加载有个先后顺序,这样,在实在难以缩减文件大小的时候,让用户先看到更重要的,正常展示的内容。

以上只是几点举例,更多实战结论,大家可以多读相关的博文或者书籍,都会有前辈们的经验之谈。

从结论出发

除了需求当中一些通用部分,另外一些也是需要注意,但不会被正式定义的东西,它们来源于我们的实践经验,比如:

层级嵌套不要太深

稍微了解一些浏览器渲染原理的都知道,它在解析CSS规则的时候,是从右向左,一层层的去遍历寻找,如果层级太多,必然增加了渲染时间,影响渲染速度。另外,如果选择器层级过多,也就间接反应了,你的HTML结构可能写得不够简洁。

那么具体多少层合适?一般建议是不超过4层,但话又说回来,超过4层会怎样吗?不会有多明显的影响,除非你写到很恐怖的数量,或者项目极其庞杂,可能能看出来影响,其实从我们日常需求来看,4层以内足可以解决绝大多数问题,故而,是合理的。

避免使用元素选择器

出于两点考虑:

第一点,和上一段提到的相关,在HTML中,有很多常用的高频元素,比如,div、p、span、a、ul等,如果,你在多层选择器的最内层使用了元素选择器,那么,在开始寻找时,浏览器就会遍历HTML中的所有该元素,显然,这是没有必要的。

第二点,我们的需求和代码结构都是存在着潜在变化的,今天写好了一个页面,明天可能就要再加进去一个按钮,再加进去一句话,再加进去一个图标。我们写好的一个结构,也随时可能被复用到别的结构中去,所以,如果,你使用了元素选择器去定死某个东西,不论是新加进来的东西,还是被复用的东西加到别的结构里去,都极有可能产生样式的冲突,这个时候,你又不得不写多余的样式进行覆盖修正,或者重新定义类。

所以,出于以上考虑,在具体的代码模块中,尽量不要使用元素选择器,使用元素选择器的前提是,你完全的确定,不会导致出现问题。注意,我用的限定范围是“具体的代码模块”,那么用于定义通用规则的样式,是可以的,也是推荐使用的,比如,reset。也可以是别的地方,这就需要我们自行考量。

避免使用群组选择器

群组选择器会有什么问题?直接上图吧。

澳门威斯尼斯人网址 6

图中这种情况不多见,此处只是举个例子,这里写了三组选择器,用来定义不同地方的同一种样式,其明显的缺陷是,如果有第四个地方需要使用到,你不得不再往里加一组选择器,如果有10个不同的地方,你就写10个?这对于维护来说,是很痛苦的,聪明的我们,怎能被如此繁复又不必要的劳动所困扰,故而,墙裂不推荐此种做法,完全可以提取出来一个公用类,定义统一样式,然后,哪里需要放哪里,复用和维护都会更加方便。

当然,你可能会说,我在写第一个的时候,不会知道后面还有那么多,有没有必要提取是不知道的,是的,所以,需要你根据经验去判断,也需要在项目推进过程中,适时的对代码进行整理和重构。

文件引入的数量和顺序

对于刚接触网页的朋友来说,这两点也是容易忽视的,因为它们看起来没什么大影响,多几次请求,样式是否已经加载,都没那么容易把人逼疯,但是出于对用户体验的极致追求,我们还是希望文件请求次数尽量少,内容的显示有个优先顺序,文件加载有个先后顺序,这样,在实在难以缩减文件大小的时候,让用户先看到更重要的,正常展示的内容。

以上只是几点举例,更多实战结论,大家可以多读相关的博文或者书籍,都会有前辈们的经验之谈。

本文由vnsc5858威尼斯城官网发布于澳门威斯尼斯人网址,转载请注明出处:【澳门威斯尼斯人网址】谈CSS的设计模式,没那

关键词:

上一篇:没有了

下一篇:【澳门威斯尼斯人网址】改动CSS世界驰骋准绳的