CSS 设计模式

Thursday, April 4th 2019, 9:10:26 am ( ISO 8601 )

标签:

要对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、在文件头部建立一个简要的目录

/*
*...........公共样式
*...........引入图标
*/

2、使用区块注释

/*--------------------------------------------
这是一些注释
-----------------------------------------------*/

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

从结论出发

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

  • 层级嵌套不要太深

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

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

  • 避免使用元素选择器

出于两点考虑:

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

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

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

  • 避免使用群组选择器

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

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

  • 文件引入的数量和顺序

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

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

从现有模式出发

再来简单看看一些广为流传的模式。(ps:先后顺序与排名、好坏无关)

  • 一、OOCSS——Object Oriented CSS 接触过计算机的应该都知道,OOP——Object Oriented Programming,如果你是第一次接触OOCSS,你会很困惑,难道是“面向对象的CSS”吗?它不是一本真正的编程语言啊,如何面向对象?

OOCSS,最早被提及,是在2009年,它的两大原则是:

separating structure from skin and container from content.

直译过来就是,结构和皮肤分离,容器和内容分离。

即不要把结构和皮肤以及内容进行强耦合,而是相互独立,所要达到的目标是更易复用和组合,可以选择使用,选择引用等。

详细了解链接:https://www.smashingmagazine.com/2011/12/an-introduction-to-object-oriented-css-oocss/

  • 二、SMACSS——Scalable and Modular Architecture for CSS

从实践上说,OOCSS给出了一种值得借鉴的思想,但在代码的组织方面,它并未给出具体的实施方法,从这一点上来说,SMACSS更进一步。

它的核心是:

1、Base(基础) 基础的样式,就是一些需要最先定义好,针对于某一类元素的通用固定样式。

2、Layout(布局) 布局样式,是跟页面整体结构相关,譬如,列表,主内容,侧边栏的位置、宽高、布局方式等。

3、Module(模块) 模块样式,就是我们在对页面进行拆的过程中,所抽取分类的模块,这类的样式分别写到一起。

4、State(状态) 页面中的某些元素会需要响应不同的状态,比如,可用、不可用、已用、过期、警告等等。将这类样式可以组织到一起。

5、Theme(主题) 主题是指版面整个的颜色、风格之类,一般网站不会有频繁的较大的改动,给我们印象比较深的是QQ空间,其他应用的不是很多,所以,这个一般不会用到,但有这样一个意识是好的,需要用到的时候,就知道该怎样规划。

有了以上5点分类策略,我们的代码组织起来,思路就会很清晰,会安排的很有序,另外的好处是,可以解决命名难和混乱,之所以有这个问题,主因便是我们不知道以怎样的标准去定义元素的所属和特点,有了分类之后,我们不会很随意和混乱的去命名,有了依据,就能更轻松,也不易冲突。

详细了解链接:https://smacss.com/

  • 三、Meta CSS

原子类,也可以称之为“无语义”类,样式和结构、内容无关,预先定义好这么一组规则,在需要的地方加上即可,我相信每个人第一次看到这种写法的时候,都会想:还能这样写啊?!是的,总有一些人,一些新的思想和方法会涌现出来,它就是其中之一,当然,并不是在称赞其本身有多么好,而是说这种现象和过程是好的,它本身经常被人吐槽,比如:“这样写和直接内联有区别吗?”、“如果要调整样式,就要去改HTML,维护更加麻烦,也有违样式和结构分离的初衷”等等,其实我个人也是不赞成上面这种写法的,如果你要把这些抽离出来,那么还有什么抽不出来的呢?而且这些属性,在项目之间,页面之间,模块之间,并没有太大的通用性,把这些抽出来,只不过是稍微懒省劲儿些,但为了照顾到更多情况,你必须写入冗余代码,是得不偿失的。

虽然它有缺点,我个人赞成另外的一些东西分出来,比如:浮动(float)、文本布局(text-align)、Flexbox布局等,这些是没有那么多可能性的值,而且使用频繁,复用方便,改动较少,除此之外,你还可以提取另外一些公共的小颗粒类,比如按钮的种类,文字颜色的种类等,这些和CSS本身无关,和项目相关,这就是借鉴其思想,而不是直接拿来用。

  • 四、BEM

严格说来,BEM不是一套有骨有肉的模式,也不仅仅局限你在CSS的层面去规划,它是一种怎样去组织、编写代码的思想,而且,看似简单的它,对前端界的影响却是巨大的。

它的核心如下:

