Gutenberg: 增强选择子/父块的工具

我喜欢面包屑的想法。 （实际上，我在四月的＃6459中提出了类似的建议。）启用统一工具栏时，面包屑会发生什么？

我也认为点击型想法也很不错，并且已经在移动设备上使用，因此可以增加一致性。 不过，我不太确定直通想法。 我想这可能会由于跨块的不同行为而引起混乱。

我喜欢面包屑，但我也喜欢统一的工具栏。 我们可以为面包屑找到另一个位置吗：）

另外，我个人不喜欢父块周围的边框。 但是，如果我们保留它们，我们将如何处理多选:)。 我们应该在多选块的父对象周围显示边框吗？

我喜欢点击型选项。 这将需要在“直通”块上进行一些额外的工作（例如，每个单独的“列”都不被视为可以单击的层），但是我认为这很有意义。

启用统一工具栏时，面包屑会怎样？
我喜欢面包屑，但我也喜欢统一的工具栏。 我们可以为面包屑找到另一个位置吗：）

好问题。 快速而肮脏的模型：

是的，我看到了切换台重复图标的挑战。 我认为最好继续考虑一下。 还要注意此设计如何省略文档大纲，该文档大纲在＃4287中被阻止。

另外，我个人不喜欢父块周围的边框。 但是，如果我们保留它们，我们将如何处理多选:)。 我们应该在多选块的父对象周围显示边框吗？

我认为将它们显示为指示内部块是父组的一部分很重要。 他们把内部的块固定住了。

现在，这是多重选择的工作方式：

当您仅选择两个子块时，会发生以下情况：

换句话说，在master中，我们已经有了父边框，并且在多选子块时我们将其隐藏。 我实际上认为，即使在多项选择中，始终显示父边框也很有意义_当您仅选择子块时_。 但是，当_parent_块被多重选择时，也许我们应该使多重选择有所不同。 因此，我们不是仅突出显示具有附加图层效果的每个子块，而是仅突出显示父块。 那行得通吗？

我喜欢点击型选项。 这将需要在“直通”块上进行一些额外的工作（例如，每个单独的“列”都不被视为可以单击的层），但是我认为这很有意义。

是的，现在_column_子块提出了一些UI挑战。 例如，您不能在其前面插入一个块，那么为什么要选择它呢？ 但是，这是一个非常困难的技术挑战，而且我了解它所涉及的挑战。 因此，我并不是说这很容易。

由于我工作的https://github.com/WordPress/gutenberg/pull/9653 ，我意识到arrowkey导航我们已经有目前用于导航层级（当一列，以选择父使用箭头键向上（即，列块）运行得很好。 事实是如此的好，以至于只需将此功能显示为类似于Windows文件资源管理器中的“转到父文件夹”的“向上”按钮，就可以代替完整的面包屑。

这是看起来的样子。 顶部工具栏：

块工具栏：

CC： @youknowriad

一些想法

面包屑

我喜欢面包屑解决方案，但是它存在歧义，只有图标的界面可能会出现问题，并且我可以看到自己将鼠标悬停在图标上以查看其含义，或者将面包屑混淆为选项工具栏而不是面包屑。

因此，也许顶部的工具栏不是显示它的最佳位置，也许其他地方的面包屑提示也会有所帮助。 例如，PHPStorm中的层次结构工具栏可以显示文件->类->您当前所在的方法/函数，还是MacOS Finder和Windows资源管理器中的文件夹工具栏？

通过点击

点击将是一个隐藏的用户界面，我看到很多误解和困惑，因为人们希望选择一个图像块只是为了找到包含该列的块。 通常，由于Adobe软件中的单击UI引入了模式，因此会造成混乱，并且很难告诉您您在哪里以及如何退出它，尤其是在嵌套的情况下。 例如，如果您双击进入一个子块，您如何返回到父块，以及UI如何指示您在一个块内？

关于模式，有很多研究和指南，不应将其视为好东西，因为它已出现在Illustrator或Photoshop中，要做很多工作，而不仅仅是单击后才能成为合适的解决方案。

https://medium.com/interaction-reimagined/dangers-of-modal-user-interfaces-316828de8161

http://www.azarask.in/blog/post/is_visual_feedback_enough_why_modes_kill/

