Gutenberg: 添加块：部分

我真的喜欢这个主意！ 我也喜欢它具有背景设置的事实。

真好！ 如果该块允许以下三个“高级”设置怎么办：

• 定义要序列化到子级.child_class, .child_class_1
• 添加可选的第一个子类.child_class, .child_class_1, .child_class_first
• 添加可选的最后一个子类.child_class, .child_class_n, .child_class_last

:nth-child选择器可能能够补偿最后两个选择器，但是我认为在某些情况下向所有子级添加类可能很有用。

喜欢这个主意。 如果可以更改背景颜色和文本颜色，则也可以添加链接颜色。

好主意。 这实际上将为古腾堡编辑器增加很多价值。

比有很多问题的Columns块好得多。 凉！

当看到嵌套可用时，这是我着手创建的第一件事。 我的版本与我的版本相似，只是我设想您将在其中添加column块。

您有可用的代码吗？

如果该块具有“列”，我们应该只更新“列”块。 但是仍然可以在section块内使用column块，并使section块保持无列。

只要您不能将列块放在列块中😉

许多站点页面分为多个部分，这些部分的内容混合在一起，包含多行列，通常列嵌套在较大的行中。 这是一个简单的示例：

我认为这是最灵活的节块，就像一个裸包装一样。 （就像能够嵌套列块一样！）

我们本周开始了一个新的站点项目。 通常，它将使用“高级自定义字段”灵活的内容布局来构建，但我将看看仅使用Gutenberg就能获得多大的收益。

是的，我认为类似@jvisick的上述示例的多列部分并不罕见。 具有背景/文本选项并嵌套块的容器将是最灵活的方法。 由于我们现在有一个运行正常的列块，因此我们甚至可以考虑从中取出列选项。

如果在此块中包含一个内部容器（div），然后再包含所有子块，那就太好了。 然后可以使用max-width和margin-left / right设置此容器的样式：自动将子块居中并具有全角背景。

通常的设计模式是使用全角部分并将内容包含在较窄的布局中。 我想知道是否最好由嵌套块控制，而不是烘焙到父节块中？

我认为节块对于...好吧，页面上的节非常有用，并且我同意列应该是可以嵌套在节块中的单独的块（就像现在存在的块一样）。 我认为这是应与Columns块一起包含在合并到WordPress 5.0中的Gutenberg版本中的。 如果您查看现有的页面构建器插件，那么部分和列（很明显）都被大量使用，因此在我看来，将它们包含在初始核心版本中至关重要。

（我还认为，列块具有可变宽度列和响应列之类的功能很重要，这既是为了获得核心体验，又是使现有页面构建者更轻松地基于Gutenberg重新建立自己的基础，但是，那是一个单独的问题。）

考虑了一下之后，我认为让Section和Columns块是同一件事会更有意义。 只需添加使“列”块中只有一列而不是最少两列的功能即可。 然后将该提议的Section块的背景设置添加到Columns块。

我认为只有一个Section / Columns块会减少您必须做的嵌套量。 现在，建议的Section块实际上只不过是具有背景和宽度选项的区域。 可以将这两个都添加到Columns块中，并且如果Columns块只允许包含一列，则将不需要Section块。

此外，如果要使用标准宽度内容的全角部分，可以通过将另一个Section / Columns块嵌套到另一个设置为全角的块中来实现。 可以通过检查器中的设置来完成，以独立于整个块的宽度来更改块内容的宽度。 也可以将其添加为可见的调整大小手柄，类似于Beaver Builder行/列的工作方式，或在Gutenberg中Image块的工作方式。

至于您所说的组合块，我认为仅保留名称“ Columns”即可，因为这是人们所寻找的最明显的功能。 在检查器中找到背景设置应该不难（而且我想如果有一个单独的Section块并且他们不知道的话，无论如何人们都会首先看到它们），并使用Columns作为单列容器的块应该不难发现，因为用于更改列数的滑块应该使如何操作变得非常明显……只需将其一直拖动到最左边即可。

我改变了关于合并Section和Columns块的想法。 为了使列具有最大的灵活性，最有意义的是将每个列都作为自己的块：一个Column块。 这将允许轻松控制单个列的设置，以及将一列从一行拖到另一行。 当然，由于列是从左到右移动的（在大多数布局系统中都是换行的），因此您需要将其父块作为在水平方向上插入内容并具有换行（而不是标准垂直方向）的块。父块可能只允许将Column块插入其中。 该块将是行。 这2个块将替换Columns块。 但是它们并不能解决您希望多个行（它们内部通常具有不同的列数）位于同一背景/容器中的情况，这是Section块所要做的。 当然，Section块不过是带有背景，填充和宽度选项的容器，任何块都可以插入其中。 对于更复杂的布局，可以将Section块插入Column块中。

请参阅＃6461。

我实际上认为最少1列的想法不是一个坏解决方案。 实际上，如果使用检查器将滑块的“最小”（min）属性更改为1，然后选择一个，它的效果将与预期的差不多。

但是，从语义上讲，节块仍然更有意义。 内部内容（即，全宽度部分内的最大宽度部分）可以通过嵌套两个部分来实现-内容宽度在全宽度内。

背景色的主意很好，但是...也许有两个特定的含义。 我认为更通用的方法是只在该部分使用自定义类。 前端CSS可以直接捕获所有子类。

在＃6461中进行了一些讨论之后，我认为行块+列块的想法不是正确的方法。 与＃5351（注释）中的Layout块相似的Layout块可能会大大减少混乱，并且更加灵活。 无论如何，肯定应该有一个Section块，并且我认为应该绝对在WordPress 5.0版本之前添加它。

至于背景颜色选项，我认为在Section上具有背景选项非常有意义。 仅具有类选项似乎有点限制性。 通常，在Section块中嵌套的全部目的是使多个事物共享背景。 此外，我更希望是否实施了其他背景选项（例如背景图像和渐变背景），因为通常需要这些背景色来代替纯色背景。 嵌套节块甚至可以将背景色应用于单个块，这意味着“段落”块中的背景色选项可能不再需要。

至于嵌套Section块，而不是具有2个单独的宽度设置，我认为这可行。 我最大的担心是嵌套Section块会增加额外的填充量，这会导致填充选项。

我认为，Section块必须能够自定义其使用的填充量，或者至少要删除默认填充。 当然，这引起了一个问题，即当另一个块嵌套在该块中时，如何选择它。 我认为此问题将通过诸如＃6471之类的改进以及try/alternate-hover-approach分支中正在处理的东西来解决。

：+1：

我们确实需要一个通用的行/容器块，尤其是宽度设置。

理想情况下，我认为其他设置（例如“背景色”和“文本颜色”）应该位于每个块的某些“额外”设置标签下（除了其他几个通常适用的CSS设置之外）。

至于响应能力，我认为我们应该添加一个“响应”块。

背景颜色和文本颜色的问题很简单：它在哪里结束？ 仅在此线程中，就有人建议链接颜色。 为什么不选择边框的颜色，厚度和样式？ 老实说，填充和边距最有意义。 阴影，背景图像，定位选项和显示模式如何？ 字体样式和大小，行高和最小高？ 有数百种CSS属性，您需要哪些属性会因设计而异。

它应该是某个类，然后你就可以使用样式任何东西，包括后代元素，或CSS属性的过滤列表，以便为主题的div可以在钩，并添加他或她想要的人。

@tmdesigned它以功能完整且直观的WYSYWIG控制网页样式，格式和布局为结尾。 这不是古腾堡的目标吗？

古腾堡（Gutenberg）为世界提供了新鲜的，精心计划的，前沿的，可模板化的和可扩展的Web内容。

最终的想法是减少我们现在正在做的工作量，无论是编写CSS，编写有问题的CSS覆盖或执行重复的内容任务。

不是所有的东西都可以或应该用类来定义，特别是如果它们的目标性很差或属性不可覆盖。

以用户定义的数字设置为例。 为每个值定义一个类会很痛苦，并且块开发人员可能会想将值直接注入到style属性中。

如果它作为一个块存在，并且可以应用用户定义的CSS样式，则理想情况下，即使它是一组键/值对文本框，也应该有一个统一的标准化方法。

如果您愿意，可以阅读我建议的方法来解决您的问题。

我阅读了您对API的建议，与我所说的有关允许添加键值对的附加钩子相距不远。

但是我认为我的原始观点仍然有效。 就像我说的那样，这里有数百个属性，尽管有些属性更为常见，但这样的列表将迅速增长。 我们可以走这条路，并尝试找到“良好的妥协”，就像在Classic中包含或删除的TinyMCE功能一样。 但是这里有更多的属性在起作用，所以这将是一个挑战。

但是更重要的是，当您缩小一点并且不仅仅考虑单个块时，添加直接块级样式的想法就破裂了。 当您在一页或多页上有多个相似的块时，您将不需要重新输入所有这些值。 您将要像CSS类一样抽象。

允许-或鼓励-单独的块级样式是不理想的，因为它不可重用。 您说对了，不是所有的东西都应该抽象到一个类中，但是CSS的开发是有原因的，不应如此之快。

@tmdesigned非常感谢您的反馈。 我想我理解混乱，因此我将尽力澄清。

目标不是消除甚至减少CSS类的数量。

非常具体的目标是将用户定义的块样式设置统一为单个UI或至少单个API。

