SASS的问题很清楚。同时，新的CSS规格非常清晰，值得注意。我们试图鉴于这一点，我们回到纯CSS，但最终与之保持联系，因此这是该过程的摘要。
为什么我们首先使用Sass？
这对我个人和团队来说都是如此。我认为每个人在这个领域都不一样。
- 想要 nest 样式规则，当您想在不命名类的情况下样式标签时
- 想要 nest 按内容部分按内容来提高源代码的可见性
- 通过目的或内容进行分开文件以提高可搜索性
- 为大型项目定义和重复使用颜色模式
- 为媒体查询定义和重复使用屏幕宽度值
- 大型项目想使用
@extend到共享样式 - 有些项目使用
@mixin到共享供应商前缀（尽管最近我一直在使用AutoPrefixer）， 定义样式规则，共享断点，等。
您对Sass有什么困扰？
1.所有功能都是预设。
未使用的功能也是预设。如果我们作为一个团队不阐明我们要使用的功能的标准，那么新加入的成员很可能会使用每个功能并使审核过程变得困难。
2.语言实施已被弃用，需要迁移。
除了Dart Sass，Sass: Embedded Sass is Live
3.本质上，使用政策往往是不稳定的。
sass具有务实的策略，允许规格更改以匹配CSS设计理论，该理论被认为在现实世界中有用。以下功能是在被弃用的过程中，需要更改过去的代码
@import
@import即使以层次结构的方式使用@import，允许访问样式约定，但是该规范开始被视为有问题，而@use被用作替代方案。这意味着只能在调用它们的文件中访问样式约定。
4.可能与CSS身体规格发生冲突。
使用/的部门。
在CSS中，有一个使用/作为定界符的属性。
在这种情况下，SASS无法区分/是定界线还是除数。作为替代方案，我们建议Math.div。
Sass: Breaking Change: Slash as Division
顺便说一下，CSS怎么了？
cssdb - CSS Database定义了阶段**为新功能的标准化，称为阶段。
| 阶段 | 级别 | 成熟度 |
|---|---|---|
| stage4 | 标准化 | 高 |
| stage3 | 拥抱 | ： |
| stage2 | 允许 | ： |
| stage1 | 实验 | ： |
| stage0 | 抱负 | :: |
似乎随着舞台的上升，浏览器的支持实际上有所改善。
此外，postcss-plugins/plugin-packs/postcss-preset-env允许您遵守此阶段并使用将来将标准化的功能。
似乎我们在Sass中使用了很多功能。
| css | Postcss插件 |
|---|---|
| 嵌套 | 嵌套规则（阶段1） |
| CSS-NESTING | |
| 颜色重复使用 | 自定义属性（阶段3） |
| 重用媒体查询 | 自定义媒体查询（阶段2） |
| 类继承 | 讨论 |
| 混合 | 讨论 1 |
@apply正在讨论，但显然有一些技术问题使它变得困难。
请对每个规则的符号进行一些研究。
如何用于不同目的的混合蛋白
- 定义通用样式规则=>请勿采用单一类
- 公共供应商prefix => self -prefixer
- COMMON BRKINKPOINTS => CSS中的自定义媒体查询
低阶段规则规格非常不稳定
W3C定义的阶段不是官方发行版本，其使用量较低。
还必须考虑到规格更可能更改或拒绝。
。
在对CSS草案知识或经验很少之前，最好遵循Postcss-Proset-env的默认（阶段2）。
例如，嵌套规则仍在阶段1中，因此规范可能会更改。 如果您在Postcss-preset-env中实现它，则可能只需要在以后的嵌套部分重新实现。
。也许现在采用PostCSS-Preset-env还为时过早。
在上述所有讨论之后，采用Postcss-preset-env可能还为时过早。
从现在开始。
- 我们将使用Caniuse和其他工具来查看浏览器如何支持。
- 如果我们想要使用的功能阶段达到4，并且浏览器支持就足够了，我们将采用它。
- 我们将继续采用COSTCS，用于CSS本身以外的其他方法，例如Autprexier 。
我认为这就是我的想法。非常感谢。