未来的主题：设计框架和主主题

WordPress 主题有着悠久的历史。 多年来，主题作者为该平台带来了大量功能。 部分原因是他们经常不得不解决 WordPress 的基本问题，以创建最终用户想要的功能。

所有主题作者今天使用的帖子和正文类？ 这些最初是在一个名为沙盒的主题中。

特色图片？ 这些在十年前被杂志主题所普及。

你认为帖子格式起源于 Tumblr？ WordPress 的共同创建者 Matt Mullenweg 在 2004 年教我们如何在主题中创建旁注，但在此之前它们就存在了。

WordPress 功能通常始于主题世界。 我们有时认为主题作者投入工作的想法多年的实验和迭代是理所当然的。 甚至块编辑器也在处理传统上属于主题设计领域的项目。 盖块就是一个很好的例子。 多年来，主题作者为带有文本和按钮的基本英雄图像构建了主题选项。 结果通常很笨拙，对用户来说并不理想。 通过将此功能引入核心，它使用户能够将此覆盖块放置在任何允许的块区域中。

许多主题功能使其成为核心的原因是它们在标准化时工作得更好。 用户知道会发生什么，主题作者可以专注于设计方面，而不是解决用户体验问题。

过去的部分问题是核心采用的每个新特性都没有遵循任何标准的设计模式或命名方案。 设计 WordPress 主题的一项巨大技能是将数百个类的混搭提交到记忆中。

块编辑器处于独特的位置，可以通过创建通用设计框架来改变这一点。

WordPress 需要前端设计框架吗？

随着未来的块模式和之后某个时候的全站点定制，主题作者想知道这艘​​船到底在哪里航行。 这是令人兴奋的，因为最终用户的可能性是无限的。 对于将自己的帝国建立在一种做事方式上的主题作者来说，这是令人恐惧的，但发展更多的是适应而不是其他任何事情。

有了对景观正在变化的预知，这是主题作者需要联合起来在基于区块的世界中塑造他们的未来的时刻。

在我参与的一个开发人员小组中，有一个笑话说核心开发人员不是主题作者。 从主题作者的角度来看，有时似乎想法是随意组合在一起的，没有考虑 CSS 设计系统。

哦，我看到了一些 BEM。 为什么这个子元素不遵循相同的命名方案？ 等待。 那是一个 38 个字符的实用程序类吗？

WordPress一直缺乏的是一个通用的前端设计系统。 有时，这是一件好事。 它允许主题作者使用他们喜欢的框架。 任何参与游戏时间足够长的主题作者都会告诉你，那种灵活性很棒......直到它不是。 您是否尝试过向小部件添加上下文类？ 向评论表单包装器添加一个实用程序类怎么样？ 你需要一片阿司匹林。 或者两个。

使用 WordPress，有些东西是一成不变的，而另一些则是可插拔的。 一些特性遵循标准的类命名方案，而另一些则没有意义。 主题的结果通常是臃肿的 CSS，试图与各种组件争吵。

如果不重新创建核心功能，几乎不可能在主题中完全使用像 Tailwind CSS 这样的实用程序类框架。

这在很大程度上源于多年的遗留代码堆积和 WordPress 对向后兼容性的承诺。 但是，未来不必与过去相似。 我们正处于一个新时代的门槛，现在是前端设计师参与对话的时候了。

WordPress 需要一个可靠的前端设计框架。

那是一个加载的语句。 如果你把 20 位设计师放在一个房间里，让他们讨论设计框架，这可能是打架的秘诀。 我倾向于是一个乐观主义者，并希望辩论能取得成果。

古腾堡已将我们部分推向这个方向，但还远远不够。 随着未来的全站点编辑，需要一种更全面的方法来解决这个问题。

最重要的是，我们需要更多的前端设计师参与对话。 没有办法.has-subtle-pale-green-background-color应该作为实用程序类存在于.bg-pale-green 、 .bg-green-100甚至.background-pale-green类的东西上，如果你想要更详细。 该决定中没有优化的概念。 在开发人员在千兆互联网连接上运行的时代，很容易忘记世界大部分地区都在以较慢的速度跟进。

具有健康剂量的实用程序类的基于组件的命名方案是一种可以达到几个最佳位置的选项。 这不是一个 CSS 框架优于另一个的论据。 有许多好的现有选择。 WordPress 应该通过借鉴其他项目奠定的基础并创建独特的 WordPress 来解决这个问题。 它应该是该领域的领导者。

设计框架也与插件有关。 自主题系统出现以来，两人一直在进行一场持续的战争，主题领域有一些交叉。 主题和插件之间的战场上到处都是好主意的死亡。 太多的人从未获得进入核心区所需的支持。 某种通用设计标准可以阻止大量问题并呼吁停火。

例如，输出自定义前端组件的插件无法知道当前主题如何处理垂直节奏。 它使用上边距还是下边距？ 使用的值和单位是什么？ 这是基本的东西，当插件尝试添加自定义 CSS 来处理它时，它几乎总是被破坏。

WordPress 需要一个设计框架或语言，它允许其所有移动部分在前端和谐地结合在一起。 我相信我们会在某个时候到达那里。 我希望它比过去的随机组件和命名方案更具凝聚力。 我们还应该有一个明确的路线图来填写一些技术细节，以便开发人员和设计人员做好准备。

单一主题的未来可能吗？

Rich Tabor 在他的文章 A Look at WordPress Themes of the Future 中提出核心 WordPress 可以提供单一父主题的论点。 这个想法是主题作者将被降级为为这个“主”主题创建一个子主题。

许多人的直觉反应是它不起作用，主题会失去个性，我们将生活在一个千篇一律的设计世界中。

现实情况是，我们正朝着一个单亲或主主题的想法成为一个认真考虑的未来发展。

大多数主题是几乎所有主题中都存在的标准元素的自定义分组。 除了风格问题之外，还有一些决定会使主题彼此不同，例如标题的布局。 一个主题可能在一个块中有一个站点标题和导航菜单。 另一个可能有一个导航菜单、标题和下面的第二个导航菜单。 然而，另一个主题可能会显示一个搜索框。 在全站点定制属于用户的世界中，这些决定成为用户体验的一部分，而不是开发人员体验的一部分。

主题需要通过调色板、排版和他们自己的古怪品牌脱颖而出——这是 CSS Zen Garden 时代的回归，但规模要大得多。

我不会为此难过。 看到该领域顶级设计师之间的竞争会很有趣。 它还可能将 WordPress 主题带回到一个任何人都可以通过一点 CSS 知识和决心来做的时代。

虽然我们还没有为一个主题统治所有主题的未来做好准备，但它是一个开始对话的地方。 如果我们为这个潜在的未来设计 WordPress，即使我们从未实现过主主题，路线图会是什么样子？ 有什么阻碍？ 可行吗？