感谢您发布此信息！ 对可能性感到非常兴奋😍

这些定义的样式可以在整个用户站点中全局应用（例如，声明字体比例、颜色或所有按钮的外观）。

目前，Gutenberg 仅支持在每个块级别的样式定制。 因此，在一篇文章中更新 Button，不会追溯更新其他页面上的 Button。

澄清一下，用户能否通过编辑器 UI 更新所有按钮的颜色或所有段落的字体大小？ 如果是这样，他们是否仍然能够在每个区块的基础上进行调整？

与 Gutenberg 块的保存/渲染方式类似，我们可以保存和存储从全局样式输出的 HTML。 这个 HTML 包含生成的变量，可以通过 PHP 注入到头部，这意味着加载时不需要变量/样式合并。 它已经完成了。

在前端使用 CSS 变量是否有更好的替代方案？ 这里的问题是任何使用 WP 的网站都会停止在 IE 上工作。 即使 WP 作为一个项目决定停止支持 IE（这很可能在未来的某个时候），如果用户不能再用它构建与 IE 兼容的网站，这对于任何使用它的政府或其他官方机构来说都可能是一个巨大的问题可湿性粉剂。

太酷了，等不及要这个功能了！

在前端使用 CSS 变量是否有更好的替代方案？ 这里的问题是任何使用 WP 的网站都会停止在 IE 上工作。 即使 WP 作为一个项目决定停止支持 IE（这很可能在未来的某个时候），如果用户不能再用它构建与 IE 兼容的网站，这对于任何使用它的政府或其他官方机构来说都可能是一个巨大的问题可湿性粉剂。

这是一个重要的问题，也是一个不幸的现实。 如果我们能得到一些关于这会产生多大影响的硬数据，那就太好了。

话虽如此，我想知道像https://www.npmjs.com/package/postcss-css-variables这样的东西是否可以在构建过程中使用以帮助最终的 css。 也许可能有一个 WP 插件可以即时处理 css 输出以转换（使用该包）到 IE 友好的输出，然后那些需要它的站点可以使用它？

@tellthemachines + @nerrad感谢您的反馈！ 我同意，对 CSS 变量的关注和缺乏（旧的）浏览器支持是非常真实的。

也许可能有一个 WP 插件可以即时处理 css 输出以转换（使用该包）到 IE 友好的输出，然后那些需要它的站点可以使用它？

那会很有趣！ 服务器端的东西，以减少对基于 JS 的 polyfill 填充客户端的需求。

我真的希望我们可以在这个项目的样式机制中使用 CSS 变量。 要么使用@nerrad建议的技术，以及 pony/

话虽如此，我不认为 CSS 变量是制作/破坏全局样式的部分。

我认为最关键的部分是创建允许主题、块和用户自定义（全局 + 一次性）相互配合的系统。 一个可以降低 Block Developers 和 Themers 的复杂性和开销的系统。 这将为用户提供更具凝聚力的体验。 也许是经常自定义事物或尝试使用来自不同块作者的不同自定义块的用户。

我认为，专注于用户体验最终是古腾堡体验的重要组成部分:)。 @nerrad写的评论（下面的链接）让我想起了这一点，他雄辩地强调了 WordPress 中用户体验的重要性。

https://github.com/WordPress/gutenberg/pull/16384#issuecomment -573430079

👋大家好！

我有一个更新。 我一直在与@karmatosed合作，以找出全局样式如何在完整站点编辑以及主题和块的上下文中工作的流程。

我创建了一个原型来演示全局样式如何与块和主题一起工作的流程 + 层次结构

我录制了一个关于原型 + 概念的截屏视频：

:video_camera:视频
https://www.loom.com/share/73f721797f524dfeb2c3a222e9e24561

:raised_hands:演示
https://yvz8y.csb.app/#/v2/post

太长没看

不用担心！ 我会尽量总结 <3

样式层次结构可以用这个金字塔来表示：

核心：古腾堡/全局样式系统附带的基本样式
主题：由主题定义的自定义样式
Global ：用户应用的自定义样式，适用于整个站点
文档：用户应用的自定义样式，用于某些页面/模板部分 (FSE)
块：用户应用的自定义样式，用于单个块

在上面的金字塔中，我们可以看到核心样式（黑色文本）一直向上，因为没有在任何其他层上定义样式。 导致看起来像这样：

如果我们将主题切换为Blue ，则蓝色主题的自定义样式（在本例中为蓝色文本）将覆盖核心的样式。 由于没有应用其他自定义样式，它将持续向上

结果是一个看起来像这样的网站：

如果我们应用全局样式，它将覆盖主题的：

如果我们应用文档样式，它将覆盖全局的（如果适用）：

最后，如果我们自定义一个特定的块，它将覆盖其他层：

导致：

我们还将能够“重置”或删除自定义设置。 在这个例子中，假设用户删除了他们的全局样式设置。 但是，文档样式仍然存在，呈现如下：

主题切换

全局 + 文档样式与主题相结合。 您可以将它们视为用户主题配置。 如果用户切换到另一个主题，它将应用该主题的全局 + 文档样式。

假设用户已经对他们现有的主题（“蓝色”）进行了大量定制。
假设用户安装了一个全新的主题（“红色”）。 他们刚刚下载的主题。

一旦他们切换，全局+文档样式将被重置。

原因是他们从来没有在“红色”主题上定制过任何东西。

切换回“蓝色”，将恢复他们以前的全局/文档样式。

TLDR（太长，没读）

• 有一个样式层次结构 - 核心、主题、全局、文档、块
• 全局、文档、块样式由用户自定义
• 全局 + 文档样式与主题相关联
• 这允许以最小的副作用进行主题切换

非常感谢您的参与！ 欢迎想法+反馈🙌

很好的分解，谢谢@ItsJonQ！
主题和全局不是几乎一样的东西吗？
我的意思是考虑主题的未来可能会是什么样子，大多数主题可能会从使用定制器切换到全局样式系统。 现在存在于定制器中的设置将被迁移到这个系统......它们可以被认为是同一件事。 如果主题使用定制器，我们可以称它们为“主题”，如果主题使用全局样式系统，我们可以称它们为“主题”，但它是一个或另一个，在定制器和全局中没有任何主题具有相同的设置-样式编辑器，因为没有理由这样做，两者兼而有之也没有任何好处。

