随着原子 CSS（也称为功能性 CSS）越来越受欢迎，一些类似的相关术语也随之出现了一些混淆。本文旨在澄清这些术语。
有一些 其他项目 使用“原子”一词，包括 Brad Frost 的 原子化网页设计。原子 CSS 与这些概念是**完全独立**的。
让我们从定义原子 CSS 开始
原子 CSS 是一种 CSS 架构方法，它偏爱小型、单一用途的类，其名称基于视觉功能。
编写原子 CSS 的方法有很多种（参见下面的变体）。一个例子如下所示
.bgr-blue {
background-color: #357edd;
}“原子 CSS”一词由 Thierry Koblenz 在他 2013 年 10 月的基础文章 “挑战 CSS 最佳实践” 中创造。
一段时间后，有些人开始将这种方法称为“功能性 CSS”。尽管过去曾有将功能性 CSS 用于描述其他事物的案例，但如今功能性 CSS 和原子 CSS 两个术语可以互换使用。
虽然原子 CSS 一直是源自 Thierry 原创文章的一个开源项目的名称，但该术语本身适用于架构理念，而不是任何一种特定的变体（参见下文）。
原子 CSS 的变体
静态
许多人编写原子 CSS 的方式与他们一直以来编写 CSS 的方式非常相似。通常使用预处理器生成一个类库，其中包含定义基于单元的设计系统（用于间距、颜色、排版等）的设置变体。
这种风格的优势在于，由于它很熟悉，因此入门门槛较低，并且那些不熟悉 CSS 的人更容易理解。
编程
编程方法的原子 CSS 涉及使用构建工具根据在 HTML 中找到的内容自动生成样式。
例如，给定以下内容
<!-- Programmatic Atomic CSS Example -->
<div class="Bgc(#0280ae) C(#fff) P(20px)">Lorem ipsum</div>将生成以下 CSS
.Bgc\(#0280ae\) { background-color: #0280ae; }
.C\(#fff\) { color: #fff; }
.P\(20px\) { padding: 20px; }这种风格的原子 CSS 使用了带有参数的函数调用的 语法。正如使用 Atomizer 以编程方式生成样式的开源 ACSS 项目 所示，现在无需编写任何 CSS。在构建过程中生成的样式表已完全优化，没有任何未使用的样式。
长手写/短手写
长手写风格偏爱更易读的类名（参见 表达性 CSS 和 Solid），而短手写风格则偏爱简洁性（参见 Tachyons 和 Basscss）。
/* Shorthand Atomic CSS Examples */
.bg-blue { background-color: #357edd; }
.f1 { font-size: 3rem; }
.ma0 { margin: 0; }
/* Longhand Atomic CSS Examples */
.bgr-blue { background-color: #357edd; }
.background-blue { background-color: #357edd; }
.backgroundcolor-blue { background-color: #357edd; }
.text-h1 { font-size: 3rem; }
.text-3rem { font-size: 3rem; }
.text-huge { font-size: 3rem; }
.fontsize-1 { font-size: 3rem; }
.marg-0 { margin: 0; }
.margin-0 { margin: 0; }
/* Programmatic Shorthand */
Bgc(#357edd) { background-color: #357edd; }
/* Programmatic Longhand */
bgrBlue(#357edd) { background-color: #357edd; }
backgroundBlue(#357edd) { background-color: #357edd; }
backgroundColorBlue(#357edd) { background-color: #357edd; }相关术语
实用程序类
实用程序类（也称为辅助类）易于理解，是帮助处理常见样式模式的单一功能类（例如 .clearfix、.hidden）。
许多 CSS 架构都依赖于实用程序类（例如网格、间距、排版），但不一定完全遵循原子 CSS 的概念。
不可变 CSS
原子/功能性 CSS 的一个方面是，实用程序类永远不会被修改，从而产生高度可靠的结果。
不变性在原子 CSS 架构的正确执行中起着至关重要的作用。如果没有它，您将面临以下风险
.black {color:navy;}原子 CSS 旨在将复杂性从样式表转移到 HTML 中。当原子 CSS 项目中发生设计更改时，最好拥有结构良好的 HTML 模板，以便例如，您可以使用编辑工具快速将 Bgc(colorOne) 更改为 Bgc(colorTwo)，无论您需要在哪里更改。
断点前缀
此技术是一种允许实用程序类在不同断点覆盖样式的方法，从而使响应式网页设计的实现变得简单高效。
/* Examples of breakpoint prefixing */
.grid-12 /* Full width by default */
.m-grid-6 /* 2 column at medium screen sizes */
.l-grid-4 /* 3 column for large screen sizes */入门
下面列出了您可以根据自己的喜好选择不同变体开始使用的资源。
- 对于原子爱好者：原子 CSS 快速入门 或 什么是原子 CSS （视频）
- 对于库爱好者：Tachyons 入门 （视频）
- 对于大胆的设计师：使用设计系统烹饪
- 对于重构叛逆者：使用 Tachyons 和功能性 CSS 在 10 天内完成完整重写 （案例研究）
- 对于反应式反应器：Tachyons 和 React 以及 CXS
此外，以下是一些值得阅读的基础文章
“在现实世界中”
原子 CSS 特别是在那些将其用于快速原型设计以及大型持续前端项目的人群中越来越受欢迎。
- 雅虎！
- Solid 由 Buzzfeed 开发
- Shed 由 TED 开发
- 漫威应用程序样式指南
- Tachyons 图库
感谢 Thierry Koblenz 对本文的反馈以及多年来的辛勤工作！
Atomizer 尚未支持 CSS 网格。
感谢这篇文章！
我们也很喜欢原子 CSS，自从我们转向它以来，就再也没有回头过。
这是我们对该主题的看法：Ekzo，它将原子方法与 BEM 方法结合起来。
在 Kotsu 的上下文中检查 Ekzo 是值得的，因为这个入门套件更好地展示了基础知识和使用方法。
我必须指出，根据我的经验，如果网站没有使用良好的模板语言并且没有将所有内容封装到组件中，那么对于大型项目来说，原子 CSS 可能是痛苦的选择。它可能看起来非常重复，并且在各处散布着长而难以理解的类属性。
在组件化方法中，所有这些“CSS”逻辑始终与组件一起使用。因此，如果您需要更改某些内容，只需编辑该组件中的原子类，然后就会发生神奇的事情。
不是要鹦鹉学舌地重复其他人在这个话题上的说法，但这种方法与内联样式有什么区别呢？
命名约定描述了单个CSS属性，没有上下文说明它在什么情况下使用。描述其值的类名在未来维护方面会带来麻烦（正如你在black:navy示例中提到的那样）。听起来设计更改需要在HTML端而不是CSS端进行大规模查找/替换操作，除非我对这个概念的理解有误？
在元素可能被动画化、根据状态设置样式或需要特定响应式行为的交互场景中，这种系统是否也会导致过多的前端压力？
除非我遗漏了什么，否则这感觉像是倒退了一大步。
我最喜欢的关于这与内联样式有何区别的讨论可以在一个关于Tachyons（一个流行的原子CSS项目）的讨论中找到
https://github.com/tachyons-css/tachyons/issues/12
内联CSS具有极高的特异性，不支持@规则、伪选择器或伪元素。原子CSS的编写方式与内联样式有些相似。
正确。你在这里找不到语义类名（除非你设置了一些辅助类）。
乍一看可能违反直觉；但实际上恰恰相反。
black: navy示例是一个不要这样做的例子。不变性是原子CSS设置的基础。使用原子CSS，CSS端的未来维护基本上不存在。在标记中，你只需更改所需的类，即可使正在处理的对象看起来不同。至于全局替换，这根本不是我的经验……尤其是在像React这样的前端框架中使用原子CSS时，我只需要更改单个组件内的原子CSS。如果你设法从你的BEM类中获得高度的复用，那么这可能确实是你需要关注的一个领域。但即使我使用BEM时，我也很少能复用我的语义类名，并且发现自己在重构时会添加额外的类名，以免破坏某些地方的东西。
不，除非我误解了你的意思。在这些领域，原子CSS与使用任何其他类型的基于类的约定有什么不同？
Ailwyn，我完全同意你的观点。
举一个这种方法可能出错的例子：使用CSS动画从中性状态过渡到焦点状态。举例来说，你将如何处理背景颜色更改、悬停状态颜色、边框/轮廓更改等？这些简单的触觉反馈状态似乎在原子CSS下添加起来相当复杂。
如果你的应用程序有视觉修饰符来进一步提升页面一部分的状态（举个简单的例子：延误的火车可能显示为橙色），你如何在不大幅重写类的情况下轻松添加/删除大量单个样式？
如果设计更改通过类更改而不是CSS更改来推动，那么有什么可以阻止冗余的CSS随着时间的推移而累积？
每个过渡/动画都是它自己的原子类，各个属性也是如此。复杂的部分不是在原子CSS中解决上述问题，而只是确定你的命名约定。例如，假设我们想要在焦点时在两种背景颜色和两种文本颜色之间进行过渡。以下是如何使用纯原子CSS（无工具）实现此目的的示例。根据以下虚构的约定，我使用简写属性标识符、值，然后使用伪类字母标识符作为我的命名约定。
CSS
.BgcDarkGray { background-color: #111; }
.BgcWhiteF:focus { background-color: #fff; }
.CWhite { color: #fff; }
.CBlackF:focus { color: #000; }
.TrsAll { transition: all .115ms ease-in-out; }
HTML
<button class="BgcDarkGray BgcWhiteF CWhite CBlackF TrsAll">点击我！</button>
围绕原子CSS的所有库和工具的巧妙之处在于，如果你不想自己想出命名约定，你就不需要这样做（你可能不会）。编写实际上是原子CSS最困难的部分，所以我绝对建议查看一些工具/库。
所有伪类、伪元素、@规则等都将以与上述示例相同的方式处理。我可以使用H后缀表示“悬停”，或者可以使用
@MqMinW60em后缀表示仅在窗口宽度至少为60em时应用此规则。对于最小宽度为60em的深灰色，生成的CSS将如下所示CSS
@media (min-width: 60em) {
.BgcDarkGray@MqMinW60em { background-color: #111; }
}
再说一次，处理起来并不困难，只需要考虑你希望如何命名所有内容。
你将在应用程序中使用的每个属性的类都将存在。由你来应用当前应用程序状态所需的任何类。假设我需要在API请求失败时显示错误消息。中性状态的HTML可能如下所示（我将在此示例中使用Atomizer类）
HTML
<output class="D(n) Ta(C) Fz(1.25em) C(#111)"></output>
然后发生错误，需要显示消息并以红色显示文本……因此HTML将变为
HTML
<output class="Ta(C) Fz(1.25em) C(#f00)">出现问题了！！</output>
我只应用实现我想要的外观所需的类。我只需根据需要添加/删除类。
原子CSS类的独特性和不变性是其特点。它们永远不会改变，也永远不会重新定义。只有你需要的CSS属性应该有原子类。原子CSS是CSS约定中与冗余相反的理念。
那么，这比仅仅使用内联样式有什么优势呢？在我看来，很多这些示例都存在与在每个元素上重新定义所有样式相关的相同脆弱性，并且增加了在类名和CSS文件中都包含样式的额外开销。
内联样式不支持@规则、伪选择器或伪元素。此外，它们具有极高的特异性（这可能是也可能不是你想要的）。
想想JavaScript中不变性和函数式编程的诸多好处。现在将这种思维应用到你的CSS中。简而言之，这就是原子CSS为你提供的。
如果你自己处理一个小型项目，可能没有太多好处。但随着项目的规模（范围和团队规模）扩大，原子CSS开始真正闪耀，尤其是在可以使用相关工具的情况下。生成的CSS将更小，并且可以完全避免重构。
除了对观察开发者工具并尽我所能理解它感到着迷之外，我在这场竞赛中没有立场。
使用新工具时，往往难以表达的是，**到底**何时开始使用它？答案很少是立即的，也并非在所有情况下都适用。
在我有限的经验中，这些情况之一是大型团队和大型代码库。感觉CSS可能会变得过大，团队成员基本上会害怕它，CSS会开玩笑地但准确地被称为“仅追加”。
随之而来的是一种工具，它实现了交付更少CSS的承诺，并且以一种（经过学习曲线后）没有人再害怕的方式交付……我能理解它的吸引力。
这是否意味着我将在每个项目上开始使用它，并期望你也这样做？不。
披露：这里有一位shed.css作者。
你准确地指出了促使我们采用这种方法的原因，“仅追加”CSS模式。即使在“正确”的BEM代码库中，一旦应用程序或网站达到一定规模，事情就会变得具有挑战性。经过多次讨论，我们选择在TED.com上尝试函数式方法。10个月后，9次产品发布，以及3名前端开发人员的入职培训，我们发现函数式CSS方法实现了其承诺。
我认为，如果你使用它一段时间，你就会爱上它，以至于你会在每个新项目中使用它，因为它解决了任何规模的实际问题。
改述https://twitter.com/j9t/status/851462393204940804，原子CSS的问题在于它可能只想忽略可维护性，但这给人的感觉是不理解它。
我认为值得补充的是，像每个工具一样，它应该明智地使用，不要过度使用。
例如，如果你注意到小实用程序类链的模式——将其封装到可理解的模式类中，例如对象（示例）。
你的某个特定组件样式过多，并且需要表达内部元素之间复杂的关系？是时候将其封装到组件类中了，否则你的开发人员将会很难理解所有关系，以及你为什么使用了某些特定的实用程序。
最后一点实际上非常重要。表达元素之间关系是原子 CSS 的弱点，使用它的人应该始终牢记这一点。
约翰，干得漂亮！
自从第一次使用 Atomizer 尝试原子 CSS 以来，我就被它迷住了，目前在工作中的几个项目中都使用了它。最初我们使用 Atomizer，但后来切换到我编写的一个名为 Pre-Style 的工具（这是一个 CSS-in-JS 变体，允许你编写内联样式并在构建时输出原子类）。
不变性大大减少了我们的重构时间，并且通过使用 Atomizer/Pre-Style 等工具，这意味着我们的样式表永远不会比我们需要的大，并且永远不会更大。
不用说，这位开发者强烈推荐原子 CSS！
其中一些类名让我感到难过。“.text-3rem” 将功能和视觉规范混淆在一起。如果该元素需要设置为 3.375rem？2.975rem？使用语义名称。例如，如果它是副标题，则将其命名为 .subhead 或 .text-subhead，如果这适合项目。
对于 .bgrBlue 之类的东西也是如此。如果该元素的背景需要更改为绿色阴影，那么你现在不仅需要更新颜色定义，还需要更新你的标记或忍受 .bgrBlue 实际上是绿色的荒谬情况。
这就是我担心的事情。
对于我的大多数项目，我可能更倾向于这种思考和工作方式，而不是原子理念，但我对其他方法感到好奇并持开放态度。闭目塞听并带着情绪和喊叫攻击其他想法对网络的危害比任何类名都大。
我认为我并没有攻击任何人，也不认为我思想封闭，所以我不确定这从何而来。
我不明白为什么原子和语义类名一定是相互矛盾的，但如果被迫选择其中一个，我将始终选择语义类名。也许是因为我独自工作，或者有时与另一位开发人员一起工作，所以我没有遇到大型项目中大量开发人员的问题，但我宁愿按命名空间对事物进行分割，并最终获得“重复”（即 .component1 .subhead 和 .component2 .subhead 与 .subhead3rem）。
它来自将类名称为“悲伤”以及用全部大写字母陈述事情。
是的！将观点范围限定在你的经验范围内更有价值。这就是我的处境。我独自工作，并在规模较小的团队中工作。网络是一个很大的地方，我们都面临着独特的挑战。
使用语义类名与功能类名的区别是什么？
它们无助于我们的应用程序运行得更快或以任何方式使最终用户受益。它们不会提高可访问性或搜索引擎优化。据我所知，语义类名实际上只是开发人员的元数据，以便他们知道在相应的 CSS 中更改什么。
如果是这样……那么选择一种更具功能性、不变性的 CSS 方法有什么问题，尤其是一种证明比其语义对应物更有效的方法？
按照原子约定，你不会遇到这种情况。**原子类是不变的。** .bgrBlue 将是蓝色，并且始终是蓝色；.bgrGreen 将是绿色，并且始终是绿色。如果要更改背景颜色，则需要在标记中元素本身交换类名。这种不变性原则使基于原子的工具能够在构建时删除任何不再使用的 CSS，从而产生仅包含站点所需的原子类的 CSS。
所以它与内联样式完全相同？如果页面上有 12 个应该被强调的按钮怎么办？与其修复
button-accent类，不如将 12 个background-blue替换为background-green？我想我遗漏了一些东西，因为这似乎不太方便。
如果你好奇为什么有些人选择这种方法，我建议阅读这两篇文章
使用 tachyons 和功能性 CSS 在 10 天内进行全面重写：案例研究
https://hackernoon.com/full-re-write-with-tachyons-and-functional-css-a-case-study-part-1-635ccb5fb00b
构建和交付功能性 CSS
https://medium.com/@cole_peters/building-and-shipping-functional-css-4f29b947bcb9
或者使用
.bgrBlue .bgrAddYellow获取绿色。:P 开玩笑的。老实说，我完全同意你的观点。组件的概念以及使用原子部分来避免过多依赖的想法是有道理的。使用类来表示单个属性的想法（除非它们是类似
.hidden { display: none; }的东西）实际上毫无意义。它也没有比内联样式好多少。
当在混合移动应用程序（PhoneGap）上工作时，如果框架提供了“颜色相关”类，我会理解（并且实际上使用）一点点。但是这些很少超出 HTML 元素上的单个
layout-red类或类似的东西，并将该类更改为同一主题的其他类会更改所有内容。在这种情况下，它可能是有意义的。嗨，Rick，
你可能想阅读这篇文章：http://cssmojo.com/opinions_of_leaders_considered_harmful/
它讨论了“语义名称”的重要性……
是的，我也在我的一个客户项目 https://www.scislides.com 中使用了这种原子 CSS。让我分享一下我对它的看法，它是一个很棒的工具，但同时也很难管理，尤其是在大型项目中。尽管如此，这种原子 CSS 还是帮助我在媒体查询、上下文样式和伪类等方面使用了方便的功能。
这很有趣，因为它与我可能预期的完全相反。1) 在大型项目中难以管理。2) 对媒体查询等内容很有用，我认为仅使用类名来管理媒体查询会非常不直观。
查看该网站的 CSS（除非自你处理它以来已更新），我认为你误解了实现原子 CSS 的很大一部分。
我对哪种方法更好没有意见，但你对工具难以管理程度的看法会因你没有正确实现它而受到严重影响。
你的 CSS 主要基于模块，并带有一点原子 CSS。
我仍然想知道如何在 WordPress 中实现这个概念。将模板分解成更小的组件，这些组件还可以包含子组件，听起来不错，但我还没有在 WordPress 中找到一个好的例子。
首先，感谢这篇文章。
我有一个问题没有得到解答——实际上，在讨论 CSS 方法时从未解决过这个问题，所以这没什么大不了的。
如何处理可访问性？例如
-ms-high-contrast、inverted-colors或light-level（MQ 级别 4，如果在某个时候实现）出于某种原因，我从未找到任何愿意回答这个问题的人，但我真的很想得到一些关于这方面的反馈。
使用原子 CSS，所有媒体查询都以相同的方式处理。
在 Atomizer 中，你可以在
atomizer.config文件中定义媒体查询。因此，你可以指定一个invc（或任何你想要的）媒体查询，然后像这样使用它：class="Bgc(blue)--invc"，这意味着当反转媒体查询处于活动状态时，此元素应具有蓝色的背景颜色。Atomizer 会为你处理实际 CSS 的编写。使用其他工具，你可以像这样内联编写它（React 示例）
该媒体查询的所有实例都将合并在一起，并且所述媒体查询中的所有属性都将具有自己的原子类。所有 Pre-Style 块都将写入外部 CSS 文件。
TL;DR – 简而言之，原子 CSS 通常是每个属性一个选择器，无论是典型的类选择器、伪选择器/元素，还是媒体查询内部。
一种可能性是以类似于断点前缀的方式处理它们（例如，使用 .dim-text-black 类将文本颜色设置为暗光级别的黑色）。
一点无耻的自我推销，但我只想添加一个我最近构建的新工具，名为 hydrogencss。主要用于 CSS Modules，但也可以用于其他东西。https://github.com/eddiemoore/hydrogencss
我认为它的一大优点是，你可以根据需要使用其中很少一部分或全部。
出于某种原因，我发现
.black{color:navy}比无法一并更改所有“黑色”实例更不令人反感。类似的问题可以通过简单的重命名来解决，使其更易于理解。选择器“black”可以改为“color-default”。我只是看不到使用它的任何好处。CSS 的创建初衷正是为了让我们能够用很少的代码进行广泛的更改。
使用
.color-default、.color-primary、.color-secondary作为选择器而不是.black是一种完全可以接受的 Atomic CSS 方法。我同意。我喜欢使用诸如“color-primary”和“color-secondary”或“bg-color-primary”和“bg-color-secondary”之类的名称，以使其灵活且易于通过简单的更改进行修改。
回复 @Lazza（无法回复主题）
它的编写方式相似，但
class="BgcBlue"与style="background-color: blue;"的内部工作原理却大不相同。我在其他评论中概述了一些内容。如何突出显示？如果要更改按钮的
background-color，只需使用不同的类即可。底层 CSS 类不会更改，它们是不可变的。因此，<button class="AccentBlue">点击我</button>变为<button class="AccentGreen">点击我</button>。如果您使用的是纯普通 HTML，没有模板、部分或服务器端包含，那么是的……您必须手动替换所有 12 个实例。但说实话……哪种情况更常见：一次更改 12 个按钮的背景颜色（我的天哪，设计师太犹豫不决了）还是需要使其中一个按钮与其他按钮不同？Atomic 在后者方面绝对出色。以至于您再也不用担心会造成 CSS 更改错误。如果前者更常见，那么 Atomic 可能不适合您或您的团队。如果您想制作一个 CodePen 来展示您的意思，我很乐意制作一个 Atomic 版本来说明我在这里所说的内容。
我个人认为 Atomic CSS 将最终用户置于开发人员便利性之上。但是，Atomizer、Pre-Style 等工具以及 Tachyons 和 Basscss 等库使 Atomic 的编写变得更好。
哈哈！ :)
为什么“原子部件”的概念或仅仅是保持“DRY”对于组件（或 HTML 和 JS）有意义，而对于您的 CSS 却没有意义？可重用性意味着更少的代码重复，这意味着更小的文件，这意味着更快的加载时间。
您是否应该仅仅为了微不足道的性能优势而切换到 Atomic？可能不会。您最好从应用程序中删除一张图片。但这些性能优势是在一个非常易于维护的圣代上的糖霜。不可变性因素意味着我可以一年后回到项目中，并对一组组件进行全面的样式更改，而无需担心在任何地方破坏任何内容。除非完全放弃可重用性的概念，否则使用语义类约定无法获得这种保证。此外，我获得了 BEM 的所有特异性处理优势。
感谢您的回复。
通常，如果我想更改网站上按钮的外观，我不想更改一个按钮，而是想更改所有按钮，除非其中一个按钮是特殊的。CSS 的发明是为了避免重复并将样式与内容分离。
我不想将“colorful”类绑定到元素，因为更改它的每个出现都会变成一场噩梦。如果一家公司将其主色从蓝色更改为红色，该怎么办？我是在每个
.color-blue元素上替换所有类，还是只是重新定义一个单一的、语义化的.color-accent类？老实说，我更喜欢后者。 :)
我不明白这些东西与您使用的 CSS 方法有什么关系。您可以使用各种服务器端内容编写 WordPress 模板并使用正确的语义 CSS。如果您谈论的是使用 PHP 来
<?php print_correct_accented_color_class_name_here(); ?>而不是编写class="accented"，在我看来，这就像试图破坏 CSS 的目的以便在服务器上重新创建它。或者使用 CSS 预处理器，它们只是不错的（但多余的）抽象工具，最终会生成正常的 CSS。回复 @Lazza
CSS 是20 年前发明的。其最初的目标与后来演变/转变的问题相关。正如我在这篇文章中所讨论的那样，对于许多开发人员来说，关注点分离现在已经成为一个无关紧要的问题。
在我看来，如果不首先接受“可以”在样式表外部更改样式，就无法理解 Atomic CSS 的优势。Michal 的评论似乎证明了我的观点
:-(
Thierry，我理解，既然您创造了 Atomic CSS 这个术语，您认为它是最棒的想法，人们不应该试图批评它，但我认为我们应该保持冷静的语气。
也许吧，这取决于“外部”的含义。当然，如果您用粗体写东西，您不会“更有道理”。:) 如果“外部”是指添加一个奇怪的
class='text-centered'，也许我们应该回到整个表现性 HTML 标签的想法，并恢复<center>……甚至添加更多。我想<h1 color='red'>万岁？我会保留 CSS，但如果您愿意，您可以保留非语义标记。
进化是一回事，回归到我们之前使用的东西（如前面提到的“视觉”标签）是另一回事。难道很奇怪吗？大多数使用 Atomic、BEM 或其他方法的人最终不得不使用预处理器、编译器或其他花招来重建使用这些方法之一时丢失的 CSS 的语义方面？
这并不意味着使用 Atomic CSS 是非法的，或者有人会对你生气。这只是以一种非常奇怪的方式使用 CSS，与它的设计初衷完全不同。不太方便。更类似于内联 CSS，在某些情况下也不太好。
这也不意味着它总是一个坏主意。我可以想到一些使用它可能是一个好主意的情况。我也可以想到一些我将使用（或已经使用）内联 CSS 的情况（这几乎是一样的），但是是的……应该小心。谨慎使用。;)
您的文章标题很巧妙，“被认为有害的领导者的观点”，然后在很长的文章中，您扮演领导者的角色，发表有害的观点。这里和那里也有一些人身攻击用于攻击基本上所有其他人的论点，在我看来，这并不是一个很好的方法。
我们还可以讨论您如何将最佳实践（源自 CSS 的构建方式以及它如何工作以及简化样式维护）定义为简单的“观点”，但是……改天再说。
此外，Atomic CSS 在标记中添加与表示相关的类的概念似乎表明您期望特定的标记只能以一种方式进行样式化（显然并非如此，因为可以拥有打印样式表或移动样式表，但我不再赘述了）。
您关于 Atomic CSS 的内容对于“旧 CSS”也适用
回复 Lazza
不！如果您花时间阅读我关于它的文章，您会发现事实并非如此。或者您只需查看我回复 @unleashit 的评论，我在其中说：“这里并不是说 Atomic CSS 是最好的选择，只是给您提供关于您假设的反馈”。
它显示为粗体以表示**强调**。
您“让我们保持冷静的语气”呢？
一篇简短的文章解释了差异
https://acss.io/frequently-asked-questions.html#how-is-atomic-css-different-than-using-inline-styles-
**在ACSS的情况下**，不会执行本文中建议的操作（“更改
Bgc(colorOne)为Bgc(colorTwo)）仅仅是因为 ACSS 允许开发人员通过配置文件使用“变量”。在这种情况下，将在整个项目中使用类似Bgc(color-primary)的类，然后**在一个地方更改颜色**——配置文件。这听起来很像使用
.background-primary {
background-color: colorOne;
}
但是通过配置文件、预处理器等重新发明轮子。
回复 @Lazza
我认为你错过了重点。配置文件或预处理器允许在样式表中全局替换颜色值，而不是像经常建议的那样更改标记中的类。
.background-primary {
background-color: colorOne;
}
.color-primary {
color: colorOne;
}
.border-primary {
border-color: colorOne;
}
这是否符合前端/设计人员开发客户端“应用程序逻辑”因为它是客户端这一主题？
这让我感觉像是试图让不理解 CSS 的人（例如，可能由于 Angular 等框架而现在从事前端工作的程序员/服务器端开发人员）更容易使用 CSS。
我相信有很多前端开发人员最近一直在努力提高 JavaScript 等方面的技能，我们不能要求他们对 CSS 也做到同样的事情吗？
我希望我们可以退几步，将编程保留为编程，将 UI 开发保留为 UI 开发。
我有时想知道网络的发展方向。
CSS 和 (SCSS/LESS) 简单易懂。这只是增加了另一层，而这层对使用它的人——设计师——没有好处！
你的意思是@Colin？我们的设计团队使用函数式 CSS。我认为对于设计师来说，将类名从“red”更改为“dark-red”比让他们查看标记，看到它是
.Button.Button--primary，找到对应的文件，在.Button元素中查找color: red，如果它不存在，则在.Button--primary中查找，在那里更改它，检查整个应用程序以确保他们没有更改他们本意不更改的内容（其他地方的Button--primary）要容易得多。感谢 John 撰写本文。
只是一个脚注。我认为这些技术会激发热情，因为它们看到了一种在 KISS 的旧方法和最近对前端感兴趣并带来了他们（有时）过度设计的理念的新一代工程师之间的战场。虽然“战场”这个词听起来很夸张，但这些新声音是行业关注的对象，无论好坏，都可能成为现在/未来预期实践。我完全赞成组合和函数式编程，在“编程”中。但我确实认为试图将 CSS 和主题层都应用这些结构有点危险。对不起，但原子 CSS 是不必要的，并且是一个过度设计的理念。
这并不是说我不开放，只是我认为它错了，并且基本上是由于团队对 CSS 不满意而产生的，因为 a) 他们不理解它，或者 b) 他们没有合适的协作系统，或者没有执行它们，或者 c) 他们通过采取大胆的措施来解决问题而感到个人满足，即使新解决方案产生的问题比最初存在的问题更大。 […] 我建议进行治疗：p（以及更好的 CSS 培训）。
IMO，CSS 远非完美。为什么我们需要 Sass/Postcss/Bem？我只是认为人们应该花时间改进 CSS 本身（以及浏览器支持），而不是像这样的权宜之计。对不起，我真的不想因为想要一个不同颜色的按钮而不得不更改 500 个 React 组件文件中的标记。对我来说，这太荒谬了。如果你非常害怕修改 CSS，我建议你进行治疗：p（并接受更好的 CSS 培训）。
不，这个想法**并非**来自“最近对前端感兴趣的新一代工程师”；我不是新一代的一部分，也没有工程背景。另一方面，我相信我对 CSS 有很好的掌握。
关于 b) 我要说的是相反的，原子 CSS促进了工作流程，因为它不需要遵循严格的规则（即命名空间）。对于 c) 也是如此，原子 CSS 解决了不同的一组问题（即膨胀/性能），对于某些人来说，这些问题可能更重要……
这里并不是说原子 CSS 是最好的选择，只是给你一些关于你假设的反馈。
嗨，Thierry，首先，我的意图不是要对抗。我可以看到你对此充满热情，我正好有机会阅读了你发表在 Smashing 上的文章并获得了一些额外的背景信息。即使你没有工程背景，你也在/曾经与一家公司（就像其他大型科技公司一样）合作，该公司一直在努力尝试做任何事情，他们能想到的任何事情来提高效率并更好地竞争。你会告诉你的股东我们会“一如既往”地做同样的事情以达到他们的收入目标吗？这种现实更像是后端工程师现在做 CSS 以及前端近年来发生如此巨大变化的宏观图景。
这并不是说我认为变化是坏的，或者没有发生很多好事。已经出现过很多很酷的东西。另一方面，一些想法不是很好……在我看来，尤其是在 CSS 方面。我当然关心性能。实际上，我认为你试图解决的问题部分是由组件化开发的流行导致的，这意味着很多 CSS 会重复。就我个人而言，我喜欢结合使用 BEM 或 CSS 模块，以及适量的令人畏惧的全局 CSS。我曾在相当大的代码库上工作过，多个工程师编辑 css（没有 Yahoo 那么大，但没有多少是）。这是一个挑战，但是通过一个良好的纪律体系，并且每个参与者都对盒子模型、特异性等有很好的理解，我认为它并不比原子 CSS 更臃肿。不要忘记你添加到标记中的代码量。如果你让每个人都使用超级简约的速记版本，也许会有一些节省，但权衡是什么？标记非常难以阅读，输入起来很笨拙，没有 css 代码检查，没有 emmet（啊，这里有一些新闻！），不能使用大量的 css 框架、库、在线模式库、旧项目的 css 等。
除非/直到你可以改变整个行业来使用它，否则当他们遇到它时，它会让我的生活和许多其他人的生活变得更加困难。如果这听起来很消极，我感到抱歉，但我认为还有其他更好的方法来节省 20k 左右，而不是这个。我并没有反对你，但我也有权发表我的意见，就像你一样。
我感到绝望。网络世界到底发生了什么事？好像每个人都疯了！
这些人真的做过任何严肃的工作吗？大型项目不是那些有很多样式的项目。大型项目是那些有很多内容、样式一致、传递品牌的项目。
哪些疯狂的作者在每个新项目中都改变了他们使用 HTML 的方式？不是我。例如，我心爱的、可靠的、可重用的表单模块，它会输出我的表单的 HTML，因此我不必手动编写 HTML 表单。它正在为我完成繁重的工作，减少错误，确保可访问性等。我相信我不是唯一一个依赖组件生成 HTML 的 Web 专业人员，例如，许多人编辑降价而不是 HTML。无论如何，如果我想要一个具有不同设计的表单，我会编辑这个 HTML 吗？不会！我为什么要这样做？那真是太疯狂了！
如果我想使用原子 CSS，我必须这样做。那是一种巨大的时间浪费，并且是 HTML 和 CSS 的不恰当用法。如果你正在考虑使用原子 CSS，那么你做错了什么，并且即将使情况变得更糟。
我认为造成巨大脱节的原因在于，你更像是一个设计师还是更像一个前端开发人员。
一年前，当我遇到这个话题时，我也没有理解它与内联样式的区别。尤其是因为我是团队中唯一的那个设计师。
然而，随着我的技能集发生变化，我开始更多地从事编程方面的工作，我开始理解 ACSS 有多有益。此外，我开始在更大的团队和更复杂的项目上工作。