// Block(块)
// Element(元素)
// Modifier(修饰符)

它帮助我们定义页面中每一部分的级别属性,从某种意义上说,也是一种“拆”。 它的出现,曾给不少人带来启发,但是也有另一部分人仍然抱着挑剔的态度,譬如:

1、风格不统一,显得代码不够整洁美观 2、可能会导致类名过长

还是前面说的,你可以不去直接用它,但要清楚它的优点:能够使得我们仅通过类名就知道哪些代码是属于一个模块内,以及在模块中所起的作用。然后借鉴之。

当然,BEM集聚了很多人的心血,也得到了很多的赞誉,其中就包括OOCSS的作者。所以,它肯定不是这么简单。它还会告诉你,怎样配合着js来写,你的文件怎样组织更好,项目该怎么构建等。详细可以到官网去查阅。地址:https://en.bem.info/


Toweave

关于作者
本人是前端工程师 Toweave. 一个努力成为优秀工程师的男人.了解更多...

文章精选.

程序员的文字障
Friday, May 28th 2021, 2:31:26 am ( ISO 8601 )
什么是文字障?
文件类型判断
Friday, April 12th 2019, 1:51:30 am ( ISO 8601 )
常用的文件类型判断
vue 实例生命周期钩子
Thursday, April 11th 2019, 9:15:48 am ( ISO 8601 )
每个 Vue 实例在被创建时都要经过一系列的初始化过程——例如,需要设置数据监听、编译模板、将实例挂载到 DOM 并在数据变化时更新 DOM 等。
浏览器运行环境判断
Thursday, April 11th 2019, 9:05:35 am ( ISO 8601 )
常用的浏览器运行环境判断
现在很多人开网约车,这样能赚多少钱,能够赚到大钱吗?
苏州-虎丘
Saturday, April 6th 2019, 3:05:22 am ( ISO 8601 )
苏州虎丘一日游。
日积月累,你将完成不可思议的事情。
Wednesday, April 3rd 2019, 8:08:38 am ( ISO 8601 )
日积月累,你将完成不可思议的事情。
JavaScript Date 对象
Wednesday, April 3rd 2019, 6:18:56 am ( ISO 8601 )
Date 对象用于处理日期和时间。
常用正则表达式
Wednesday, April 3rd 2019, 3:47:31 am ( ISO 8601 )
正则表达式,一个十分古老而又强大的文本处理工具,仅仅用一段非常简短的表达式语句,便能够快速实现一个非常复杂的业务逻辑。熟练地掌握正则表达式的话,能够使你的开发效率得到极大的提升。下面是在前端开发中经常使用到的20个正则表达式。
上海-一朵梨花压海棠
Wednesday, April 3rd 2019, 3:05:22 am ( ISO 8601 )
一朵梨花压海棠。
CSS Selector 选择器
Tuesday, April 2nd 2019, 10:15:53 am ( ISO 8601 )
了解并且熟用 CSS3 为我们提供的强大并且优雅的选择器,就可以简化我们的代码。
对前端工程师的误解
Tuesday, April 2nd 2019, 9:51:16 am ( ISO 8601 )
隔行如隔山,经常会有一些不太了解前端工作者对前端开发的误解。
Material Design 中文版
Tuesday, April 2nd 2019, 9:28:52 am ( ISO 8601 )
Material Design 的核心思想,就是把物理世界的体验带进屏幕。去掉现实中的杂质和随机性,保留其最原始纯净的形态、空间关系、变化与过渡,配合虚拟世界的灵活特性,还原最贴近真实的体验,达到简洁与直观的效果。
Markdown - 使用指南
Tuesday, April 2nd 2019, 8:50:09 am ( ISO 8601 )
是一种轻量级的「标记语言」,它的优点很多,目前也被越来越多的写作爱好者,撰稿者广泛使用。
浮点数运算的精度问题
Monday, April 1st 2019, 10:33:53 am ( ISO 8601 )
根据浮点数的定义,非整数的 Number 类型无法用 `==` 来比较(`===` 也不行)
上海-顾村公园
Saturday, March 23rd 2019, 3:05:22 am ( ISO 8601 )
上海-顾村公园,摄影。
上海-世纪公园
Sunday, March 17th 2019, 3:05:22 am ( ISO 8601 )
上海-世纪公园,摄影。
Toweave's logo.
Sunday, March 3rd 2019, 8:08:38 am ( ISO 8601 )
Toweave's logo. 哈哈,2015 年,为自己设计的 logo。