Gutenberg: 特定于块的响应控件

我将围绕该主题分享一些初步的探索。

此时最需要响应式控件的块是列块。 当前，列自动在小屏幕上堆叠，而没有任何即将发生的迹象。 Media＆Text块也可以在移动设备上堆叠，但是它包含一个切换开关，用于打开或关闭该行为。 对于响应式控件，这是一个很好的基准：

对于许多用户而言，此切换开关提供了足够的控制权：合理的假设是，如果我们要求，现代的网站构建器可以自动处理所有这些。 但是，我们应该为想要指定在各个断点处显示多少列的用户提供某种程度的微调控制。

考虑到这一点，我围绕几个核心思想进行了探索：

1. 响应式控件应位于“高级”面板中。 该面板当前使用率极低，但似乎是响应式设置的合理家。 我们应该设置好的默认值，并且在大多数情况下，用户甚至都不会访问此面板。
2. 允许3个不同的选项：
   答：我们的智能默认设置：在移动设备上堆叠列。
   B.在各处使用相同数量的列。
   C.指定手机，平板电脑和台式机屏幕尺寸的列数。

考虑到这些，我构建了一些原型：

桌面原型（Figma）
移动原型（Figma）

_供参考的屏幕截图：_

正如您在单击时所注意到的那样：选择选项（C）后，“设备”面板中显示的唯一设备选项是您正在_不_使用的设备。 如果您正在使用手机，则“列”下的默认滑块将控制您在移动设备上看到的列数。 如果您选择选项（C）并从台式机访问此块，则默认滑块将控制您在台式机视图上看到的列数。 这样可以防止重复执行相同操作的控件，但是我不确定是直观还是令人困惑。 另一种选择是显示所有设备，并在选择选项（C）时禁用默认滑块，但这对我来说很奇怪。

我希望获得一些反馈！ 我也很好奇这些控件如何扩展到其他类型的设置：还有哪些其他块将对像这样的响应控件有所帮助？

我最近为接下来几周内启动的工作项目建立了一个相当大的主题。 我以为我应该分享一些想法。 以下面板是我为处理各种设备上堆积的列而实现的面板。 每个设备可以对其进行显式设置，也可以颠倒顺序。 （对列css使用flex）。

顶部（边距/填充）也可用于所有块。 允许我们完全从编辑器创建一些非常棒的布局。

我希望看到的是编辑器顶部的桌面/平板电脑/移动按钮，可在不调整窗口大小的情况下将编辑器切换到相应的模式。 这将允许非常快速地构建所有响应级别。 虽然这三种模式可以满足我的需求，但可以在主题中配置一系列响应级别，从而使您可以在这三种模式之间切换。

由于我们不再有基于iframe的编辑器，因此显然要花些时间才能完成。 考虑了一下如何完成类似的工作后，我会想到编辑器不能使用媒体查询，而是需要为每个块的编辑器专门开发css。 无论如何，我目前正在针对自己的主题进行此操作。 如果“ editor-styles-wrapper” div将当前响应添加到类中，则可以轻松地将媒体查询替换为基于类的响应。
例如：.editor-styles-wrapper--mobile {}

我希望看到的是编辑器顶部的桌面/平板电脑/移动按钮，可在不调整窗口大小的情况下将编辑器切换到相应的模式。 这将允许非常快速地构建所有响应级别。 虽然这三种模式可以满足我的需求，但可以在主题中配置一系列响应级别，从而使您可以在这三种模式之间切换。

感谢分享，@ mattbolt。 如果您还没有看到它，我们将在这里讨论确切的事情：＃13203

至于响应的边距/填充规则：我想_love_看到更多关于边距+填充的微调控件。 但我想对于大多数用户而言，它们在全球范围内将更加有益。 这就是为什么我不在上面的探索之列。 我确实认为我们绝对应该在_somewhere_中包含边距/填充控件，但是每个块对我来说似乎有点过于精细（至少对于核心而言）。

heya @mapk @ kjellr-我在＃13203上发表了评论，但我认为在本期中也应强调其中的一部分。

这是我们正在开发的最新原型-基于我在＃13203中指出的最新可用性测试中得到的反馈。

菲格玛

我们的模块有一些不同的设置，并不是每个设备都可以在每个设备上进行编辑。 因此，我们认为在各个设置中放置响应控件是有意义的。 在上面的示例中，可以调整布局的响应控件，但不能按类别过滤。 （按类别进行过滤应始终适用于所有设备尺寸）我们还希望使用智能默认值，因此人们不必去为每种设备尺寸调整布局。

测试的第一部分是使用实时块运行的，该实时块没有任何响应式布局控件。 我们的许多参与者都提出了以下问题：“如何更改移动设备的这些布局设置？” 这使我相信，比我们想象的要更多的人想要这种粒度控制。

将响应式控件置于高级设置中是另一种选择，但是，我相信它将使查找变得更加困难……这是一个一次性的问题-一旦找到它，便知道下一次在哪里寻找它时间。 也就是说，我还认为在用户正在调整的设置的上下文中也需要保留响应控件。

我们没有机会测试这个最新版本，但我们希望尽快。

@kjellr

我希望获得一些反馈！ 我也很好奇这些控件如何扩展到其他类型的设置：还有哪些其他块将对像这样的响应控件有所帮助？

我真的很喜欢您如何处理如此复杂的内容，并以一种有用的方式简化它，任何人都可以理解。 另一个可能受益的块是Gallery块，该块已经具有一些基本的列调整设置。

@mattbolt

顶部（边距/填充）也可用于所有块。

谢谢马特！ 您也可以在这里分享对边距和填充的探索。 ＃11824

@LevinMedia

我们的许多参与者都提出了以下问题：“如何更改移动设备的这些布局设置？”

非常有意思！

也就是说，我还认为在用户正在调整的设置的上下文中也需要保留响应控件。

就Woo块而言，这很有意义，它也允许调整产品编号。 您是否认为像@kjellr的模型中只有一个调整（即列）时是否有必要？

我注意到到目前为止，大多数模型都使用仅图标控件。 理想情况下，对于可访问性（和一般可用性），最好是响应控件具有可见标签。 我不确定这样做是否可行，但我只是想指出一点，因为古腾堡（Gutenberg）一直在各个领域努力解决可访问性问题，因此最好避免避免添加任何仅图标式的UI。

