有趣的主意@melchoyce。

我的第一个反应是将它们移到底部，如何使该块变得更“块状”-这说起来很奇怪，但是这让我感觉到。 单击或悬停时会显示边框吗？ 我认为点击鼠标比悬停鼠标要少得多。 另一个有趣的视觉效果使至少您的示例看起来像拍立得图像，非常有趣，我的大脑是如何到达那里的。

不过，这是我的第一个反应，多挖掘一点，我确实认为有必要探索块上交互图标的其他位置。 我认为从她那里获得的收益绝对是一种在所有屏幕上都能更好地工作的方式，随着进一步的探索，我们应该以此为指导。

我确实认为我们在互动中失去了一些背景。 例如，具有较高占位符的块将使那些交互不直接可见。 我认为这将会增加发现的难度。

所有这些都说，我绝对不是在说我们现在应该成为前进的道路。 您是否愿意进行迭代并可能进行更多探索？ 我真的希望你是。

我认为从外观上看这很好。 它本质上是在桌面断点上的移动用户界面，如果侧面用户界面无法解决问题，或者嵌套环境，我都认为这是计划B。

从那时起，我们俩都在侧面UI上取得了长足的进步，最近一次是在https://github.com/WordPress/gutenberg/pull/6141中，而且我们也使其在嵌套上下文中也能很好地工作方面仍然需要一些爱。

Althougn不那么漂亮，将这个UI放在一边的主要好处是，

1. 他们可以出现在悬停
2. 他们不会扩大街区的足迹

1尤为重要，因为从一开始就一直明确要确保拖放是_additive_，而不是与放置，重新排序和排序块进行交互的主要形式。 如果我们将它们放置在块下方，则大概它们会在单击时出现，这使其成为拖放的辅助对象，这将始终在悬停时起作用。

2可能很重要，具体取决于我们在嵌套上下文中如何处理侧面UI。 现在，我们在https://github.com/WordPress/gutenberg/pull/5452#issuecomment -380721863中面临一些挑战，尽管我敢肯定我们将能够解决这些问题，但足迹不会改变无济于事。

所有这些并不是说“不能工作”-它可以很好地工作。 一个waaaay的旧模型将这个UI作为角落的叠加层：

因此，总而言之，好主意以及将它们保留在面条中的好方法，可以根据我们收到的反馈意见加以探讨！

单击或悬停时会显示边框吗？

只需点击。 悬停类似于现在的工作方式。

您是否愿意进行迭代并可能进行更多探索？ 我真的希望你是。

总是👍

他们不会扩大街区的足迹

是的，这个想法肯定有问题。 即使在此原型中，您也会看到由于尺寸更改而跳来跳去。

因此，总而言之，好主意以及将它们保留在面条中的好方法，可以根据我们收到的反馈意见加以探讨！

👍

我确实认为我们在互动中失去了一些背景。 例如，具有较高占位符的块将使那些交互不直接可见。 我认为这将会增加发现的难度。

Althougn不那么漂亮，将这个UI放在一边的主要好处是，

1. 他们可以出现在悬停
2. 他们不会扩大街区的足迹

我认为解决这些问题的一种方法是将块工具工具栏显示在下面的块的顶部，而不增加该块在编辑器中实际占用的空间。 至于高块的可发现性，可以将工具栏置为粘性，以便在向上滚动时不会离开屏幕。 （当然，当不将鼠标悬停在块上方时，它仍然消失，也许只有当将其悬停在当前可见的块的下部时才出现，这与侧面控件当前的工作方式类似。）需要足够的空间来显示所有按钮，并且不要像本期主要文章中的样机那样在两套控件之间占用一整行空白空间。

+1只是要注意，这还可以帮助改善块周围的UI控件的选项卡顺序。 如https://github.com/WordPress/gutenberg/issues/5694#issuecomment -386645531中所述，移动用户界面以更合乎逻辑的方式放置了“侧面控件”。 请查看说明选项卡顺序的动画GIF，您可以将其与以前的GIF进行比较，并在先前评论的桌面视图中使用选项卡顺序https://github.com/WordPress/gutenberg/issues/5694#issuecomment -384619052

还需考虑：

3976建议将块工具栏（格式化工具栏）放置在块下方的第三个选项； 最好考虑同时使用块工具栏和位于块下方的侧面控件的设计，看看这是否可行。

1934年作为有关选项卡顺序一致性的一般性问题

这也可能对解决＃6272中提出的一些问题产生影响。

至于高块的可发现性，可以将工具栏置为粘性，以便在向上滚动时不会离开屏幕。

是的，这也是顶部格式化工具栏也会发生的情况：

在这里阅读所有令人敬畏的反馈，看来这可以解决当前以及当前具有可访问性的许多问题。 考虑到这一点，我认为我们应该在这里进行一些迭代，然后再进入PR进行原型制作。 您愿意这样做@melchoyce吗？

是的，我可以再看一遍。

+10尝试一下。

这是我缩小浏览器窗口的宽度时块UI的外观。 （如果我再缩小一点，则块工具栏将移动到块下方，但这与我的建议无关。）

我注意到块插入器出现在上/下移动控件的旁边。 如果像这样的问题一样，将这种UI用于所有屏幕尺寸，那么也许可以从嵌套块上下文中删除当前的块追加器，通过删除添加的始终存在的额外空间，使编辑器看起来更像前端由每个块附加程序针对每个嵌套级别。 （我还为＃6834中的appender-eating-up-space问题提出了一种替代解决方案。）

另外，这只是一个旁注，但是“删除”按钮应该位于“更多选项”按钮的右侧，还是应该在左侧？ 在大多数UI设计中，省略号菜单位于最右边。

另一个想法：

将这些块控件显示在悬停的底部，但是在这种状态下，它们不会占据页面上的任何空间，而是显示在悬停的块下方的任何内容的顶部（就像块工具栏对当前块上方的块所做的一样）一个），或者可能在悬停的代码块顶部。 底部的块控件也不应该是悬停时不间断的白色条，而是每侧2个较小的条（类似于块工具栏），以便使控件占用更少的空间并且不会覆盖太多。

当您选择一个块时，底部的块控件将占用空间，从而增加了块的视觉足迹，并将下面的块推开了，就像您选择图像块时显示标题占位符的方式一样。 如果它是垂直短的块（如单行段落块），则将更容易选择下面的块。

这种方法可以让您保留当前悬停控件的优点，无需先选择即可轻松移动/删除块，同时还可以确保在编辑块时控件不会掩盖任何内容，从而使其然后更容易选择另一个块。

还有一个主意：

允许将整个块控件栏（和块工具栏）加倍作为拖动柄（包括按钮，例如GTK标题栏的工作方式）。 我认为这几乎可以解决拖放发现性问题，尤其是在所选块的情况下，底部控件栏看起来像是初始文章中的模型中块的一部分，因此用户可能会更有可能考虑尝试将其用作拖动手柄。

与当前情况相反，在当前情况下，块的侧面看起来不像它们是块的一部分，因此，它们可以用作拖动手柄并不是很明显，还有单行段落块的问题两侧几乎没有可拖动的空白空间。 （并且由于除非禁用侧面控制按钮，否则当前不能将它们用作拖动手柄，因此问题变得更加严重。）

