😍

这是 ⭐️ ⭐️ ⭐️ ⭐️ ⭐️ 工作。 STELLAR 模型，我喜欢它。 这正是我们希望块优先 UI 能够实现的丰富布局。

CC： @melchoyce你会希望在今年晚些时候看到定制重点。

对于 V1 编辑器，恐怕像这样的列超出了范围。 这不是“不”——相反，在我们致力于真正有趣的事情之前，我们需要先打好一些技术基础。 但它可能是 V1.1，或者至少是今年晚些时候的定制人员。 甚至在此之前，最好记住这个 UI，以便插件可以更早地添加它。

这次真是万分感谢！

我的反馈是这开始将编辑器变成布局工具而不是内容编辑工具。 响应式设计之类的东西使 CMS 中的布局控制变得非常困难，恕我直言，最好留给主题设计师/开发人员。 我当然可以看到像“2-col”这样的选项，但实际上拖动分隔线以基本上允许用户布置内容对我来说似乎超出了内容编辑器工具的范围。

不确定这种哲学是否与古腾堡计划的看法一致？...

我认为这些对画廊来说也是有趣的想法。 我们可能不想保留当前的固定列方法并允许行具有不同数量的列。 就像文本列一样，一个好的画廊块听起来可能会变得非常复杂。

不确定这种哲学是否与古腾堡计划的看法一致？...

今年晚些时候，定制器将成为重点：

定制器首先会帮助编辑器，然后转向将这些基本构建块带入可以允许 post_content “开箱即用”定制的东西，包括侧边栏，甚至可能是整个主题。

列很可能是其中的一部分。

古腾堡首先用于撰写和布置帖子。 这就是我们必须正确的。 但是编辑器稍后可能会与定制器共享一些 DNA，特别是在涉及某些块时，也可能与控件共享。 因此，这个模型仍然有助于定制重点。

非常优雅的解决方案。 感觉比放入一堆列块要好得多，IMO。 我还可以看到列宽按特定百分比对齐（例如 50% / 50%，或 33% / 66%，或 25% / 75% 等）。 列几乎肯定会成为更新的定制器中的一个功能:)

@jasmussen很高兴你喜欢它
@simonrjones从默认的博客帖子中进一步扩展 WordPress 自动意味着演示页面需要多列布局。 我更愿意提前解决这个功能，而不是让每个开发人员自己做（请参阅大量的页面构建器插件）。
@melchoyce绝对列宽应该与特定步骤对齐（即使那是 6 列或 12 列步进器）。

我想知道我们是否可以找到一种方法使列对齐主题相关。 随着古腾堡的进展，我们将在接下来的几个月内思考一些事情。

在列对齐和 CSS 网格（包括响应式部分）方面都应该有一个默认值。 那么主题应该能够覆盖它们。

我们已经在开发一个集成到 TinyMCE 编辑器中的插件，该插件共享其中的一些行为——只是它不是基于拖放块的，而是一种行/列方法。 它被称为Gridable ，可能值得一试。

+100 从我。 我真的很喜欢列块的想法。

这是 CSS 网格的候选者吗？

https://css-tricks.com/getting-started-css-grid/

感谢您对我的评论的澄清。

CSS 网格非常棒，非常适合列布局。 但是，我猜测广泛的浏览器支持还需要一段时间，这可能是 WP 的问题（今天在最新的 Firefox 中有效）。 在Rachel Andrew 的网站上有一些关于 CSS 网格的非常好的资源，在Jen Simmons 网站上有一些不错的东西。

以一种或另一种方式添加列意味着 CSS 和 HTML，因此理想情况下，我们需要简单且基于标准的模式，以使主题开发人员更容易。 这可以封装在代码中，因此可以定义默认起点，然后可以覆盖该起点（例如，如果有人想使用 Foundation 来构建他们的站点，则需要以 Foundation 方式设置列）。

我听说过的经验法则是：

• 用于站点结构/布局的网格
• 该布局中内容的 Flexbox

Rachel Andrew 的一篇关于 flexbox 与 grid 的好文章： https ://rachelandrew.co.uk/archives/2016/03/30/should-i-use-grid-or-flexbox/