这忽略了所有混乱的可访问性因素。

向上按钮

向上按钮的想法很好。 我担心的是，这意味着如果您按下它，则会出现一个向下按钮，该块将向上移动，这是模棱两可的，并且会遇到面包屑块所做的相同问题

可重复使用的块模式

现在，可重用的块已经具有UI模式，该模式将chrome添加到前端看不见的块接口。 列可以做不一样吗？

或我所指的超级垃圾样机

因此，columns块的镶边将是用来选择它的东西，并且它提供了视觉上的东西来瞄准鼠标。

我们可以在此处使用的与我们的工具栏模型相适应的一种潜在的UX模式是OS X文件夹遍历按钮： https :

我要指出的是，我认为用户将希望能够通过单击和选择在视觉上选择子级/父级块，但显然，正确地进行操作有很多复杂性。 上面的遍历模式可能是一个很好的第一步，我们可以在第二阶段中更深入地开发一个更优雅的解决方案。

我_阿列克西斯（Alexis）这个概念，尤其是您提到的更复杂的块。 我非常喜欢它，因此我立即使用它，并重新混合了一些样机以说明您的想法。

没有选择：

所选块：

选中的内部嵌套块：

文件夹遍历按钮弹出窗口打开：

☝️我有点喜欢这个概念，感觉就像它融合了在该线程上共享的所有想法和反馈，从而为_solid_基线做了迭代。 非常感谢您带来崭新的观点！

我喜欢带有可视化树的下拉菜单，我的一部分认为以这种格式查看整个文档也将有所帮助，甚至提供了重新排序内容的有用方法。

但是，经过进一步的思考，我想起了我们已经有了这样的选择机制，并且在信息面板中有一个文档大纲：

可以通过模型中的样式进行增强，并用作其他选择符号。 目前，它仅显示标题，但是带有完整块树的版本以及选择指示符将非常有用

我唯一的疑虑是工具栏图标本身。 它是另一个带有箭头的神秘图标，默认情况下，除非您自定义工具栏，否则它是MacOS上Finder中所没有的按钮。 对于我们这些图标盲人且无法轻松区分图标的人来说，这是有问题的

有了文本标签，它会更清晰，但是如果没有文本标签，大多数人将不知道如何操作：

看起来不错:)我们可以尝试简化图标以提高可读性吗？ 也许3行比4行有更多的间距？

使用文本标签，它会更清晰，但是如果没有文本标签，大多数人会不单击它就不会知道它的作用。

也将有一个工具提示。

在re： @tomjn的评论中，我还认为值得探索的是，是否可以将其集成到整个文档树中而不是创建一个单独的位置。 面临的挑战是保持树的简单性和可扫描性，同时容纳更多级别的东西。 但是，这可能变得更像Sketch或Photoshop中的“图层”面板（在功能上，而不是在设计上！），这是整个页面结构的唯一真实来源。 具有挑战性的做好事，但也许值得探索？

再说一次，这很可能是我们反复尝试的事情，那么最有用的MVP可以成长为更复杂的东西了？

也将有一个工具提示。

我认为这还不够，但是我认为这是一次单独的讨论，也是一项功能请求，我将打开一张新票证

我们可以尝试简化一下图标以获得更好的可读性吗？ 也许3行比4行有更多的间距？

我喜欢：

但是，经过进一步的思考，我想起了我们已经有了这样的选择机制，并且在信息面板中有一个文档大纲：

我还认为，如果可以将其集成到整个文档树中而不是创建一个单独的位置，则值得探讨。

我认为这可能有效。 之前我曾建议该项目可以重写为插件，以便显示在右侧（请参阅＃4287）。 但是我很喜欢将其重新用于文档树。

关于标签，我喜欢标签，但是鉴于此，需要考虑将块工具栏停靠在顶部的选项。

讨论使我想起了＃9053（抄送：@westonruter）—我想您可能会喜欢Alexis的建议，如https://github.com/WordPress/gutenberg/issues/9628#issuecomment -429012989中所示。

很高兴看到这种情况继续发展，并感谢@alexislloyd的概念。 @jasmussen我真的很喜欢这些

那么，最有价值的MVP可以成长为更复杂的东西吗？