Web开发人员，块开发人员，主题开发人员仍将继续编写CSS代码来样式化块，并且块仍将具有类，属性和ID，以便开发人员可以对它们进行样式设置。

他们将拥有与现在完全相同的类，并且将拥有与现在完全相同的布局。

但

区块开发者意识到他们具有可以由用户配置

当以非编程方式控制网页内容的基于样式的通用配置时，这将导致一个单一的通用界面（针对开发人员和用户）。

这给用户和开发人员提供了一种一致的方式来查看，添加，删除，修改和覆盖块样式，这些样式最终归结为简单的CSS属性。

很抱歉在此线程上造成太多噪音。 我们可能应该进一步讨论相关问题。

编辑说明：

我忘了讲抽象。

用户需要两次将完全相同的样式应用于完全相同的块的那一刻，就是确切的时刻，应该为CSS类（对于该块）放弃用户定义的样式设置。

换句话说，用户定义的样式设置为用户提供了一种一致的机制，使用户可以根据自己的喜好自定义块，无论是单个页面上的唯一内容（应是唯一的）还是100次，以及如何选择结构它仍然完全取决于您。

我认为我们大都同意。 我在第一篇文章中的建议是有一个添加/删除控件的钩子。 我不反对使用样式的块级用户自定义，只是很难选择“默认情况下值得在通用节块上使用的样式”，而列表不会呈指数增长。 最少有几个就可以了，特别是在允许添加其他控件的情况下。 无论如何，让我感到惊讶的是，对于节块而言，边距和填充不会比背景颜色更普遍地有用。

FWIW，我喜欢您将生成类作为输出的想法，因此无需使用！important仍然可以重写。

@rchipka @tmdesigned我知道这是两个多星期前的事，但是您是否有兴趣在另一期中讨论更多这些详细信息？ 我认为，更多关注此会议将是有益的。

根据之前的对话，再次看了这个区块。

分享想法的最简单方法是通过原型： https :

一些注意事项：

• 基于快速民意调查： https ://wordpress.slack.com/archives/C02QB2JS7/p1527283199000343我已将名称从_Section_更改为_Container_。
• 我删除了列设置，因为合理的做法是人们希望在特定部分中混合和匹配列布局，如@jvisick所示。
• 除了背景色之外，我还添加了背景图片支持。 这些设置基于核心的现有“背景图像”功能。
• 我们应该让人们将一个容器块嵌套在一个容器块中吗？

@melchoyce看起来很棒！

我想看到的一个不错的功能是在检查器中进行选择，以在<aside> ， <div>和<section>之间切换块的HTML元素。

我认为绝对应该允许嵌套容器的功能。 使用上面建议的HTML元素建议，在单个语义部分中具有不同的彩色区域的情况下，这不仅会有用，而且在您不希望为单个块提供背景的情况下，也很有用背景颜色选项本身。

另一个不错的功能是渐变背景，因为这些背景在某些设计中似乎很受欢迎。

@melchoyce +1可嵌套容器。

能够更改HTML元素的@SuperGeniusZeb也在我脑海中

@jvisick是的，这就是我的想法。 Beaver Builder和Elementor的行/节都具有类似的设置。

@melchoyce我认为容器应该是无限可嵌套的。 这将允许用户在任何块（包括其他容器）周围包装自定义类（或自定义CSS）。

没有理由向通用容器块添加嵌套限制。

我了解语义HTML元素的价值，但我也想知道是否存在一种将功能以某种方式委派给插件的方法，因此高级用户可以选择使用它，但普通用户无需考虑它。 由于添加的那一刻，您不仅要承担提供功能的责任，而且还要承担对用户进行语义含义教育的责任……而语义含义往往是非常情景的。

@chriskmnds好点。 我认为这是设置容器标签的错误位置。

容器块应充当没有语义含义的通用容器。

语义含义应由（未来）块模板功能提供，以便<aside>内容可以是模板的一部分，而<section>可以是模板的一部分。

这样，用户可以按自己的意愿（在任何深度级别）在容器中组织内容，而不会影响语义。

我同意，对于大多数人来说，能够换出HTML元素似乎有些高级，并且可能不属于Gutenberg基本设置。

语义含义应由（未来）块模板功能提供，以便<aside>内容可以是模板的一部分，而<section>可以是模板的一部分。

这绝对是一个很好的探索。

我不同意保持基本UX简单的观点，但是我想问一下，在哪里添加<section> ， <nav> ， <header>等。包装元素？ 通用容器块，本质上是包装元素，似乎是一种自然选择。 对于这些情况中的每一种，这都比重复块更可取。 默认值可以是<div> ，除非需要，否则用户无需触摸设置。

如果HTML元素的选项的功能类似于alignwide / full设置，可以从主题或插件中设置一系列受支持的元素，该怎么办？

@jvisick理想情况下，将使用页面/帖子的“块布局模板”创建这些包装元素。

使用块布局模板，您可以设置一堆默认的容器块，并提供一个设置（在代码中）以指定容器块的生成标记名称应为什么。

@rchipka我看到了使用布局模板的目的，这些模板为用户提供了预定义的区域来管理内容。 我是从将Gutenberg用作未定义页面的页面构建器的角度来看的，从中可以设置从编辑器使用哪种类型的HTML元素将很有帮助。 我认为这两种情况都很重要。

也就是说，我同意@melchoyce的观点，即容器容器的初始运行不需要设置HTML元素，但我认为在下一个“页面构建器”阶段值得探索。

部分基本上是1列。

我注意到3.0.0列（测试版）块的滑块上不允许1列。

不知道最好只贴上Column块并组合这些实现是否更好。 缺点是什么？

最好添加一件事，就是切换容器（部分）是全宽还是包含。 如果包含它，则应遵守主题（＃5650）中设置的content_width ，否则应为全角。 我认为大多数页面构建器都具有此功能。

是的，这是我上一个模型中的快速工具栏中所包含的。

@melchoyce请记住，在

我认为默认情况下，容器本身可以变为全角，但是其中的任何本机不支持全角的内容（例如图像/封面）仍将被限制为编辑器宽度。

@melchoyce假设我理解正确，那意味着Container块上的宽度控件只会影响容器的背景，而不会影响内容？ 这就说得通了。 感谢您的澄清。 ：+1：

是的，这就是我的想法！

不知道是否进行了讨论，但是一个部分可以是“ section” HTML元素，也可以是“ article”，“ div”或其他内容，对吗？ 可以选择它会很好
我认为这也可能使“行”块变得不必要

在插件中实现

var el = wp.element.createElement,
    registerBlockType = wp.blocks.registerBlockType,
    InnerBlocks = wp.editor.InnerBlocks;

registerBlockType( 'nbrummerstedt/section', {
    title: 'Section',
    icon: 'universal-access-alt',
    category: 'layout',
    attributes: {},
    edit: function( props ) {   
        return el( 'section', {className: props.className},
            el( InnerBlocks )
        );
    },
    save: function( props ) {
        return el( 'section', {className: props.className }, 
            el( InnerBlocks.Content )
        );
    }
} );

@eddr对此进行了讨论： https :

我仍然认为选择使用的HTML标签的下拉列表是一个好主意。 感觉这是集成语义HTML元素（如<aside>和<section>而不创建一大堆过于相似的块的最简单方法。

@nbrummerstedt很好的初始基本实现，但是该块现在称为Container块，应该使用<div>作为元素，尽管理想情况下（如上文和前面的注释中所述），您可以更改HTML元素，从<div>到<section> ， <aside>甚至可能是<article> 。

这是您的实现的修订版：

( ( blocks, editor, element ) => {
    const el = element.createElement,
        { registerBlockType } = blocks,
        { InnerBlocks } = editor;

    registerBlockType( 'nbrummerstedt/container', {
        title: 'Container',
        icon: 'universal-access-alt',
        category: 'layout',
        attributes: {},
        edit: ( props ) => {    
            return el( 'div', {className: props.className},
                el( InnerBlocks )
            );
        },
        save: ( props ) => {
            return el( 'div', {className: props.className }, 
                el( InnerBlocks.Content )
            );
        }
    } );
} )( window.wp.blocks, window.wp.editor, window.wp.element );

为什么将其从WordPress 5.0里程碑@mtias中删除？ 似乎仅仅是因为它的实用性和简单性，才应该将其纳入初始版本。 许多块没有背景设置，因为假定您将为此使用Container块。 实施此模块不难，不是吗？ 我不明白为什么要将其推回WordPress 5.0之后的版本。

另一方面，我最近正在检查Oxygen，并对其基于Flexbox的布局系统印象深刻。 如果Container模块实现了其中一些功能，该怎么办？ 我敢打赌，它可能真的很强大，并提供了除Columns块以外的其他布局方式……也许它甚至可以使Columns块不必要？

https://oxygenbuilder.com/documentation/visual-editing/layout-spacing/
https://oxygenbuilder.com/documentation/visual-editing/response-controls/

我强烈建议您检查一下。 实际上，我建议您完全看一下氧气。 它与所有其他页面构建器插件都非常不同，我认为古腾堡可以使用很多好主意。

我绝对同意，这应该是5.0版本，您需要一个容器来避免使用column块的任何棘手的解决方案。