关于这个问题，我们进行了很多精彩的讨论，让我们看看我是否可以提供一些总结性反馈，以期为您提供一些可以通过@melchoyce进行迭代的东西。

总的来说，我认为我需要在原型中感觉到这一点，并且我的许多想法都可以通过此缓解。 但是，我需要考虑一些模拟因素：

• 高块的解决方案。
• 不太“块状”的感觉：这可能只是在模拟中显示占位符状态，我认为这些更改使它更加明显。
• 显示嵌套如何工作。

我很想看看它也如何适应不同的设备，我的想法是变化更少，这可能是一件好事。

@SuperGeniusZeb您那里有一些有趣的想法。 我想看看梅尔在以上迭代中的应用。 我认为现在要避免将UI加倍以拖动手柄是现在要避免的事情，有一些嵌套更改正在研究中，我想进入那里。 我并不是说我们不会迭代，但是此UI并非专门用于此目的。 我还认为，您可以推断出归属感，而无需在视觉上将其显式地显示出来，而变得过于显式的地方就是障碍的消极感觉出现的地方-感觉太近且太局限了。

我在＃7211上闲逛，在那项工作的背景下，我发现了＃7646，这使我回到了这个想法，这确实是解决许多问题的最佳解决方案。

该票证将直接或间接地修复很多问题：

• ＃7646→控件位于上方/下方，您不必担心容纳侧面UI
• ＃7182→类似于此票证上的模型中的控件的控件直接连接到块，并且无论嵌套级别如何，都具有一致的UI
• ＃6451→如果顶部/底部工具栏具有纯色背景，则无需担心如何使控件在深色背景上可见
• ＃7114 /＃6265→如果您使用上述某些模型中的全宽工具栏，则可以使用空白区域进行拖放

所有这些说明，如果仍然有可能在Gutenberg发生如此大的变化，我认为它可以解决很多问题，并使很多事情变得容易:)我将加入其中，并努力工作希望这个周末有一些样机/概念。

@chrisvanpatten只是为了增加角度，这个问题是关于控件而不是工具栏被移到底部的。 这将导致更多的可用性问题。 只是检查您链接的某些问题似乎在工具栏附近。

我完全赞成尝试这种方法，因为它可以大大改善Tab键的顺序。 快速更新：省略号菜单中已移动了“垃圾箱”按钮。 我还建议尝试满足控制原理的要求，并在移动器的右侧立即放置省略号按钮。 不知道为什么它应该保持在右边这么远：

@afercia，因为它们是不同的控件，我认为在右侧使用省略号是有意义的。 让我们将其作为第一步进行探索。 我们需要重点研究以下内容：

高块的解决方案。
不太“块状”的感觉：这可能只是在模拟中显示占位符状态，我认为这些更改使它更加明显。
显示嵌套如何工作。

这些要点需要探索，以确定从这个有希望的点开始的路线。

@karmatosed我正在使用令人困惑的术语-我的意思是控件，而不是工具栏。 工具栏已经位于顶部-此处无任何更改:)

我只是做了一些我想像的模型的样机，如果将其放在块下会看起来像。 请注意，在这些模型中，块工具从不占用任何空间，仅像桌面上的块工具栏一样充当叠加层。 在这些模型中也选择了块。 如果仅将鼠标悬停在某个块上，则不会显示顶部的块工具栏。 另外请记住，底部控件仍只能像当前的侧面控件一样在它们附近徘徊时出现。

正常：

当块底部不在屏幕上时：

（注意：图像块工具栏与这些模型中的一个不匹配，因为其块工具栏中具有不同的选项。）

考虑到块工具在侧面的问题以及将其放在底部的若干好处，我现在深信将其放在底部是解决之道。

@SuperGeniusZeb这基本上就是我在想的，除了我要使用向上/向下箭头而不是向右放置更多选项按钮作为组合工具栏。

@chrisvanpatten是的，无论控件是否分开，我都不会介意。

这里还有一些样机：

徘徊：

使用全角条进行选择，该条会占用移动设备上的空间（而不仅仅是覆盖），并且可以用作拖动手柄：

我必须说，我认为这有点太过危险了……这是描述这个问题的怪异方式，但是要继续下去:)例如，上一个模拟中显示的悬停非常强烈。 我认为我们必须看到梅尔在第一个图像中显示的边界少了一点，这确实有帮助。

我进行了第一个模拟并移除了垃圾桶，以获得我认为最好的进展：

我们不需要额外的边框，也不需要增加重量。 这样，它可以轻松拖动，而不会出现异常的悬停轮廓。

@karmatosed我修改了您的模型以显示当您将鼠标悬停在一个块上时的样子：

这就是选中的块和显示的块工具栏：

（我还更新了Image块占位符，以匹配Gutenberg中的当前占位符。）

这种东西使我感到困惑，因为控件上没有上边框：控件是否仍在白色背景上？ 这是否意味着整个块后面都有白色背景？ 听起来这会在嵌套的上下文中引起问题，在这种情况下，将块嵌套在具有深色背景的容器中，因为选择（和/或悬停）会导致块的背景发生变化，这看起来会很刺耳。

这种东西使我感到困惑，因为控件上没有上边框：控件是否仍在白色背景上？ 这是否意味着整个块后面都有白色背景？

可以，但是控件有目标。 我认为值得展示，并且避免了视觉障碍。 这绝对需要在嵌套中进行探索，但是如果没有背景，则在视觉上嵌套甚至会变得更糟。

可以，但是控件有目标。 我认为值得展示，并且避免了视觉障碍。 这绝对需要在嵌套中进行探索，但是如果没有背景，则在视觉上嵌套甚至会变得更糟。

同意，并且具有背景也可以解决＃6451。

我不喜欢在最后的模型中将悬停的空白栏显示出来。 理想情况下，您希望在悬停时尽可能少地覆盖周围的块，但这将覆盖下面的很多块。 这样的事情怎么样？

如前所述，箭头移动器和省略号可以兼用作拖动手柄，和/或悬停标题可以是拖动手柄。 （请参阅＃7114。）

@SuperGeniusZeb虽然我理解您的观点，但在这种情况下，从视觉上看，列出的块实在不是很好。 让我们坚持我根据梅尔（Mel）出色的工作所做的模拟，以将其视为原型。

我刚刚意识到有关在选定的块后面出现白色背景的事情：对于要在深色区域（由Container块提供的东西）看到的白色（或其他浅色）文本颜色的块怎么办？ 在整个情况下，将整个块都设置为白色背景将不起作用。

背景位于工具栏周围，该工具栏将始终具有这些控件。

@SuperGeniusZeb是的，我看不到白色背景会影响块本身，只会影响控件。 实际上，可能是这样的：

或可能会删除填充（我真的很喜欢这种方法，但是显然这是一个更大的问题，涉及拖放操作。仍然认为这值得考虑）：