我会说将其构建为一个更简单的遍历控件，然后再看一下以根据选择将它与文档内容框结合起来是否有意义。

根据＃10767中的讨论，请重新打开以进行迭代。

另请参阅＃11159中建议的其他想法。

使复杂的块更容易使用的另一种想法是，记住_未被选中的块是Preview_，并且_selected块可以显示其他编辑控件_。

我们可以利用该想法使选择column块的元素更容易。 例如，当选择了列块，或者它们的任意子，在以腾出空间的容器动画填充以选择子元素。 这也将使侧面UI可以访问。 我们想在父块周围显示一个边框，即带有扩展填充的边框，例如虚线。

如果我们在顶层块上恢复了.is-selected类，即使选择了一个子代，实现起来似乎也比较简单。 我们使用hasSelectedInnerBlocks属性来完成此操作。

这是我们将鼠标悬停在列块中的单元格上时看到的：

将鼠标悬停在“媒体和文本”块中的单元格上。

人们看到了内在的和外在的。
如Column-> Paragraph。 列-> YouTube。 媒体与文字-> YouTube

使悬停信息中的面包屑信息（内部和外部块）可单击是很好的。 单击列选择父级，或单击段落选择子级。

现在尝试一下，我注意到的一件事是，选择父列块的最简单方法是利用我们在父块的右侧/左侧提供的额外的不可见点击区域：

该额外的点击区域在块的顶部和底部不可用，这使得选择这种方式变得更加困难。

使复杂的块更容易使用的另一种想法是，记住未选择的块是预览，并且选择的块可以显示其他编辑控件

我们可以利用该想法使选择column块的元素更容易。 例如，当选择了列块，或者它们的任意子，在以腾出空间的容器动画填充以选择子元素。 这也将使侧面UI可以访问。 我们想在父块周围显示一个边框，即带有扩展填充的边框，例如虚线。

我不确定100％是否是@jasmussen在上面建议的内容，但是在编辑模式下添加一些填充+父块的可视指示可能会在这里

当有人退出该图块时，多余的填充会消失，以显示该图块的更准确表示。

该额外的点击区域在块的顶部和底部不可用，这使得选择这种方式变得更加困难。

我可以发誓有一个解决此问题的票证，这也与同级插入器的工作方式有关。 我现在找不到它，但是我相信这个问题应该可以解决。 @aduth响起钟声，我可以发誓您在评论中？

我不确定100％是否是@jasmussen在上面建议的内容，但是在编辑模式下添加一些填充+父块的可视指示可能会在这里

那或多或少完全是我的意思，只是比我能看到的更漂亮。

这是另外的蜡笔素描，以说明我的意思。 列块：

Kjell本质上就是您所拥有的-虚线可能稍暗。 另外，根据column块的进一步开发情况，请记住也有_column_块。 即当前的层次结构是_Columns→Column→Image_。 我们正在使用激烈的CSS向导来使第二层或多或少变得不可见，但是如果您以后希望选择该层，例如对它应用CSS类或我们可能需要为各个列使用的其他任何选择，那就是值得考虑。

幻灯片块：

需要明确的是：没有计划的幻灯片放映区。 这纯粹是为了说明一点，即一个块的预览和编辑模式可以有很大的不同。 通过简单地选择和取消选择模块，在两种模式之间切换非常容易，而且令人惊讶地无干扰，我们应该让自己精益求精，并抓住机会进行创新。

在幻灯片放映的情况下，几乎按照定义，内容将在屏幕/块外部不可见。 但这并不是必须在编辑时。 只需选择块即可查看带有可编辑字幕的缩略图。 然后取消选择该块以预览结果。

我可以发誓有一个解决此问题的票证，这也与同级插入器的工作方式有关。 我现在找不到它，但是我相信这个问题应该可以解决。 @aduth响起钟声，我可以发誓您在评论中？

我认为最接近的东西可能是＃8883，＃8881，＃5180之一？

虽然文档树很有用，但仍然需要我将重点从尝试操作的位置转移到其他位置。 我真的希望有一种更好的方法来直接单击实际块和嵌套块。 我认为@jasmussen上面概述的点击方法值得进一步探讨。

这是我通常遇到的问题：