我也认为此块必须比现在晚可用。 许多WordPress开发机构在与古腾堡（Gutenberg）合作之前都在等待这一块。

@ dingo-d和@ericvalois是的，正是由于缺少3种内容，我才避免将Gutenberg用于博客文章之外的任何内容：响应列，非等宽列和Container块。

为了详细说明我之前所说的关于采用氧气的容器模块的做法，我认为容器模块可以选择将其嵌套模块的流向从默认的垂直更改为水平。 可能还有像氧气一样的垂直和水平对齐选项。 这些功能真的非常强大-尤其是与大多数页面构建器插件允许的以响应方式更改这些选项的功能结合使用时，尤其如此。

当然，存在一个显着的问题，即使用基于Flexbox的对齐/布局的Container块不允许将float对齐的块直接嵌套在其中。 但是我认为有一个简单的解决方案：添加使容器能够使用标准CSS display: block布局或Flexbox布局的功能。 标准的display: block模式将是默认模式，因为这是根文档将使用的模式。 启用flexbox显示模式将使所有整齐的对齐选项出现在检查器中。 另外，您显然希望在检查器中为这两种布局模式赋予不同的名称，以使其更加用户友好。 不过，我不确定您会如何称呼他们。 也许是“标准”和“灵活”？

允许容器块使用支持浮点的模式或具有更好的对齐/布局选项的模式将非常有用。 您可以嵌套容器块以在必要时使用两种布局。 将其添加到Container块可能具有的其他功能中（背景选项，选择HTML标记以增加语义的能力而不必求助于Custom HTML块等），并且Container块最终将是最重要的功能之一和核心WordPress中的有用块。

值得注意的是，如果具有两种布局模式的Container块听起来功能太多（我并不认为这会是一个问题），那么可能只有两个单独的块：

• 一个标准的Container块，它支持浮点数，但没有所有高级对齐/布局选项
• 使用Flexbox布局并提供所有简洁选项的Advanced Container（或Advanced Layout或Flexible Layout或您所说的任何名称）块

我建议您观看此氧气文档视频，以了解其布局系统如何工作。 确实令人印象深刻：

https://www.youtube.com/watch?v=NnSfR-YFcQI

我认为这里有很多潜力可以使古腾堡变得非常强大。 当然，对于最初的实现，我只希望Container块具有背景选项，更改所使用的HTML元素的能力以及使Container为全角（而不是其中的内容）的选项。 甚至只是背景选项。

实际上，仅包含一个甚至没有任何选项的Container块仍然很有用，因为它使通过CSS设置一组块的样式更加容易。

重要的是要考虑古腾堡，而不仅仅是在5.0之后停下来。 这是一个非常有用的块，将进行探索，但是对于第一阶段，实际上并不需要集中精力进行编辑。 当项目扩展到从简单编辑到布局的扩展时，毫无疑问需要那里的解决方案。 没有人说这不会被创建，这是优先考虑什么是编辑器，然后将其纳入第二阶段。

但事实是，大多数人都将Gutenberg用于布局目的，而不是用于撰写帖子。

人们习惯于写单词文档之类的帖子，因此他们在“帖子”页面上禁用了古腾堡。

但事实是，大多数人都将Gutenberg用于布局目的，而不是用于撰写帖子。

您基于此假设的数据来源是什么？

我曾在贝尔格莱德举行的WCEU期间与几人交谈，他们都同意，他们认为与Gutenberg一起写帖子很奇怪，因此他们在Posts上禁用了它。

与@ dingo-d所看到的相反，我只在文章中使用Gutenberg。 实际上，我发现在Gutenberg中进行后期制作的经验比在Classic Editor中要好得多。 部分原因是由于模块和上下文控件具有更多的模块化特性，部分原因是到处都不再插入烦人的<p>不可见标签。 那总是让我很烦。

我需要一个Container块（甚至没有任何选项的块）和一个像样的Columns块（或其他布局块）才能使用Gutenberg进行均匀的页面构建。 看起来Columns块将获得某种基本的响应能力（请参阅＃6048），这意味着缺少Container块使我无法在更多情况下使用Gutenberg。

我知道容器块显然会在某个时候添加（可能不迟于WordPress 5.1），但是我坚信应该在WordPress 5.0淘汰之前添加它。 即使在撰写文章的上下文中，容器对于诸如<aside> （如果它具有HTML元素选择下拉菜单功能）之类的附加语义也可能有用。 现在，如果要将任何内容包装在另一个HTML元素中以增加语义，则必须使用Custom HTML块，这意味着该Custom HTML块中的任何段落都无法利用Paragraph块的功能，或者该自定义HTML块中任何图像的Image块的任何功能，等等。

@karmatosed

没有人说这不会被创建，这是优先考虑什么是编辑器，然后将其纳入第二阶段。

我认为，Container块绝对属于第一阶段。

我觉得有点怪异的是，Columns块看起来将使其装入WordPress 5.0（可能仍带有“（Beta）”标签，但Container块却可能没有？），如果现在的重点应该放在写作上帖子，那么为什么要添加Columns块却不添加Container块呢？我认为，在帖子的上下文中，Container块比Columns块有用得多。当然，它也有很多好处。页面构建的上下文。

如果Container块没有进入WordPress 5.0，则意味着它直到5.1才会问世，这使它不能被大多数人使用几个月。 我希望古腾堡（Gutenberg）成功，而且我认为没有理由在WordPress 5.1之前禁止发布诸如Container Block之类的基本内容。 为了获得良好的第一印象，我什至建议您在WordPress 4.9.8标注之前添加它。

我不希望它具有人们建议的所有功能。 它的存在就足以解决许多当前尚无法解决的常见用例，除非通过使用Columns滑块手动设置为1的Columns块的相当棘手的解决方案，然后才有一个像背景颜色选项的选项会使它变得更加有用。

我同意这是一个很酷且有用的功能块，但它始终更多地涉及项目的第二阶段，我们确实需要集中精力，否则我们将永远无法交付。 我们构建嵌套块基础结构是因为正确获取抽象并允许人们构建其自定义布局块非常重要，因此像这样的实际核心块就不那么重要了。 重点是总体上正确地使用嵌套和子UI（使用_Columns_作为豚鼠）。

这个问题也已经开放了五个月，而且还没有任何可靠的实施建议，包括颜色，宽度，块的方向与嵌套列的方向，与封面图像的重叠等。按目前的情况，我们可以不要将其优先于我们需要做的其他一般用途工作，以及WordPress中即将出现的“尝试”通知。 这并不意味着它不会成功，特别是如果有人想在代码中提出建议的时候。

另外，对我来说，最大的问题是，不清楚（仅从此处的对话中可以看出），理想的用户体验应该致力于实现。 对于普通用户而言，诸如公开html标签之类的事情似乎过于复杂和不直观。 容器这个概念需要进行更广泛的测试，以查看它是否是最佳的布局抽象，同样，应该在下一个焦点阶段弄清楚这个概念。 对于这样的块如何将样式层叠到内部的任意块，还存在一些未知数–考虑核心块而不是任意块相对容易。

同时，想要提供自定义块的开发人员应该有一个轻松的时间，即使用InnerBlocks它们与想要的任何标签（如上面所示的代码段）放在一起，并收集用户反馈。 因此，对具有此类阻滞（并必须对其进行维护）的岩心的压力较小。 综上所述，任何人都应该随时通过PR提出建议并帮助用户进行测试。 我可以将其作为“实验性”添加到插件中，并认为它可能会在5.0版本中被删除。

@SuperGeniusZeb氧气非常酷！ 对于其中的一些探索，绝对应该加以研究。

出于好奇，如果主题和插件添加了自己的Section块，并且用户停用了插件或更改了主题，会发生什么？ 是否存在某种后备方式？ 还是用户会丢失其内容？

@tomusborne这种情况有一个问题：＃7811。

啊! 我不知道在这里讨论过这个。 所以我也根据需要制作了一个插件。

https://github.com/marcusig/gutenberg-section-block

我一直在关注此主题，并感谢所有想法。 我最近在Atomic Blocks插件中发布了一个容器块，该

此问题之后。我创建了一个“容器”块，该块允许选择列的结构和其他选项。
如果它可以帮助改善顶部的“ Columns”块，或在内核中创建一个新块，请访问： https :

@MarieComet很好，但是我认为您的区块应该分为2个不同的区块。 第一个应该是具有所有基于列的结构布局选项的Columns块。 第二个容器是一个Container块，它具有不是基于列的背景选项和布局选项，例如能够使用flex来水平而不是垂直地布局子级，并使用与CSS Flex属性相对应的选项来对齐和对齐它们。

您可能还可以使用Container块来替换各个Column块，尽管您可能希望在Column上使用某些选项，而这些选项对Section没有意义。

我已经意识到，使用HTML和CSS进行布局的未来并不总是像大多数页面构建器一样总是使用列，而是要使用CSS Flex和Grid在更少的<div>显示内容。标记，并具有更灵活，更简洁的样式。 我的主要灵感来自氧气的作用。 我在此评论中谈到了氧气。

这个问题不是关于立即替换column块。 重点关注此问题的实质，这是一个重要的部分。

@karmatosed @melchoyce说到哪个，这个问题不应该重命名吗？ 我们不再将其称为“ Section”，而是切换到“ Container”，以避免与<section>元素混淆。