我们需要考虑的另一件事是可能需要响应设置的工具栏选项。 例如，在Cover块上找到的块宽度功能。 您可能希望在台式机上使用窄宽度，在移动设备上使用全宽。

嘿亚@mapk

您是否认为像@kjellr的模型中只有一个调整（即列）时是否有必要？

我做。 可发现性对我来说是很大的原因。 它将响应式设置直接放在正在操作的设置的上下文中。

我认为在很多情况下，一个块具有多个响应设置，但并非所有这些都可以整齐地放置在单个存储桶（如布局）中。

例如，上面的第二个问题。

是否需要根据设备宽度隐藏/显示块？

在我以前使用页面构建器的情况下，该问题的答案是肯定的。 通过它自己的响应控件添加“可见性”设置将允许这样做。

事后看来-在这种情况下，可见性可能不是最好的例子，因为类似的东西可能更适合作为简单的切换列表。

[toggle]在桌面上显示
[切换]在平板电脑上显示
[切换]在手机上显示

我们的许多参与者都提出了以下问题：“如何更改移动设备的这些布局设置？”

@LevinMedia我想对这一发现进行跟进：您能否分享有关参与此测试的用户群的更多详细信息？ 这个发现让我有些惊讶，所以我想了解更多。 谢谢！

我认为这里的关键考虑因素是我们对响应式操纵对整体创作体验的影响的期望。 不仅现在，而且将来也是如此。

块的默认设置应该是哪个？ 台式机，手机，平板电脑？

这个问题现在对我来说是最重要的。 出于上述@mapk的原因，我非常喜欢@kjellr的设计，但是我不确定它将过渡到“移动优先”体验的程度如何？

正如@LevinMedia所说，我们最近的可用性测试的大多数参与者已经对移动设置表现出了浓厚的兴趣，并宣布它对他们“非常重要”。 当然，必须说那里存在一些偏见，因为每个参与者都是WooCommerce用户，也许比其他用户更“精通技术”。

我目前的倾向是同意@LevinMedia-这里的上下文至关重要。 我认为用户应该很容易找到这些设置并了解他们的工作。

与此相关的是，我个人不喜欢设置面板的“高级”部分-几乎在任何使用情况下都如此。 对我来说，这是任意的，并且我根本不期望在第一次与块进行交互时会在其中找到什么设置。

这个问题现在对我来说是最重要的。 出于上述@mapk的原因，我非常喜欢@kjellr的设计，但是我不确定它将过渡到“移动优先”体验的程度如何？

沿着这些思路，我上面的方法中的考虑因素之一是它知道您正在编辑哪个屏幕。 换句话说，您正在使用的设备就是您要为“第一个”设计的设备。 如果您使用手机访问，则在主区域中唯一看到的滑块是移动滑块。 其余的在高级中关闭。 或者，如果您是从平板电脑访问的：平板电脑将显示为默认控件，而其他平板电脑则位于下方。 最终，这很容易造成混乱：在常规的侧边栏面板和“高级”之间拆分控件对我来说有点不舒服，正如我在上面的笔记中最初提到的那样。

但总的来说，我确实喜欢设备感知的总体思路。 在@LevinMedia发布的模型中，这相当于在移动设备上访问时默认选择移动选项卡，或者在从平板电脑访问时默认选择平板电脑等。（实际上，我认为我在您的其中一个模型中看到了，但现在找不到。）

为此花了一些时间思考一个略有不同的方向。 在上一次迭代中，我不太满意的一件事是如何在主侧栏“列”面板和“高级”面板之间分离列控件。

此探索稍微简化了选项，并将所有内容移回主要的“ Columns”区域：

🖥桌面原型

📱移动原型

第一帧仅添加了我们当前可用于“媒体和文本”块的“移动堆栈”切换。 默认情况下，它是打开的，并且所有内容都会自动处理。 对于不想管理这些设置的用户，这是最佳设置。 与今天不同的是，如果用户将其切换为关闭状态，则会在此向他们显示更多的微调控件。 从这里，他们可以不理会它（每种情况默认为​​相同大小），也可以调整以为每种设备类型设置不同的列数。

一些注意事项：

• 通常，这需要更好的标签+描述。
• 这对于一个选项来说效果很好，但是如果每个断点有多个设置，它将无法很好地扩展。
• 通常，我们不会基于关闭的切换开关来显示/隐藏控件。 不确定在这里是否真的有意义。
• 与上述相关：在层次结构方面，似乎有一个切换开关影响其上方的字段很奇怪。 在这种情况下，使用开关进行引导可能会更自然。 但是，这也感觉不对，因为人们在这里要做的主要事情是调整列数而不切换响应控件。

在探索和阅读这里的思想时，我会不断提到一个问题：_in核心应该是多么简单或复杂？_一些自定义块肯定会包括每个断点的大量单独设置：边距，填充，显示+隐藏块等。这可能是他们的用户群满意的。 但是我们不一定要在默认块中包含该级别的控制，因为它对于新手用户可能是压倒性的。 就是说...建立起可以扩展到那些超级复杂场景的设计模式对我们来说可能是有益的，这样我们可以帮助证明在所有情况下都应如何处理。 我们如何定义一个简单的模式，在不想要管理响应式设置的人和想要对这些事情非常具体的人之间进行缩放？

不错的模型，@ kjellr！

通常，这需要更好的标签+描述。

至少应将设备图标移动到每个滑块的标签，例如“🖵Desktop”。

这对于一个选项来说效果很好，但是如果每个断点有多个设置，它将无法很好地扩展。

我认为答案就在于切换。 如果每个响应控件都有一个启用/禁用自定义设置响应的切换怎么办？ Divi Builder与此类似。

与上述相关：在层次结构方面，似乎有一个切换开关影响其上方的字段很奇怪。 在这种情况下，使用开关进行引导可能会更自然。 但是，这也感觉不对，因为人们在这里要做的主要事情是调整列数而不切换响应控件。

我想我更喜欢在滑块上方设置切换，因为切换会影响滑块。

但是我们不一定要在默认块中包含该级别的控制，因为它对于新手用户可能是压倒性的。

