190323&说说你对 CSS 的理解和认识

说说你对 CSS 的理解和认识

对于前端开发者来说，css 的使用已经司空见惯了。那对它到底有个什么样的理解和认识呢，下面我来说说我对其的理解和认识

囫囵吞枣来一遍

CSS 这项技术产生的原因，主要还是时代下的产物。当时网页特别流行，而对于样式的需求越来越迫切，CSS 就是用来解决网页的美观问题的。

对于如何使用 CSS 来说，最简单的做法就是跟着 w3cschool 的教程一个一个的学习一遍也就会了。

那么紧接着问题就来了，就这么简单吗？上手如此简单？

是的，会写 CSS 并不难，但能写好 CSS 那就不一定了。写代码的姿势有很多，想要得心应手的管理还真不是那么简单。

大致有这么几种方式。

• 直接写 CSS，不采用任何的 CSS 处理器
• 通过 CSS 处理器写，然后再编译成 CSS
• 直接写 CSS，通过 PostCSS 在处理
• 通过处理器编译出 CSS，再使用 PostCSS 二次加工
• CSS In JavaScript

一开始的时候，想尽办法在 类命名，命名空间，文件结构 3 个地方做处理，比如 BEM、SUITCSS、MCSS、AMCSS 等。

@simurai曾经总结过一些选择方法，但原文地址已经404了。大致摘取下来的内容是这样的：

Q: 我只需要创建一个单页面或简单的站点。内容以文本为主。没有人和我协作，就我自己。

A:简单就好。直接给 HTML 元素添加样式，连 class 都不需要。依赖级联关系，利用样式继承。随着站点增长，可能需要开始看看 OOCSS，或不时使用一些工具类。

Q:我们是一个中型团队。项目复杂度增长较快，采用多人协作。

A:使用 BEM、SUIT、SMACSS、ITCSS 或 Enduring CSS 等。它们各不相同，但也有相似点，在某些方面亦有重叠之处。它们所使用的命名约定，能保证你们之间不会发生冲突。和团队一起讨论下，在作出最终决定前，可能需要多进行一些尝试。

Q: 我们是有多个团队的大公司，产品庞大而复杂。跟踪变化相当困难。代码库不断变化，而我们又不想顾此失彼。 A: 使用 JSX、JSS，或其他类似的 CSS-in-JS 库。将 CSS 与 HTML/JS 绑在一起，更容易修改、移动或删除组件，而又不影响其他部分。还可以看看 ACSS 这样的 Atomic CSS，这是另一种解决相同问题的思路

一个 CSS 架构具备良好的可扩展性，细心的规划能提供下列的好处。

• 更少的样式
• 更少的样式冲突
• 更长的维护周期
• 更快的提升新团队成员
• 团队成员之间更容易交流
• 更平稳的项目交接

为此，也就创建了 CSS 的具体规则，每次编写之后，复查这些规则。

• 模块化：设计系统在每一个方面都是模块，这是非常实用写 CSS 的方法，但在组件之间需要清晰分隔。
• 可读性是关键：开发者必须在第一眼理解 CSS 代码，并且理解每一个选择器的目的
• 清晰胜过简洁：设计系统有时候看上去很冗长，但是作为交换，它提供清晰和韧性。保持 CSS 可读性和可扩展性意味着牺牲简洁的语法。
• 保持平面化：长的选择器要回避，无论什么地方，尽可能保持 CSS 独立 DOM 和模块化
• 避免冲突：因为组件会部署许多不用的应用，保证设计系统之间的 CSS 不会和其他的库和系统有冲突，这很重要。通过系统空间- [ ] 命名 Class 名可以完成这个。

再然后呢，出现了

• 像 Less、Sass 这样的预编译器，
• PostCSS 后编译器，
• CSS Modules 以及 Styled Components

总结来看呢，实际使用过程中，没有最好，只有更好，具体采用哪种方式，还是要依据实际的场景来取舍决定。
下面这张图提供了一些思考轨迹，可以借鉴和参考

不管以后如何发展，还是要具体情况具体分析。
回过头来想，CSS 既然现在能在布局，背景，文字，效果等方面做出让人惊叹的目的，那具体是怎么实现的呢？

其实对于 CSS 的实现机制，或者实现原理，主要还是来源于浏览器对 CSS 的解析。那这个问题其实就变成了“浏览器中是如何解析 CSS 的呢？”

具体可以按照以下这么几个方向去分析。

• 浏览器渲染

主要关注的几个问题。

• Webkit CSS 解析器
• CSS 选择器解析顺序
• CSS 语法解析过程
• 内联样式如何解析？
• 何谓 compoutedStyle？
• 不同的 CSS 选择器对于解析速度的影响

当然了，了解了这些实现原理，也就对我们在实际编写的过程中，提供了很多的指导意义。比如

• 对 id selector 的使用，
• 避免深层次的 node 节点
• 慎用 ChildSelector
• 不到万不得已，不要使用 attribute selector
• 理解依赖继承，如果某些属性可以继承，那么没必要再写一遍
• 规范真的很重要，对可读性和性能都会有很大影响。

对于目前 CSS 的局限来说，可能最大的还是来自于管理吧。如何根据具体场景写好 CSS，避免其他库的冲突并能提供很好的扩展性，以及团队内部更方便的去协作。是需要持续注意的一件事。

说到这，有些好奇。现在大部分招聘描述，对于 CSS 来说，是 CSS3 要熟练掌握，那 CSS3 是什么时候出的呢？之前的版本呢？在以前的开发中还真没想过这个问题。

CSS3，制定时间是在 1999 年，草案完成时间是在 2001 年的 5 月 23 号。

现在已经 2019 年了。如果按照完成时间算的话，也过去了 18 年了。突然感觉有些长，会不会马上明年或者后年就要出 CSS4 了。有些期待。拍脑袋瞎想的，根据以往的规则呢。

CSS2 是 1998 年 5 月 发布的。距离 CSS3 的版本只经历了 1 年。

CSS1 是 1996 年 12 月 发布的。距离 CSS2 的版本不到 1 年半的时间。最初是 1994 年 哈坤·利 提出的。

看这 CSS1，CSS2，CSS3 的版本间隔都是 1 年左右，可以大致判断，现在 CSS 的发展趋于稳定，基本满足了市场需求了。

所以呢，我对自己说：小伙计，你还是好好学习一下吧，把知识好好扎实一下。趁着 CSS4 还没出来。

参考

写 CSS 的姿势
探究 CSS 解析原理
CSS 规范 - 分类方法
了解 CSS 发展史和工作原理
你不懂得 HTML 与 CSS 的恋情发展史
CSS 是什么,CSS 版本发展
CSS-百度百科