最近在 Weekly 邮件推送中查阅到这样的一条信息：
会发现这条信息里面出现了一个CSS的新名词 CSS Cascade Layers ，出于好奇以及对新知识的渴望（说得我自己都信了，哈哈），于是查阅起 CSS Cascade Layers 的相关资料，试图搞懂它。
at-rule 规则， CSS Conditional Rules Module Level 3 新增的规则，是一条语句，它为CSS提供了执行或如何执行的指令，常见的 at-rule 规则有：
级联(层叠)与继承 经过多年的发展迭代，目前已有多个版本（ CSS2.2、Level3、Level4 和 Level5 ）
何为级联（层叠）？
层叠本质就是定义了如何合并来自 多个源 的属性值的算法，简单来说，CSS规则的顺序很重要。当两条同级别的规则应用到一个元素的时候，写在后面的就是实际使用的规则。
两条规则 优先级相同 ，所以顺序在最后的生效， h1 是 color:blue '胜出'，显示蓝色。
css属性一般来自于哪几个源？
层叠（级联）算法如何过滤来自不同源的css规则？
过滤来自不同源的css规则后，确定同源优先级高低，决定谁“优胜”
了解级联算法有助于帮助我们理解浏览器是如何解决样式规则冲突，也就是浏览器决定哪个样式规则运用到元素上，更多相关 css级联 的了解：
何为继承？
当元素的一个继承属性没有指定值时，则取父元素的同属性的计算值 。只有文档根元素取该属性定义的默认值，类似的属性有 color 、 font-size 等 。
CSS是由 Cascading Style Sheets 三个词的首字母缩写，很多人将其称为 层叠样式表或者级联样式表 .
CSS Cascade Layers ，也叫做 CSS级联层 ，是 Cascading and Inheritance Level5 规范中新增了一个新的 CSS 特性，对应的CSS属性写法 @layer ,即 一个新的 @ 规则 ，也就是大家所说的 at-rule 规则。
为啥会出现@layer？
也就是说我们一般会使用选择器权重和顺序作为控制级联的方法，但是这样却会时常碰到：
使用较高权重的选择器来防止你的代码被后面的代码（或别人的代码）覆盖。但这也会引起另一个不良的现象，可能会在代码中新增很多带有 !important 的样式规则，这本身就会引起更多的问题，比如 !important 在 CSS 样式表中随处可见，需要覆盖的时候难以被覆盖 。
使用较低权重的选择器又很容易被后面的代码（或别人的代码）覆盖。比如你在引入第三方代码库或组件时，自己的代码可能被覆盖。
这两个现象也是编写CSS代码，特别是在一个大型项目或多人协作的项目中常出现。也给很多CSS开发者带来很多困扰。
虽然社区有很多第三方方案，如 CSS-in-JS 、 CSS Modules 和 CSS Scoped 等来协助解决级联所带来的问题，但由于 源码顺序（打包产物）仍然起着决定性的作用，顺序带来的覆盖和冲突依旧未真正的解决，而且选择器权重仍然比层的顺序（源码顺序）更重要 。
这样的背景促进了 @layer 的出现，要真正的解决级联带来的这些问题。
@layer 的出现，也要求我们对以往 css级联 有个新的了解,
可以看出 CSS的级联层 一般位于“Style 属性”（Style Attribute）和 CSS 选择器权重（Specificity）之间。
使用 CSS级联层 ，可以通过 @layer at-rule将 CSS 分成多个层。
1、使用@layer 块规则，并立即为其分配样式：
2、使用规则@layer 语句，没有指定任何样式：
3、将@import 与layer关键字或layer()函数一起使用
以上每一个都创建了一个名为 的级联层reset。
在下面的例子中，我们建立四个级联层： reset，base，theme，和utilities 。
重复使用级联层名称时，样式将附加到现有级联层。级联层的顺序保持不变，因为只有第一次的出现已经确定顺序：
重新使用级联层名称时层顺序保持不变的使@layer 语法变得更加方便和严谨。使用它，可以预先建立图层顺序，然后将所有 CSS 附加到它：
按以往CSS级联来进行分析的话， form input （多层级）的优先级会大于 input ,但是由于 级联层 所起的作用， @layer theme 的 input 会取胜。
级联层 支持嵌套使用，如下：
在这个例子中有两个级联外层：
就像一棵树，像这样，
如果要将样式附加到嵌套级联层，需要使用以下全名来引用它，
如果第一个 @media (min-width: 30em) 匹配（基于视口尺寸），则layout级联层层将在图层顺序中排在第一位。如果只有 @media (prefers-color-scheme: dark) 匹配，theme则将是第一层。
如果两者匹配，则图层顺序将为layout, theme。如果没有匹配，则不定义层。
随着 Cascade Layers 的出现，我们的开发人员将拥有更多的工具来控制 Cascade 。 Cascade Layers 的真正力量来自它在 Cascade 中的独特位置： Style 属性（Style Attribute） 和 CSS 选择器权重（Specificity） 之间。因此，我们不需要担心其他层中使用的 CSS 的选择器特异性，也不需要担心我们将 CSS 加载到这些层中的顺序.
了解到这里，是不是觉得 @layer 相当地cool，迫不及待地想去使用了，我们看一下 caniuse @layer 的兼容情况，
很遗憾，支持程度惨不忍睹，想真正使用可能还要再等等，对于明年三月份 Chromium 99 ,发布我们拭目以待。
当然现在如果想尝鲜，对于社区也有给出一些办法，
大家也可以试一试，感谢阅读！
DIV+CSS优点如下：
1、能够使代码精简，使用div+css布局使代码很是精简，css文件可以在网站的任意一个页面进行调用，避免了使用table表格修改部分页面。
2、提升了网页访问速度，div+css布局较传统的Table布局比较，减少了许多代码，其浏览访问速度自然得以提升，从而提升了网站的用户体验度。
3、有利于优化。采用div-css布局的网站对于搜索引擎很是友好，简洁、结构化的代码更加有利于突出重点和适合搜索引擎抓取。
4、浏览器兼容性 。DIV+CSS更容易出现多种浏览器不兼容的问题，主要原因是不同的浏览器对web标准默认值不同。
5、需要注意的是，网页不喜欢一个页面有太多的css代码，否则同样会影响蜘蛛的爬行，影响搜索引擎的收录，所以采用外部调用的方式调用CSS是非常不错的方法。
6、若非必须太多花哨的网站，采用CSS布局，同样可以到达所想要的效果。如网站导航中的文字颜色变化、css下拉菜单等。
扩展资料：
DIV+CSS对SEO网站优化能起的作用
1、精简的代码，使用DIV+CSS布局，页面代码精简，这一点相信对XHTML有所了解的都知道。代码精简提高了百度蜘蛛的爬行效率以及高效性，能在最短的时间内爬完整个页面，同时这样对收录质量也有一定好处。
2、提高访问速度、增加用户体验性
使得加载速度得到很大的提高，那么用户点击页面的等待时间就越少，用户体验性的增加相应的带来就是网站受到搜索引擎的喜欢，进而提高网站排名。
3、div+css结构清晰，很容易被搜索引擎搜索到，本来就是适合优化seo，降低网页的大小，让网页体积变得更小。
4、要注意的是：div+css结构清晰、精简，不意味着可以全部用div+css结构，比如通篇HTML标签全DIV的，貌似除了<head>之上及<body>之上及之外，其它全是<div>，就如同整个HTML是一万个毫不相干的内容拼装起来，或者通篇是<div><ul><li>结构的，就如同这个页面所有元素全是列表。
参考资料来源：百度百科-div css
在瞬息万变的前端开发世界中，很难找到一个真正有意义的概念，并且将其清晰明了的向广大人民群众普及。
把目光投向CSS，一个重大转折就是CSS预处理器的出现（在工具方面来看），其中， Sass 应该是最为著名的一个。此外，还有 PostCSS ，它和Sass略有不同，但是殊途同归——都是用浏览器不能解析的语法编写，并且最终编译成浏览器能够理解的语法。
现在，又有一位新的成员出现了，它就是 CSS模块 。本文就将介绍CSS模块化的诸多优点，以及如何编写模块化的CSS。
首先，让我们从官方文档入手：
事实稍微有一些复杂。由于类名需要 默认具有局部作用域 ，这就涉及到一些初始设置、一个编译过程，以及其他一些难以琢磨的东西。
但是最终，我们会为CSS模块化带来的好处而开心：CCS模块将作用域限制于组件中，从而避免了全局作用域的问题。我们再也不用操心为组件寻找一个好的命名了，因为编译过程已经帮你完成了这个任务。
CSS模块需要在构建步骤进行管道化，这也就是说，它不是自动驱动的。它可以看成是 webpack 或 Browserify 的一个插件。其基本工作方式是：当你在一个JavaScript模块中导入一个CSS文件时（例如，在一个 React 组件中），CSS模块将会定义一个对象，将文件中类的名字动态的映射为JavaScript作用域中可以使用的字符串。举个具体的例子：
如下是一个简单的CSS文件。其中， .base 类名不需要是工程中唯一的，因为它将不会是真正被解析的类名。它可以看成是在JavaScript模块中使用的类在样式表中的别名。
下面是该CSS类在JavaScript组件中的使用方式：
最终，它将生成下面这个东西（当使用webpack的默认步骤时）：
当然，生成的类名可以通过配置，使得它的长度更短或者遵循一些特定的模式。当然了，这些最终都不重要（虽然短的类名意味着更短的样式表），重点在于这些类名是动态生成的、唯一的且和正确的样式表一一对应的。
这就是CSS模块工作的方式了。这时，你可能会想，“这到底是个什么玩意儿，我甚至。。。”。OK，停下！我知道你想说什么。现在就让我一一解答你可能有的疑虑。
这看起来太丑了
确实如此。但是类名并不要求一定要长的好看对不对？只要可以将样式正确的应用于元素就可以了嘛。而CSS模块化方法完成的非常好，所以我觉得，这不是一个问题。
这非常难debug啊
由于需要有一个编译的步骤，所以直接debug是非常困难的。其实，像Sass直接debug也是相当不容易的，所以我们才有了 sourcemaps 。对于CSS模块，我们也可以设置sourcemap。
其实，我还想说的是，虽然在模块中，类的名字是自动生成而不可预知的，但是对于模块来说，它还是比样式表更容易debug的。只要你知道当前在开发者工具中查看的样式属于哪个模块，在相应的样式表中也是很容易定位。
这使得样式不容易复用啦！
这句话既对也不对。一方面来说，确实如此。但这是因为模块将CSS样式和组件相绑定，从而不会发生全局样式的冲突。这其实是一件好事，我相信你也会同意的对不对。
另一方面，要定义全局样式也是可以的，只要使用 :global() 就好了。比如，作者需要保留的全局辅助样式。
CSS模块还可以从其他模块中继承样式，这和Sass中的 @extend 方法其实是一样的。它不会拷贝样式，只是将选择器连接到继承的样式中。
它需要webpack，Browserify或者其他工具！
这和Sass需要将 .scss 文件编译成CSS文件，PostCSS需要将样式表处理成浏览器能够识别的样式其实是一样的。无论如何，都需要一个构建步骤。
我们究竟为什么要讨论这个东西？
其实，我甚至不确定CSS模块在未来到底会不会继续存在，不过，我确定这是一种编写样式的正确方式。试想，在拆分成许多细小组件的庞大站点中，却拥有一个臃肿的全局样式表，这肯定是不合适的。
CSS统一的名空间使得它既强大又脆弱。而CSS模块化或者未来延续这个思想的其他工具可以在支持样式复用的同时，避免命名冲突，这是一个双赢的选择。
如前面所说的，你需要有webpack或者Browserify来实现CSS模块化。
先从webpack版本的模块化开始。在 webpack.config.js 中，加上如下配置，使得webpack将CSS文件作为CSS模块来看待：
这时，它将把样式注入到页面中的``元素中。这可能不是我们想要的，使用 extract text plugin for webpack ，我们可以很方便的抽取出样式表：
对于webpack，要讲的就是这么多了。
我只在命令行中用过Browserify，所以我猜使用起来会更复杂一些。在 package.json 文件中，加入 npm script ：
这条命令告诉Browserify运行 src/index.js ，返回 dist/index.js ，并且使用 css-modulesify 将样式表编译至 dist/main.css 。如果你想再加上 Autoprefixer ，那么命令可以写成这样：
如你所见，使用 --after 选项可以在编译完成样式表时候，继续对它进行处理。
从今天看来， CSS模块化 系统和生态确实有些原始了，从Browserify中的配置就能看出来。不过，我确信CSS模块化将变得更好，并且越来越多的人将意识到不管对小项目还是大项目来说，这都是一个很好的方法。
我认为CSS模块化背后的思想是正确的。当然，我不是说这个库就是最佳解决方案，但是，它确实包含了一些CSS应该采用的写法：模块化、作用域隔离、同时支持复用。
最后，我向大家推荐项目作者Glen Maddern的文章 this introduction to CSS Modules 。