关于 css-vars：我不会担心 IE 支持...解析内容并用它们的值替换 css-vars 在 PHP 中并不难。
IMO 我们可以使用 css-vars 和一个简单的过滤器，它可以在 PHP 端搜索和替换服务器端，可以完美地工作。

在前端使用 CSS 变量是否有更好的替代方案？ 这里的问题是任何使用 WP 的网站都会停止在 IE 上工作。

这可以通过创建回退来解决，例如：

p {
    font-size: 16px; // Fallback for IE.
    font-size: var( --font-size-paragraph );
}

它可以使用https://www.npmjs.com/package/postcss-custom-properties自动化另一种方法是 SASS mixin，虽然 CSS 变得泥泞（你必须写<strong i="11">@include</strong> font-size-mixin( 16px );这有点不自然。有一些选项可以克服旧的网络公民，因此 CSS 自定义属性可以很好地使用。

我刚刚通读了#9534 和这个问题的所有内容，我想提出一个就我所读到的还没有提到的观点。

用户样式与构建器样式

以上所有内容主要涉及“用户”的最大灵活性和控制，以核心和主题样式的形式为他们提供坚实的基础，但让他们拥有最终决定权和广泛的能力来改变网站的样式。

这是一个有效且肯定是最常见的用例，但我来自一个完全不同（而不是相反）的方向：有多个用户的站点以及设计者、开发者和编辑者之间的

在那种情况下，上面提到的主题级别应该是第一个、最后一个也是唯一一个来决定所有内容的样式。

我们不应该只接受用户的控制吗？

一般是的，但可能不是这里。 让我们看看为什么。

如果一个网站是基于企业设计、风格指南或任何其他经过深思熟虑的系统，一个按钮看起来就像一个按钮，用户（想想内容编辑器）甚至不需要能够对诸如按钮的背景颜色。 个人用户控制不可能保持全局一致性。

（更重要的是，我个人认为取消一些与样式相关的选择实际上可以帮助用户成为内容编辑器，让他们无需考虑样式。这实际上使他们感觉更有控制力，即使他们在技术上可能不是。_ “决定，而不是选择”_)

核心风格总是固执己见。

我知道必须有一些基线，但即使没有删除，通常也需要彻底改变。 简单的例子：目前，Column 和 Gallery Blocks 使用 CSS Flexbox 进行布局，如果你的整个站点布局基于 CSS Grid，那么即使不妨碍任何 Core Block CSS 也完全过时。

所以基本上在这里，多层覆盖的整个概念介于无关和有害之间禁用、覆盖或尽可能多地控制它。 即使某些东西可以被用户设置样式，我也会看到金字塔被洗牌，例如主题层在顶部拥有最终决定权，并且只能“让”用户选择某些样式。

因此，如果整个系统为用户提供了比我们现在更多的样式控制，请确保作为用户可控引入的任何设置都可以禁用、限制或覆盖。 这样一来，在自定义颜色/渐变、字体大小、列数、首字下沉等方面就不会像当前那样难以控制。

最后的想法

总结起来，我知道古腾堡的总体方向是一种非常直观的内容编辑方法。 WordPress 一直很关注内容和布局的分离，但目前我看到了这可能成为棺材上最后一颗钉子的风险，因此这不仅很困难，而且随着我们走得更远，它变得完全不可能为用户提供无限的造型力量。

在这种情况下，用户特别应该没有或至少很少控制网站的样式。

@kraftner这真的很准确，我只想指出这种级别的控制已经“在那里”发生了。 目前不乏插件，使用户能够对自己的网站布局进行微观管理——甚至对自己不利。

通过在核心中实施这个新系统，这种做法最终会被 WordPress 本身所宽恕，IMO 不符合特定类型用户的最佳利益，他们不知道什么是设计系统，因此也不知道它们的相关性和影响。 我什至会说这种用户代表了大多数用户群。

这是在继续之前要解决的重要问题。

感谢您的详细想法， @kraftner ，这些都是很好的观点。

以上所有内容主要涉及“用户”的最大灵活性和控制，以核心和主题样式的形式为他们提供坚实的基础，但让他们拥有最终决定权和广泛的能力来改变网站的样式。

我认为这里不一定是这种情况。 该系统提出了一种以可以更好地控制的方式构建块的样式能力的方法，但它并没有说明谁将承担这种控制。 其中大部分内容完全有可能仅作为主题构建器工具向管理员和设计人员公开，而不必向最终用户公开。

将其更多地视为“主题编辑器”的演变，而不是将所有样式细节的控制权交给用户。 后者对大多数用户来说也不是很好，因为它会让人不知所措，但主题需要更好、更轻松地控制块（尤其是他们甚至不知道存在的块！）。

有多个用户以及设计师、开发人员和编辑人员之间明确分离的站点。 在这种情况下，用户特别应该没有或至少很少控制网站的样式。

这是完全合理的，不言而喻，站点可以控制是否公开这些工具、哪些角色以及哪些容量 — 就像您的普通用户无法访问 PHP 主题编辑器一样。

甚至核心样式也可能过于自以为是。 相反，主题级别应该是第一个、最后一个也是唯一一个来决定所有内容的样式。

以这种方式设置事物应该在您的控制之下 - 不要加载默认块样式（可能在结构样式之外）并限制编辑全局和局部块样式选项的能力。 我认为您概述的是一个完全有效的用例，应该很容易适应和改进。

因此，如果整个系统为用户提供了比我们现在更多的样式控制，请确保作为用户可控引入的任何设置都可以禁用、限制或覆盖。

确实。 再一次，我认为这个基础对块的主题给予了更深思熟虑的控制。 一个副作用是，如果用户想要使用 GUI 进行那种级别的控制，而不是手动编写 CSS 和修改 PHP 模板，我们最终会得到一个也可以向用户公开的系统，但这不会是一个-size-fits-all-use-cases，因为 WordPress 的世界非常多样化，我们需要适应不同用例的工具。

如果有更多您认为正在放弃对您的控制权的事情的例子，请将它们报告为问题，以便讨论和解决。 我确实同意，目前可能需要努力完成您可能想要禁用的所有内容。 更全面的块样式系统的部分动机是使其更易于控制——无论是通过打开还是关闭它。