名字尚未确定，所以我们一切都很好，离开了一点点。

目前，我正在尝试与古腾堡（Gutenberg）编辑一起实现主题。

网站的布局具有不同背景的不同区域，其中包含多个项目，例如段落或列表。 这是出于布局目的和导航目的。 section / container块应作为锚点/应具有唯一的CSS ID。

如果没有通过创建自己的块来“侵入古腾堡”，我就无法完成这个主题。 可以将它作为核心模块来完成。 我不会只将Gutenberg编辑器用于纯文本和简单的布局-我未来的布局/设计应该与主题和Gutenberg的块系统一起完成。

我真的希望，这个话题将得到更高的优先。

我在各处都使用了3rd-party容器块（例如Atomic块），并与Columns块结合使用。 它们非常有用，是我最受欢迎的功能块。 我感到奇怪的是，它会在以后的晚些时候或作为附加组件被考虑。 需要处于核心地位。

否则，我只是在HTML视图中手动构建容器，但这很烦人/效率低下，因为单击HTML视图是多余的菜单。 HTML视图有一个键盘快捷键... shift + option + cmd + M ... yeesh。 而且它甚至不会来回切换。 再次点击快捷方式没有任何作用。 要返回“所见即所得”视图，您需要浏览菜单。 主工具栏上的一个大块状拨动开关会很大。

是否有人编目/正在维护当前狂野的实施清单？ 我认为它还需要某种“事情做对与错”的参数矩阵。 例如，为相关的填充/边距指定硬编码单位（px）（错误），何时应该将单位留给用户（右侧）等等。

https://editorblockswp.com/library/在目录中有一些内容，但是为了向前推动此问题，似乎需要发生针对Sections / Container的特定操作。

我认为，基本的Container块至少应具有以下选项：

• 背景图片
• 背景颜色
• 能够在图像上覆盖背景色并控制不透明度
• 所有4个方向的填充和边距选项，可以切换每个值分别使用的单位
• 支持左浮动，右浮动，宽和完全对齐
• 以某种方式控制所包含块的最大宽度的能力
• 选择容器使用的html元素的能力

另外，我希望也有以下内容：

• CSS Flex布局选项：可以设置内容的流动方向，从上到下，从左到右，从左到右，从下到上； 以及设置内容的垂直和水平对齐的能力
• 当然，使用flex选项与float对齐方式不兼容，因此该块必须至少具有2种布局模式：standard和flex，否则必须有一个单独的Flex Container块
• 字体大小和颜色选项可为容器中的内容设置默认值，而不必为每个包含的块分别设置默认值

Felix Arntz刚刚发表了一篇有关他的节块实现的博客文章。
我喜欢响应式背景图片。
https://felix-arntz.me/blog/building-a-reusable-gutenberg-section-block/

在过去的几个星期我一直在尝试马克·拉克鲁瓦的执行，这工程确定，但似乎谷登堡3.9.0打破https://github.com/marcusig/gutenberg-section-block

我已经考虑了一段时间了。 出现了如此多的实现这一事实意味着它相当有价值，对于内核而言，提供一致的机制以避免碎片化可能更好。 我主要担心的是围绕用户的“节”块的复杂性。

我建议以一个非常简单的方式开始，只需要一个容器（一个InnerBlocks区域），宽阔且完整的对齐方式以及背景颜色的设置（无图像等，为此我们有“ Cover”功能）。

如果要在5.0中使用它，我们没有太多时间去做。

@mtias如果需要将容器块暴露给最终用户，那么默认情况下，也许每个块都应该具有容器或容器设置。

然后，我们不必担心会告诉最终用户他们需要将某些东西包装在容器中才能使其具有诸如背景图像之类的某些东西。

我认为这实际上是一个好主意，因为这样一来，想要扩展或包装任意块的人将有一个清晰的位置，而最终用户将对其熟悉，因为它在每个块上。

也许“容器设置”可能是“块设置”旁边的选项卡。 对于开发人员来说，这是一个（可扩展的）地方，可以放入（或过滤掉）背景图像设置，宽度设置等内容。

这也将为开发人员提供一个放置更复杂设置的地方，这些设置几乎可以应用于任何块，例如响应/断点控件。

@rchipka从技术上讲，大多数块都包含一个父div，而您要描述的块级别设置就是这些块现在可以实现的功能。

容器的功能并不完全位于单个块中，而是使您可以在容器内部添加其他块，从而创建更复杂的布局，节和页面结构。

@mikemcalister好一点，最终用户仍然需要一种可视化的分组/组织块树的方法。

我认为哲学仍然是一样的。 如果编辑器具有树型块分组机制（即没有“容器块”界面），则任何子块的“容器设置”将镜像该组的设置（即树中的该级别）。

同样，该想法的唯一目的是减少最终用户涉及的步骤数量，因此也减少了学习曲线并增加了可发现性。

我认为主要的问题是，当前的古腾堡（Gutenberg）仅限于标准的帖子/页面内容。 如果没有Section / Container块，我们将无法让用户构建具有全宽部分（具有背景纯色/渐变色或全宽背景图像）的头版，并在其中包含各种内容（希望通过嵌套块）。

一个区段/容器块在这里将是完美的。 即使是基本主题，也可以通过主题/插件扩展更多控件。 我也希望在那里获得更多的对齐设置。 我们已经在与CMB合作，在页面上建立一个伪页面构建器，但我们真的希望Gutenberg可以为所有人提供更灵活的选择。

@JiveDig我认为包括古腾堡团队在内的任何人都不会反对某种块容器机制。

Gutenberg团队（在这种情况下以及许多其他情况下）的主要犹豫是从UI / UX角度将核心接口降低到Squarespace复杂性级别。

为了在内核中实现此功能，主要问题似乎是寻找一种可以在不给最终用户带来额外负担的情况下进行表示的方法。

尽管在我看来，这似乎没什么大不了，但“容器块”通过要求了解其用途和用途，确实给最终用户带来了很小的负担。

这就是为什么我提出“分组”的概念，作为最终用户更类似于“容器”的方法。

最终用户不会考虑将块包装在容器中，而是会考虑将块分组在一起，这似乎更直观。

这样，最终用户无需提前知道任何东西就可以将块分组在一起并将设置应用于该组。

当然，这些“组”在内部将完全像一个Container块一样起作用，它只是一个更加集成和直观的前端界面。

@rchipka一种非常简单的方法，即可以选择一个或多个块，然后单击“更多”菜单中的“将选定的块移入容器块”选项。 这样，块不需要_additional_设置面板。

是的，节块应该在核心。 在HTML中呈现一个简单的div就足够了。 但是，由于实际上可以提供数百个属性，因此我强烈建议应提供的两个属性是CLASS和ID（ID是最不重要的）。 这样，就可以在CSS中设置元素的样式。

-
Wes模式
美国河人的秘密历史
http://peoplesriverhistory.us

从我的苹果发送] [e

2018年10月12日上午8：09，Matias Ventura [email protected]写道：

我已经考虑了一段时间了。 出现了如此多的实现这一事实意味着它相当有价值，对于内核而言，提供一致的机制以避免碎片化可能更好。 我主要担心的是围绕用户的“节”块的复杂性。

我建议非常简单地开始，只需要一个容器和一个背景色设置（没有图像等，为此我们有“封面”）。

如果要在5.0中使用它，我们没有太多时间去做。

-
您收到此消息是因为您已订阅此线程。
直接回复此电子邮件，在GitHub上查看，或使该线程静音。

同样，每个块都应具有设置其类属性的能力。 不论类型。

-
Wes模式
美国河人的秘密历史
http://peoplesriverhistory.us

从我的苹果发送] [e

2018年10月12日上午8：40，Robbie Chipka [email protected]写道：

@mtias如果需要将容器块暴露给最终用户，那么默认情况下，也许每个块都应该具有容器或容器设置。

然后，我们不必担心会告诉最终用户他们需要将某些东西包装在容器中才能使其具有诸如背景图像之类的某些东西。

我认为这实际上是一个好主意，因为这样一来，想要扩展或包装任意块的人将有一个清晰的位置，而最终用户将对其熟悉，因为它在每个块上。

也许“容器设置”可能是“块设置”旁边的选项卡。 对于开发人员来说，这是一个（可扩展的）地方，可以放入（或过滤掉）背景图像设置，宽度设置等内容。

这也将为开发人员提供一个放置更复杂设置的地方，这些设置几乎可以应用于任何块，例如响应/断点控件。

-
您收到此消息是因为您已订阅此线程。
直接回复此电子邮件，在GitHub上查看，或使该线程静音。

我不反对分组方法（只要我可以分配类属性即可），尽管如果您希望以这种方式构建容器，那么如果还有一个容器块也会很令人高兴。

-
Wes模式
美国河人的秘密历史
http://peoplesriverhistory.us

从我的苹果发送] [e

2018年10月12日，上午10:50，克里斯·范·帕滕（Chris Van Patten） [email protected]写道：

@rchipka一种非常简单的方法，即可以选择一个或多个块，然后单击“更多”菜单中的“将选定的块移入容器块”选项。 这样，块不需要其他设置面板。

-
您收到此消息是因为您已订阅此线程。
直接回复此电子邮件，在GitHub上查看，或使该线程静音。

@chrisvanpatten我同意，但是此解决方案不能充分解决@mtias最初向最终用户公开“容器”或“节”概念的担忧。

@mtias提出的问题不是关于将块放入容器的后勤问题，而是与最终用户直观地呈现该界面（而不暴露其他块类型）。

有必要进行“如何将块放入容器中”的讨论。 但是，我不一定认为它对用户来说过于复杂。 许多用户不会使用它，或者至少不会在其主页之外使用它。 我们的许多客户和主题客户都以适合Section部分的视觉术语表达了他们的网站需求。 他们说：“我想要一个大的全幅{bar / area / section / block / panel / span}并有漂亮的图像”，然后是“和{insert content request here} in this section”。 他们从视觉上了解该部分本身（容器）与其内部内容是分开的。

当然，需要弄清楚如何通过UI进行操作，但是希望以上几点是有意义的。

@chrisvanpatten我的上

我在这里争论语义的唯一原因是代表@mtias ，因为首先暴露这些语义的复杂性引起了一个问题。

我喜欢您的建议，但是如果按照我的类比，也许我会更改语义“分组选定的块”。

@rchipka并不是我解释他的评论的方式-我认为它是指所建议的区块将很简单，但本身仍将是一个区块（如果要成为InnerBlocks区域，则必须将其括在其中一个街区）。 也许有一种对插入器隐藏它的方法，只有通过选择多个块并提供“放置在容器中”选项来创建容器块，但是基于我对系统的理解，这仍然意味着一个专用块。

那就是说我很高兴犯错了:)