作为用户，我将与之抗争至少一分钟，然后再找到屏幕其他位置的另一种解决方案。 😉

* _当我添加此评论时，出现了很多其他评论。 现在可能不那么重要了，但我将其保留在此处以记录这场斗争。

但是在编辑模式下添加一些填充+父块的可视指示器可能会在这里起到很大的帮助。 这样，就可以清楚地指示要选择父级时应单击的位置：

我对这种解决方案的关注是填充如何与周围的块相关联：

1. 父块中的填充是否反映在前端？ 还是在编辑器中添加更多填充？

2. 这样选择块时，是否会动态添加填充？

1. 还是填充后的父级出现在周围的块上方，像这样？

只是尝试进一步研究这个概念。 会喜欢上它的一些想法。

谢谢@aduth ，您让我至少找到了正确方向的车票。 ＃9229中的GIF解释了这个问题：GIF中的黄色区域被“保留”用于兄弟插入物。 这就是阻止您通过单击块上方或下方的填充来选择块的原因。 这就是@kjellr的评论的答案：

该额外的点击区域在块的顶部和底部不可用，这使得选择这种方式变得更加困难。

为了进一步说明，该黄色区域仅用于使同级插入器按钮可见。 因此，我们实际上需要拦截的只是_hover_动作。 如果点击仍然可以通过该黄色条传播，让您选择下面的块，那将是很好的。

虽然文档树很有用，但仍然需要我将重点从尝试操作的位置转移到其他位置。 我真的希望有一种更好的方法来直接单击实际块和嵌套块。 我认为@jasmussen上面概述的点击方法值得进一步探讨。

即使当前的实现有些半熟，您现在也可以立即进行测试。

• 运行任何版本的Gutenberg。
• 插入带有内容的栏块。
• 将窗口大小调整为低于600px断点，然后选择。

这是针对移动设备实现的，换句话说，是让您更轻松地选择父块。

GIF：

目前实施的问题是，一旦您深入到最深层次，就会重置“状态”。 因此，即使您只是两次选择相同的段落，也因此是“列”>“列”>“段落”，“列”>“列”>“段落”。 尝试解决该问题的明显解决方案是使其变得“深入”到所需级别，然后将您停留在该级别，直到再次取消选择该块。 即列>列>段落，段落，段落，取消选择，快退等。

我还认为，对于_some_块，此点击方法将至关重要。 尤其是当我们开始查看可能包含各种嵌套内容的页面模板时。

也可以在Keynote中尝试一下有关点击功能惊人的工作原理。 插入一些形状，您可以直接单击它们。 一旦您将两个形状组合在一起，它们就会变成易于移动的新形状。 但是要编辑组的内容，您必须双击。

要在https://github.com/WordPress/gutenberg/issues/9628#issuecomment -456637172中回答您的好问题：

父块中的填充是否反映在前端？ 还是在编辑器中添加更多填充？

不，此填充仅在编辑器中，并且仅在选择了_block时。 这是基于块是接口的原理，它在编辑器中指出：

• 未选中的块是预览。 它应该看起来尽可能的前端
• 所选块实际上是“块编辑模式”，在此状态下，该块可以输出其他控件，甚至看起来完全不同。

这就是我尝试在上面的示例幻灯片块涂鸦中突出显示的内容：未选中幻灯片块时，它就是幻灯片。 选中该选项后，您将处于_幻灯片编辑模式_并看到每张幻灯片的缩略图网格，因此您可以轻松地编辑字幕，重新排列等。

这样选择块时，是否会动态添加填充？

是的，或多或少。

我认为这可能是值得更好地解释和感受的原型。

最终，此功能可能应该是块本身的支柱，而块可以选择使用此功能。 例如，带有嵌套段落的blockquote可能不应该使用此接口-但是在编辑列时，它可能是一种完美的选择。

这是一个快速的Codepen原型： https ://codepen.io/joen/pen/exmMQv = 1100

这有点静态，但是希望可以理解这一点。

这是一个快速的Codepen原型： https ://codepen.io/joen/pen/exmMQv = 1100

这有点静态，但是希望可以理解这一点。

这确实有助于理解要点。 我进行了少许编辑，因此我们可以看到单击时那些虚线边框可能会出现：

https://codepen.io/kjellr/pen/jdEJQb?editors=0110