我认为，默认情况下，很多东西可能会隐藏在切换器的后面，例如默认情况下，或者默认情况下，只需将它们保持在封闭的手风琴中即可。 边距和内边距都可以在同一个手风琴中，您可以像在模型中那样使用切换来切换这些控件的响应性。 如果此手风琴放置在所有较常见的选项下方并且默认情况下处于关闭状态，我认为这不会给用户带来过多的选项。

@kjellr-跟进Jay的评论。 我们的样本量较小（有八名参与者），因此正如我之前提到的，绝对有必要进行更多测试/研究。

所有参与者都来自WooCommerce设计反馈小组-正如杰伊·杰伊所说，我们的参与者，尤其是这组参与者都倾向于偏向更具经验的建造者/商店组装者个人资料，而不是DIY商店所有者。

我昨天发布的模型的一个小后续：

🖥桌面原型

📱移动原型

与@jasmussen和其他一些人一起研究ButtonGroup而不是Toggle以及一些（希望）更清晰的副本。 通过这种方式更改格式和复制，我们可以更自然地将控件放置在column控件的顶部。 从层次上来说，这感觉更加令人期待。

我真正喜欢这种方法的一件事是，它树立了一个先例，这些控件默认情况下应由块处理。 块设计者将拥有比用户更多的控制权，因为他们将能够定义自己的断点。 块设计者还将比许多用户有更多的响应式设计经验，并且应该能够在此处应用最佳实践。

同样，如果用户切换到手动模式，对断点设置进行了大量调整，并且搞砸了，“自动”选项对他们来说是一个快速逃生舱口。

这里还有一些奇怪的事情（例如，谁选择了这些确切的断点？）。 但这似乎是一种可以扩展到更复杂设置的设置，我认为我们正在接近。

爱它，凯耶尔。 它允许使用默认值，该默认值在大多数情况下是最佳的，但对于希望使用它的用户来说则是粒度。 感觉就像是一种模式，可以从列块扩展到其他块，甚至扩展到第三方块。 做得好。

很好，@ kjellr！

我仍然认为，出于可访问性和清晰度的原因，每个滑块都应具有可见的文本标签，但除此之外，我认为我们即将能够实际实现此功能！

另外，就可访问性而言，在这种情况下，我们确定按钮组比切换按钮更合适吗？

我喜欢这些概念，它们在专栏文章中也很不错，但是我发现两者都有一些小问题。

带有切换功能的概念是我最喜欢的两者，但由于设置每次标签都不同，因此在设置之间并不一致。 因此，该设置具有移动选项不会立即变得显而易见。 我担心可扩展性。

带有分段控件的概念对我来说有点奇怪，因为您要作者在实际与列设置进行交互之前先选择自动还是手动。 在设置中打开“列”部分时，这不是我期望的。 标签对我来说也不太清楚。

我渴望听到更多有关@LevinMedia早些时候分享的概念的想法。 经过一轮可用性测试之后，我们得出了该解决方案，它似乎与其他区块作者所做的事情相当一致。 我们不赞成这种方法是有原因的吗？

我渴望听到更多有关@LevinMedia早些时候分享的概念的想法。 经过一轮可用性测试之后，我们得出了该解决方案，它似乎与其他区块作者所做的事情相当一致。 我们不赞成这种方法是有原因的吗？

当然！ 我无意打折该解决方案。 我认为从这个方向上缺少的关键是介绍了“让我们来处理”选项。 虽然高级用户可以直接进入并编辑每个设备图标下的所有内容，但对于通知用户而言，这将是一项繁重的工作。 特别是当我们可以为他们自动处理时。

除此之外，该方向的症结在于设备的分段控制：

我认为效果很好，可能是在这里使用的一种模式，尽管如果我们在其上面合并一个分段控件，可能会感到很奇怪。

我认为从这个方向上缺少的关键是介绍了“让我们来处理”选项。

知道了因此，令人担心的是平板电脑/手机切换按钮不是可选的吗？ 这就说得通了。 但是我觉得设备分段控制将在不同的设置类型之间提供更一致的模式，因此扩展性更好。 易用性与一致性和可伸缩性是很难的！

为了对这些概念进行压力测试，我建议在列下添加另一个选项，该选项也将包含一个响应组件：行。

为了对这些概念进行压力测试，我建议在列下添加另一个选项，该选项也将包含一个响应组件：行。

是的，我很快就嘲笑了类似的东西来尝试一下。 从技术上讲，它确实有效，尽管确实有些重复+冗长：

记录另一个和我@kjellr一起工作过的概念，以获得其他想法：

Figma原型

我喜欢的东西：

1. 这意味着作者只需要调整一个设置即可，前提是他们希望自动处理。
2. 即使在“自动模式”下，他们仍然可以看到他们将在移动设备上获得多少列，这并不神秘。
3. 只需单击一下，即可取消设置的完全控制链接。

我不太热衷的事情：

1. 视觉上占据了相当大的空间
2. 没有简单的“移动堆栈列”选项。 老实说，不确定这是否很重要……

我认为我更喜欢将标准切换按钮切换到链接图标按钮，因为它更容易给出标签。 请记住，UI的设计必须考虑可访问性。

我认为UI可能如下所示：

列数
（ON⚫）自动调整移动设备的列。
――――― o― [__4]

列数
（⚫OFF）自动调整移动设备的列。

🖥️桌面
――――― o― [__4]
⬛平板电脑
――― o ――― [__3]
📱电话
―o ――――― [__2]

能见度
（ON⚫）🖥️Show在桌面上
（开⚫）tablet在平板电脑上显示
（开⚫）📱在手机上显示

从技术上讲，“链接”概念是同一回事，切换开关在视觉上只是位于不同的位置。 它仍然可以以几乎相同的方式显示给屏幕阅读器，并且可以将工具提示添加为标签（不过我不确定它们的可访问性）。 告知作者即使在“自动”模式下在小屏幕上将使用多少列，也无需强制将其预览，这还有一个额外的好处。 也许那还没那么有用-没有测试就很难知道。

我同意这种格式对于可见性设置不太适用。 将这些选项链接在一起似乎毫无意义。 但对我来说，该设置也不需要自动/手动切换。 每个设备一次可见性切换最有意义。

从技术上讲，“链接”概念是同一回事，切换开关在视觉上只是位于不同的位置。 它仍然可以以几乎相同的方式显示给屏幕阅读器，并且可以将工具提示添加为标签（不过我不确定它们的可访问性）。