@JiveDig我非常同意....

但是，古腾堡团队似乎对将这些东西暴露给古腾堡核心的最终用户非常敏感。

这是提出这些论点和提出这些想法的唯一依据。

再说一次，如果是我，我们只会有该死的集装箱街区。

我认为容器块甚至没有意义，因为它会使UI混乱。 我宁愿在Microsoft Word上看到类似“ Section Break”标记的内容。 添加分节符将在检查器中提供一些样式选项，例如该节的类名，背景颜色，文本颜色，阴影，无论是样式定义您的节。 它可以像插入任何块一样插入，也可以像插入任何块一样移动。

@rwrobe这个想法不适用于嵌套容器。

我目前正在与古腾堡（Gutenberg）建立一个站点，并大量使用了marcusig的section block的修改版本。 这是我根据经验中学到的：

• “ Section”是该块的最佳名称。 它的含义对开发人员和最终用户都很清楚，并且避免了通过逻辑上使用<section>块来使标记/选项复杂化。

• 唯一需要的上下文菜单选项是alignnormal / wide / full（实际上我只使用alignfull）。 对齐方式不会影响内部块，除非内部块具有自己的对齐选项，否则内部块将保持在正常对齐范围内。 主要用例是创建一个包含常规对齐文本块的alignfull背景色-这是当前无法实现的非常常见的设计模式。

• 唯一需要侧边栏设置的是背景颜色和背景图像（以及相关的固定/不透明度选项）。 任何其他自定义项都可以使用自定义CSS类进行处理。 （包括Background Image选项还具有将其转换为Cover Block更加有用的版本的副作用。）（但是：如果

• 可用性很简单。 比Columns更容易，Columns已经存在了一段时间。 唯一潜在的问题是，当第一次添加该节时，焦点将切换到该节内的一个段落，因此很难说出该节刚刚添加，直到将鼠标悬停在该节上。 一种可能的解决方案是默认使用浅灰色背景色。

@ZebulanStanphill您在谈论专栏吗？ 我可以看到“节”块完成了垂直分隔内容的工作-甚至可能有一个切换开关来继承前一节的样式，这种切换允许您“嵌套”节内的样式变化。

由于古腾堡以全角块从上到下构建页面的方式，因此像在列中一样，水平组合似乎更困难。

@mikedance我认为这正是需要的。 通过IMO，背景图像选项很重要。 也许此块可以代替Cover Block，尽管命名可能对那些只希望背景图片带有基本文字的人不利。 尽管在功能上存在一些重叠，但是在不增加bg图像支持的情况下，它将占用Section块的大部分用例。

@rwrobe应该注意的是，您可以具有水平布置的块。 Column（注意缺少“ s”）块就是这样。 列块将它们水平放置。 UI可能会在某些方面得到改善，但块不限于全角或垂直放置。

@mikedance

“ Section”是该块的最佳名称。 开发人员和最终用户都清楚其含义，并且避免了逻辑上使用标记/选项而使标记/选项变得复杂的问题。

块。

因为<section>元素具有附加的语义，所以最好是选择使用<div>而不是<section> ，因为在很多情况下，您都希望包装几个块，但从语义上讲，它们不是节的一部分。 实际上，如果您还可以选择使用诸如<aside>或<header>类的元素，那会更好，后者对于在页面构建中为带有背景的标题添加语义特别有用。

另一方面，我认为让Container块具有可用的背景图像选项将非常有用。 当然，与Cover block概念的重叠变得非常明显。 如果使Cover块更灵活，无论如何它基本上都会变成Container块，因此也许不需要Cover块概念？ 容器块可以完成几乎所有的工作。 Cover概念可能只是可重复使用的块模板。

我同意@ZebulanStanphill 。 允许您选择是节，标题，旁边还是div（默认值）的高级配置将很有用。 是的，大多数用户可能不会使用该选项，但是它是支持优秀Web开发的选项。

主题如何整合？ 在这种情况下，主题可以添加“变体”到块中吗
该版块和用户可以直接从中选择一种，并查看所应用的结果样式？
另外，将过滤器或钩子添加到节块中以使操作非常有帮助。
主题添加包装器和样式有时需要的其他元素。

@ZebulanStanphill @wmodes我怀疑包括选择包含元素的选项是否会超越核心开发人员。 这太复杂了。 从某个角度看，<section>元素具有尽可能的语义，因为用户已经通过创建块将其定义为“ Section”。 就像标题一样，由他们负责任地使用它。 但是，如果可以避免使用语义参数，那么使用<div>就不会有问题。

@mikedance同意，我们应该只使用<div> 。 如果需要考虑语义布局，则最好将其作为对容器块的扩展来处理。

@strarsis主题可以使用现有的块样式API向块添加样式。 （默认情况下，核心的Button和Quote块包括多个样式变体。）不幸的是，我找不到有关此功能的任何文档。 （跟踪当前缺少文档有多个问题：https://github.com/WordPress/gutenberg/milestone/500）

@mikedance

从特定的角度来看

element具有尽可能的语义，因为用户已经通过创建块将其定义为“ Section”。

我想我明白你的意思，但我不同意。 在很多情况下，Container块仅用于为一对甚至没有自身背景（或其他样式）选项的块添加背景颜色。 包装在容器中的List块为其赋予背景色并突出显示它并不意味着List位于其自己的部分中。

但是，是的， <div>是最中性的选择，因为它没有语义。 如果核心永远不会有更改HTML元素的选项，那么<div>是最佳选择。

我希望能够选择HTML标记的主要原因是因为它使您可以更轻松地创建语义页面和帖子，而不必求助于Custom HTML块或添加自定义块的插件。 如果您现在想在Gutenberg中使用<section>标签，最终将不得不将所有内容放在Custom HTML块中的该部分中，从而失去对诸如段落，列表等内容的可视化编辑功能否则会的。 也许标签切换器可以显示在检查器的“高级”组下？

@strarsis @ZebulanStanphill

您可以在可扩展性下找到用于在手册中添加Block Styles文档https://wordpress.org/gutenberg/handbook/extensibility/extending-blocks/#block -style-variations

@ajitbohra谢谢！ 我多次检查了该页面，但始终以某种方式缺少该部分。 ：笑：

@ajitbohra ：谢谢！ 是否有一个古腾堡块样式变化的演示。

@strarsis

是的，检查核心button和quote块

https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/button
https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/quote

@strarsis pullquote ， table和separator块也具有样式变化：
https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/pullquote
https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/separator
https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/table

我真的很想看到一些组织障碍。 列的当前问题是创建单个列块来对内容进行分组（例如，出于共享背景色，视频或图像的目的）是不直观的。 我想，理想情况下，希望看到编辑器到达的地方是能够创建内容的阶段，如该编辑器内几乎严格。

暂时将其移至5.1版本，以便我们有更多的时间来定义应如何显示此块。

当我在考虑时...由于此代码和Cover块之间有重叠，如果Cover块更多地是“配置”，那会是什么呢？当您添加该代码块时，它实际上会添加一个带有Heading的预先配置的Section Bock还是嵌套在其中的文本/段落块？

@JiveDig

如果Cover块更像是一种“配置”，那是什么呢？当您添加该块时，它实际上添加了一个预配置的节块，其中嵌套了Heading或Text / Paragraph块？

这听起来很像是将Reusable块作为独立的块插入到我的手中。 也许核心可能会默认包含多个可重用的块模板。 UI必须进行改进，以使作为独立的可重用块的插入变得更加容易。 请参阅＃8403。

是否会有叉子来测试新的段/容器块？ 我有兴趣玩它并帮助测试它。

容器/节块非常有用，我不得不使用
现在，高级古腾堡块集装箱块。
而且重要的是使节/容器块易于看到和选择。

在部分评论中指出，节块对模板开发非常有用。