@chrisvanpatten我喜欢上一个样机。 我认为拖放不会成为问题，因为底部栏可以用作拖动柄（并且可能栏中的按钮也可以作为一个拖动柄）。 您甚至可以将鼠标悬停图标添加到悬停的底部栏中，或者始终在该图标上拖动鼠标悬停图标以指示您可以使用它拖动该块。

通过这种方法，我没有理由将可拖动区域保持在块的边界附近。 删除该填充也可以帮助使块悬停/选定的轮廓更接近块的实际边界，因为它们将不再需要考虑具有的拖动空间，而只需要调整为大于块中的实际块。嵌套的情况使选择父块更加容易。 （如果实现了＃6459中此注释中的样机之类的东西，选择父块将不再是问题。）

@SuperGeniusZeb

您甚至可以将鼠标悬停图标添加到悬停的底部栏中，或者始终在该图标上拖动鼠标悬停图标以指示您可以使用它拖动该块。

好主意💡

我认为让我们将可拖动区域留在一侧并实现它。 重要的是要首先解决这个问题。 我必须说我不确定图标是正确的方法，但是如果没有这样的实现，让我们重新访问一下。

@karmatosed

我认为让我们将可拖动区域留在一侧并实现它。

我不太确定这是什么意思？ 哪一边？

很高兴看到这将会发生。 提醒一下，这不只是视觉上的位置。 对于a11y，视觉顺序和选项卡顺序（DOM顺序）应该匹配，因此这些“块工具”应实际上移动到标记中的块可编辑区域之后。

切换到块下面的控件的一个很好的好处是，如果当前的设计遇到问题，它可以打开侧边空间，以允许将同级插入器重新设计为类似于Squarespace中的插入器。 当前的侧面控件将与这种插入器重叠，并且看起来很混乱，但是随着控件移到底部，这不再是问题。

https://support.squarespace.com/hc/zh-CN/articles/206991377-Adding-blocks#toc -insert-points

刚刚在＃7500上对此发表了评论。 我想知道这种设计的连续段落如何？ 我认为，将栏设在底部将导致段落之间的很大差距。

@talldan引用＃7500：

块控件不会在悬停时占用空间（就像它们和块工具栏现在不会占用空间一样），据我所知，甚至还不确定它们是否会占用选定块的空间。 当然，仅针对已选择或悬停的块显示控件。 块之间的标准距离应不受更改的影响； 仅所选块可能会受到影响。

这看起来真的很好，我全力以赴。

在此之前我们要考虑的一件事。 那长块呢？ 那些以及带有块的编辑器屏幕底部会发生什么？

您的意思是，当块很长时，它会滚动到视线之外吗？ 我想说的是，在此之前人们已经了解了它的工作原理并知道在哪里可以找到它。 我们只需要测试一下，如果您在一个小屏幕上写了很多长的段落，是否会感到烦恼。 但我喜欢它更好地反映了移动体验。 您对帖子的最后一块有哪些担忧？

他们如何看待他们的第一个街区是否很长？

我们至少应该为此添加一个NUX技巧；）但是您担心的是有人打开一个现有的帖子，该帖子可能是一个较长的段落，或者没有正确转换为块？ 有可能...如果他们发表新文章，几乎可以肯定会在第一个占位符块上看到它，对吗？

考虑到这一点，我没有看到将控件放在块顶部的探索，这可能是一个选择。 为此做了一个快速的模型。 （这里也提到了组合杠）

如果块太高，底部控件是否不会卡在屏幕底部，例如顶部控件如何卡在屏幕顶部或在移动设备中如何工作？

@hedgefield我非常喜欢它，但是它在狭窄的上下文（如列块）或较长的工具栏中无法正常工作。

@hedgefield @chrisvanpatten也许在宽度变窄的情况下，箭头/省略号控件可以移到格式控件的下方（或上方）？

@karmatosed我会说控件可能很粘并且在屏幕底部仍然可见。 但是，这会导致此问题覆盖每次尝试开始在段落中尝试编写的行的控件（大概像现在一样，在键入过程中它们将被隐藏）。 但是无论如何，这种解决方案似乎值得怀疑。

回到@hedgefield的模型，这可以使控件像格式化工具一样保持粘性，而不会造成阻碍。 当然，工具栏必须具有响应性，理想情况下，箭头移动器和省略号应在薄块下方/上方/某处移动。

还存在可访问性的问题。 @hedgefield的模型在

而且我不知道是否应该在视觉外观和源顺序之间发生不一致

在某种程度上，有一个特定的WCAG成功标准是不可取的：
https://www.w3.org/TR/WCAG21/#focus -order

我会说控件可能很粘，并且在屏幕底部仍然可见。 但是，这会导致此问题覆盖每次尝试开始在段落中尝试编写的行的控件（大概像现在一样，在键入过程中它们将被隐藏）。 但是无论如何，这种解决方案似乎值得怀疑。

实际上，再多考虑一下，除非该段落恰好位于屏幕底部的旁边，否则控件实际上不会掩盖该段落的最后一行，因此＃353可以使它不成为问题。 即使没有＃353，您仍然可以向下滚动（无论如何，这是大多数人所做的事情），并且如上所述，控件也仅在您移动鼠标时显示。 我改变了主意。 这可以工作！

宽块的外观如下：

薄块的外观如下：

甚至更薄的块（考虑8列之类的东西）：

我想我真的开始喜欢这种设计。 对于较宽的块，我不确定箭头移动控件是应位于格式控件的左侧还是右侧。

感谢您的探索，但是将所有内容整合到一条线中，可以将不同的动作合并到一个位置。 我不确定这是否有意义。 我们还考虑了当某人将工具栏置于顶部时会发生什么-他们选择不“放置”某些东西，而现在控件已放置。 感觉不到体验，因为我们在工具栏中无法使用块控件-感觉很奇怪。

但是，将所有内容组合成一条线将不同的动作合并到一个位置。

扮演魔鬼的拥护者，按照定义，这不是工具栏的目的吗？

另外，虽然我可以理解分离某些控件的想法，但是在这种情况下，我不确定是否有足够的说服力。 工具栏是工具栏； 将给定块的所有控件放在一个地方是合乎逻辑的，而不是提出模糊的原因，即为什么某些工具属于某些地方，而其他工具属于其他地方，插件无论如何都会不可避免地忽略它们。

@karmatosed如何通过颜色分离控件？

不幸的是， @ SuperGeniusZeb不能解决我的其他问题，我不确定它是否有效。

我真的认为在这种情况下，这是试图适应一种被认为可以胜过获得可行的设计的情况。 如何退后一步并考虑我提出的其他观点？

@chrisvanpatten根据定义，工具栏不是放置所有内容的地方，有用的工具栏必须具有上下文和顺序。 作为用户，您必须期望有正确的选择。 尽管我们可以争论一个单词的含义有一段时间了-这样做很有趣-我们不能忽视这样一个事实，即一次结合了太多的东西，这对于更多的人来说将是一个问题。

@karmatosed好吧。 让我们回到顶部的编辑工具栏：

（不确定栏上方的蓝线是否应该存在。）