我认为您概述的是一个完全有效的用例，应该很容易适应和改进。

这听起来很棒@mtias。 我只是想再次强调这一点，尤其是我认为对于这些用户可控的功能中的每一个都应该是一个阻塞要求，仅当它带有控制选项时才进入插件或至少核心（配置、限制、禁用）。

我来到这里的原因主要是因为你在 6 月份的 WCEU 办公时间里几乎说了同样的话，当时你、我和@m在谈论这个特定的话题时。 但是我当时已经有了这样的印象，即这被视为以后的“可有可无”的东西，而不是硬性要求，甚至不是优先事项。

关于我正在谈论的失去控制的例子 - 他们中的大多数人已经有了问题，但不幸的是，对他们中的很多人来说，几乎没有任何动静。 通常我也不明白相应的错误是如何发生的，为什么在开发过程中甚至没有尝试将其关闭以获取新功能。
所以最后感觉就像一个非常令人沮丧的“Whac-a-mole”情况，对于每个可以重新控制的功能，另外两个无法控制的功能正在进入编辑器。 只是为了强调我正在谈论的内容，这里列出了我目前或以前正在努力解决的问题，没有或只有 hacky 方法来控制它们。 （这是我对即将到来的关于这个主题的

• 首字下沉：#6184 / #14654 -> #6023（早在 WP 5.0 之前就已知/据报道这是有问题的，为什么这个功能根本没有出现？）
• 表格的背景颜色 #16478 / #19659（为什么“权衡”可以，而不是阻塞问题？）
• 字体大小 #13824 / 46290 （这怎么会漏掉？禁用东西是添加任何选项后首先要尝试的事情之一，不是吗？）
• Gradients：#18213（为什么此功能不等待通用解决方案禁用，而是添加一个实验性标志，没有文档，仅引入另一种禁用某些功能的新机制？）
• 列数 #10791 -> #18892（我理解需要通用解决方案，但为什么在此之前没有暂停新功能？）
• 模板锁定 #8112 / #7845（这些是能够锁定 CPT 结构以取代旧的自定义字段插件方法的迫切要求）

我知道在这个列表的最后，我有点偏离了样式问题，但我相信所有这些都表明了一个总体主题：控制古腾堡仍然介于困难和不可能之间。

不要误会我的意思：我确实理解 Gutenberg 仍在大量开发中，孤立地看待所有这些问题当然可以说会发生错误，没有什么是完美的，我们只能做一件又一件的事情。 但是以上所有的总和让我觉得它没有被项目领导视为优先事项，而不是首先通过内容编辑解决这个重要问题，我们已经在推进下一个更复杂的领域的完整站点编辑。

TL;DR：控制用户能力是整个古腾堡的一项重要而紧迫的需求，我真的认为现在是时候更加关注这一点了。 请在实现任何更多功能之前，请让我们重新控制。 ：祈祷：

我不想过多地深入研究杂草，但在问题描述中的一个示例中，我想到了一件事情：

对于开始使用全局样式的块，它们的 CSS 需要重构以使用系统输出的 CSS 变量。

然后这是示例的一部分：

border: 1px solid var(--wp-gs-color-primary-dark20);

当涉及到主题时，颜色总是很困难，因为很难将它们基于特定的语义。 本质上，这是对主题模式和块样式之间的关系进行硬编码，这可能是限制性的。 我可能错了，但我认为这意味着可以定义的颜色数量和颜色类型是固定的。 此外，块实现者必须对主题的配置以及这应该是哪种颜色做出判断。 我想知道是否可能需要一个单独的层，将这些样式连接到主题的架构。

相反，这可能被定义为：

border: 1px solid var(--wp-button-block-border-color);

然后定义一个关系（按主题？）：

--wp-button-block-border-color: --wp-gs-color-primary-dark20

不知道我是否解释清楚了。 这听起来已经很复杂了，但我预计它可能需要解决。

编辑：进一步，尽管不确定我提出的建议如何与第三方块一起使用。 也许问题是语义需要更清楚地定义，因此我们避免将某些东西命名为“黑暗”或“光明”。

由于我是可视化的，我想知道这是否可以帮助任何人了解每次迭代某些内容时会受到什么影响。 例如，图层如何过滤。 这建立在@ItsJonQ创建的金字塔级联

这样做是查看具体操作：

• 全局更改样式：例如，增加基线字体大小。 在这种情况下，它跨越一切作为全局。 圆点显示是顶部（尊重层次结构）以及因此受到影响的内容。
• 本地/文档更改样式：例如，基线字体大小仅在关于页面上增加。
• 块样式更改：例如仅更改引用块上的基线字体大小。

如果您注意到有 2 列在那里没有任何交互，那么在您进行任何交互之前，这些列会一直存在。

另一个需要注意的块包括以下几点：

• 风格变化
• 自定义样式
• 开发者（插件）块样式

在此图像中，主题是核心默认值旁边的图层，任何在该图层之上全局更改的图层一直到顶部的块。

全局样式 - 第一次迭代

今天早上（多伦多时间），我与@nosolosw和@jorgefilipecosta 通了电话，以同步这个新的全球风格焦点。

我们每个人都在某个时间点独立解决了这个问题。 鉴于 Global 风格的许多方面都是全新的（在古腾堡的背景下），以及所有不同活动部分所涉及的复杂性，我们觉得最好同步 - 分享我们的经验、想法、实验，并开始计划。

三部分

在讨论了各种实现细节和各种边缘情况后，我们将最初提出的概念简化为 3 个主要部分：

• 解析器（我们在会议中称之为“合并”）
• 块
• 控件

除了“变形金刚”、“钩子”和“渲染器”这3个部分仍然体现了原始设计的精神，简化并合并为“解析器”和“块”

解析器

Resolver 负责检查theme.json文件和之前保存的数据库中的全局样式数据。 然后它将数据集合并在一起并准备一些东西供古腾堡使用。

块

积木是我们都知道和喜爱的古腾堡积木！ 需要对块的.css以开始使用将成为全局样式系统核心的 CSS 变量。

控件

控件是使用户能够调整全局样式值的用户界面。 这些将在完整站点编辑体验中呈现。

