CSS的发展动向
一、使用全局命名空间写css,用命名规范来避免命名冲突和重用性，需要程序员的功力
一旦你使用了全局命名空间（Global namespaces），就相当于打开了一扇麻烦的大门。麻烦就很快的到来。如果在代码中没有为对象提供唯一的名称，那么你将不可避免地面临命名冲突、各种副作用以及无法维护的代码问题相继到来。对于CSS来说，这意味着有布局的Bug，有CSS权重]的烦恼，很长的选择器和无法调试的CSS。因为每个选择器都可以针对不需要的元素，并与其他选择器发生冲突。
因为我们的社区有很多有才华的人，让我们有了OOCSS、BEM、SMACSS和其他类似的方法。这些都是非常有用的方法。他们通过预先设置好的类来解决命名冲突的问题。
他们的主要问题是手工操作，我们必须自己编写这些很长的选择器。但你也可以使用处理器（less sass等）来处理，不过它只是消除效果，而不是原因。这个问题仍然存在。
编写CSS代码时都有哪些痛点
-
全局污染 - CSS的选择器是全局生效的，所以在class名称比较简单时，容易引起全局选择器冲突，导致样式互相影响。
-
命名混乱 - 因为怕全局污染，所以日常起class名称时会尽量加长，这样不容易重复，但当项目由多人维护时，很容易导致命名风格不统一。
-
样式重用困难 - 有时虽然知道项目上已有一些相似的样式，但因为怕互相影响，不敢重用。
-
代码冗余 - 由于样式重用的困难性等问题，导致代码冗余。
在CSS的进化历史上，出现过各种各样的框架致力于解决以上的问题：
重用性：
**SASS, LESS - 提供了变量、简单函数、运算、继承等，扩展性、重用性都有了很大的提升，解决了一些样式重用冗余的问题，但是对于命名混乱问题的效果不大。
命名：
**BEM (.block__element--modifier) - 比较流行的class命名规则，部分解决了命名混乱和全局污染的问题，但class定义起来还是不太方便，比较冗长，而且和第三方库的命名还是有可能冲突。
二、出现模块化CSS
CSS Modules - 模块化CSS
将CSS文件以模块的形式引入到JavaScript里，基本上解决了全局污染、命名混乱、样式重用和冗余的问题，但CSS有嵌套结构的限制（只能一层），也无法方便的在CSS和JavaScript之间共享变量。
例子
CSS-Module.png
生成的dom结构如下图，基于css文件中的class名称生成了唯一的class名称，样式会定义到生成的class上。
生成的DOM结果.png
JSON文件styles 来存储原始类和映射出来的类。
CSS-in-js (在JavaScript里写CSS)
现在随着组件化概念的流行，对从组件层面维护CSS样式的需求日益增大，CSS-in-JS就是在组件内部使用JavaScript对CSS进行了抽象，可以对其声明和加以维护。这样不仅降低了编写CSS样式带来的风险，也让开发变得更加轻松。它和CSS Modules的区别是不再需要CSS样式文件。
多用在react框架中
CSS-in-JS框架有很多，介绍流行的2个
styled-component（携带样式的组件）
styled-component.png
会生成唯一的class名称，解决命名混乱和全局污染的问题。组件相关的代码都在一起，可以统一查看，也可以方便的重用样式。
glamorous（重写了一套标签，样式可以作为标签的属性来使用）
glamorous.png
glamorous的样式直接以attribute的形式定义在了dom上，之后虽然也为其生成了class名称及样式，但这种以attribute定义的方式对伪类选择符（如 :hover）支持的不好，会带来一些不方便，而且需要再记住一套attributes名称和值与真正的css样式代码的对应关系。
网友评论