这个设计有什么问题吗？ 可以使编辑工具栏按照可访问性的源顺序显示在块之后。 这不是理想的选择，但是由于将编辑工具栏置于该块下方似乎不是一个可行的选择，因此这似乎是我们唯一可以做的事情。

另外，我只是有一个主意：如果底部的条在悬停时部分透明怎么办？ 这样会使它更轻吗？

@SuperGeniusZeb只是为了获得意见，我可以建议我们减少丰富多彩的模拟吗？ 我了解所建议的内容，但是如果没有视觉上的复杂性，让界面独立存在会更容易。

只是为了下一步模拟。 @SuperGeniusZeb在屏幕（正常的桌面大小）和很长的块的情况下，以上

一些样机：

在控制栏顶部带有边框

控制栏顶部无边框

请注意，工具栏在悬停时不会占用任何空间，但是在选择块时会占用任何空间。

在制作这些模型时，我注意到了一些事情：在这种情况下应该怎么做？

在显示所选块的格式化工具栏和悬停的块的底部控件之间存在冲突。 如果格式设置工具栏位于底部（或者如果块控件全部位于顶部），则不会有问题，但是在这里，下面显示的控件和上面块显示的控件的组合会产生问题。

我能想到的最好的解决方案是使悬停的块及其工具栏具有更高的z索引，并显示在下面的块及其格式工具栏的顶部。 不过，我不确定这是否是正确的方法。 这是它的样机：

同样，底部栏和块内容之间没有边界：

我不太喜欢将悬浮的块与选定的块重叠的想法，但是否则，我看不到在选定块的正上方使用悬浮的块的底部条的方法。 您确定最好将所有控件放在顶部或底部的单个栏中，至少在台式机上会更好吗？ 这肯定会防止出现此类问题。

@SuperGeniusZeb我以某种方式错过了那些模型。 感谢您制作！

这是我从未考虑过的很棒的要点（将块悬停在所选块上方）。 那绝对是个问题。 作为常驻页面构建器专家，其他页面构建器中是否还有其他类似的模式，具有类似的分层工具栏？

另外，对于它的价值，我认为工具栏应始终悬停，选择或不选择。 占用空间有时会导致跳动的内容，总体而言这是一个比较尴尬的体验。

@chrisvanpatten我见过的所有页面构建器仅在模块/小部件的顶部显示了控件（也许是同级插入器除外）。 我认为Divi是最好的例子之一：

https://supergeniuszeb.com/wp-content/uploads/2018/06/Divi-Visual-Builder-add-button- responseness-demonstration.webm

视频中未显示，当您单击模块中的文本时，Divi中的格式设置工具栏将出现，并在您正在编写的行上方弹出一个弹出窗口。

Elementor做几乎相同的事情。

在Beaver Builder中，单击窗口小部件中的文本将导致块控件工具栏被格式设置工具栏替换，直到您的鼠标移到窗口小部件的边界之外，这将导致在您下次将窗口小部件悬停时显示标准块控件。 ，尽管您仍然可以输入窗口小部件。 再次单击文本将使格式设置工具栏再次替换标准工具栏。

另外，对于它的价值，我认为工具栏应始终悬停，选择或不选择。 有时占用空间会导致跳动的内容，总体而言这是一个比较尴尬的体验。

没错，但我担心这对拥有干净的UI会有影响。 如果您的格式化工具栏与上面的某些内容重叠，那没关系。 但是，如果您在块的底部添加了一个全角条，那么现在您正在重叠许多其他内容。

理想情况下，您希望所有控件都位于块的顶部或底部。 在大多数情况下，这将防止工具栏相互重叠。 为了便于访问，将控件放在底部将是理想的。 但是，您可能会遇到工具栏与您正在编写的内容（如“段落”块）重叠的问题。 但是，应注意，实际上仅需要始终显示格式设置工具栏，因为箭头移动器和省略号并不是经常使用的东西。 此外，如果块内容的当前正在编辑的部分与屏幕底部保持足够的距离，则格式设置工具栏不必将其重叠。

如果将控件置于底部太尴尬，那么似乎第二个最佳选择就是将它们全部置于顶部。 当然，存在潜在的问题，即控件在寻找瘦块时显得笨拙。

如果是台式机还是移动机，通常可以转移工具栏的位置。 现在，格式化工具栏和其他控件都显示在当前所选块的下方，并占用了移动设备上的空间。

但是，在宽块而不是薄块的情况下，将控件移动到较薄的块可能会感到尴尬。 最一致的外观可能是格式工具栏位于顶部，其他控件位于底部。 但这又使我们回到了工具栏重叠和内容重叠数量增加的问题。

古腾堡（Gutenberg）的设计理念是，选定块的外观针对编辑进行了优化，因此，我认为让工具栏占用物理空间并没有那么糟，只要您选择块就只能在块周围移动东西而不会移动所选块本身。

最后，我觉得这些模型仍然是一个不错的选择。 它不是完美的，但是从可访问性的角度来看是有意义的，它看起来不太笨拙，与移动设备一致，并且很少会导致工具栏重叠。

有关如何工作的一些说明：

控件在悬停时不占用空间，但是在选中块时确实占用空间。 当将鼠标悬停在一个块上时，仅显示箭头移动器和省略号，但是选择该块会使格式化工具栏出现，从而将其他控件向下推。 这可能是此设计的最大问题。 我认为，要使其达到最佳效果，在单击移动器/省略号工具栏选择一个块时，希望将块的内容向上推，但是如果您通过单击内容区域来选择该块，则希望这些工具栏可以移动。

当块延伸到内容区域以下时，箭头移动器和省略号将不在屏幕上，但是格式工具栏将保持可见状态，并停留在屏幕底部（或内容编辑器区域）。

如果这不是最佳解决方案，那么我会寻求基本相同的东西，但所有控件都在顶部，移动器/省略号出现在薄块格式工具栏的上方，也许在格式控件的左侧宽块。 移动设备看起来仍然像现在这样。

另一个想法：如果只是在悬停时不显示任何控件，则可以摆脱切换控件问题和工具栏相互重叠的问题。 这样一来，在块的顶部和底部显示工具栏就不再是问题了。 但是，当然，您会失去将控件显示在悬停上的好处。 我真的不确定这是否是任何人都想去的方向，但是我开始怀疑是否有必要。

我不得不说，悬停的块重叠的想法也不是我喜欢的。 我认为这需要更多思考。 控件可能会在悬停时占用不同空间的想法有些尴尬。

控件在悬停时不占用空间，但是在选中块时确实占用空间。 当将鼠标悬停在一个块上时，仅显示箭头移动器和省略号，但是选择该块会使格式化工具栏出现，从而将其他控件向下推。 这可能是此设计的最大问题。

我认为这是模拟游戏的大问题。 还有什么可能发生？

看页面构建器是一方面，其他应用程序和产品又如何呢？ 这在别的地方解决了吗？

@karmatosed

看页面构建器是一方面，其他应用程序和产品又如何呢？ 这在别的地方解决了吗？

很难找到古腾堡可以使用的类似的UI示例，因为几乎没有什么东西可以说明古腾堡所做的所有事情。