注意：对于单个块实例也存在控件。 它们是块的InspectorControls中可用的各种控制字段。 更新只会调整样式值的应用方式，即添加内联样式 CSS 变量，而不是硬编码值。 （稍后会详细介绍）

流（“后端”）

下面将详细介绍 Global Style 系统的后端流程。

解析器

当解析器启动时，它首先在本地查找theme.json文件。

1. theme.json

对于此提案， theme.json文件是主题的一种简单方法：

一种。 选择使用全局样式
湾声明主题特定的样式值

theme.json的示例可能如下所示：

{
    "name": "Awesome Theme",
    "global": {
        "color": {
            "background": "black",
            "text": "red"
        }
    },
    "blocks": {
        "core/paragraph": {
            "color": {
                "text": "hotpink"
            }
        }
    }
}

在这个例子中，主题覆盖了全局默认的color.background和color.text 。 它还专门调整了核心段落块的color.text 。

2. 检查数据库

如果找到theme.json ，解析器将检查数据库以获取先前保存的全局样式。

主题特定的全局样式

全局样式将以特定于主题的方式保存。 这使得能够在没有风格美学冲突的情况下安全地切换主题。

这可以在此演示中演示

（尝试应用一些全局/文档样式并切换主题）。

3. 合并

theme.json数据和数据库数据被合并并准备被古腾堡使用。

堵塞

1.渲染

块由古腾堡编辑器加载和呈现。 块使用一系列与全局样式约定相对应的 CSS 变量。

CSS 变量

以下是使用全局样式的核心段落块的示例：

p {
    color: currentColor;
}

.wp-gs p {
    color: var(--wp-gs-paragraph-color-text, var(--wp-gs-color-text));
}

.wp-gs范围

对于我们最初的实现，我们的想法是将特定的 CSS 选择器（ .wp-gs ）应用于html或body DOM 节点，以有效地建立一个“支持全局样式的环境” .

这提高了全局样式块的 CSS 特异性。

在上面的例子中，没有全局样式的<p>渲染（就像他们今天所做的那样）将从父选择器继承它的颜色。

但是，在“支持全局样式的环境”中，将应用.wp-gs p规则。

var(...)

我们采用的惯例是在全局样式 CSS 变量前加上--wp-gs （WordPress 全局样式）。 在上面的例子中：

.wp-gs p {
    color: var(--wp-gs-paragraph-color-text, --wp-gs-color-text);
}

var()设置为：

1. 处理自定义块特定样式渲染
2. 回退到通用值

使用带有回退的块特定样式的约定为系统提供了更精细的粒度控制和稳定性。

2. 块 x 控件

如果块实例具有自定义美学更改，例如 textColor 更新，则更新的属性将呈现为内联样式。 当前实现和提议的实现之间的区别是在硬编码值上使用 CSS 变量。

当前的：

<p style="color: red;">...</p>

建议的：

<p style="--wp-gs-paragraph-color-text: red;">...</p>

在许多方面，效果是相同的。 但是，使用 CSS 变量可以应用大多数 CSS 级联效果。

控件

控件将出现在完整站点编辑的站点编辑流程中。

1.更新

当进行更新时，更新的属性被发送到解析器。

解析器完成它的工作（可能与@wordpress/data商店协调），并将更新的消耗品数据推送回 Gutenberg。

最后，更新的数据（以及更新的 CSS 变量）被水合并呈现到 FSE 用户界面和任何可见块。

流（“前端”）

我们（目前）提出的解决方案要求解析器检查/读取theme.json和数据库，以获取和创建给定页面的最新样式值组合。

这发生在页面加载的服务器端。

然后，解析器将创建一个<style>标记，以在加载时将其注入页面的<head> 。 例子：

<head>
    ...
    <style>
        :root {
            --wp-gs-color-text: black;
            --wp-gs-color-background: white;
            --wp-gs-color-primary: blue;
            ...
            --wp-gs-paragraph-color-text: hotpink;
        }
    </style>
</head>

最后，需要注入.wp-gs CSS 选择器来激活块中的全局样式。

- <html>
+ <html class="wp-gs">

就是这样！

第一个倡议

@nosolosw 、 @jorgefilipecosta和我将共同努力创建上述 3 个部分：

• 解析器- @jorgefilipecosta
• 块-@nosolosw
• UI 控件- @itsjonq

我们将要构建的第一个计划允许用户：

1. 为默认文本颜色设置全局样式
2. 启用核心段落 + 标题块以使用全局样式
3. 允许主题自定义默认文本颜色、标题和段落块文本颜色

陷阱

目前最大的问题是我们不确定如何正确支持 IE。 我们当前的系统非常依赖 CSS 变量，以及IE11 不支持的浏览器本机功能。

有可用的 polyfill，但不足以进行我们需要的渲染合并（至少，不是开箱即用的）。

我们非常注意这个差距。 现在，我们将继续使用基于 CSS 变量的解决方案，因为我们要验证系统的机制和流程。 它们不仅有效，而且不应该破坏向后兼容性，它们应该帮助 Block Builders、Themers 和用户感到被赋予权力而不是不知所措（例如冗长的 API 或 CSS 繁琐）。

反馈+谢谢！

首先，如果你已经阅读了（无论你是否略读过），非常感谢！ 我知道这是一个可怕的阅读。 ：心：

我的意图是在任何设计、实验和实现方面尽可能透明。

全局样式涉及许多活动部分。 我可以提供的上下文 + 更新越多，参与这个项目的人就越有见识。 这将导致更好的讨论和决策。

一如既往，欢迎提出想法和反馈！！

再次感谢 ：）

目前最大的问题是我们不确定如何正确支持 IE。 我们当前的系统非常依赖于 CSS 变量，以及 IE11 不支持的浏览器本机功能。

只是为了显示 IE11 周围的统计数据，以防它帮助人们加入：

• 截至 2020 年 1 月，IE11 使用率为 1.43%（通过CanIUse ）
• 截至 2019 年 8 月至 9 月，IE11 屏幕阅读器使用率为 10.9%（通过WebAim。2017年为 23.3%）。

将 IE11 支持留在“功能性”而不是“完美视觉”级别是一种常见的行业标准。

这可能就足够了，尤其是考虑到屏幕阅读器用例以及主题和块样式的其余部分作为后备？