太完美了，谢谢Kjell！ 这就是我的意思。 我相信我们可能需要调整实现中的某些方面，并解决当直接父级（单列）被填充时它的外观。 但这很酷！ 我认为可以。

我真的很喜欢
我们是否应该着手创建用于测试更多块和内容的PR？
我们是否需要确定这将影响哪些块？

我也挖了。

我们可能现在可以在Columns块上对此进行原型制作，但是要使其着陆，我们可能需要_method_既通用，因此其他块（如您所说）可以使用此方法，还可以使用prop来使一个块选择加入。 一旦收到嵌套的块，Quote块将具有破坏性。

@gziolo有什么想法吗？ 尤其是Kjell在https://github.com/WordPress/gutenberg/issues/9628#issuecomment -456811415中提出的方法

@gziolo有什么想法吗？ 尤其是Kjell在＃9628中提出的方法（评论）

看起来很棒。 最终将可以在需要时轻松选择父块。 我唯一的问题是，您如何以使其他列变窄为代价，使列的宽度更接近原始大小？ 目前，当其中一个被选中为3+列时，这可能是次优的体验中的所有列得到缩小。 @jasmussen您还有其他问题，我应该回答吗？

我唯一的问题是，您如何以使其他列变窄为代价，使列的宽度更接近原始大小？

我倾向于同意这是我们应该微调和平衡的东西，可能是在实施中。 我们还可以考虑扩大父级的宽度/高度，以不减小子级的大小，尽管从技术上讲这可能更具挑战性。

还有其他问题，我应该回答吗？

基本上，我们在这里讨论的接口是：在选择子块时向父块添加填充，以使其更易于选择。 这在Kjell的Columns块原型中很有用。 在其他块（例如，Section块）或子内容可能会填充内部所有可用空间的许多其他块中，它可能会非常受欢迎。 但这对于Quote块之类的东西可能不是那么好，该块当然还没有使用嵌套，但是将来可能会使用它。

因此，以对所有块都是_generic_的方式（默认情况下_off）来构建此“选择父”接口会很好，但是某些块可以使用prop选择加入。

您对如何最好地解决这个问题有什么建议吗？

所有包含嵌套块（当前为列，媒体和文本）的块都会呈现此InnerBlocks组件，从而呈现.editor-inner-blocks类：
https://github.com/WordPress/gutenberg/blob/16a718a4bf359c53f0fb9c3626b08e2434a6fd7d/packages/editor/src/components/inner-blocks/index.js#L103
这可能有助于提出一个适用于所有嵌套块的通用解决方案。 但是，由于将.is-selected应用于后代元素之一，可能会比较棘手。

Edit:如果它不适用于CSS。 我们总是可以找到一种更新父状态的方法，以在其中公开有关已选择嵌套块之一的信息。 @jorgefilipecosta和@aduth可能

因此，最好以所有块通用的方式构建此“选择父”接口，默认情况下处于禁用状态，但是某些块可以使用道具选择加入。

您为这种方法考虑哪些块不使用嵌套？ 这使我想到为什么他们不首先使用嵌套？ 想象一下，我们将Gallery转换为带有嵌套Image块的容器。 我们将免费获得此行为，但也将其作为奖励进行排序。

您为这种方法考虑哪些块不使用嵌套？

画廊是一个有趣的画廊。

老实说，我主要考虑的是更高级的布局块，例如Grid布局块或Tabgroup块，或其他类似的“页面构建”块。 任何特定于内容的内容都不应使用此接口。

老实说，我主要考虑的是更高级的布局块，例如Grid布局块或Tabgroup块，或其他类似的“页面构建”块。 任何特定于内容的内容都不应使用此接口。

我预计它们都适合在容器块类别下，这意味着它们应使用InnerBlocks作为实现细节，因此应适合该类别。 对于块定义中的supports组，我们仍然可以提供与其他功能类似的选择退出功能。

我预计它们都适合在容器块类别下，这意味着它们应该使用InnerBlocks作为实现细节，因此应该适合该类别

但是，如果/当它获得嵌套功能时，Quote块也不会使用内部块吗？

但是，如果/当它获得嵌套功能时，Quote块也不会使用内部块吗？