许多较简单/较旧的页面构建器插件都不必担心掩盖其等效块的内容，因为所有内容编辑都是在模式或侧边栏中完成的。 这样可以释放它们，使其模块控件可以重叠内容。

即使在Divi或Beaver Builder之类的情况下，您也可以在不打开模式/侧栏的情况下编辑文本，但模式/侧栏仍然是主要的编辑方式。 Divi和Beaver Builder都显示了本质上是前端的完美副本，而不必担心必须进行优化，例如将它们用作文本编辑器或确保可以在以下位置内联编辑大多数主要块内容。块。

此外，在页面构建器和其他类似构建器的UI中，由于对可嵌套内容的限制，嵌套的问题要少得多。 Divi具有严格的“节”→“行”（内置列）→“模块”设置（尽管为某些常见的嵌套列情况设计了一些“专业”节）。 Beaver Builder和Elementor一样，只允许将列嵌套在列中。 它们控制唯一一种可以具有多层嵌套的对象。 默认情况下，所有内容都在一个具有单行的Section中。 没有无限层的嵌套块，可以用于将嵌套用于各种用途和各种样式（例如Gutenberg允许的样式）的自定义块的任何组合。

Divi可以对节，行和模块的控件进行颜色编码，因为它具有严格的结构，并且没有可充当节或行的自定义模块。 （这还允许它在同一行上显示多个插入器按钮，但是用不同的颜色来区分每个按钮的作用。）在大多数构建器中，模块与布局元素是分开的。 由于模块和布局元素的分离，Beaver Builder可以执行类似的操作。

如果您查看不是页面构建器的内容，例如文本编辑器，您会发现它们不必担心页面构建器必须处理的所有事情。 如果您查看大多数页面构建器，则它们不会通过直接的内联WYSIWYG控件来处理文本编辑器。

古腾堡想做的是独特的。 它试图成为一种所见即所得的“选定块”，除了它是针对编辑进行了优化的页面构建器之外，它也是一个全文本编辑器，从节到列再到小部件的所有内容都是同一种对象：块。

基本上，这是一个复杂的问题，因为古腾堡（Gutenberg）试图同时做几件不同的事情，看似没有其他事情要做。 ：stuck_out_tongue：

无论如何，这是可以查看的列表，以查看它们如何处理块/模块/小部件UI：

WordPress插件/主题

• Avada（Fusion Builder）
• BeTheme（松饼生成器）
• 海狸生成器
• Divi（Divi Builder）
• 元素
• 氧
• SiteOrigin页面构建器
• 蓬勃发展的建筑师
• 视觉作曲家
• X＆Pro由Themeco

WordPress以外的网站建设者

• Drupal
• 方形空间
• eb
• 蜡

不是页面构建器，但类似于页面构建器的事物

• MailChimp
• 概念

这些就是我现在所知道的。

同级插入器有一个问题：它始终与所选块的内容重叠。 当您尝试摆脱每个块上的自动边距之类的问题以使古腾堡更具所见即所得的功能时，此问题会变得更加严重。

解决方案？ 好吧，如果我们要在块的底部添加一个栏，为什么不将同级插入器也扔进该栏呢？

另外，我只是想出一种方法来使悬停的变体上的边框看起来不那么刺眼。 只需更改将块内容与底部栏分开的边框颜色即可！

好处包括：

• 同级插入器永远不会与所选块的内容重叠。 这意味着，除了粘性格式化工具栏外，现在应该没有任何UI可以覆盖所选块的内容，如果您只是向上滚动或只是键入而不移动鼠标，则该粘性工具栏不会覆盖该内容。
• 现在，同级插入器的显示顺序与HTML选项卡的顺序相同，这对可访问性很有用。
• 现在，同级插入器显示在块下方，而不是上方。 我认为这更有意义。
• 兄弟插入物始终对所选块可见（可能在键入时，如果控件仍然像现在一样不可见）
• 与移动用户界面的一致性。
• 可以删除块的所有边距和内部填充，并且可以将块边界更改回为块的实际大小，而这一切都不会使块UI妨碍块的内容。

如果将同级插入器更改为直接打开插入器菜单（如＃7271中所述），而不是插入一个空的Paragraph块，则可获得加分。

当然，将块悬停在所选块上方时会发生什么问题仍然是一个问题。 但是，我认为这并没有给我那么大的困扰。 您所要做的就是单击该块以选择它并查看控件，如果将悬停控件显示在当前所选块的下方，那么就可以了，因为应该以所选块为焦点。

我认为这是一个不错的设计。 我认为所有积极因素都超过消极因素，而且我认为这肯定比现在存在的情况要好。 你们有什么想法？

我模拟了顶部和底部工具栏重叠时的外观，以及悬停的块始终在选定块上占据最高z索引的情况。

我非常喜欢这个，但是它有一个小问题……单行块很不走运，因为它们几乎完全隐藏在底部控制栏的下面。

@chrisvanpatten我在想，选择该块时，底部的条实际上会占用空间。 我认为这将解决单行代码块问题。 您可以制作一个模型来显示外观吗？ 另外，如果悬停的块不与所选块重叠，那会​​是什么感觉？

另外，当底部重叠某些内容时，底部栏下方可能会有阴影。

@SuperGeniusZeb我真的强烈反对让底部的栏占据空间，这会导致UI跳变。 现在，当您选择可重复使用的块时，它就会使我发疯。

（编辑：详细说明，这对于鼠标用户来说确实很难，因为您不能真正依靠事物在一瞬间到另一瞬间处在同一位置。这会造成很多尴尬。）

@chrisvanpatten

我主要是想在撰写文章的背景下，您可能不想掩盖您要键入的内容下面的段落。现在看来，所选内容下面的段落段落缺少第一行。 我认为当您选择一个周围的块时，我希望周围的块略微跳动，而不是在我当前正在编辑的块之后看不到块的顶部。 就个人而言，跳来跳去并不会打扰我。

在Gutenberg中，更改内容时通常会更改某些内容：图像标题占位符，引用引文占位符，库中的占位符/插入物以及可重用块，如您所提到的。 古腾堡（Gutenberg）通常围绕这样的想法进行设计：选择块时，应优化其外观以进行编辑。 我要说的是，可以使块的高度更高，因为底部的杆会占用空间。

或者，也许可以将底部的条形图设置为半透明，以使其更清楚地显示其下方是否有块？ 听上去怎么样？ 我想我可以接受。

唯一的问题是，在Gutenberg UI中其他任何地方都没有使用透明性。 这并不是说不应该使用它……仅仅是因为它没有现有的示例，因此我们可能会引入UI设计不一致的问题。

还有一种想法是消除左右控件之间的空白空间，但是由于使UI看起来过于“块状”，所以在票证中对此予以了删除。

@chrisvanpatten话虽如此，我想我还是会喜欢您的样机，而不是现在的样机。 与我们的任何一个模型都将解决的所有问题相比，遵循块的第一行似乎消失了。

@SuperGeniusZeb我认为在这种情况下特别尴尬的是，当您将鼠标悬停时，控件就在其中。 在所有其他跳跃控件示例中，至少当您将鼠标悬停时它们不存在，只有在选中时它们才存在。