我不知道例如ie11CustomProperties polyfill 有多可靠，但开发人员可以在需要时手动包含它。 您甚至可以通过某种选择加入切换从核心提供它？

截至 2020 年 1 月，IE11 使用率为 1.43%（通过 CanIUse）

在 2019 年 1 月至 2020 年 1 月的所有桌面访问中，IE11 使用情况为：

• 全球 4.09% ( statcounter )
• 荷兰 6.17% ( statcounter )

将 IE11 支持留在“功能性”而不是“完美视觉”级别是一种常见的行业标准。

同意

我不知道 ie11CustomProperties polyfill 有多可靠，但开发人员总是可以在需要时手动包含它。 您甚至可以通过某种选择加入切换从核心提供它？

根据个人经验，大多数 css-vars polyfill 无法正常工作，当它们发生时，它们会严重阻碍性能。

将 IE11 支持留在“功能性”而不是“完美视觉”级别是一种常见的行业标准。

这就是我们大多数人处理 css-vars 和 IE 难题的方式......定义一些合理的全局 CSS 规则，然后被 css-vars 覆盖。 如果访问者使用 IE，那么他们仍然可以完美地使用该网站 - 只是使用不同的配色方案、间距等。
WordPress 与 IE11 兼容，但“与 IE11 兼容”并不意味着 IE11 应该以恐龙后浏览器呈现它们的方式显示事物......只要它的功能正常，我们就清楚了。

我是 ie11CustomProperties 的作者。 https://github.com/nuxodin/ie11CustomProperties/
同时，Polyfill 速度非常快并且支持很多。
如果您想尝试，如果遇到问题，我会很乐意为您提供支持。

@nuxodin公平地说，我几个月没有测试过它，上次我检查了 v1.3 上的特定存储库，我发现从那时起它已经走了很长一段路：+1：

然后解析器将创建一个

@nuxodin哇！ 这看起来很有希望！ 非常感谢。 一旦我们准备好开始测试 IE11，我们肯定会探索 ie11CustomProperties。

我刚刚开始思考这可能如何在那里工作，但我想尽早标记这个问题。
@koke谢谢🙏！！ 我真的很感谢你和其他人尽早考虑问题/陷阱。

如果访问者使用 IE，那么他们仍然可以完美地使用该网站 - 只是使用不同的配色方案、间距等。
WordPress 与 IE11 兼容，但“与 IE11 兼容”并不意味着 IE11 应该以恐龙后浏览器呈现它们的方式显示事物......只要它的功能正常，我们就清楚了。

@aristath ，我非常同意这种观点。 我想如果 IE11 是您的主要浏览器，那么您已经错过了当今现代网络所提供的大量内容。 只要该后备版本有效且可访问，它应该没问题，但只有当您是 _site 访客_ 浏览其他人的 WordPress 站点时，这可能才是正确的。

从使用 WordPress 和 IE11 浏览器的 _site admin_ 的角度来看，很难知道编辑/自定义体验会是什么样子。 当使用 IE11 浏览器时，我们可能需要添加一些东西来禁用 WordPress 站点管理员的全局样式。 否则，他们将无法看到他们所做的任何自定义，这对他们来说可能是一种破碎的体验。

将 IE11 支持留在“功能性”而不是“完美视觉”级别是一种常见的行业标准。

这可能就足够了，尤其是考虑到屏幕阅读器用例以及主题和块样式的其余部分作为后备？

我更乐意为编辑器使用此选项。 我主要关心的是在前端输出 CSS 变量，因为这意味着任何使用 WP 创建网站的人_不再可以选择_来完全支持 IE，如果他们愿意的话。 在我之前的评论中（如果不够清楚，请见谅），我想指出这对于可能_必须_提供全面支持的政府和其他官方实体来说可能是一个问题。

由于性能影响，我也不愿意走 polyfill 路线。 可能值得研究一下如何在前端不使用 CSS 变量的情况下实现这一点（即使我们确实在编辑器中使用了它们）。

我主要关心的是在前端输出 CSS 变量，因为这意味着任何使用 WP 创建网站的人都不再可以选择完全支持 IE，如果他们愿意的话。

可以添加一个 PHP 解析器，如果启用该解析器将在服务器端运行，并将 css-vars 替换为它们的实际值。 这将使 IE 上显示的所有内容与在现代浏览器上显示的完全相同。
我们以前为我工作的机构做过这件事，而且效果很好。
此类任务所需的所有过滤器都已准备就绪，因此这不是一项不可逾越的任务。

可以添加一个 PHP 解析器，如果启用该解析器将在服务器端运行，并将 css-vars 替换为它们的实际值。 这将使 IE 上显示的所有内容与在现代浏览器上显示的完全相同。

这绝对是要走的路。 尽管我假设有一个限制，只要 CSS 变量保存在 :root 或类似的顶级选择器中。 类似于https://jhildenbiddle.github.io/css-vars-ponyfill/

可以添加一个 PHP 解析器，如果启用该解析器将在服务器端运行，并将 css-vars 替换为它们的实际值。 这将使 IE 上显示的所有内容与在现代浏览器上显示的完全相同。 我以前为我工作的机构做过这件事，而且效果很好。

这个 PHP 想法听起来非常有趣，特别是如果它没有与回退相同的限制。 我很想看到这个工作的 PR 或代码片段 - 听起来很有希望 :-)

当然，我可以为此处理 PHP 实现......
我们基本上需要两件事：

1. 获取 CSS 变量的值。
2. 为 IE11 添加回退样式。

对于第一个，我在https://github.com/WordPress/gutenberg/pull/19883#pullrequestreview -349737431 上发表了关于添加过滤器的评论。 我们可以使用该过滤器来获取 css-vars 及其值。

第二个取决于使用这些 css-vars 的实际 css 的打印位置。 它会在块中内联吗？ 如果是这样，那么我们可以使用render_block过滤器来处理注入向后兼容的 CSS。
如果没有，那么是否有 PR 或有关如何/在哪里打印这些内容的想法？ 或者主题只是使用wp_enqueue_style将样式表排入队列？
如果使用wp_enqueue_style ，它仍然可行，但需要解析入队文件的内容，查找 css-vars，如果文件中使用了这些变量，则计算需要添加的样式并打印它们. TBH 我想避免最后一个选项，因为如果主题添加大文件，它可能会增加一些开销。