可见标签总是更易于访问。 还应记住，控件的视觉顺序应与其选项卡顺序相匹配，并且它们的选项卡顺序应遵循信息体系结构……这意味着您将在逻辑上使用的控件首先出现在您随后使用的控件之前，就像标题出现在标题之前一样。 Pinging @afercia ，因为他比我对这件事了解得多。

告知作者即使在“自动”模式下在小屏幕上将使用多少列，也无需强制将其预览，这还有一个额外的好处。 也许那还没那么有用-没有测试就很难知道。

这绝对是一个整洁的好处，尽管我不确定默认情况下显示一堆禁用的控件是否适合尝试防止UI变得不堪重负。 我个人不会被它打扰，但是有些人可能会被它打扰。

喜欢这个想法和讨论！

到目前为止，看起来讨论的焦点已经集中在admin UX上。
但是，我想在前端，内容优先和现代网络上提供一些思考的食物。

在让普通用户掌握“响应式设计”方面，您真的无法超越3种设备范例。 问题是，针对3种设备的3种设计实际上并不是响应式设计。 这是自适应设计。 这是像素完美的梦想，而现代网络却不存在。 它是严格的，脆弱的，不能用于未来，并且不能总是产生用户期望的结果。

新的CSS功能一直在发布，以引导我们从自适应设计转向自适应。 rem ， vw ， flex ， grid 。

响应式设计是让内容通知设计，而不是让设计决定和破坏内容。

这是二十十九世纪的专栏

如果我的网站设计要求6列文字，那么我希望在段落宽度小于150px之前妥协一下设计。

Flexbox可以使它相当自动。 试试看。

.wp-block-columns {
    display: flex;
    flex-wrap: wrap;
}

.wp-block-column {
    flex: auto;
    width: 100%;
    margin: 0 1rem 1rem;
}

.has-4-columns .wp-block-column {
    width: calc(100% / 4 - 2rem);
}

.has-6-columns .wp-block-column {
    width: calc(100% / 6 - 2rem);
}

.wp-block-column {
    min-width: 100px
}

从UX的角度来看，到目前为止讨论的内容是很棒的：

允许3个不同的选项：
答：我们的智能默认设置：在移动设备上堆叠列。
B.在各处使用相同数量的列。
C.指定手机，平板电脑和台式机屏幕尺寸的列数。

我想从内容优先的角度出发：

也许这三个选择？
A.智能默认值：最小列宽为200px（ish）。
B.指定列数。
C.调整将列推到下一行的最小列宽。

感谢您提出这个问题，@ meh。 您对其中的大部分内容绝对是正确的-这也绝对是我的主意。

对我而言，最重要的一点是：没有什么比设备范式更胜一筹了，以使人们掌握响应式设计。 他们看到这些图标，然后立即得到它。 诸如“调整将列下移到下一行的最小列宽”这样的设置对我们来说很有意义，但是它们更加抽象，将使用户有更多的头脑来弄清楚。 许多专业人员都在努力理解真正的响应式设计，因此我们需要寻找最简单的方法来与用户进行交流。

真正的响应式设计非常依赖于上下文和内容。 虽然您建议的3个选项可能对column块很好用，但产品或author bio块的设置可能完全不同。 票证的主要目标之一是找到一种可以在许多不同背景下工作的解决方案，并为块设计人员/开发人员创建一个遵循的通用模式。 这实际上是我在上面发布的第一个伴奏中放弃这3个选项的关键原因。

正如您所注意到的，设计师和开发人员已在很大程度上转变为在需要中断布局的内容上设置断点，而不是在任意设备测量上设置断点。 我们擅长这样做（大多数是😄）。 我认为每个区块的“智能默认设置”是我们解决该问题的最佳场所。 块设计人员/开发人员（通常）知道其块可能包含的内容种类，理想情况下，他们无需为默认状态而遵循这些设备断点。 如果用户决定自己管理这些内容，我们可以删除开发人员内置的任何超级特定的响应规则，并为用户提供更标准化，易于理解的替代方案。

这完全有待辩论，但这至少是我对此主题的思考。 🙂

是的，我理解并同意explore探索设备驱动解决方案的理由。 只是想将这个bug计划在耳朵里。

我认为可能会有妥协。 通常，CSS如何处理传递给它的选择和值。

从上周开始就

首先，我考虑了切换选项的一些替代标签：

我倾向于右边的两个：我认为它们比我最初输入的内容更清晰，并且通过与一个非技术性的朋友进行的快速现场测试，她似乎了解这些内容意思比其他更清楚。 对于实际的ButtonGroup标签，我认为将“自定义”替换为“手动”可能有点道理？ 虽然我没有很强的偏好。

我还认为，包括可选的第二行文本是有帮助的，因此块可以为默认行为提供一些附加的上下文。 在column块的情况下，可能类似于：

我还花了一些时间重新评估围绕更复杂设置的探索。 我不知道允许插件在单个设备类型下对多个控件进行分组是否会有所帮助：

与他人讨论此问题时出现的另一件事是在为另一台设备进行设置与预览更改之间的链接。 也许我们可以在某个地方包含指向该区域中特定于设备的预览的链接（与＃13203相似）。

关于流程的注意事项：如果我们确实旨在改善团队之间的协作并开发出更好的产品，那么讨论引入新的UI控件的问题应带有“可访问性”标签。 正确标记和鼓励参与将不胜感激🙂

回复：具有“自动”和“自定义”选项的最新原型：这些控件应基于哪些底层本机HTML元素？

• 按钮：通过辅助技术从上下文中读取文本“自动”和“自定义”没有多大意义
• 单选按钮：上面的“特定于设备的布局”文本可用于字段集图例，该图例将为单选按钮提供上下文。

此时：不使用本机单选按钮的论点是什么，这些单选按钮是用于单选选项的适当元素？

@kjellr @afercia
我认为没有理由不只是使用标记为“使用自定义设备的特定布局”的切换开关，还是默认禁用的类似开关。 类似于“古腾堡”中现有的某些切换控件，可以在切换框下方显示描述当前状态的其他文本。 但是，如果使用单选按钮，则我同意“自定义”比“手动”更好。