是的，报价，清单，封面-过去，这3个被视为转换为嵌套块。

一个问题（这不应该阻止实验，但是值得一提！）是，列块已经存在一些问题，涉及到列的狭窄程度以及对编辑模式工具的影响。 该建议将在编辑交互过程中有效地使列甚至更窄，从而可能重新出现这些狭窄问题。

它还会从1对1编辑/视图奇偶校验进一步推进，这可能会或可能不会引起关注。 诚然，我已经使用InnerBlocks在自定义块上执行了与此类似的操作（选择时需要额外填充），并且效果很好-但是这意味着编辑视图不太准确。

因此，最好以所有块通用的方式构建此“选择父”接口，默认情况下处于禁用状态，但是某些块可以使用道具选择加入。

构建Jetpack Form模块时，能够选择加入这样的功能非常好。

它还会从1对1编辑/视图奇偶校验进一步推进，这可能会或可能不会引起关注。

我认为在选中状态和未选中状态之间进行一些更改是可以的，特别是如果它使UX变得更好的话……尽管现在可以就内部块进行争论了。

当我将块嵌套3深时，还会发生什么？ 如果第二层也是父块，padding选项是否会扩展到第二层？

@mapk

当我将块嵌套3深时，还会发生什么？ 如果第二层也是父块，padding选项是否会扩展到第二层？

嵌套的各级填充受着听起来像它最终可能会导致一些大尺寸的增大，并在部分行选择深度嵌套块时，例如在报价段落列减小。 理想情况下，选择一个块不应彻底改变其他每个块的外观，因此对我来说，仅更改其直接父对象的间距就足够了。

只要您可以选择直接父级，就可以沿层次结构进行操作，因为选择父级将使其父级变得容易选择，依此类推。 可以使用“块导航”菜单来进行快速访问，并且如某些人之前所建议的那样，可以将其设置为可固定的侧边栏，以便可以快速访问它。 （请参阅＃11408和＃11688。）

我建议在任何时候填充更改仅应影响所选块和直接后代。

以防万一，这会影响这项工作，请允许我迅速浮出水面，我希望进行的工作是向Columns块添加Vertical Alignment，使_individual_ Columns可选（以前是不可选择的）

https://github.com/WordPress/gutenberg/pull/13899

我希望将垂直对齐方式添加到Columns块的工作使_individual_ Columns可选（以前是不可选择的）

感谢您在这里指出。 这就是让这种互动尽早进行整理的更多原因。

只是想分享我今天早些时候与@jasmussen讨论的有关块边界的内容。

这在上面的一些模型中

在此示例中，我将深色边框用于聚焦状态。 如果该块是父块或子块，则我在其他相关项目周围包括了虚线边框（以及一些其他填充）。 这有助于用户清楚地看到他们在块层次结构中的位置，同时还使他们清楚地知道可以单击以选择其他嵌套块的位置。

@kjellr我真的很喜欢。 这使它非常清楚什么是结构。

但是……我认为我们将再次遇到虚线对比度问题。 我不能肯定地说，但是我怀疑引入虚线意味着它需要遵循可访问性标准。 而且我认为提高对比度可能会导致视觉上的沉重感，从而抵消其优势……

只是大声思考一下。 真的很像一个有远见的用户，但是很好奇听到我的反馈是不够的：）

在我的屏幕上，起初我什至没有看到虚线。 如果我的屏幕稍微倾斜一点，几乎看不见。

如果可以降低对比度，则无需降低太多。 只要是_little_打火机，并使用其他的border-style我认为它就可以正常工作。

抱歉-我的原始评论应该更清楚：我在与Joen交谈的几分钟内创建了该模型。 我想我只是从当时屏幕上的一些灰色中随机选择了颜色。 😄确切的阴影并不意味着传达最终的解决方案，而只是一般的方法。

为了解决有关在父块上添加填充导致内部块与前端不一致的问题（＃14148＃14169），我工作了另一个想法。

这需要更多的开发才能实现，但可能是一个不错的选择。

基本上，单击父块时，它会扩展（比正常块大一些），以提供轻松进行子/父选择所需的填充。 这使内部块的视觉效果与前端保持一致。

截屏

InVision原型

https://wp.invisionapp.com/share/EGQRWRC8MFT