我们刚刚创建了一个自定义节块来代替它在内核中，并发现了一个问题，如果块保持不变但属性正在变化，则块属性不会更新。

PR＃12406（以上）已解决此问题

是否仍将节块视为5.1（目标时间为2019年2月21日）或更高版本？

我已经编写了一个节块插件，我已经在几个项目中使用了该插件，并希望将其发布为更通用的插件存储库。 它允许设置背景颜色和图像或视频，以及由主题定义的类来格式化innerblocks区域中包含的项目。

在我的用例中，客户端在内部块区域上方具有预定义的（可选）标题和描述字段比较容易，在该区域中它们可以堆叠“项目”，在我的用例中，这是我与另一个块创建的伪部件。类型。 但这很容易成为简单的嵌套节，其中第一个节块包含标题，段落，然后是另一个节块，后者又包含项...

部分意味着gutenberg必须能够正确处理其显示设置为flex并正确呈现直接子级的flex属性。

我用JS渲染我的部分，但是代码中有很多我认为是hack的东西。 用PHP渲染它们简直是小菜一碟...除了将内部块内容发送到PHP仍未解决，不是吗？

由column块实现的Columns是完全不可行的解决方案，因为它需要手动管理column，这不是移动友好的事情，并且使得在集合中添加或删除另一个项目变得非常麻烦。

节中的“列”仅是一个基于伸缩的声明，可以并且应该很容易地成为行，并且不是项目的实际容器，而仅仅是它们如何流动的定义。 请不要破坏与列相似的部分的概念作为其中项目的容器。

应该通过该节中包含的块轻松发现该节中设置的属性。 我应该能够创建一个块类型，该块类型可以智能地响应父级中的选择（如果有父级的话）。 实际上，如果不编写看起来像1400行代码的代码，就很难发现有关父母属性的任何信息。

块是嵌套的，因为这些块的父/子上下文对于如何显示和编辑它们至关重要。 在最坏的情况下，假装上下文不存在是理想主义。

默认情况下，嵌套块应该能够轻松引用父级属性。 如果您的目标是在极少数情况下不在服务器端呈现块，那么上下文信息的传递就已经发生了，否则render()将是return null的荒原，因为它是新的有用的但出现复杂的方块。

（我认为，如果columns块实现了[仍处于实验阶段] CSS columns属性，它将更加有用。它本质上是section一种特殊类型，将所有并通过检查器中定义的列属性使它们流动： column-width ， column-count ， column-rule等）

该块类型（添加块：部分）是否有发布日期？

@JQOz否。下一个市长版本的路线图上都存在此问题，但尚无任何公开的请求要求。 如果您对此功能块有想法或功能，则可以在此处开始添加它们。

你好

我不仅考虑一次。 节应为全角容器。 我们能否仅在部分内的容器中添加一个装订线并使它们像add_theme_support('alignwide')否则就不能工作。

对于一个案例：

https://tech.cornell.edu/

我们有许多不同的部分。 其中一些还活在一个容器中。 有些不是。 但是所有这些都需要一个容器。

古腾堡（Gutenberg）列块太嵌套类了，没有太大帮助。 它应遵循网格结构，并使用parent> child类使它们正常工作。

当我执行https://www.luminasolar.com/开发时，必须将它们包装在template密钥内以保持结构。

我建议，作为页面布局策略的一部分，应该考虑为第三方主题和页面生成器的插件开发人员提供一个挂钩/ API，以添加自己的界面和花哨的内容。

在WPTavern上

具有CoBlocks，Kadence（或您自己拥有的任何东西）可以覆盖的通用标准布局可以解决此问题。 更改插件或主题，至少您的内容仍将保留相同的基本布局。

这基本上是使我在网站上保持基本状态的唯一缺少的功能...

在WPTavern上

具有CoBlocks，Kadence（或您自己拥有的任何东西）可以覆盖的通用标准布局可以解决此问题。 更改插件或主题，至少您的内容仍将保留相同的基本布局。

对对对！ 我相信，灵活的节块是古腾堡最大的缺失功能。 我很高兴听到它计划将来发布的消息，但令我失望的是，目前还没有人对此进行开发。 没有这个，用户仍然无法布局常见的页面格式，主题开发人员仍然需要诉诸专有技术来使它到达用户可以实际构建合理的常见页面布局的位置。

该节块必须位于Gutenberg的核心中（并且可以通过主题进行配置和扩展），以便最终解决能够布置更复杂的页面并且仍然能够切换主题的问题。

当然，作为主题设计师，我将添加自己的调色板，控制边距和填充以匹配主题，格式化图像以使其匹配以及所有这些特定于主题的“设计”事物……但是对于用户应该能够切换到任何WordPress主题，并且至少以基本相同的布局（分组的节，列等）保留其内容，并且可以作为Gutenberg块进行编辑（不必切换到Custom HTML块）。

我有一个section block插件，我的工作版本很早，希望在本周晚些时候进行更新，并将其提交到存储库中。 它允许块的无限嵌套（我想是在合理的范围内，我想是）。 该插件还允许主题或插件根据需要定义自己的节样式，然后可由用户选择。 我计划仅包含一些默认样式，可以根据需要将其禁用。

检查员面板

• _Background._我的插件允许设置背景颜色和/或图像（如果需要），以及用于图像放置，混合，去饱和度甚至覆盖颜色的控件。
• _Dimensions，Padding，Margins._默认情况下，这些部分会自动调整内容的高度，并遵循完整，宽阔和居中的对齐方式，左右对齐为45％。 就是说，我将添加控件以允许指定的宽度和/或高度，在InnerBlocks周围填充并在块周围添加边距。 _但是请参阅下文，了解古腾堡的问题。_
• _Columns ... and Rows._经过大量使用flex的实验后，如果您追求的是基于列的布局，那么对直接子对象使用CSS _grid_是最好的方法。 使用网格是一个切换； 否则，孩子只是正常的障碍物。 （老实说，虽然行是可行的，但它们却增加了编辑界面的复杂性，最好在需要启动新行时在正在处理的行下面添加一个新节来解决。）网格优于flex-即使您只是在做列-因为flex _requires_在容器或子项上设置特定的非百分比高度，这消除了很多灵活性。

移动
使用网格的任何节插件的一个问题是在定义的移动断点处网格会发生什么。 用户（或主题作者）应该能够定义某节从显示3个项目到2个项目再到1个项目的时间。

断点必须能够由主题定义，并且不会真正感觉它们本身属于块本身，因为它增加了另一组检查员选择，您可能希望断点在各个帖子和页面上保持一致。 但是，当使用grid选项时，该块需要了解断点，并且需要允许用户（或主题）指定节布局如何适应这些断点。

我敢肯定有一种优雅的方法可以做到这一点，但是就权宜之计而言，在短期内，我只是允许该块通过config“学习”断点，然后使用逗号分隔的值列表进行定义断点（在此处想象一个屏幕截图）：

Columns:        3,2,1,1
Column 1 width: 70%,50% 

等等（显然，单列是100％，不需要指定）。

主题和插件注意事项
主题（或插件）可以定义具有其所有属性的部分，并向用户隐藏所有这些属性，以免造成混淆，或者主题只能公开他们希望用户能够修改的那些内容（例如，选择的实际背景图像）。 主题或插件还可以使用其样式表来自由指定样式，以添加繁荣……实际上，理论上，它们可以忽略我所有的检查器框，向用户隐藏所有检查器面板，并使用其表完全对样式进行样式设置。 但是，这消除了用户保留主题完整的主题移动的可能性。

用户注意事项
假设该主题发挥得很好，并使用了我的代码块中可用的各种路径来“正确地”定义一个部分及其属性，如果更改了该主题，则所有这些属性都将保留下来，并且如果该主题迄今尚未向用户隐藏，则它们重新暴露。 这是因为“预先设置样式的部分”选择器中的首选是“自定义”，它允许用户修改所有内容，如果先前选择的样式不再可用，则该块将默认使用该样式。 主题所做的不是直接样式表选择的所有设置仍将存在。

这不能保证您的版面能够以看起来不错的方式生存（您可能拥有一个主题，该主题具有超宽版面，并转移到具有窄版面的主题，因此六列版面可能不再是最佳选择...但是它仍将保持原样。用户可以将该布局保存为可重复使用的块。

选择节样式时，如果您从预定义节转到自定义节，则遵循预定义节的检查器属性，因此这是用户修改预定义节的一种方式，而无需在主题或主题中修改该节的定义。插入。

古腾堡问题
因此，古腾堡在以下方面做得很差：

• 需要垂直对接的块，有时可以将其成像。
• 任何形式的显示为flex或grid的调用。 由于编辑器的div汤，您必须在innerblocks包装器上将CSS调用取消设置为grid或flex ，然后在其中一个编辑器块上将其重置。
• 左对齐和右对齐。 我对此提出了一个错误，但是由于Gutenberg并不将左或右块的浮点数限制为仅具有data属性为left或right（或center）的块的直接子代，因此所有后续的嵌套块都向左或向右浮动。对。
• 添加新块通常是一个完全神秘的问题，您将在其中插入它们……您以为自己在本节的底部，想要一个新的内部块，而编辑器将在您的文档底部插入一个新块
• 用于移动块的Gutenberg拖放模型不适用于可能具有水平位置的块