我认为没有理由不只是使用标记为“使用自定义设备的特定布局”的切换开关，还是默认禁用的类似开关。 类似于“古腾堡”中现有的某些切换控件，可以在切换框下方显示描述当前状态的其他文本。

我将为此+1。

我对分段控件的主要抱怨是，它看起来像两个选项，与单个切换相比，它可以将感知的复杂性提高100％。 作者必须了解_two_设置而不是_one_。

由于切换按钮可以具有更详细的标签，因此更易于理解。 似乎其中一种设置的解释非常清楚，而两种设置的解释却更加模棱两可。 那里有一个明显的赢家。

但是，我认为默认情况下该切换为_on_并将标签设置为“自动为其他屏幕尺寸配置布局”之类的内容。 我的理由是，这是我们作为“智能默认值”呈现的东西，默认情况下_enabled_。 对我来说，感觉就像您选择退出。 例如卸下训练轮或禁用ABS。

您的过程给我留下了深刻的印象，在这里，Kjell –您对此持积极态度和开放的态度，成为模型高效的贡献者❤️，并利用了现有的模式和UI控件。

我记得看到您（我不记得私有DM在哪里？）也为此创建了一个切换版本，并且您探索了使用ButtonGroup实际改善可用性和可访问性的方法。 也许也应该在此处发布该模型？

我个人并不喜欢我们可能会在动荡的评论海中提出哪个版本，但是鉴于最近提到过切换，似乎也值得一提。

该按钮组适用于“图像”尺寸，尤其是因为该组中的每个项目都具有明显的相关性：

与往常一样感谢您的反馈。 👏

@afercia

正确标记和鼓励参与将不胜感激

当然！ 该线程非常活跃，我几周以来都没有向上滚动来查看标签。 感谢您添加辅助功能标签，并欢迎您进行讨论。

此时：不使用本机单选按钮的论点是什么，这些单选按钮是用于单选选项的适当元素？

我较早尝试过，但没有分享探索内容：

这就是我亲自通过的原因：

1. 无线电控件占用了大量空间，我认为它们并不清晰。 这里的目标是使它看起来很简单-大多数人应该能够掩盖该设置并让我们处理。
2. 我们有关RadioControl的准则建议“要打开或关闭单个设置，请使用ToggleControl组件”。 这是单个设置，因此某种切换似乎更合适。
3. 我一直在寻找Material来使用的图案。 我一直找不到触发显示/隐藏其他控件的单选按钮的任何示例。 但是，我发现了一些使用切换的示例。

@jasmussen

我记得看到您（我不记得私有DM在哪里？）也为此创建了一个切换版本，并且您探索了使用ButtonGroup实际改善可用性和可访问性的方法。 也许也应该在此处发布该模型？

是的，我在与DM交谈时与您分享了这一点。 这里是：

我还为这种方法设计了

我被这两种解决方案所困扰。 按照我们自己的准则， ButtonGroup用于“将所有相关的按钮分组在一起”，而我们的标准FormToggle “打开或关闭单个设置”。

仅基于这些简短描述，我认为FormToggle更有意义。 但这在这两种方法之间或多或少地折腾了。

ButtonGroup要做的主要事情是它使我们能够更清楚地标记两种状态（自动，手动）。 这样做的措辞确实令人困惑，因此这似乎是一个加号。 我完全可以相信，否则，两者都值得测试。

哦，还可以从这里回应自己：

与他人讨论此问题时出现的另一件事是在为另一台设备进行设置与预览更改之间的链接。 也许我们可以在某个地方包含指向该区域中特定于设备的预览的链接（与＃13203相似）。

我快速浏览了一下它的外观，并考虑了模态内部的预览：

这似乎很有趣，但也可能超出了此问题的范围。

我也不太喜欢预览图标的“仅悬停”。 在移动设备上进行尝试时，我对其进行了一些调整：

真正挖掘响应式预览。 我一直在闲暇时用相同的方式涂鸦，只需将预览按钮替换为：

👆但是在烤箱中需要更多时间，即使是建议也不要考虑。 只是一个想法的种子，可以混合在一起，成长为某种实际的东西。

我通过在设备图标上添加标签以及在滑块组中添加“列数”标签，对@kjellr的简洁模型之一进行了调整，使其更加易于访问。 （那最后一个必要吗，@ afercia？）

我不确定的一件事是断点宽度是如何定义的。 它们是由主题提供还是由块提供？ 块可以选择只有2个断点而不是3个断点吗？ 那4呢？ 自定义断点宽度如何？ 无论如何，我都不认为编辑器应该提供它们。

这种与@meh在此评论中谈论的联系。 我开始倾向于类似于他在评论末尾所建议的内容。 我想可以通过2个滑块来实现列的响应控件：

最小列宽
――――― o ―――― [300] px
每行最大列数
――― o ―――――――― [__3]

对于我来说，这似乎简单得多，并且“响应”得多，而不必基于平均设备屏幕宽度来求助于硬断点。

这里的目标是使它看起来简单

@kjellr肯定，感谢您的澄清。 但是，控件不仅应_appear_简单。 他们还需要在语义上正确以支持辅助技术。 例如，屏幕阅读器需要以有意义的方式宣布它们。 想象一下屏幕阅读器用户通过可聚焦的控件进行切换：在某个时候屏幕阅读器会宣布：
“汽车”
“手册”
没有任何上下文：“自动”和“手动”指的是什么？

而是，将带有图例的字段集中分组的单选按钮会提供上下文，因为已宣布了图例。

作为一般规则，本机表单控件已经提供了语义和可访问性所需的内容。 相反，自定义控件通常会破坏预期的语义和交互。

对于设计人员和开发人员而言，了解在实现自定义控件时应格外小心，以重建等效的本机控件的所有功能，这一点非常重要。

在这种情况下，这是两个选项之间的一个选择。 按钮不合适。 在带有图例的字段集中分组的单选按钮将是理想的选择。 如果将控件的_signage从两个选项之间的单个选择更改为“ on / off”开关，则该切换可能是可以接受的折衷，这相当于一个复选框（所有有关警告的详细说明均在此处进行了讨论）在之前的问题中）。

回复：材料设计：我不确定对于像WordPress这样旨在尽可能容易访问的项目，它不一定需要成为灵感的来源🙂许多材料模式很大程度上受移动用户界面的启发，并且还有很长的路要走使这些模式完全可用。