由于悬停/选择/跳转/单行段落问题，我认为不值得放弃，但绝对需要多加思考。

我仍然有信心在这里找到解决方案……只需要不断迭代就可以了！

@chrisvanpatten

我认为在这种情况下特别尴尬的是，当您将鼠标悬停时，控件就在那里。 在所有其他跳跃控件示例中，至少当您将鼠标悬停时它们不存在，只有在选中时它们才存在。

好吧……您不能在悬停上显示任何控件，但是我认为可以肯定没有人真正想要它。 我知道我当然喜欢悬停时可用的控件。

无论如何，透明度如何？

如果您想做一点梦，并希望在所有主流浏览器中都实现backdrop-filter ，则可以添加一些模糊处理：

顺便说一下，这是60％的不透明度。

不透明度肯定会有所帮助，但是我不确定要将不透明度引入方程式中。 感觉有点像作弊。

@chrisvanpatten确实，的确有点像作弊……但是我们还有其他选择吗？

我们不能将控件放在一边，因此此问题首先存在。

我们不能将控件放在块中，因为那样会掩盖内容。

由于格式栏已在此处，以及细块可能导致的问题，因此我们无法将控件放在最上面。

将控件放在底部最有意义，因为它对可访问性更好，提供了一个方便的位置来插入同级插入器和拖动手柄并解决与之相关的问题，与移动设备更一致，并且对于薄块。

为了减少底部栏所占用的空间，实际上我们只能做几件事：

• 降低钢筋的高度。
• 删除插入器/移动器/拖动手柄和省略号之间的空白区域。
• 将省略号向左推，并在右侧删除多余的空间。
• 选中时使其占用空间。 （但是您不想要这个。）

除此之外，所有可以做的就是使它成为半透明的，以使其在视觉上更轻，并更容易看到其下方。

另一个想法：如果_both_工具栏是透明的而不只是底部的透明工具栏，那么透明的东西就不会让人作弊。

制作了更多的模型来尝试上面提到的一些事情。

透明工具栏：

没有透明度：

我想我实际上更喜欢没有透明度的产品。 你怎么看？ 我认为缩小底部栏的宽度已经解决了下一个块重叠开始的问题。 当然，它仍然会以较小的宽度发生……但是无论如何格式化工具栏已经发生了这种情况，因此我认为这并不是一个真正的问题。

还要注意，我为拖动手柄留了一些空间。 它可能只有很少的灰色点（通常在应用程序中用来表示拖动手柄），或者它的鼠标图标始终悬停显示。 或者它可以保持空白。 从技术上讲，它还可以更薄一些，但我还是把它的宽度留了下来以保持舒适。

可以吗？ 这样的迭代是否足以代替当前的迭代？ _（请说“是”。：stuck_out_tongue：）_

感谢大家在这里所做的所有探索。 跳进去只是为了增加半透明效果不理想的另一个原因：图标与背景的对比度必须为4.5：1。 使用半透明将使这变得不可能，只需考虑具有普遍深色的图像，具有深色背景的段落或具有深色背景的主题：

感谢大家在这里的精彩讨论。 看到应对挑战的热情令人振奋和高兴。

我一直在远处观看，设计了该块的初始配置-带有固定的工具栏，侧面的向上/向下箭头，最后是右侧的省略号。 我添加了这些成分，是因为我觉得给搬家提供优质的房地产作为拖放的替代品非常有用，而这通常很容易产生错误，而搬家的行为总是可以预见的。

我完全意识到这对嵌套块带来的挑战，并且我一直在想最好的解决方案是什么。 master的内容（即使嵌套也可以左右重叠）有效，但也不是一件好事，我承认。 另一种选择是使用移动用户界面-在选中时在块下方显示用户界面，在这里，它是在各种变体中模拟出来的，尤其适用于移动设备。 但是，在桌面上，当您只想选择一个段落进行较小的编辑而所有内容都会跳来跳去时，它会变得非常混乱且容易跳动。 同样，如果工具栏如最新版本那样被覆盖，则感觉它与书写体验之间的距离太远，而与布局体验之间的距离太远了。 这是我们试图达到的恒定平衡。

第二种选择是回到我以前使用的旧模型的方式：

也许经过一些调整，可能是这样的：

但是我不喜欢那个。 并且_这将使动子仅在将块悬停时可见，否则我们将要对处理进行一些调整。 这也使按钮的点击区域缩小了几个像素，这对于可用性而言并不是很大。

因此，到目前为止，尚未考虑这些变体，因为它们并不比我们拥有的更好。 但是，在此处张贴内容，以防万一他们可以激发治疗方法以使其起作用。

将块工具与悬停标签结合使用时，我看到的最大问题是，除非您也希望开始显示所选块的标签，否则它会在选定的块和悬停的块之间造成不一致。 如果这样做，则标签不应位于块边界之内，而应位于其边界之外。

但是即使这样做，您仍然会遇到以下问题：在块的顶部有太多控件，并且必须弄清楚如何使宽块和薄块都保持一致。

我坚信，除了停留在屏幕上的粘性工具栏外，所有选定的标准块UI都不应该覆盖该块的任何部分。

将块工具放在底部可以很好地放置同级插入器，这不仅有助于实现上述不重叠的目标，而且还可以使同级插入器更加可见并解决其自身的重叠问题。 （我认为由于重叠的同级插入器，尚未将嵌套块更新到Quote块。）

由于具有同级插入器和可访问性的优点，我认为位于块下方是放置块工具的最佳位置。

现在，我不认为要缩小控件的大小是摆在桌面上的，因为缩小控件的难度当然会使它们变得更难使用。 但是，由于您似乎并不反对它，那么为什么不尝试呢？

这怎么样？

底部栏中的按钮（但不包括图标）的大小已从38px减小到32px，并且我修复了先前模型中的mover控件之间的间距不一致。 请注意，如果省略号按钮比其他按钮更细（例如，编辑器顶部栏中的一个），则可以使其水平方向变小。

您还可以减小空的拖动手柄区域的大小，以使该条占用更少的空间。 如果该栏中的所有控件都作为拖动手柄加倍，例如GNOME中窗口的顶部栏如何工作，这将更加可行。

请注意，在移动设备上，控件的外观可能几乎与master样子完全一样，在这些控件上，条形占据了空间，因此使其变大不是问题。 减小大小只会影响桌面用户，并且在此大小下触摸仍然可以使用控件。

我还进行了一些小型的探索，将控件移至顶部的工具栏，这解决了一系列问题……但是，当您选择该块时，您又回到了“一切工具栏”，该工具栏在狭窄的上下文中不起作用。首先进行此探索的重要原因。

我仍在尝试弄清我对那些最后的模型的感觉。 悬挂在底部的控件对我来说有点尴尬。 我不确定我有一个更好的主意，只是让它回到@karmatosed想避免的那种块状/碎片感。