尝试一下
当我在github上放置一个我认为值得关注的版本时，如果有人感兴趣的话，我会在该线程中发布一个链接。 我已经花了几个月的时间，可能还不够好，但这是必须的。

我还要补充一点，我坚信字体字样，标题大小等不是本节块应该直接说的话。 我正在设置的检查器属性对我来说就像保留一个主题的某个部分的“大图”属性所需的基本知识，或者防止删除插件完全使网站外观不堪重负。

@rogerlos您应该考虑看看Blocks 。 他们似乎很好地处理了基于flexbox的列。

我还要补充一点，我坚信字体字样，标题大小等不是本节块应该直接说的话。

我完全赞同这个。 一个例外是区域级别的“字体颜色”设置。 这是必要的，因为字体主要为深色的站点在具有深色背景图像/叠加层的区域内对比度不够。

这是一个演示如何

这些“内容节最大宽度”设置几乎是节块需要考虑的唯一唯一的全局重复（因此是主题定义）模式（除了全局继承的组件限制，如允许的字体颜色，列装订线大小等）。 ）

根据网络代理的经验，在我收到的任何设计中，内容部分的宽度都不超过三个。 这三个宽度之外的任何内容都倾向于是特定于内容的变体，有意以非重复的方式脱离主题的设计模式。

一个好的分区将引导用户使用主题定义的默认设置（遵循原始设计的模式），但有时允许他们以合理的方式脱离这些模式。

为了在所有屏幕尺寸上实施一致且可预测的布局，在我们的设置的根目录级别不允许使用“面向文本”的块。

所有非图像/嵌入块都必须包含在根级别的“部分”（Kadence行布局）中，这将强制执行主题内容的部分宽度，同时仍允许完全自定义的行具有任意数量的列以及全宽背景选项等

容器元素还应允许层叠元素（z索引）。
例如，这允许将视频元素或滑块作为背景或视差效果。

@strarsis好主意。

理想情况下，节块将使用z-index提供可切换的前景/背景编辑模式。

这样，section块本身就不会重新发明背景图像/叠加层内容，而内置的Cover Image块上都提供了这些内容。

背景内容不受宽度限制，因此主题开发人员应具有定义哪些块可以进入节背景的能力。 前景内容的宽度将限制为主题提供的一定数量的最大宽度。

如果用户需要在给定特定内容的情况下偏离默认宽度，则可以选择宽度第二大的部分并相应地填充侧面。

前景内容需要在视觉上超出节的最大宽度的实例应注册为“样式变化” ，以调整该特定块上的负边距。

这样做的原因是，尽管用户可以安全地调整填充值，但我们绝对不希望负边距成为用户定义的内容。

当响应不同的屏幕尺寸，内容部分侧边距，某些断点处的装订线宽度等时，允许在编辑器中定义负空白将是一团糟，因此应与主题/代码紧密结合，并以更高级别的抽象形式公开。最终用户。

关于开发者控制：有一个Mesh插件提供“硬”容器，
应该由主题来强制。
主题有时必须限制可用区域，例如仅限制整个页面的左上角。
古腾堡应该为主题提供一种机制，以便在页面编辑器内设置这些“硬”容器。

@strarsis在我看来，在the_content()区域之外发生的任何事情都与Gutenberg编辑器无关。

这些“区域”是页面模板的一部分，而不是页面内容，应在其他地方处理。

页面内容与页面模板（/布局）

编辑器内的内容/部分应假定周围的布局不存在（在编辑时），而应具有当放置在特定布局内（在前端）时可以正确响应的功能。

如果满足以下条件，则元素是页面模板的一部分（而不是页面内容）：

1. 元素定义或依赖于结构，边界，或定位the_content()区域作为一个整体，并
2. 该元素是重复模式的一部分（即可能在两个或多个永久链接中看到）

一些基于经验的背景

重复模板/布局元素通常特定于自定义帖子类型，并且包括内容英雄，内容侧边栏和内容页脚。

在每种情况下，我发现这些布局元素中的内容都是从位于自定义字段，分类法或其他位于帖子级别而不是块级别的设置中的信息中派生的。

而且，在每种情况下，我都坚定了我的信念，即如果将它们作为古腾堡编辑器中的模块来实现，那么对这些部分进行批量修改或重新样式设置将是一项了不起的任务。

所以最后

Section的定义（以及最终实现）应该只扩展到足以满足主题设计模式对the_content() 。

属于“模板”而不是“内容”的所有内容都应在任何Section块之外和Gutenberg编辑器（目前）之外进行处理。

我希望Gutenberg能够像其他所有人一样内联模板内容，但是我们似乎还没有出现，因此我们一定要确定此Section块，然后才能适当地处理模板。

几天前，我想创建一个基本布局，并需要此布局。 因此，我从安装插件A开始，尝试了一下，发现它是有问题的。 卸载后，找到插件B，已安装，尝试了它的块，它是baaad。 下一个插件C越野车，插件D称它为容器，它是meh。 下一个插件E，F .........
我可以向您保证，如果您要创建页面并编写内容，当前的Gutenberg“生态系统”将非常令人沮丧。
这里的人们一直在说“看看插件X”，“如果您要安装此功能，请安装插件Y”等事实，这清楚地表明人们需要它。 他们不想要它，他们需要它。 现在有十二个插件，它们都有自己的容器/部分/任何您想调用的实现。
我并不是说古腾堡应该在阳光下添加所有功能，但这是基本功能。 它必须在那里。 它不需要所有可能的选择，但基础知识应该存在，并且开发人员可以根据需要进行扩展。
我们已经达到了一个基本容器将有20种不同实现的地步，但没有一个能按应有的方式工作（当然是个人观点）。

作为一种简单的替代方法，我只使用了column块并将列数设置为1（滑块限制在2到6之间，但是您可以在输入字段中输入1）。 之后，您需要在管理员中修复CSS：

//Allow single columns
add_action('admin_head', 'gutenberg_allow_single_columns');
function gutenberg_allow_single_columns() {
    ?>
    <style type="text/css">
    <strong i="6">@media</strong> (min-width: 600px) {
        .wp-block-columns.has-1-columns > .editor-inner-blocks > .editor-block-list__layout > [data-type="core/column"] {
            flex-basis: 100% !important;
            flex-grow: 0; } }
    </style>
    <?php
}

当然，您也需要在前端设置相同的值，但这就是一个主题问题。 我认为，对于基本的容器选项而言，允许单列布局就足够了，这通常还是出于样式目的而需要的。 其他任何事情（如设置背景，z-index，视差等）都应使用imo插件完成。

并且请为主题（开发人员）添加一种方法，以控制使用的包装数量和包装类型。
一些设计只需要一个以上的元素。 当前，我必须对容器元素使用另一个插件，然后使用PHP解析器解析整个内容，以将容器内容包装到额外的包装元素中以进行样式设置。

@strarsis这绝对是从一开始就应该做的事情。

为了对帖子内容进行任何体面的样式设置，每个根级子级必须放置在一致的行/节中。

例如，如果不包装每一行，则很难进行不同宽度的部分（特别是全宽部分）的修改。

我也考虑过PHP解析选项，但是意识到它并不能使内容编辑器对特定内容所在的节类型有任何控制。

相反，在我们的设置中，我们强制Gutenberg编辑器的所有实例对任何帖子/页面/帖子类型仅在根级别允许单个Container块。

根容器块强制执行可以在其中添加的块的有限子集。

为了添加任何文本或非全角块，您需要首先插入Kadence行布局，在这种情况下，它用作我们的主要部分包装器元素。

核心内只需要一个简单的可扩展容器块即可。 关于样式的扩展，应该留给插件/主题开发人员。 它也应该为希望构建自己的容器块的开发人员提供回退转换状态。

我已经测试过的所有提供容器/部分/行的现有第三方插件在内容锁定方面都存在重大问题。 停用这些插件后，将无法再从编辑器内部访问内部块内容，并且将其转换会剥离HTML。 用户应该完全了解的一些内容。

看到：
https://github.com/WordPress/gutenberg/issues/13391#issue -401130412

好。 我已经测试过Gutengerg，这很好，但是是的，它肯定缺少Section部分。
确实，很多块都有其容器，我们可以在其中添加一个css类并为其设置样式。 但是，主要内容是在没有容器的情况下编写的，因此也没有任何类的编写，因此我们无法设置样式。 并且由于主要内容与其他所有块都在同一阶段编写，因此很难将其与其他块进行装箱。

换句话说，我将恢复为经典状态，等到您将“节”提供给我们。

谢谢，问候。

是的，绝对正确。 我认为它比目前正在开发的所有其他模块更为重要。 @youknowriad您能不能给它更高的优先级？

如果有人愿意试一试，它已经在第二阶段的范围https://github.com/WordPress/gutenberg/issues/13113 。

@youknowriad恐怕我不是开发人员。 但是我记得开发已经在进行中。 在发布Wordpress 5之前不久，已经有了一个非常先进的PR。 尚有待澄清的细节，但已准备就绪。 不幸的是我找不到PR。 有谁知道那是哪里？

是的，不用担心，我了解。

这是公关。 https://github.com/WordPress/gutenberg/pull/10562

我想澄清一下，这是一个开源项目，它基于志愿服务。 我可以给出一个全球方向，寻求帮助，但不能分配人员。 人们倾向于不同意。