基于 WordPress 当前的浏览器兼容性要求，我认为标准的“行+列”网格作为默认系统（例如 Bootstrap 或 Foundation）将提供简单性和灵活性之间的最佳平衡。

我同意标准的行 + 列结构是要走的路。

如果可以在 WordPress 设置中选择网格系统，那就太好了：

• 默认
• 引导程序
• 基础
• 风俗

默认网格系统将包括支持 CSS（作为TwentyEightteen 主题的一部分？），而其他选项将依赖于CSS 主题。 本质上，WordPress 输出网格类，主题提供样式。

自定义选项将允许您设置行和列的类名。 对于我所描述的内容，一个密切的 UI 比较是当前的永久链接设置屏幕。

多列布局是必备的！ 目前，古腾堡没有解决任何问题。 您最终仍会得到一长列内容。 页面构建器如此受欢迎的全部原因，以及成千上万人使用它们的原因，是因为它们提供了轻松制作多列布局的能力。 如果没有此功能，您就没有任何理由在页面构建器插件上使用古腾堡。

@maddisondesigns是的，V2 计划进行多列布局。 他们的基础工作现在正在 V1 中完成。 实际上，底层的块解析器确实支持嵌套，只是显示嵌套块的 UI 还没有实现。 另见#428。

@westonruter很

我很欣赏想要专栏的兴奋和紧迫感。 我们也有同样的紧迫感。 这不是不想要列，这纯粹是在这一点上管理资源。 我们会做到的，这绝对是一个元目标。 如果我们能打个响指并让它发生就好了；)

即使没有专栏，Guttenberg 也是向前迈出的一大步，我印象非常深刻，但我同意包含它们对于 V1 必不可少，并且值得推迟 V1，直到该功能准备就绪。

如果您添加前三个页面构建器的活跃安装和来自 .org 的列插件的第一页，您将获得超过 150 万……而如果您添加的溢价还不是它的一半。 关键是我认为没有栏目的编辑器不能满足当前的需求。 如果 Guttenberg 在没有专栏的情况下发布，那么我想会在第一天出现十几个插件来添加它们。 然后当随后添加时，用户需要管理一些东西。

Guttenberg 将是非常具有破坏性的，但我敦促基本的构建块都已就位。 +1 的兴奋和紧迫感。

我想挑战古腾堡中“需要”支持复杂布局的概念。

建议的列和嵌套组合是一个兔子洞，直到用户体验对实际编写内容的人来说真的很糟糕时才会结束。 任何“成熟的”页面构建器都证明了这一点。

不是每个人都使用页面构建器构建布局，并且在数据库中拥有这种页面结构是非常有问题的。 最好专注于拥有用于扩展 Gutenberg 的良好 API，并且在向 Gutenberg 核心添加复杂功能时非常谨慎。

@khromov - 看起来您可能正在回复我的评论。 我提倡使用列，而不是复杂的布局、嵌套或整页构建器。 我有时在编写内容时需要列。 我拒绝使用短代码，所以我有两个选择：手动创建嵌套的 div，这是一种可怕的用户体验，并且会极大地分散实际编写内容的注意力，或者使用页面构建器，这通常是矫枉过正。 我认为使用列是很常见的，也许比嵌入视频更常见。

无论如何，我的理解是列在路线图上。 我想在 V1 而不是 V2 中看到它们。 像你一样，我很欣赏为打下良好的基础而采取的谨慎措施。

要记住的“列”的一个方面是它不仅仅是桌面布局的问题。 它拥有一个可以从移动设备扩展到桌面设备的系统。

在 CSS 中是column-count吗？ 如果我们使用它，将很容易快速创建一些响应式内容，但是您将无法在特定断点处布置您想要的列中的内容。

它是 CSS Grid 还是 flexbox？ 然后我们希望确保用户有适当的响应选项，以便跨设备预测结果，不仅如此，我们还希望让 WordPress 主题了解这些功能，以便它可以相应地进行调整。

我们知道我们想要列。 事实上，3rd 方插件今天可以构建列块。 但这是一个复杂的功能，需要适当地准备好它才能工作的许多方面，并且如果没有更多的项目贡献者，它不太可能在 V1 中发生。

