[Kend C. Dodds]: […] 询问任何做过常规旧 CSS 的人，他们都会告诉你：“我不知道我是否可以更改它，所以我会复制它。” 现在我们已经有了——在 PayPal（这不是编造的），我在使用的项目中有 90% 的未使用 CSS，因为每个人都害怕触碰旧的东西。 所以我们只是复制了一个新的东西，并用另一个名字命名。 你可能会说我们不擅长 CSS，但也许 CSS 不擅长我们，我不知道…… [笑声]
[Emma Bostain]: 嗯，这就是为什么 styled-components 和 CSS-in-JS 如此关键；它就像“哦，嘿，我们实际上可以将所有这些逻辑封装在它正在触碰的组件内部，并且不必担心代码泄露了。” 删除、添加这些东西都容易多了。
[Kend C. Dodds]: 是的，你说得完全正确。 这就是这些东西被设计用来解决的问题。
音频剪辑
我之前多次听说过这个故事，通常来自大型公司。 许多开发人员，典型的开发人员流动…… 没有人知道哪些 CSS 实际上被使用，哪些没有被使用，因为 这是一个非常难的问题。
这就是我有时喜欢基于组件的样式解决方案（CSS-in-JS，如果你讨厌它）的原因之一。 不是因为我喜欢复杂的工具。 不是因为我喜欢 JavaScript 语法而不是 CSS。 而是因为样式和组件的共置。 因为没有人再害怕样式了——它们与它们要修饰的东西紧密耦合。 它不是每个项目都需要的，但是如果你正在使用组件构建（一种非常好的构建前端的方式， 不需要 JavaScript），你也可以用这种方式进行样式设置。
出于这个原因，我很高兴“作用域样式”在标准讨论中卷土重来。
我记得一个古老的想法（也许它甚至在浏览器中运行过一会儿？），你只需将一个 <style scoped> 块直接放到 HTML 中，无论父级是什么，样式都会作用于该父级。 真是太酷了，我希望我们能再次拥有它。
但似乎更新的东西（这里有 Miriam 的原始提案）有一些比这个基本概念更聪明的东西——比如能够设置下界而不是上界，从而可以对 DOM 中的 “甜甜圈形状”样式 进行作用域 (Nicole Sullivan 的一个术语)。 无论发生什么，没有 Shadow DOM 的作用域样式，零工具，这都是巨大的。
嗯？ 我是不是漏掉了什么？ 我以为实现 HTML 组件的唯一方法是使用 JS 来定义它…？
我的意思是，你可以用 JavaScript 组件进行创作，并生成静态 HTML 输出（比如 Astro）。
你可以使用模板语言构建纯组件 html 组件。 比如 twig 或 handlebars
阅读这篇文章让我想知道，为什么将组件文件保存在同一个目录中，并以组件命名，这样还不够。 通过使用一些类，我们可以有效地将样式/脚本绑定到我们的组件并为其作用域，对吧？
我知道它不像一个完整的 js 组件系统那样万无一失，但同时，我们是否希望团队中的开发人员无法遵循这样简单的流程？
我的意思是，我是不是漏掉了什么？ 我们难道不能像上面提到的那样，完全不用任何工具，就有效地为资源“作用域”吗？
我认为可以。 但没有强制执行意味着… 没有强制执行。 我认为，如果没有工具（或原生支持）进行真正的作用域化，团队将看不到近乎任何好处。
这正是我们所做的。 每个组件都有一个文件夹，包含其模板、css 文件和控制器/后端代码。 模板总是用一个类名与文件夹名相同的元素进行包装。 无法创建两个具有相同名称的文件夹，因此样式以这种方式进行作用域化。
听起来像是一个普遍存在的问题，可以通过广泛采用 web 组件框架来解决。
希望它能朝着这个方向发展
我们的生产 react 应用程序通过用一个 id=pageName 的 div 包装整个页面，将 css 作用域到特定页面。 然后，我们的 scss 文件以它们要修饰的页面的名称命名，所有内容都放在一个巨大的 #pageName { 块 } 内。 所有页面特定的组件都在那里进行样式设置，任何共享的组件都在一个全局的 components.scss 中进行样式设置。
Vue 开发人员
¯_(ツ)_/¯
听起来像是实习生/学生的工作，删除 css 样式并查看它对项目的影响，尝试查看它是如何工作的，并告诉我们你认为哪些部分没有作用。
模块化 css？ 为什么我应该浪费时间去命名像 main-section、details 之类的东西，如果我可以使用描述它们的模块化类呢？