Eric，再次不浪费任何话 撰写博客文章标题。 这是我
我遇到的最常见的 CSS 声明组织技巧是根本没有组织。
几乎没有。 我倾向于将它们按我的大脑在编写时输出的方式进行分组，这通常会导致一些逻辑分组，比如将盒子模型的东西分组在一起，将颜色东西分组在一起。 它只是……对我来说无关紧要。 但这很大程度上受到通常在小型团队或独自工作的影响。 Eric 建议使用字母顺序方法，因为
[…] 它在整个团队中施加了基本结构感。 这个要求通常就足够了，尤其是在这意味着清理之前的内容的情况下。
他（可能更大）的观点是，所施加的结构有助于在 CSS 技能被低估的世界中使 CSS 正名。 我不会反驳这一点，但我认为在现有项目上手动按字母顺序排列 CSS 很可能不是一个好主意。 更糟糕的是，如果盲目地这样做，可能会破坏某些东西，这就是为什么 Prettier 放弃了它。 如果你和你的团队同意这是一个好主意，我会想办法将它添加到代码编辑器的保存函数中，并将其作为预提交钩子。 按字母顺序排列是电脑要做的任务，并且可以在你编写时验证输出。
VSCode 有一个命令可以做到：按升序排序行。
只需将其绑定到一个键，选择声明并对其进行排序。 它半自动化，但你无需更新整个项目。
可能是我漏掉了什么 :-) - 但是这篇文章中是否缺少了什么？
这只是在说“ABCSS”（按字母顺序排序），对吧？
我之所以这样问，是因为这太老了。（CSS Tricks 通常是新的 :-)）
我谷歌了一下，发现很多人早些时候就写过这方面的内容
关于 CSS 中的声明排序 (2014)
按字母顺序排列你的 CSS 属性，天啊 (2017)
整理 CSS 的一个简单规则 (2019)
是什么让 Eric 与众不同？
建议：一篇关于 CSS 排序历史的文章，并向所有这些人士致敬？
我可能错了或过时了，但我感觉按字母顺序排列 CSS 规则的解析速度也会更快。 并非以任何有意义的方式，我们说的是最多几毫秒，但如果你需要一种方法来向你的老板证明这样做是合理的，你可以省略这个细节：D
关于这一点的来源？ 根据我对解析的了解，这听起来不太对。
按字母顺序排列感觉很正确，但它实际上会对 GZIP/Brotli 压缩率产生负面影响，因为它会缩短整个文档中重复段落的长度。
例如，大多数遵循简单大脑转储排序方法的人会自然地将逻辑相关的规则分组在一起，比如宽度和高度或边距和填充。
在给定的样式表中，多个块共享相同宽度和高度的可能性非常大 - 例如
width:100%;height:auto非常有可能。 编码器会注意到这一点并对整个配对进行标记。但是如果你将所有内容按字母顺序排列，那么这些常见的配对只会在没有其他定义的类中保持常见配对，这些定义介于 H 和 W 之间。
这正是阅读本文后首先出现在我脑海里的东西！
如文中所述，自动执行此操作很危险，因为 CSS 声明的顺序会影响应用哪个声明。 我们多久会做一次这样的事情？
如果将这两行按字母顺序排列会导致顺序与现在的顺序相反，该怎么办？ 我们能自信地说这种情况永远不会发生吗？ 世界上没有哪种按字母顺序排列算法会先对减号进行排序吗？
感觉太脆弱了，不能依赖于自动化。 ¯_(ツ)_/¯
我的想法也是这样。 乍一看，它听起来不错，但由于 CSS 是级联的，你可能被迫使某些声明不按字母顺序排列。
怎么样呢？
animation: spin 2s linear 3;-webkit-animation: spin 2s linear 3;
希望永远不会出现这样的代码！
按字母顺序排列声明完全是精神错乱，我甚至不想开始考虑级联和排序选择的含义……
我尝试在一个大型项目中使用按字母顺序排列的方法，我发现的一个大问题是，它在再次阅读代码时通常会导致困难，因为你的眼睛必须在规则集中跳来跳去，才能试图弄清楚多个相互关联的属性的累积效果可能是什么。
比如，
align-items除了网格或 flex 之外毫无意义，而且按字母顺序排列，在它和display之间还有其他 A 以及 B 和 C 属性。 因此，当我或我团队中的其他人查看规则集时，我感觉需要更多的认知负担来跟踪哪些属性共同作用以实现某种效果。我最终采用的约定是按依赖或相关性顺序大致列出属性。
display: flex; align-items: center或position: sticky; top: 0（即使那个是按字母顺序排列的，哈哈）。 我还会将诸如animation和transition之类的东西分组在一起，因为它们是相关的，但在字母表中彼此相隔很远。 我甚至经常将动画或过渡更改的属性保持在附近，比如transform或opacity。我喜欢你将事情按它们从你的大脑中输出的方式列出的想法，因为我认为大脑会自然地按重要性顺序进行组织。 “哦，我需要一个 flex 容器，它具有 space-between 对齐方式和间隙” ->
display: flex; justify-content: space-between; gap: 1rem。 非常不按字母顺序，但当再次阅读时，大脑更容易理解，以更具支架的方式理解。 至少在我看来是这样。我个人不喜欢按字母顺序排列，因为我不喜欢将某些应该保持在一起的属性分开。
但我理解为什么它在团队中有所帮助，因为它增加了更多的一致性。
幸运的是，在我的团队中，我们遵循盒子模型顺序。 这对我团队中的其他人以及新加入者来说都是可以解释的，因为浏览器就是你的参考手册。
我们是否考虑过 Awesome 风格的 lint？……它做很多事情，你甚至可以对自己的模式进行正则表达式，这样 padding-right 永远不会出现在 padding 之前等
我认为这不是一个好主意。 我认为我们应该按部分组织我们的 CSS。 因为如果你要删除某些部分，那么清理你的 CSS 会更容易。 否则，你需要逐个找到类，或者你会处理未使用的垃圾 CSS。 这根本不是一个好主意。 按字母顺序排列 CSS 毫无用处。 我觉得这完全没有用
不，不，不！ 按分组顺序排列要好得多，例如 这个
需要考虑这样一个事实：在 CSS 中，对于具有相同特异性的规则，声明的顺序会影响输出。 你的 CSS 能够以任何顺序运行可能是最好的 - 但仍然，级联的一部分就是声明顺序。
因此，虽然按字母顺序排列样式表可能使其更容易筛选，但也可能对你如何声明选择器、HTML 甚至命名类施加很多其他可能不必要的限制。
后续文章：如何以逻辑方式命名类。
由于我在草稿文件夹中有一篇关于这个主题的博客文章，所以这里是我使用字母顺序排列的一些好处的简短列表。 请注意，这是由在大型代码库中工作的人编写的，有 15 多个开发人员不断贡献到该代码库。
民主：选择按字母顺序排列意味着某些人的任意偏好不会被选中（另请参阅下面的最后一点）。
一致性：在整个代码库中使用相同的顺序使代码可预测，并让你在了解了查找位置后更容易找到特定值。
轻松自动化：如果您使用的是Stylelint，您可以借助stylelint-order插件来强制执行排序。 而且，在 VS Code 和 Webstorm/IntelliJ 中都有将排序与快捷方式关联起来的方法。
易于新同事理解：与第一点相关，应用字母顺序有助于新同事的入职，因为大多数人都能背诵字母表。 对于大多数其他排序方案，您需要记住它，这会增加认知负荷。
无/少争论：大多数其他排序方案都涉及不同程度的个人意见。 在完成为哪些属性分组以及哪个组排在前面的初始工作之后，您需要在每次向代码库中引入新的属性（或属性组）时重新审视该会议。 而且，如果您团队中的开发人员不止几个，那么旧的排序决定很可能被重新提出以供重新评估。 使用字母顺序，无需进行此类讨论，因为排序是由普遍且超出开发人员控制范围的事物决定的。
起初，依赖于并非由您自己决定的东西可能会让人感觉有点奇怪，但就像采用Prettier一样，一旦您决定使用它，您就不必再考虑或推理属性的顺序，让工具为您处理它，这是一种幸福的感觉。
虽然从逻辑上将相关选择器分组感觉是显而易见的选择（相信我，将
align-items放在display之前确实感觉很奇怪），虽然我们可以将我们分组的方式制定成一种规则，但这种规则仍然会非常主观，并且会留下很多解释和误解的空间（“为什么盒子模型组不是第一个？”、“如何在组内对单个属性进行排序？ 或者也许我们不需要？”）。 当然，如果您是为个人项目或贡献者人数很少且开发人员对如何运作具有同质观点的项目做出决定，这很好。 但对于大型项目和企业应用程序，其中开发人员数量更多且代码库需要维护更长的时间，这些问题就会累积起来。 虽然这在最初看起来可能是一个重要的决定，但一旦您确定了解决方案，您真的不想一遍又一遍地进行相同的讨论。在理想情况下，我会选择逻辑分组。 但由于…… 你知道的（疯狂地挥舞着周围）（疯狂地挥舞着周围），我的务实方法是选择第二好的方法，即字母排序。
我喜欢 Chrome 开发者工具在计算样式面板中对属性进行分组的方式； 布局、文本、外观。
在人们开始告诉你这样做或那样做之前，我一直都在做类似的事情。
作为一个自由职业者，如今的每个项目都在适应他人的想法，包括每次键盘敲击、拉取请求、过多/不足的评论…… 打哈欠。