@jasmussen - 是的。 我很欣赏路线图上的专栏，也许画廊块中的一些见解会有所帮助。

构建此功能时应考虑到现代布局工具。 现在创建不必要的容器来创建列布局将限制我们将来使用现代技术的能力。

对于像列这样的简单一维布局，我们可以使用 flex 或 grid。 我倾向于网格的原因很简单，虽然我们今天只讨论列，但未来用户会想要更高级的网格控制，所以我们现在应该奠定基础。

至于浏览器支持，flex 和 grid 都在现代浏览器中得到广泛支持，并在旧浏览器中干净利落。 为旧浏览器提供回退也相对简单。

我强烈反对采用嵌套元素的经典框架方法来完成这项工作。 它几乎会立即导致遗留成本并阻碍未来的布局工作。

在此处采用网格为布局相关的未开发领域打开了大门。 下周我会尽量找时间写一些关于这里可能发生的事情的更全面的内容。 与此同时，这是相关的： https :

我对此的担忧是它会将用户锁定在一种特定类型的 HTML 结构中。 然后所有主题都必须适应以支持这种结构。 它是嵌套的div吗？ 嵌套的section s？ 我们是否使用float来向后兼容（因为很多网站都需要它。Win7 仍然拥有巨大的市场份额，这意味着 IE11 仍然如此，而 IE11 与flexbox玩得不好)，或者为未来使用flexbox/grid 。 我们是否为用户提供了更改的选项（然后让他们重新了解 CSS）？ 这可能会很快变得危险。

内容将包含嵌套块，但为呈现而生成的标记可能由主题决定。

我认为 Gutenberg 应该专注于提供用于添加嵌套块的功能和 UI，而不是允许开发人员为列之类的东西创建自定义块。 古腾堡不应该关心网格，因为这是一个主题应该控制的东西。

@westonruter +100000 对此。 我认为 Gutenberg 可以提供一种默认方式来标记网格及其样式，但重要的是它应该被主题覆盖，例如通过add_theme_support() 。

来自我的巨大+1，这将是一个非常受欢迎的功能。

这是一个很好的例子，说明为什么 Gutenberg 数据不应该被存储为原始 HTML……如果它以符合标准的方法存储，比如 mobiledoc，那么列将只是对象，并且渲染它们很容易被覆盖任何主题。 如果主题想要使用传统结构，比如 row/col，他们可以。 如果他们想使用网格，他们可以。 如果他们想使用 flex，他们可以。 如果他们想使用接下来出现的任何技术，他们可以。 真正的对象存储方法将使内容面向未来。 HTML + 评论只是不能。

+1 此功能对每个人都非常重要。

我正准备重新设计一个大型 B2B 网站。 现在它使用 Divi，我希望能够使用 Gutenberg 进行重新设计，否则我将再次使用 Divi 多年。

如果未处理列 - 我们将被迫继续使用“非 WordPress”方法来构建我们的 WP 站点。 我也很好奇古腾堡是否会包含一些“页面布局”预设来覆盖不兼容的主题并包含基本布局。

请使用基于 Flexbox 的网格。 不是 CSS Grid，因为它需要容器 CSS 更新才能进行任何更改。 Flexbox 只需添加块即可工作。 谢谢。

绝对会喜欢这个功能。 这里的讨论很好，期待看到它的发展。

我喜欢这个。 尤其是调整列大小的能力。 我特别喜欢您可以控制布局这一事实。 我不认为这是一个弱点。 这正是我在 Gutenberg 中一直想要的，但我很沮丧，因为许多其他类似的工具都提供了这个功能。

所以我刚刚更新了 Gutenberg 插件，并试图弄乱其中的列。 我创建了一个新帖子并添加了一个列布局块，并尝试使用滑块增加它。 每次我尝试这样做时，它都会显示错误：“此块遇到错误，无法预览。”

感谢您的错误报告， @mhenrylucero — 我已经为它打开了一张单独的票 #3710。

3745 已于本周早些时候合并，部分实施了此处的提议。

据我所知，剩下的任务在很大程度上改进了围绕将块重新排列成分栏布局的用户体验，我说得对吗？ 我是否正确地假设这将更适合初始合并提案后的定制重点？

将关闭它，这将作为进一步改进定制的参考。