我重申，如果有开发人员希望更快地看到这种情况并希望提供帮助，欢迎他们参加Core Slack＃core-editor频道（和会议）上的每周会议，并讨论/合作/寻求帮助。

嗯，就是这样！ 大！ 您有一个概览！！！

是的，这是事实，不应该责备。 我只是问自己：没有重要甚至更重要的任务吗？ 如果50个人需要一个RSS块，而1000个人需要一个容器块，那么将整个事情放在更具体的位置将是有意义的。 现在，容器块已不再是奇特的东西。 我认为这是每个设计的基础。

请不要误会：您做得很好。 作为第二阶段负责人，您正在做一流的工作。 这都是关于专注的问题。 在下一次闲聊中我会敬酒... ;-)

再次非常感谢！

谢谢，很高兴澄清。 我个人对他们也同样重视。 阶段2的中间步骤是使用小部件屏幕中的块。 因此，即使人们不要求RSS块，小部件屏幕（这是第2阶段的重要步骤）一旦要使用块，如果人们没有找到他们曾经使用的RSS小部件，他们将抱怨它。

就复杂性而言，这两个任务都是“中等”任务，它们在功能上很重要，但在框架上却不重要。 目前，我个人最优先考虑的是能够实现第2阶段目标（小部件屏幕中的块，post_content之外的编辑器）的框架事物，因为这些概念问题对于尽快进行实验和阐明很重要。

好。 我已经测试过Gutengerg，这很好，但是是的，它肯定缺少Section部分。
确实，很多块都有其容器，我们可以在其中添加一个css类并为其设置样式。 但是，主要内容是在没有容器的情况下编写的，因此也没有任何类的编写，因此我们无法设置样式。 并且由于主要内容与其他所有块都在同一阶段编写，因此很难将其与其他块进行装箱。

换句话说，我将恢复为经典状态，等到您将“节”提供给我们。

谢谢，问候。

在新的块编辑器成形之前，这就是我的立场。 希望这会发生，因为新编辑器有一些不错的方面。

一节非常棒，尽管我缺乏后端开发技能，但我该怎么办？

现在有很多块插件，但是我想要的唯一块是一个节或容器块，所以我很乐意看到其中的一个。

WordPress核心需要包括其自己的块编辑器的节，行，列布局结构的实现，这是标准的，并且可以被所有第三方插件，主题和页面构建器使用。 正如我之前多次提到的，应该提供一个API，以便它们可以添加自己的接口，铃铛和哨子。 关闭任何这些第三方解决方案，您的页面结构将保持不变。

因为存在针对各个方向的节/行的第三方解决方案，但是，一旦开始混入本机核心模块和第三方模块，就会开始看到许多不一致之处，并且模块崩溃并且需要解决。 我并不是要批评那些为布局提供这些解决方案的人所做的努力，而是他们在填充急需的功能。 他们中的许多人都很好，但是总体体验有些不对劲。

我只是为了使核心块编辑器保持简单，允许第三方添加额外的功能和复杂性而已，但是确实需要加强它，否则，很难接受它就不会受到欢迎。

这里最大的问题是谁来照顾它。 难道没有几个开发商有时间和精力去做吗？

对对对！ 我相信，灵活的节块是古腾堡最大的缺失功能。

我什至不敢相信它还不存在...

一种替代方法是允许column块仅包含一列，并且还允许将背景色设置为column。 TA-DA：节块。

好吧，如果对任何人有帮助：一段时间之前，我们为我们的项目写了一个Block部分。 我确信它可以在某些时候美化，但这可能是一个很好的起点：

https://github.com/Impuls-Werbeagentur/impuls-section-block

我将全力以赴地工作。 我可以从下周中开始做起

@chrisvanpatten-看来您以前在此方面取得了很大的进步，只是想检查一下我接受此方法是否还好？

我使用了插件中的一些容器块。 我认为主要要求是支持广泛和完全对齐，浮动以及用于更改容器背景的控件。 旨在以第一个版本发布该版本，将为进一步改进提供良好的基础。

我认为第一个改进是在任何块之外添加了更多包装器。

例如：

<div class="wp-block-paragraph">
  <div class="wp-block-paragraph__container">
    <InnerContent />
  </div>
</div>

目前，许多元素都是直接插入的，这阻止了我们应用样式制作包装器。

<ol>
  <li></li>
</ol>

可以添加包装器：

<div class="wp-block-listing">
  <div class="wp-block-listing__container">
    <ol>
      <li></li>
    </ol>
  </div>
</div>

然后，我们可以应用容器集以使其保持匹配：

// Example
#content > * > * {
  max-width: 1280px;
  padding: 0 20px;
}

@talldan您可以介意此问题-最好是需要Core Container块来提供输入，以便为第3方容器块提供“后退”状态。
https://github.com/WordPress/gutenberg/issues/13391#issue -401130412

节块非常棒，但请仅对其进行语义标记！ 将事物保持在语义HTML结构中将创建最不可知的代码库。
<section>, <article>, <header>比<div class="wp-section">更好。

@talldan对不起，我错过了您的评论，但您对此表示

能够使用文本和媒体块＃10925的焦点也很好。 当然，这只有在您具有图像背景的情况下才有意义。

很好，顺带一提，很多页面构建器也有。 或者至少是这样的：

商定一个焦点选择器在这里会很棒。 它在封面上真的很好用！

考虑到这一点，我已经为节块更新了我的早期模型。 它纯粹用作具有可调背景颜色和图像的容器元素。

预览：

您可以在此处检查原型。

一些附加说明：

• 我认为我们应该启动它时不要启动背景图片，而只能启动背景/文本颜色。 将其推出后，我们接下来可以构建背景图像。 使用现有模式可以快速解决问题，并且仍应涵盖大量用例。
  
  
  
  • 合并第一个版本后，就可以从文本块中弃用背景和文本颜色。 相反，我们可以在段落块中使用内联颜色选项/突出显示选项。 这似乎是一个总体上较好的段落模式。
  
  
• 该块将不包含任何响应设置，因为它始终只是一个容器。 容器内部的内容（如列块）将提供响应行为。

我同意，如果需要，可以使用CSS添加背景图片：+1：

合并第一个版本后，就可以从文本块中弃用背景和文本颜色。 相反，我们可以在段落块中使用内联颜色选项/突出显示选项。 这似乎是一个总体上较好的段落模式。

之所以将section块视为块级颜色的正确位置，原因之一是，否则我们必须回答为什么list，header和其他基本文本块没有这些颜色选项。 而且由于这些块是在块级别进行拆分的，因此您永远无法拥有连续跨越所有这些块的背景图像，而节块可以解决该问题。

弃用这些颜色的方法可能是仅删除它的UI，但让现有块保持原样。

真好！ 具有用于垂直填充的小/中/大类将很有用。

真好！ 具有用于垂直填充的小/中/大类将很有用。

这涉及主题/框架级别，我不确定核心是否可以放置https://cdn.vaadin.com/vaadin-lumo-styles/1.4.1/demo/sizing-and-spacing之类的地方

我认为我们应该在没有背景图片的情况下启动它

完全同意。 推出v1，然后v2可以添加更复杂的功能。

该块将不包含任何响应设置

同意-此区块应尽可能简单且不受限制。

我认为，如果可能，我们应该合并此PR 。

我对这样的东西大吃一惊...作为插件发布：

https://wordpress.org/plugins/magic-block/

请不要再有其他插件会依赖于它。 只需释放该死的块。

@webdados我第二个。

不减少任何人的工作，但我们确实需要在某种程度上将其内置。

特别是在存在这个问题的世界中。

如果找到适合＃13391的解决方案，那么存在无数个容器块实现可能就可以了。

直到新的区块构建器开始为第三方插件可以扩展的布局元素（容器，节，行列）打下标准基础之前，它还是一无是处，并永久地开启和关闭了第三方区块，主题，构建器（那些试图解决布局问题的人），最终导致内容和页面布局丢失。

我们什么时候可以使用此功能？

应该已经是最新版本：
https://github.com/WordPress/gutenberg/releases/tag/v5.5.0

@ksere ：我可能错过了，可能是因为插件v5.5.0的更新日志为空。

到目前为止，还真的在挖掘实现。 我了解它是在5.5版本中发布的，但是我想知道我们何时可以期望添加背景图像（及其位置），背景颜色不透明度等。这是我们应该在2019年下半年之前期待的，还是我们讨论的时间更长？ -比那个？

@nathansnelgrove感谢您的反馈。 小组块肯定有一些改进，这里有两个正在进行中：

• 添加一个内部容器使样式更容易-https: //github.com/WordPress/gutenberg/pull/15210
• 添加编辑器选项以对选定的块进行分组/取消分组-https: //github.com/WordPress/gutenberg/pull/14908

我还没有看到您提到的有关在任何地方跟踪背景图像和不透明度的问题，因此如果您有时间（因为此问题现在已经关闭），可能值得为此创建一个单独的问题。

背景图像/颜色/不透明度来自原始提案-我将为其发布新的杂志。

我刚刚安装了WordPress 5.2.4，但找不到任何“ Section”或“ Group”块。 这里发生了什么？

@patrikhuber ：这将包含在WordPress 5.3中，目前计划于11月12日发布。

我看到@noisysocks ，非常感谢！