今天早些时候，Mark Root-Wiley 发布了一篇围绕 WordPress 的标准化设计标记和 CSS 的深入建议。目标是围绕核心设计工具创建一个一致的、可定制的和可互操作的系统。本质上，他提出了一个标准化的设计框架，或者用他的话说，是一个 WordPress、主题和插件可以依赖的“共享 CSS 工具包”。
博客文章接近 4,000 字。他还添加了一个通过 Gutenberg GitHub ticket 建议的较短版本。然而，这篇文章扩展了这个想法，链接到跨越数年的资源。
我给 Root-Wiley 发了邮件。这对我来说是一个密切的话题。在过去的几年里，我有幸与之交谈过的其他主题作者也对此感到沮丧。这些人从第一天起就 100% 支持区块链系统，而不是随便在后面大喊“古腾堡糟透了！”的人。
我分享的主要想法是我对这个话题有点厌倦了。每隔一段时间就会有人推动将标准预设纳入核心。只是，总感觉轮子在泥里打转，等所有人都出来了，才发现它不动了。
Root-Wiley 指出我 2019 年的帖子“未来主题：设计框架和主主题”是一个共同的祖先，他在其中深入探讨了这个问题。但是，我和其他人甚至在 WordPress 5.0 发布之前就一直在谈论它中的块编辑器。
部分原因是我们对实现更多标准化的潜力感到兴奋。 WordPress 终于可以纠正一些长期存在的问题，并迎来一个基于精心设计的约定的主题创建乌托邦。
WordPress 5.0 引入了带有自定义字体大小和调色板主题支持的徽标。这些功能本身是值得欢迎的第一步，但还不够。 WordPress 从第一天起就应该超越并设定标准。
相反，我们得到的是默认字体大小和颜色名称的混搭，但没有解释它们的含义。 “巨大”的字体有多大？如果我需要遵循该命名方案并需要更大的东西怎么办？我应该给它起什么名字？ （有关尺寸名称的潜在教育意义，请参阅本文末尾的注释。）
每次您看到像 .has-luminous-vivid-orange-background-color 这样的类时，我仍然会畏缩.
但是，我不会继续抨击该平台过去的错误。是时候继续前进了。 Root-Wiley 在他的帖子中指出：
我想建议一种方法来标准化使用 CSS 创建 WordPress 设计和布局的方式，使它们更透明、高效和可定制。这种方法不仅简化了核心样式，还解决了一些长期存在的 WordPress 痛点，这些痛点甚至早于 WordPress 5.0 中块编辑器的发布。
我想查看用户可以通过块设计器工具选择的所有内容的预设。例如，他们可以从 WordPress 和/或其主题中选择一个预定义的大小，而不是为边距设置绝对单位。但是，应该有一个命名这些预设的标准。
为什么这如此重要？想象一下，在博客文章中将块的上边距设置为 20 像素。它看起来不错并且与您当前的主题相匹配，并且您在各种元素上重复此过程数十次或更多次。然后，您可以随时随地更改设计。这可以是一个完整的主题切换或通过全局样式系统进行的更改。这种新设计实现了不同的垂直间距系统。 24px 可能比网站上到处都是的 20px 更有意义。
在理想世界中，旧设置将与全球价值观相关联，而不是社区。这将使它能够匹配任何现有的设计系统。
边距只是更大拼图的一小部分。各种设计工具的预设甚至没有涵盖 Root-Wiley 提案中的所有内容。这就是为什么我鼓励所有主题和插件作者对其进行审查。
我不同意提案中的某些项目。然而，这些涉及低级别的实施工作，而不是创建标准化系统的概念。我原计划详细讨论这些问题，但这样做会陷入与我共事的前团队成员所说的“草丛中的讨论”。他们妨碍了大局。
如果 Root-Wiley 和我在一件事上达成一致，那就是创建 CSS 工具包以将 WordPress 带入未来的大局。
Never Published Size List
这有点离题，但我确实根据 WordPress 字体大小模型对大小名称进行了大量研究。而且，由于我可能永远没有理由在其他地方发布我的发现，所以我不妨将它们发布在这里。
如果您想知道哪些特定尺寸比其他尺寸更大或更小（例如 Jumbo 与 Titanic），我为您提供了一个受过教育但可能不是 100% 正确的列表：
p >
- Small (2XS)
- Small (XS)
- Small
- Normal (Medium, Normal, Basic) < li>大号
- 特大号（XL）
- 特大号（2XL）
- 特大号（3XL）
- 特大号（4XL）
- 泰坦尼克号（5XL）
- 奥林匹克号（6XL）
- 星球号（7XL）
- 银河系（8XL）
- 一般(9XL)
li>
这可能不是一个详尽的列表，但我花了数周时间查找和比较定义和资源。我在混音中添加了一些替代品以供参考。
我还想发布这个来展示命名事物如何破坏用户体验。普通用户不必考虑最大或最小尺寸。像这样的命名系统会造成混乱。即使用户体验有效，基于代码的 slug 也不应该让开发人员感到困惑。
相同的规则适用于颜色和所有其他预设。命名很难，但当你把事情搞砸了并且需要稍后修复它们时就更难了。它从基础开始，尤其是当今天添加的所有内容都将成为未来几年遗留代码集的一部分时。
资源