感谢大家在这里所做的所有工作。 我将尝试提供一些反馈，但是我现在必须说，我不认为这已经准备好进入原型。 我仍然认为嵌套存在问题，还需要解决不同的设备，但是正如我在前面的评论中提到的那样，我认为当前的路线是不正确的。 我觉得我们也回到了我已经建议我们避免的领域。

我不想阻止探索，但现在我建议考虑考虑其他建议。 最大的问题是，在底部添加半个标签会增加视觉密度，但不会增加增益。 让我们考虑一下我们要解决的问题：

• 在不同的设备上会发生什么。
• 同级插入（尽管这可以在其他问题中解决）或至少是如何交互的。
• 嵌套可见性并简化交互。

所有这些的主要驱动力是它如何响应和嵌套。

让我们考虑一下在增加或减少可用性时创建的内容。 例如，使用透明胶片和图层之类的东西虽然对于具有正常视力的人来说是可以的，但对于很多其他人却不能使它变得更好。 考虑复杂的布局，包括视频和大量图像的布局。 在这种密集的信息结构中，建议的内容不会成立。

考虑复杂的布局，包括视频和大量图像的布局。 在这种密集的信息结构中，建议的内容不会成立。

是的，我认为这是最大的要点，我还要在较小的空间中增加密度，这是挑战的另一部分。 嵌套块通常需要与非嵌套块所需的所有控件相同的控件，但是它们需要用一小部分空间来完成它，并且理想情况下以非唯一的方式（例如，嵌套块通常应类似于非嵌套块；一致性得到）可用性）。

回到画板…🙂

为什么我认为我的模型比当前的UI更好

我了解避免出现块状外观的愿望，但是我还没有找到任何看起来都不块状但仍然功能正常的东西。 问题在于，您需要知道正在处理的块的边缘，并且希望控件既不掩盖块中的内容，又不掩盖块外的内容。 这几乎可以保证外观有些块状。

仅查看本期顶部的屏幕截图，您就可以看到古腾堡在某一时刻如何具有非常不阻塞的块UI。 但是该UI的问题在于，很难分辨出块的边缘在哪里。 这就是为什么我们拥有现在的UI。

并且当您使用同级插入器引发问题时，您意识到需要使同级插入器按钮位于块内容边界之外。 将其与您通常希望在当前块之后（而不是之前）插入块以及增加可访问性的愿望结合起来，您最终将不得不拥有类似于我的最新模型的东西。

就个人而言，我更喜欢这种块状UI，而不是看起来像第一个模型的东西。 由于内容和控件之间没有边界，因此这些第一个模型看上去很混乱，并且这些酒吧占用了很多不必要的空间。 由于我们不希望跳转UI，因此底部栏必须是所选块外部内容的覆盖，因此应尽可能小。

另外，我认为我的模型在嵌套上下文中肯定比当前模型更好。 正如我将在下面解释的那样，此UI重叠的工具栏/内容情况比上一个更好。 在嵌套上下文中，您需要进一步了解块的边界，因此在这种情况下，略带块状的外观实际上会有所帮助。

重叠的工具栏不太容易混淆，也不太可能成为问题，因为与小屏幕上的块在水平方向上较小的可能性相比，块在垂直方向上的可能性较小，这导致诸如Columns块之类的问题。 当文本块变薄时，其文本将环绕并变高。

在嵌套的上下文中，将鼠标悬停在当前块上方的块上几乎不会覆盖下面块的所有内容，因为该块的宽度足以使底部的栏无法覆盖全部，否则该块将相当高，因此它仍有选择的空间。

此外，仅当您将鼠标悬停在该块上时，才显示该块的底部，而不仅是当鼠标靠近该块时。 由于块的侧面有奇怪的，不可见的拖动手柄，因此当前的UI并非如此。

要添加到上面的要点，只有当前块上方的块可以掩盖所选块中的任何内容。 其他3面完全正确，因为将鼠标悬停在水平相邻的块上不会覆盖当前块，并且悬停的块上方没有UI，因此将块悬停在所选块的下方也很好。

另外，您可以简单地选择不使悬停的块永远不会掩盖当前选定的块，而这将导致嵌套上下文中选定块的字面重叠量为零。 由于悬停的块仅在底部有一个条，因此当前块下方的那个将永远不会与所选块重叠。 在这种情况下，您唯一放弃的是能够访问当前块上方的块的块工具，除非您选择它。

还有一个想法：当光标悬停另一个块时，底部栏可能会自动隐藏。 直到您再次将光标移到块的边界中，它才会回来。 这可以在嵌套上下文中提供更多帮助。

最重要的是，如果您仍然希望嵌套上下文中的重叠问题更少，则可以将格式工具栏停靠在编辑器的顶部栏中。 （这对移动设备没有影响，但是在移动设备上，条形占用空间并且没有任何重叠，因此首先没有重叠问题。）

总体而言，我认为通过最新的模型可以改善的情况要比恶化的情况多。

实际上，我认为像我的模型（或接近模型）解决的问题要比其创建的问题多。 除上述内容外，好处还包括：

• 适用于所有块宽度。
• 同级插入器，移动控件和省略号的更好可访问性。
• 更好的可见性和可发现性，可用于同级插入器和拖动手柄。
• 可以删除块侧面的拖动区域，并且悬停标签不必成为拖动手柄（无论如何，它都是很小的）。
• 同级插入器位于块的下面，通常是您要在其上使用的地方（与上面相反）。
• 无需单独的同级插入器UI，从而降低了复杂性。
• 同级插入器在嵌套上下文中不再有重叠问题。 （我认为这是＃6520尚未发生的原因。）
• 围绕一个块的块UI永远不会与该块的内容重叠。
• 可以删除块的自动边距，并且块完全没有内部填充，并且块UI边界可以更改回实际的内容边界，但是任何控件都不会覆盖块内容。 这些边缘情况将在自定义块中发生，因此考虑它们是很好的。
• 与以前的省略号和箭头移动器位于块相反侧的情况相比，所有的块工具都相当靠近，因此更容易将它们全部找到并全部发现。
• 与您经常在嵌套上下文中使用当前控件所引起的混乱相比，控件所附加的块是非常清楚的。
• 这些控件与移动设备更加一致。

所以，是的，我认为我的模型在嵌套上下文中实际上更好地工作，而且我认为与获得的内容相比，块状UI几乎不重要。 你怎么看？ 如果您不同意，您是否可以指出其中的样机比当前的UI差很多并且前面提到的建议都无法解决的情况？

还有...另一个...〜天行者〜

如果其他所有方法都失败了，我确实有一个从技术上解决所有主要问题的想法。 如果格式化工具栏始终像在Gutenberg 1.6中一样一直停靠在顶部，但是这次移动控件和省略号将显示在块上方而不是侧面？ （您也可以像我的模型一样将它们放在底部。）

在这个概念中，同级插入器将不存在，因为编辑器顶部栏中的插入器将提供相同的功能，并且在这种情况下，由于格式设置工具栏位于同一区域，因此插入器更接近。

移动用户界面将与现在完全相同。 此更改只会影响台式机（甚至平板电脑）用户。

但是，等等，还有更多！