优点

1. 内块保持适当的宽度。
2. 内部块在视觉上与前端保持一致。
3. 选定的块更改大小是已经使用的模式。

缺点

1. 将块选择（宽度）扩展到正常块选择之外是一种新模式。
2. 我不确定将块设置为全宽时这将如何工作。

基本上，单击父块时，它会扩展（比正常块大一些），以提供轻松进行子/父选择所需的填充。 这使内部块的视觉效果与前端保持一致。

挖那个。 我希望块工具栏与左边框保持齐平，但这是一个实现细节。

当无法实际变大时，在较小的屏幕上将是一个挑战，但这也感觉可以解决。

值得注意的是，这种方法可以扩展到具有内部块的_any_块，甚至是Quote块（这是一个基本文本块），因此选择应尽可能不受阻碍。

实际上，Kjell确实可以深入挖掘您的工作，它不仅可以与Mark的想法进行隐形结合，而且可以在需要时突出显示文档的结构，但是在您只想编写时就不会中断流程。 感觉像是一个稳定的方向，接下来我们需要一个强大的开发人员。

在实现注意事项上-虚线双亲_could_理论上与所选块具有相同的颜色，但由于被虚线冲了，它仍将显示为次要的。 悬停父对象时，轮廓可能会变为实心，甚至可以使_child_（悬停时选择的内容）变为虚线，以帮助指示单击时将要发生的情况。

在实现注意事项上-虚线双亲_could_理论上与所选块具有相同的颜色，但由于被虚线冲了，它仍将显示为次要的。 悬停父对象时，轮廓可能会变为实心，甚至可以使_child_（悬停时选择的内容）变为虚线，以帮助指示单击时将要发生的情况。

是! 我认为那也完全可以。 让我们看看＃14145的出网位置，然后从那里找出一种处理方法。 👍

当我使单列可选但由于超出PR范围而被删除时，我也修改了边框。 绝对感觉像是用户体验的改进。 爱这前进的方向！

请注意：我正在将上述想法分解成一个单独的，简洁的问题进行探讨。 按照这里：

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

如果任何人都可以在选中其子级后加入has-child-selected类到父级块中，那么这就是开始该操作的唯一障碍。

我发现一个相关问题，然后测试了新引入的Group块：

目前令人困惑的是，当您插入Group块时，您实际看到的是Paragraph块：

我们至少可以做以下事情：

或@mtias在我们的私人聊天中建议您重用“块导航”功能：

_无论如何都不是最终设计方案😃_

@gziolo该问题应由＃14241解决。 顺便说一句，我同意你的意见，因此尽快将其寄出是很高兴的:)

@gziolo该问题应由＃14241解决。 顺便说一句，我同意你的意见，因此尽快将其寄出是很高兴的:)

好吧，我会说一部分。 当您使用此新的自定义插入器插入段落时，我们回到第一个方框🤷‍♂️

我认为＃14935也会在这里有所帮助。 我们还应该探索边栏中的一些选项，以提供更多方式来确保嵌套当前选定的块。

是的。 我一直在考虑恢复侧边栏中的面包屑，就像我们在这里看到的那样：

https://github.com/WordPress/gutenberg/issues/13309#issuecomment -458452168

简单且相对优雅，也可以解决此问题（9628）。

在上面的一些想法上提出一个迭代：

如果我们将块转换/样式移动到自己的专用项中，并使块图标进入其自己的“块树”面板，该怎么办？

我认为这可能会增加块转换/样式的可见性，同时还可以帮助人们更清楚地导航到其他嵌套块。 这是一个更复杂的示例的模型：

（两个伴奏也都使用＃14961中的轮廓/填充）

看起来很有趣，Kjell！ 然后，它将与“块导航”区域配合使用，从而在它们之间建立一致性。 当人们学习使用块导航时，同样的学习可以继续选择嵌套块。

我真的很喜欢概念上的样机，但是关于执行的一些感觉却有点密集。 我不知道我一定有个更好的主意，但我确实想知道是否有办法使这种感觉减轻一些？

我知道我一直在努力寻找我的块结构的快速轮廓，所以这个概念是解决此问题的好主意。

我在这里的关注模仿@chrisvanpatten 。 虽然经过深思熟虑，但确实感觉很多。