除了列之外，我还需要Image块的“移动堆栈”选项。 我要迁移到Wordpress二十九岁的旧版网站上有很多左右浮动的文字换行图片，宽度（并且需要保留）为300px左右。 将这些图像块放到“段落”块中后，在桌面上可以正常工作，但在大多数移动屏幕上，它们会将其旁边的文本压缩为难以辨认。 对于每个图像，我必须使用Image块上的Advanced面板添加一个CSS类.isom（比键入“ is-stacked-on-mobile”要快得多！），该图像可将断点扩展为100％的宽度二十九个用途。 我认为这对许多用户来说可能是一个普遍的问题，而不仅仅是迁移者（如果是这样的话）。

只是一个建议，因为我对Gutenberg尚不熟悉，无法提供解决方案。

感谢大家的不断反馈！

我不确定的一件事是断点宽度是如何定义的。 它们是由主题提供还是由块提供？ 块可以选择只有2个断点而不是3个断点吗？ 那4呢？ 自定义断点宽度如何？ 无论如何，我都不认为编辑器应该提供它们。

通常，断点将由块作者指定。 我最近与@jasmussen聊天，我们同意Gutenberg提供少量默认值开始是有意义的（也许这些默认值映射到Gutenberg使用的默认断点），但是我们应该给块作者一个选择选择启用或停用这些功能，以及在特定区域需要它们时添加更多功能。

在这种情况下，人们似乎或多或少地在使用标准的切换控件。

我已经对@ZebulanStanphill的comp进行了一些轻微的清理，调整了间距和类型层次。 由于我们已经在使用文本粗细来区分面板标题和各个字段标签，因此我对各个设备标签进行了颜色调整。 它们的灰色是$dark-gray-300 ，它通过了AA。

这是更新的模型和原型：

🖥桌面原型

📱移动原型

我也继续前进，并模拟了一些替代案例：

• 画廊街区
• 一个更复杂的示例（我认为这里最底部的某些标签可以合并。）

为了继续前进，我在想什么：

1. 从线程中的每个人那里获得另一轮反馈。 我很想从一个完整的角度来听听：这是否是一个可靠的解决方案。
2. 收集一些备用标签。 切换字段的标签仍然有些混乱。 我们应该生成更多选项，然后：
3. 对标签进行标签正确设置了对该功能的期望。

请让我知道对该方向以及后续步骤的任何想法！

@kjellr

由于我们已经在使用文本粗细来区分面板标题和各个字段标签，因此我对各个设备标签进行了颜色调整。 它们的灰色是$dark-gray-300 ，它通过了AA。

就个人而言，为了安全起见，我宁愿选择深灰色。 浅色的标签看起来有点怪异。

一个更复杂的示例（我认为这里最底部的某些标签可以合并。）

是的，没有理由在每个切换按钮上方放置标签。 可以将图标放在切换标签旁边的切换旁边。

另外，这只是一个小问题，但是这些滑块不应该一直延伸到左侧，而不是看起来像是从断点标签缩进了吗？

就个人而言，为了安全起见，我宁愿选择深灰色。 浅色的标签看起来有点怪异。

稍微深一点就可以了。 我不会比$dark-gray-500更暗（如下图所示），否则灰色最终看起来与文本的其余部分非常相似。

另外，这只是一个小问题，但是这些滑块不应该一直延伸到左侧，而不是看起来像是从断点标签缩进了吗？

我缩进他们，以增加一些层次结构的字段。 当每个字段为全角时，不清楚它们是从属于“列数”标签的。

@kjellr

我缩进他们，以增加一些层次结构的字段。 当每个字段为全角时，不清楚它们是从属于“列数”标签的。

在这种情况下，缩进断点标签是否也有意义？

在这种情况下，缩进断点标签是否也有意义？

有点，但我们通常不缩进。 这样做对我来说似乎是无意的/残破的：

这也是具有全角字段的comp，用于比较：

正如我上面提到的，这消除了一些视觉层次，而且乍一看似乎不太容易扫描。 仅缩进字段似乎是一个很好的折衷方案：

我真的很喜欢只缩进字段的布局。 这似乎解决了所有问题，并同意在那里获得一些反馈。

我唯一真正关心的是共享的“复杂示例”。 这是我觉得设计无法正常工作的地方。 一旦有两件事需要响应控件（即列和产品数量），所有这些图标和标签就让我难以解析。 从好的方面来说，它的结构足够好，我仍然可以解析它。 😉

我唯一真正关心的是共享的“复杂示例”。 这是我觉得设计无法正常工作的地方。 一旦有两件事需要响应控件（即列和产品数量），所有这些图标和标签就让我难以解析。

我完全同意。 在以前没有标签的有效期中，我认为这些仍大部分可消化：

...但是当新版本变得复杂时，很难对其进行扫描。 改善此问题的一种可能方法是采用以下思想：

• 建议将多个控件合并在同一设备部分下（如下面的“布局”部分所示）。
• 当控件的标签可以声明设备名称时，消除设备标签（如下面“可见性”部分所示）。

我感觉很好的第一个。 对第二个不太确定，因为我认为很难确定最佳做法。

我建议先考虑语义，然后再围绕所需的语义进行设计。

每个输入都需要以有意义且独特的方式标记。 这些文本标签将是与滑块和数字字段关联的<label>元素。 作为辅助技术的用户，我应该如何区分均标有相同文本的多个字段？

例如：

• 作为屏幕阅读器用户，在不同的数字字段之间切换时，我会听到多个字段的“列数”，而不清楚它们指的是什么（台式机，移动电话？）
• 作为语音输入用户，说出“单击列数”命令会使我正在使用的语音识别软件感到困惑，因为它无法区分名称相同的字段

用户可以使用一些解决方法，但强迫他们探索周围的事物或使用其他方法浏览内容并不理想。

所有这些标签都需要提供更好的上下文，并且每个字段都必须唯一。

该界面很复杂，我建议您探索一种从根本上简化它的方法。 例如：

• 我不确定这些滑块增加了什么价值，除了它们的“精美性”：即使使用鼠标也很难使用它们，它们占用了大量空间，并且已经有输入字段
• 不确定设备图标是否确实必要：删除它们可以节省一些空间

