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