全球风格路线图

谢谢大家，到目前为止您的想法/反馈！

已经有一些关于系统的某些方面（例如 CSS 渲染）的讨论，这是有效的。 对于整个系统以及各个部分如何组合在一起，似乎没有太多阻力或担忧，这是一个好兆头。 看起来我们走在正确的轨道上！

本周，我专注于探索和计划。 仔细考虑技术细节、实现细节、约束、要求和用例。 全局样式是一个庞大的项目，有许多活动部分。 这是一个可以对用户体验和生态系统产生深远影响的项目。

正因为如此，我认为提供清晰（高层次）的愿景非常重要——让任何参与其中的人都更容易理解和遵循。

我已经汇总了系统如何工作的高级概述，以及对工作阶段进行排序的粗略路线图。

📹视频截屏/演练
https://www.loom.com/share/9e63b821916a4f70821a52ced069b92b

在视频中，我介绍了系统的渲染流程并回顾了各个阶段。

渲染流程

上图（上图）说明了全局样式的渲染流程。 它可视化了系统的样式层次结构。 我给它起了个绰号叫“合成级联”。

它从左边开始（有古腾堡和积木）。 当块通过主题层、全局层、范围层和古腾堡编辑器中的最后本地化更改时，块的样式可能会被修改。 最后，所有这些累积的更改都会呈现到用户站点的前端。

“范围”

术语“范围”是指 FSE 体验中的“文档”或“模板”部分。 本质上，一个包含块的“容器”块。

第三方区块

第 3 方块是任何非核心块。 系统需要为他们提供一种方法来注册他们自己的自定义样式，并通过全局样式编辑界面来自定义这些样式。

第 3 方全局变量

3rd Party Globals 是指与块无关的非核心样式。 例如，为整体站点动画速度添加自定义全局样式。 或者整个网站的排版字体配对（标题/正文）。

阶段

我已将工作分解为 6 ​​个不同的阶段（上图）。 注意：Vibrancy 强调了我们对该领域所需的关注。 例如第一阶段，Red，Core/Block 区域非常活跃。

🔴红色

第一阶段！ 目标是在核心中创建基础系统，并将几个核心块装配到全局样式系统中。 我们还需要提供一个简单的接口来更新这些值。 最后，我们需要创建一个初始的客户端 (Gutenberg) 和服务器端 (Site) 风格的渲染系统。

首先，我们将针对core/paragraph和core/heading块。

认为这是MVP！

🟠橙色

第二阶段！ 这一阶段的重点是在系统中引入主题支持。 主题选项和theme.json文件将如何与核心默认值相互作用。 最后，主题定义的值如何呈现以及如何在全局样式编辑器 UI 中进行修改。

🟡 黄色

第三阶段！ 此阶段侧重于全局样式编辑器。 如何呈现块样式值以及如何修改它们。 用户自定义的全局样式如何影响主题和核心价值。

这是涉及大量视觉/交互设计的第一阶段。

🟢绿色

第四阶段！ 此阶段继续关注全局样式编辑器，但与文档/模板部分有关，以及它如何在 FSE 体验中发挥作用。 系统将需要确保范围内的更改与样式层次结构正确配合。

🔵 蓝色

第五阶段！ 这个阶段主要关注样式渲染方面。 在这里，我们将重新审视 CSS 变量在哪里是正确的解决方案。 如果没有，我们可以做些什么来复制这种体验，同时与系统的其余部分一起工作。 在研究解决方案时，我们需要确保范围和主题覆盖按预期工作。 最后，此阶段将开始研究 3rd 方块支持，并了解它如何与系统的其余部分配合使用。

🟣紫色

第六阶段！ 此阶段继续关注渲染并确保它在用户站点的前端正常工作。 它还确保（可能）新的渲染机制与样式层次结构的其余部分一起使用。 最后，它集成了 3rd 方区块和 3rd 方全球支持。

我们在哪里？

截至目前，根据（上文）描述的阶段，我们已经开始🔴红色阶段，我们的第一个倡议。

@jorgefilipecosta创建了一个初始 PR ，涉及此阶段的所有方面。

@karmatosed正在探索全局样式编辑界面的设计。

@nosolosw正在研究系统的解析器 x 客户端渲染器方面。

我一直在关注控件。

时间线

我还不能提供该项目的准确时间表。 我认为一旦我们开始构建、测试和合并，我们就会对事物有更好的认识。 在那之前，希望这些阶段的分解会有所帮助。

一如既往，欢迎提出想法和反馈！ 如果你坚持到最后，非常感谢你的时间！ ：心：

当然，我可以为此处理 PHP 实现......
我们基本上需要两件事：

1. 获取 CSS 变量的值。
2. 为 IE11 添加回退样式。

对于第一个，我在#19883（评论）上发表了关于添加过滤器的评论。 我们可以使用该过滤器来获取 css-vars 及其值。

第二个取决于使用这些 css-vars 的实际 css 的打印位置。 它会在块中内联吗？ 如果是这样，那么我们可以使用render_block过滤器来处理注入向后兼容的 CSS。
如果没有，那么是否有 PR 或有关如何/在哪里打印这些内容的想法？ 或者主题只是使用wp_enqueue_style将样式表排入队列？
如果使用wp_enqueue_style ，它仍然可行，但需要解析入队文件的内容，查找 css-vars，如果文件中使用了这些变量，则计算需要添加的样式并打印它们. TBH 我想避免最后一个选项，因为如果主题添加大文件，它可能会增加一些开销。

嗨@阿里斯塔斯，

感谢您分享您的想法并尝试解决此问题。

我认为我们在第二种情况下，使用wp_enqueue_style 。 使用变量的样式是普通的块样式，大多数时候使用 wp_enqueue_style 入队。 除此之外，我们还有一个更大的问题，包含这些变量的核心块样式是使用 WordPress 样式连接系统加载的，因此它们是一个巨大的电子表格的一部分。

另一点是，简单地替换 vars 可能不起作用，因为我们的想法是将来我们将能够为特定块内的事物自定义全局样式（例如，在特定组内，主要颜色是蓝色）。 变量可以具有的值不是静态的； 它们将取决于上下文。