1. 在某些情况下的某些区块上，存在多种显示下拉菜单的方法。

我认为在混合中添加另一个人字形（尽管它是灰色且朝右）可能会增加解析的难度。

1. 另一个问题是工具栏越来越长。 也许这没什么大不了的，但是当我们包含图标标签https://github.com/WordPress/gutenberg/issues/10524和https://github.com/WordPress/gutenberg/issues/ 15311。

在探索这一点时，只需思考一下。 这可能是传达正在发生的事情的最简单方法。

我想知道是否有一种方法可以减轻这种感觉？

是的，我认为这与那里缺乏等级制度有关。 工具栏的第一个项目应该更像是接地元素，其他项目应该像是该块的第二个选项。 需要某种分离。 这不是正确的解决方案，但只是为了对话，我认为这会有所帮助：

在某些情况下的某些区块上，存在多种显示下拉菜单的方法。 我认为在混合中添加另一个人字形（尽管它是灰色且朝右）可能会增加解析的难度。

那可能。 可能还有另一种我也没有想到的表示方式。 老实说，它甚至可能是工具栏中更直接的额外“块树”图标，会自动为任何父元素或子元素添加：

另一个问题是工具栏越来越长。 也许这没什么大不了的，但是当我们包括图标的标签＃10524和＃15311时可能会如此。

同意无论这是否是方向，无论如何我们都需要为超长工具栏找出解决方案。 我认为像https://github.com/WordPress/gutenberg/pull/16557之类的努力对此有所帮助，对工具栏层次结构的更全面的重新思考也如https://github.com/WordPress/gutenberg/issues/ 15096。

关于块树作为工具栏按钮的想法让我印象深刻的一件事是，它是块工具栏项中的一种独特之处，它不涉及块本身的任何内在内容，而是涉及块与文件的其余部分。

这比其他任何事情都更有趣，但是要使用图形应用程序的类比，这种类型的“分层”和“分组” UI通常（仅在_document_级别）存在（我敢肯定有例子证明我是错误的）而不是在块级访问。

我知道在块和文档级工具之间的“间隙”周围存在各种可访问性问题，将其置于块级可以使导航更加容易。

这比什么都更令人着迷……关于此工具的某些方面与该工具栏如何将其与其他上下文相关联，感觉与工具栏中的其他工具明显不同。

这比什么都更令人着迷……关于此工具的某些方面与该工具栏如何将其与其他上下文相关联，感觉与工具栏中的其他工具明显不同。

是的，我有同样的感觉。

现在，我们已经在顶部的工具栏中获得了该控件，该控件似乎与代码块本身相去甚远。 也许侧边栏实际上是最合适的地方？ 该控件几乎看起来应该与该块关联，但是作为其自己的单独工具栏，但是我们绝对不想添加其中的另一个。 😄

现在，我们已经在顶部的工具栏中获得了该控件，该控件似乎与代码块本身相去甚远。

我还要补充一点，这仅在Gutenberg的默认设置中正确。 如果有人选择“顶部工具栏”选项将所有块工具栏移动到顶部工具栏，则绝对不是这种情况。 但是，话虽如此，我怀疑大多数用户都会更改该设置。

另外，我真的很想看看人们会对“顶部工具栏”设置（Gutenberg中的默认设置）有何反应。 它将与Classic编辑器更好地匹配，从而为新的Gutenberg用户提供更多的熟悉度。

已经对这个工具栏设置进行了很多研究，并且在进行了大量测试之后确定了最佳默认设置。 您可以在这里阅读有关探索的更多信息： https ：

我怀疑大多数用户都会更改该设置。

事实证明，工具栏的位置是个人难以置信的设置。 归结为在测试的第一阶段，那些开始使用WordPress的人被该块首选，那些经验丰富的人。 工具栏在两个地方都默认设置，这是我们现在最好的选择。 同样，这可能就是为什么它感觉更符合经典编辑器的原因。 我个人建议我们不要更改默认值。

@jasmussen我们是否应该以＃17088结束该项目

是的，我认为我们可以。 这张票进行了不同的探索，而另一张票则根据某些想法进行了完善。 如果您遵循新票证上的参考，仍然可以找到该票证。