其实，如果您考虑一下，这个想法与仅制作我的模型并启用“修复工具栏”到顶部之间有什么区别？ 通过从移动设备中完全删除嵌入式格式化工具栏，您获得的唯一好处就是能够将移动控件和省略号显示在块的上方而不是下方。 从技术上讲，这可能只是“修复工具栏到顶部”选项的一部分。

比较当前的用户界面，其中修复工具栏顶部没有摆脱所有的重叠控制问题，因为侧面的UI双方和混乱的无形阻力句柄仍在之间仍然分裂，然后将同级插入器仍然在嵌套上下文重叠，等等。

文本的每个段落都是单独的块，是否肯定会在将来成为现实？ 如果是这样，则块工具的显示将不得不考虑多个文本块选择（我相信这是在某个阶段）。

@padraigobeirn这是我忘记的一个好点。

值得注意的是，当前UI中的控件没有考虑长选择。 运动控件和省略号停留在所选内容中第一个程序块的左上和右上。 甚至格式化工具栏也仅适用于所选内容中的第一个块。 参见＃7962。

对于我的模型的底部栏，从理论上讲，您可以通过向上滚动使其保持在屏幕底部的方式使其与多个选择配合使用。 但是，这种粘滞行为可能仅对于选定的块是理想的。

您知道，我真的开始认为默认情况下应该将“修复工具栏到顶部”打开。

实际上，要在一个块中容纳这么多的控​​件，实际上您只能做很多事情，即使使用我的最新模型，在某些情况下，UI还是会感到拥挤。 还存在UI过于块状的担忧。

为了解决这些问题，我认为将格式化工具栏停靠在顶部应该是默认设置。 它节省了很多块周围的空间，并大大减少了可能的控件重叠量。

我想我仍然希望将运动控件和省略号放在底部，但是当格式化工具栏停靠时，它们也可以移到顶部。 没有将格式化工具栏附加到块上，将允许将块工具栏放置在右下角或右上角，而不会显得笨拙或占用过多空间。

我想我更喜欢左下或右下。 这样，控件在视觉上和按Tab键顺序都位于该块之后，这对我来说最有意义。 与在块之前出现相比，在块之后将同级插入器扔在那里比从前有意义。

旁注：我最近注意到Infusionsoft中的电子邮件构建器实际上具有其自己的“阻止”概念，并且具有右上方的块上方显示的阻止工具（复制和删除）。 当光标进入文本区域时，格式设置控件将显示在编辑器顶部的栏中。

我最近注意到，Infusionsoft中的电子邮件构建器实际上具有其自己的“阻止”概念，并且其阻止工具（复制和删除）如右上方的阻止所示。 当光标进入文本区域时，格式设置控件将显示在编辑器顶部的栏中。

您可以剪辑该界面@SuperGeniusZeb的一些屏幕截图吗？

刚开始使用古腾堡（Gutenberg）时，我肯定是“固定工具栏到顶部”的人，但是使用了一段时间后，我不确定自己是否想返回。 我完全认识到，工具栏在许多方面都是所有这些问题的原因-它最有可能在嵌套上下文中被切掉很多东西，并占用了可用于侧面控件的空间-但是拥有它与块配对非常好。 它可以将您需要的一切都集中在一个地方，避免了很多眼动和鼠标移动等。我现在很惊讶地说出来，但是我认为这是我无法忍受的。

您可以剪辑该界面@SuperGeniusZeb的一些屏幕截图吗？

@chrisvanpatten不，我在帮助某人时只能临时访问它。

在固定/非固定格式工具栏上，我都不很强烈，但是我倾向于固定，因为这将有助于减少块周围的视觉混乱。 根据用户反馈，其他人更喜欢什么，为什么呢？

@chrisvanpatten找到了一篇文章，有人在Infusionsoft中谈论电子邮件构建器，并提供了一个视频：

https://www.monkeypodmarketing.com/the-new-email-builder/

@chrisvanpatten Argh ，我刚刚检查了一下，好像该视频已经过时了……看起来像是在将格式化工具栏附加到块上，就像古腾堡现在所做的那样。 有趣的是，他们改变了它。

一些想法：

如果您打算在帖子的中间插入一个块，通常您想在选中的那个之后进行，对吗？ 您通常不希望在所选块之前插入_before_。 从可访问性的角度来看，在块之后插入也是有意义的。 有人不同意吗？ 对我来说，这似乎是一个强有力的论点，赞成在同一个块的底部附近出现同级插入器。

同级插入器不应与所选块的内容重叠。 任何内容都不应永久重叠所选块的内容。 有人不同意吗？ 这使我相信兄弟姐妹插入器应位于所选块的内容之外。

我指出这一点是因为我认为无论移动控件和省略号应放在何处，同级插入器似乎都必须出现在所选块下方的某种工具栏中，即使它本身是全部和/或工具栏具有无边框/背景。 我想它看起来几乎和现在完全一样，但是向下移动并更改为显示在方块下方，而不是方块上方。

另一个想法：将省略号与运动箭头放在同一侧会比对master有所改进吗？反之亦然？ 这可以解决嵌套上下文中重叠控件的许多问题，但代价是在块的左侧（或右侧）具有更高数量的块UI。

我刚刚尝试了＃8836。 我认为，如果将其合并，则可以帮助减少此票证中许多UI设计似乎存在的沉重/块状UI问题。

在＃9074和＃9075票中，我建议从这次讨论中汲取两个步骤，以减轻和改善这种情况。 在第一个建议中，我们将“省略号/更多”按钮移到工具栏上，所以我们只有一个侧面UI（移动器），在另一个建议中，是让块工具栏折叠部分以更好地适合弱环境。

为了使它们保持最新，我更新了模型，以解决@jasmussen票证建议的更改以及3.6中最近的UI更改：

实际上，如果已实现＃9074和＃9075，则甚至不再需要将箭头移动器移动到块下方。 如果它们停留在块的侧面可能很好，因为相邻块的省略号将不再与列之类的部分重叠。 如果针对＃8880，＃8881和＃8883的解决方案发生了，并且如果实现了＃8836和＃8920，则UI对于嵌套上下文来说可能已经很好。 我开始倾向于将向上/向下箭头留在区块左侧是可以的。

话虽如此，我仍然认为兄弟姐妹插入器肯定属于块下方，尽管您肯定可以让兄弟姐妹插入器单独出现在块下方。 也许它可以像当前同级插入器一样居中，但动作和外观类似于上/下移动控件，当您将鼠标悬停在块的下部时，它会在块下方显示为浮动按钮。

让我们专注于让@jasmussen在＃9074和＃9075中进行迭代，然后我们可以考虑下一步。 我完全想改变很多事情，但让我们保持平衡。

多亏了前面提到的＃9074和＃9075，以及诸如＃8920和＃9197之类的其他问题和PR，我认为将箭头移动器移动到块下方不再具有很多好处。

相反，我现在建议仅将同级插入器移动到块的下方，以类似于上/下移动器的浮动控件的形式出现。 请参阅＃9202。

现在，让我们结束这一讨论，因为本次讨论和其他讨论都浮出了许多改进。 最后要做的一些改进是围绕尾随插入器进行的。