我想我们应该尝试为 IE 中的 CSS 变量使用 polyfill。 我们甚至可以根据我们的特定需求定制一个，例如，从服务器传递一个带有变量值的 javascript 对象等。

然后解析器将创建一个

@ItsJonQ

它从右边开始（有古腾堡和积木）

我想你的意思是它从左边开始？

我还不明白的是：调色板，尤其是背景颜色将如何发挥作用？

• 如果我能够在全局级别上控制不同元素的颜色，我是否还可以定义一个将用作编辑器调色板的调色板？
• 如果我有一个用于背景颜色的调色板，我可以在全局级别上控制元素在不同背景上的外观吗？

以一个按钮为例。 如果我选择红色作为默认按钮的背景，它在不同背景（例如橙色）上的外观如何？

我可以全局控制橙色背景上的按钮背景颜色吗？ 或者，当每个按钮出现在不同的背景上时，我是否仍然需要分别为每个按钮选择背景颜色？

调色板，尤其是背景颜色将如何发挥作用？

@gchtr这是一个很好的问题 + 示例！ 如果我正确理解您的问题/用例……听起来我们需要处理以下情况：

• 所有按钮都全局样式为红色背景
• 但是，当它们出现在具有冲突背景（例如橙色）的东西中时，它们需要呈现不同的颜色（例如白色，黑色文本）。

这就是“范围”自定义全局样式的想法发挥作用的地方。

在 HTML/CSS 方面，你可以这样想象：

<button>...</button>
<div class="orange-section">
    <button>...</button>
</div>

button { background: red; }

.orange-section button {
    background: white;
    color: black;
}

棘手的部分是。 我们如何在 Gutenberg Global 风格系统中复制这个模型/风格层次结构？
在古腾堡的上下文中，这些位将是块。

所以在某种程度上......它会是：

<Block>
<Block>
    <Block />
</Block>

或者另一种看待它的方式......

<Block>
<ContainerBlock>
    <Block />
</ContainerBlock>

这意味着，我们必须能够限定特定于“Container”块的样式，以便任何（目标）子块都将继承这些样式。 样式系统必须从 UI 角度（样式编辑控件）和呈现角度支持这一点。

希望这是有道理的！！！ 🙏

我想你的意思是它从左边开始？

@ZebulanStanphill是的！ 非常感谢！ 我已经更正了:)

嘿@ItsJonQ ，

这看起来非常令人兴奋，但是，我也想知道全局样式系统将如何与调色板配合使用。 我使用 Gutenberg 为我的客户创建了一个迷你页面构建器，他们可以完全控制布局，但无法控制配色方案。 如果他们需要对调色板中可用的颜色进行任何更改，我必须为他们做，但如果他们有可能自己做，我更愿意。

调色板组件在我的设置中扮演着重要的角色，因为相同的颜色可能用于标题和按钮背景，下面是一个更清晰的例子：

Oxygen 已经以一种美妙的方式做到了这一点，它可以改变全局颜色并实时看到它的效果。 我希望这种行为也会以某种方式出现在全球风格系统中。

Oxygen 已经以一种美妙的方式做到了这一点，它可以改变全局颜色并实时看到它的效果。 我希望这种行为也会以某种方式出现在 Global Style System 中。

@dnnsjsk感谢您的支持和这个可爱的例子！

是的，我们必须支持这种互动。

最终，这一切努力都是为了改善（最终）用户体验。 这些调整不仅应该改变您的期望，而且在您进行这些调整时体验必须感觉良好。 它应该让人感觉有创意、自由和有趣。 这符合古腾堡编辑体验的目标:)。

诚然，根据我在本期分享的文字墙，很难分辨出这种体验😅。 我主要关注技术方面以及这些部分将如何协同工作。 除了良好的最终用户体验，开发者体验也必须良好。 我们建立的工作流程让 Themers 和 Block 开发人员感觉更轻松、更好。

@karmatosed 、 @shaunandrews和其他人开始在这里探索这种体验的设计/用户体验：

https://github.com/WordPress/gutenberg/issues/19255

我们还早呢！ 我认为最近的路线图将帮助 dev x 设计工作协同工作。

你好！ 我刚刚在https://github.com/WordPress/gutenberg/issues/19255#issuecomment -582315718 上写了很长的评论，我可能应该在这里发布？ 无论如何，该评论的关键要点是，作为设计基本块模式的努力的一部分，我无意中创建了一个项目的愿望清单，我希望看到全局样式系统能够完成（如字体粗细、行-height, dropcap-size），主要是我已经看到提到的东西。

请使滑块“有点粘”（平滑滑块在大范围内是一种糟糕的用户体验）并显示当前值。

@carike-codes 我们在更新的RangeControl组件中有这些功能🙌
https://github.com/WordPress/gutenberg/pull/19916

滑块的行为与默认 HTML input[type="range"]行为完全相同。 在有很多步骤的情况下，例如min: 0, max: 1000, step: 1 ，它会感觉“更流畅”，因为有1000值要递增

（希望有帮助）

_注意：此评论是关于 react-native 兼容性_

该 API 不包含主题默认样式，只包含用户自定义。 因此，我们可能需要另一个 API 来提供 WordPress 默认值与主题默认值的连接。 这个问题与 FSE 发生的情况非常相似......

因此，如果我正确理解这一点，我们将要实现一个客户端版本的解析器来使用该 API？ 当全局样式在控件中更新时，这是否也有助于 FSE 更新块样式？

如果是这种情况，古腾堡本地人会想要重用这个客户端解析器。

仍然存在 react-native 不支持的 css 变量问题。 postcss 转换将不起作用，因为我们需要它们是动态的，以便使用对 API 的新提取进行更新。

考虑到我们只能在原生中使用内联样式这一事实，因此我们需要一个额外的模块来为编辑器中的任何特定块填充样式。

让我们举一个块样式示例，其中用户在 InspectorControls 中覆盖了此块的文本颜色，我们有：

--wp-gs-color-text: #fff;
--wp-gs-background-color: yellow;
--wp-gs-paragraph-color-text: #000;

.wp-gs p {
    color: var(--wp-gs-color-text);
    background-color: var(--wp-gs-background-color);
}