很高兴看到“ Auto”（自动）和“ Manual”（手动）按钮在上一个原型中消失了，并且已被切换按钮取代（尽管切换按钮有其自身的问题）。 谢谢。

可见性设置是隐藏某些设备的整个块吗？ 是否将其作为每个块的选项添加？ 按钮，段落，分隔符等？

我个人不喜欢这种做法，但我想仍然有一些无法解决的用例。
有足够的用例吗？ 还是我们假设其他页面构建者这样做了，所以必须这样做吗？

可见性设置是隐藏某些设备的整个块吗？ 是否将其作为每个块的选项添加？ 按钮，段落，分隔符等？

哦，很抱歉给您带来的困惑：这只是在不同情况下对这种模式进行压力测试的一个示例（它是在上面的第3方“产品”块的背景下提出

感谢您的输入，@ afercia！ 感谢您在这里的反馈。

作为辅助技术的用户，我应该如何区分均标有相同文本的多个字段？

我的想法是，每个部分（台式机，平板电脑，移动设备等）的父标头将是区分它们的关键，但是我一直希望从有人通过控件进行切换的角度出发。 如果有人（例如）使用旁白（voiceover）并直接点击其中一个子控件，我会感到困惑。

听起来，最好让每个标签都清晰明确地为我们服务。 我不知道这是正确的解决方案，但出于说明目的，您是从标签角度提出这样的建议吗？

• 我不确定这些滑块增加了什么价值，除了它们的“精美性”：即使使用鼠标也很难使用它们，它们占用了大量空间，并且已经有输入字段

在这种情况下，我们只是重新使用在块的默认状态下使用的滑块控件。 如果我们要删除滑块，我想我们想对“自动”响应式设置和针对每个设备的手动设置都这样做。 但这似乎是围绕滑块有用性进行更广泛讨论的开始，我不确定这张票是否是解决此问题的合适场所。

在任何情况下，这都是为了开始为响应块设置定义可重用的模式，因此，在这种情况下，尽管移除滑块可能会对我们有所帮助，但在其他情况下仍然可能会使用滑块。

• 不确定设备图标是否确实必要：删除它们可以节省一些空间

我希望保留图标，因为它们是有用的视觉参考点。 尤其是在我最新版本中的缩进字段中，图标在大量的文本和控件中脱颖而出，成为快速的视觉标记。 如果我们最终在标签上添加更多文本，则将进一步增强此优势。

@afercia

我建议先考虑语义，然后再围绕所需的语义进行设计。

如果使用fieldset ， legend等来相应地编写HTML， @ kjell的布局是否可以与

听起来，最好让每个标签都清晰明确地为我们服务。

@kjellr是:)我

@mapk是的，我已经考虑过了。 fieldset和legend是将一组控件组合在一起并为其命名的正确方法。 不过，这是实际支持的问题，需要进行测试。 与单选按钮或复选框组一起使用时效果很好。 我不知道它是否可以很好地与range和number输入配合使用。

RangeControl组件还有一个问题：范围和数字输入使用相同的标签值。 因此，范围和输入的数字具有相同的可访问名称。 不理想。 将提议在今天稍后的无障碍团队会议期间进行讨论（欢迎大家参加）。

范围和数字输入使用相同的标签值

我希望通过https://github.com/WordPress/gutenberg/pull/13863 @afercia进行更改

谢谢@meh！ 我在那儿迅速发表评论。

@kjellr是:)我

谢谢，@ afercia。 这是一个样机：

对我来说，字段标签的“列数”部分在“列数”标签后显得有些重复。 但是我认为这是可行的。

是的，我已经考虑过了。 fieldset和legend是将一组控件组合在一起并为其命名的正确方法。 不过，这是实际支持的问题，需要进行测试。 与单选按钮或复选框组一起使用时效果很好。 我不知道它是否可以很好地与range和number输入配合使用。

我们如何验证它是否适用于range和number输入？ 如果已经通过这种方式解决了此标签问题，则我希望保持各个字段标签的简洁性。

我认为“列”，“项目”等部分对于每个字段标签中的设备类型很有帮助，就像您在最近的模型中所使用的那样。
除了您前面提到的画外音场景外，我还可以想象，例如，如果我在使用景观移动设备并且看不到父标题时，它会很方便。

同样，设备类型名称将全为单数或全为复数。 我知道他们是实体模型。 只是说：笑脸：

同样，设备类型名称将全为单数或全为复数。 我知道他们是实体模型。 只是说in

以上更新。

这个有趣的想法的后端呢？ 有没有人想出任何使用它的方法？ 是否会有类似对象的东西，甚至会存储多个需要的所有值的单个属性？

关于最后一个模型@kjellr ，“ Columns”的手风琴标题似乎多余，标题为“ Number of columns”，并且继续阅读“台式机上的列”或“平板电脑上的列”等。单词“ columns”出现很多。

如果标题“ Number of columns”是fieldset的legend ，是否仍然需要满足？ 然后，这应该表明该字段集中的分组项目都与“栏数”有关吗？ 因此，输入标签可以只是“ Desktop”，“ Tablet”和“ Mobile”。

字段集和图例：如前所述，需要进行测试：

@mapk是的，我已经考虑过了。 字段集和图例是将一组控件组合在一起并为其命名的正确方法。 不过，这是实际支持的问题，需要进行测试。 与单选按钮或复选框组一起使用时效果很好。 我不知道它是否适用于范围和数字输入。

根据我上面的评论，也许像下面这样？ 我还包括了标记。 @kjellr ，您怎么看？

@mapk可能应删除滑块，因为它们在诸如列数之类的粗略控件的上下文中不是很有用。

我一直在想@ZebulanStanphill

范围输入可很好地用于音量控制之类的功能，或者在我们的图像覆盖不透明度方面，您只需看一下滑块即可了解结果。 _25％，50％，100％_

来自MDN文档

由于这种小部件不精确，因此除非控件的确切值不重要，否则通常不应该使用它。

我想刻度线可能会使它更有用，但是为什么还要提供两种调整列的方法？

如果仅使用数字输入，则可以释放一些空间以在上下文中使用输入和标签。

[4] columns on desktops
[2] columns on tablets
[1] column on mobile devices

大家好！ 关于响应式可见性，我在EditorsKit插件（以前是Block Options）上具有此功能。 这些功能的工作原理如下：

https://www.youtube.com/watch?v=1VuBXAUqTjA