<!-- wp:paragraph {"textColor":"red"} -->
<p style="--wp-gs-paragraph-color-text: red;">
Lorem ipsum dolor sit amet</p>
<!-- /wp:paragraph -->

在移动设备上，我们需要生成完全相同的代码，因此save必须保持不变。 但是， edit必须避免使用 css 变量：

<RichText style={ { color: "red", backgroundColor: "yellow" } } .../>

我不确定编写 X 平台块的含义是什么。 编写这样一个自动解析特定块的所有样式的模块应该是可行的，至少如果我们将自己限制在一些 CSS 属性并且我们在 RichText 组件中没有几个可自定义的元素。
Web 和移动设备可能会共享此功能，尽管它可能会对性能产生影响，在这种情况下，我们只需要在移动设备上激活它。 @jorgefilipecosta @koke不确定您对此有什么想法吗？

@koke不确定您对此有什么想法吗？

是的，我也有类似的担忧，但我还没有任何明确的答案。 我目前的直觉是，我们最好的选择实际上可能是改进我们在原生上使用的 CSS 解析器，以实际支持 CSS 变量（以及其他一些东西，如暗模式、媒体查询和@supports ）。 与其尝试一步将 CSS 转换为StyleSheet ，我们可以让它生成一个DynamicStyleSheet ，它可以在运行时调整一些变量和查询。 这听起来像是一项巨大的努力，所以我仍在寻找可能更容易的替代方案。

我可以用它来覆盖引导程序中定义的 scss 变量吗？

我刚读完基于块的网站中复杂全球系统的冒险 - 第一部分，我认为在这里分享它是个好主意。 这是一篇很长但很有趣的读物，它可能会给这里的一些人一些想法。

我们一直在玩 Global Styles 并且有一些想法/想法/问题。

全局样式的当前方向

如果我理解当前的方向，这个想法是将全局样式变量硬编码到块中，以便它们使用它们。

难点在于，粒度控制最终可能会变得非常多和广泛，并且也很难在自定义位置使用。 例如，这些可能是粒度控制的工作方式（从概念上讲，不是语法示例）：

gs-another-background-color
gs-yet-another-background-color
gs-h1-font-color
gs-h1-font-color-exception
gs-yet-another-h1-font-color-variation
...many more variables required

Global Styles 方向的另一个想法

在使用这种方法之后，我们想知道全局样式是否可以更“与事物无关”，并像这样简化：

gs-color-2
gs-color-3
...more variables required, but no values are ever duplicated

这里的想法是，块可以选择是否希望背景为gs-color-1 、 gs-color-2或gs-color-3 。 甚至可能通过全局样式选择器 UI。 这是一个_真的_粗略的模型，它可能看起来如何。

这种方法的一些优点：

• 所需的全局样式变量总数较少。
• 样式的应用移动到块，允许更多的设计灵活性。
• 不需要重复的值（选择#fffff作为gs-color-1一次，而不是多次）
• 块用户可以灵活地在他们认为合适的任何地方使用全局样式。 例如，它可以用于背景、字体或边框，但都可以使用gs-color-1 ，而不是定义#fffff 3 次。

如果我必须在两者之间做出选择，我会选择方法 B，但我针对主题所采用的版本是基于方法 B 构建的方法 A 的细粒度版本。

首先，我定义了一堆颜色：

--white: #ffffff;
--gray-light: #d4d4d4;
--gray-dark: #333333;
--black: #141414;
--aqua: #7fdbff;
--blue: #0074d9;
--navy: #00203f;
--teal: #38cccc;
--fuchsia: #f012bc;
--purple: #b00dc9;
--maroon: #85144b;

（我可以看到您为 Wordpress 提出的更通用的 --color-1 类型设置的优势，但原理是相同的。）

然后，我将它们映射到一些相对通用的高级变量上，例如：

--text-color: var(--black);
--text-color-secondary: var(--gray-dark);
--accent-color: var(--aqua);
--background-color: var(--white);
--heading-color: var(--navy);
--action-color: var(--purple);
--action-color--invoked: var(--maroon); /* hover & focus states */

然后可以根据主题需要通过更具体的变量级联这些变量：

--focus-ring-color: var(--accent-color);

--link-color: var(--action-color);
--link-color--hover: var(--action-color--invoked);

--input-color: var(--text-color);
--input-border-color: var(--input-color);
--input-background-color: var(--background-color);

--button-color: var(--action-color);
--button-color--hover: var(--action-color--hover);

/* whatever other theme-specific variables I want to make up */

主题作者可以在这里获得他们想要的粒度（--h2-color、--page-title-color、--subhead-color，等等），但他们总是可以尝试在考虑级联的情况下构建核心. 例如，如果我在我的主题中添加一个带有深色配色方案的块：

.is-theme-dark {
    --text-color: var(--white);
    --text-color--secondary: var(--gray-light);
    --accent-color: var(--aqua);
    --background-color: var(--navy);
    --heading-color: var(--blue);
    --action-color: var(--fuchsia);
    --action-color--invoked: var(--purple);
    /* whatever other theme-specific variables I want to switch */
}

换个角度，如果有人制作了一个使用顶级颜色的食谱插件，那么当放入主题作者的.is-theme-dark组块时，很有可能会正常工作：

.recipe {
   color: var(--text-color);
}
.recipe__image {
    border: 0.5rem solid var(--accent-color);
}
.recipe-print-button {
   color: var(--action-color);
}
.recipe-print-button__icon {
   color: var(--accent-color);
}

关于 IE11 支持：

您是否检查过此解决方案： https :

我被建议澄清我们在块样式系统方面的位置。 我正在尝试巩固我们在两个主要线程中的内容：愿景https://github.com/WordPress/gutenberg/issues/9534和具体步骤https://github.com/WordPress/gutenberg/issues/20331我会在接下来的几天更新。

自从这个问题被创建以来，我们在实现方面取得了很大进展：我们有一个有效的 theme.json并且对其控制编辑器的作用有了更成熟的理解，我们已经创建了新的设计工具，一个初始机制连接块样式系统的块和全局级别，并且比我缺少的还要多。

这个问题已经达到了它的目的，所以我关闭它。 上述提示应该证明这次对话对于揭示我们需要走的具体步骤是多么重要。