希望你会爱上它！ 干杯!

谢谢@phpbits！ 我感谢您在那里的探索，但是在这种情况下，我认为“开/关”状态太难辨认。 在这种情况下，像切换控件或复选框之类的方法可能会更好？

滑块可能应该删除，因为它们在诸如列数之类的粗略控件中不是很有用。

谢谢@ZebulanStanphill。 @afercia在上面也提到了这一点。 我愿意探索另一个设计迭代。 @kjellr有什么想法吗？

另外，让我们通过设计获得此东西，并开始对其进行PR。 我认为我们可以与实际用户更好地在插件中进行测试。

谢谢@phpbits！ 我感谢您在那里的探索，但是在这种情况下，我认为“开/关”状态太难辨认。 在这种情况下，像切换控件或复选框之类的方法可能会更好？

@mapk我也想到了这一点，但是它占用了很多空间，并且在带有过多选项的块下放置这些复选框感觉不太好。 我在以前的版本中有该复选框。 但是我认为，有了设计团队和可访问性检查，您会做得比我做的更好。 我将尽我所能:)谢谢！

我认为范围输入很好，因为它们提供了最小/最大值的清晰可视指示。

滑块可能应该删除，因为它们在诸如列数之类的粗略控件中不是很有用。

谢谢@ZebulanStanphill。 @afercia在上面也提到了这一点。 我愿意探索另一个设计迭代。 @kjellr有什么想法吗？

这肯定可以更改，但是我不确定在此票证中是否也需要这样做，因为无论响应控件是否变为现实，这些滑块都存在。 还有另一张专注于探索/审核滑块的票证。 同时，我认为仅将此线程集中在获取可与滑块一起使用而无需滑块的自适应控件解决方案中是有意义的，这样它就可以扩展到不仅仅是列块之外。

我在这里阅读了几乎所有评论，但有人想到使用设备可见性作为不加载前端内容的功能，而不仅仅是使用display:none ，因为我总是得到一些确实想要的疯狂设计师隐藏前端移动设备上的许多图像，但是无论图像是否仍然加载都没有关系...所以我确实创建了ACF来防止这种情况...

在调整列的情况下，我个人觉得这些滑块非常好用，因为它们使我能够简单地单击/拖动并快速查看该设置的所有值的所有结果。 这是基于以前使用类似控件的经验得出的-显然，尚未构建此控件。 如果设置只是一个输入字段，那么对我来说编辑并去评估每个可能的值将很繁琐。 对于每个值，我都必须单击输入，退格键，类型数字，在编辑器中查看结果，然后重复。

另一个好处是，如果设计得当（大拇指，刻度线等），则滑块可以直观地传达相对的最小值/最大值。

我了解我是鼠标用户，对于其他用户而言，滑块可能也不理想。 我希望我们能找到一个对尽可能多的用户有效的平衡点。

我现在合并了：

• ResponsiveBlockControl组件
• DimensionControl分量

这些奠定了为给定Block属性（例如padding启用视口特定控件的基础。

在＃19909中，我购置了一种响应式编辑的替代方法，该方法着眼于潜在地使每个现有块都能够进行响应式更改而无需附加代码。

在移动设备上进行列宽调整的手套将在移动设备上按列顺序排列。

例如，在全屏上，我设置了列1-2-3-4-5。 当此响应进行转换时，我可能希望它们出现5、4、3、2、1。
或5-3、1（*不显示2、4）。

各个列控件_响应_：

1. 切换显示/隐藏
2. 控制宽度
3. 下拉框用于重新排序

物有所值-这是我们自定义样式控件的最新迭代，首先是单个块，然后是自定义列块

爱它！！！！！！！！！！！！！！

什么时候？ 什么时候？！

感谢您的分享！ 我被抽了!!!!!

这是我为自己的自定义阻止响应控件开发的：

@mattbolt是当前正在开发布局迭代吗？ 如果是后者，我很想知道您如何解决媒体查询的障碍。

这是这些工具的第二次可视化迭代。 我们是在Wordpress 5于2018年底发布后内部开发的原始文档，自2019年1月起已在多个站点投入生产使用，但主要是

至于媒体查询，服务器端渲染组件支持我们所有的块。 在调用$content = apply_filters('the_content', $post->post_content);我们先刷新所有当前注册的样式。 然后，在渲染过程中，每个块都会注册任何唯一应用的样式，并接收包含在该块的CSS类中的唯一ID。

调用the_content ，我们将唯一样式“渲染”到变量。 这是一个函数调用，它会生成“媒体查询” css并将其插入到

这是一个非常彻底的解释， @mattbolt谢谢您抽出内幕，这很有趣。

再次谢谢你，马特:)

这是一个按钮块。 查看周围的所有空白-特别是上方和下方。

块元素的auto / 0边距将转换为对齐方式。
例如´margin-left：自动； margin-right：0;`会将一个块元素推到右侧。
块对齐选项（如左/右）如何与边距特定的对齐方式进行协调？

退一步，我的2c：
我发现整个台式机/平板电脑/移动设备的区别有点武断，而且不是面向未来的...如果历史告诉我们任何事情，那就是设备变化很快，而我们今天所认为的规范充其量只是短暂而已。

为什么不让smartwatch，智能电视，眼镜或其他任何设备访问网络？ 什么是台式机？ 12英寸笔记本电脑与13英寸平板电脑有何区别？ 因为如果我们谈论的是屏幕分辨率，那么7英寸手机的分辨率可能比50英寸电视更大。
为什么要设置2个断点（移动/平板电脑，平板电脑/台式机），而不仅仅是1个（大/小）？

我们不应该构建一些力求完美的像素，而应该改变视点并尝试构建与像素无关的东西吗？

而不是拥有任意的断点，我们是否应该仅尝试检测例如列中的内容何时不再可读，并将其折叠为有意义的东西？

尽管＃19909中显示的模型已经过时，但该票据的主要目标是探索一个_global和extensible_接口以进行响应式断点编辑。 如果处理得当，则可以避免在看起来像桌面断点的编辑器中编辑column块的移动属性的情况。 相反，通过在编辑器视图模式和响应属性之间建立联系，我们可以进行逆操作，甚至在移动设备上时也可以编辑桌面断点，同时始终可以更好地直观显示每个响应断点。