Gutenberg: ブロックの追加：セクション

私はこのアイデアが本当に好きです！ また、背景設定があるという事実も気に入っています。

いいね！ ブロックが次の3つの「高度な」設定を許可した場合はどうなりますか。

• 子にシリアル化するクラス名を定義します.child_class, .child_class_1
• オプションの最初の子クラスを追加します.child_class, .child_class_1, .child_class_first
• オプションの最後の子クラスを追加します.child_class, .child_class_n, .child_class_last

:nth-childセレクターは、最後の2つを補うことができるかもしれませんが、すべての子にクラスを追加すると、特定のコンテキストで役立つ可能性があると思います。

このアイデアが大好きです。 背景とテキストの色を変更できる場合は、リンクの色も追加するのが理にかなっているかもしれません。

素晴らしいアイデア。 これは文字通りグーテンベルクエディターに多くの価値を追加します。

多くの問題があるColumnsブロックよりもはるかに優れています。 涼しい！

これは、ネストが利用可能であることを確認したときに最初に作成しようとしたものです。 私のバージョンは、columnsブロックを追加することを想定したことを除いて同様です。

このためのコードはありますか？

このブロックに「列」がある場合は、「列」ブロックを更新する必要があります。 ただし、セクションブロック内で列ブロックを使用して、セクションブロックを列なしに保つことは可能です。

列ブロックを列ブロック内に配置できない限り😉

多くのサイトページは、複数行の列と、多くの場合、より大きな列の中にネストされた列を持つ混合コンテンツを持つセクションに分割されます。 これは簡単な例です：

ベアラッパーのように機能するセクションブロックが最も柔軟だと思います。 （列ブロックをネストできるように！）

今週、新しいサイトプロジェクトを開始しました。 通常は、高度なカスタムフィールドの柔軟なコンテンツレイアウトで構築されますが、グーテンベルクだけを使用してどこまで到達できるかを見ていきます。

ええ、上記の例の@jvisickのような複数列のセクションは珍しいことではないと思います。 ブロックをネストする背景/テキストオプションを備えたコンテナは、最も柔軟なアプローチです。 これで機能する列ブロックができたので、これから列オプションを削除することも検討できます。

このブロックにすべての子ブロックを含む内部コンテナー（div）があると便利です。 次に、このコンテナをmax-widthとmargin-left / right：autoでスタイル設定して、子ブロックを中央に配置し、背景を全幅にします。

より狭いレイアウトにコンテンツが含まれる全角セクションを持つことは、一般的なデザインパターンです。 親セクションブロックにベイクするのではなく、ネストされたブロックによって制御するのが最適かどうか疑問に思っていますか？

セクションブロックは、ページ上のセクションに非常に役立つと思います。列は、セクションブロックにネストできる別個のブロック（現在存在するものなど）である必要があることに同意します。 これは、Columnsブロックとともに、WordPress5.0にマージされるバージョンのGutenbergに含める必要があるものだと思います。 既存のページビルダープラグインを見ると、セクションは（明らかに）列と同様に頻繁に使用されるため、最初のコアリリースにそれらを含めることが私の意見では不可欠です。

（また、columnsブロックが可変幅列やレスポンシブ列などの機能を取得することも重要だと思います。これは、コアエクスペリエンスと、既存のページビルダーがGutenbergから簡単にリベースできるようにするためですがそれは別の問題です。）

もう少し考えてみると、SectionブロックとColumnsブロックを同じものにする方が理にかなっていると思います。 Columnsブロックに少なくとも2つではなく、1つの列のみを持つ機能を追加するだけです。 次に、この提案されたセクションブロックの背景設定を列ブロックに追加します。

Section / Columnsブロックが1つあれば、ネストの量を減らすことができると思います。 現在、提案されているセクションブロックは、実際には背景と幅のオプションがある領域にすぎません。 これらの両方をColumnsブロックに追加できます。また、Columnsブロックで1つの列のみを使用できる場合は、Sectionブロックは不要になります。

さらに、標準幅のコンテンツを含む全角セクションが必要な場合は、別のSection / Columnsブロックを全角に設定されている別のブロックにネストすることで実現できます。 インスペクターの設定を使用して、ブロック全体の幅とは関係なくブロックコンテンツの幅を変更することができます。 これは、Beaver Builderの行/列の動作や、GutenbergでのImageブロックの動作と同様に、表示可能なサイズ変更ハンドルとして追加することもできます。

この結合ブロックと呼ぶものについては、「列」という名前を維持するだけで機能すると思います。これは、人々が探している最も明白な機能だからです。 インスペクターで背景設定を見つけるのは難しいことではありません（そして、別のセクションブロックがあり、それを認識していなかった場合、とにかく何人かの人々が最初に見る場所になると思います）、そして列を使用します単一列コンテナとしてのブロックは、列数を変更するためのスライダーでその方法がかなり明確になるため、見つけるのは難しいことではありません...左端までドラッグするだけです。

SectionブロックとColumnsブロックをマージすることについて考えが変わりました。 列の柔軟性を最大限に高めるには、各列を独自のブロック、つまり列ブロックにするのが最も理にかなっています。 これにより、個々の列の設定を簡単に制御したり、列をある行から別の行にドラッグしたりできます。 もちろん、列は左から右に移動するため（ほとんどのレイアウトシステムで折り返される）、親ブロックは、コンテンツをその水平方向に挿入し、（標準の垂直方向ではなく）折り返すものである必要があります。親ブロックでは、列ブロックのみを挿入できる可能性があります。 このブロックは行になります。 これらの2つのブロックは、Columnsブロックを置き換えます。 ただし、複数の行（多くの場合、列の数が異なる）を同じバックグラウンド/コンテナーに配置する必要がある状況はカバーされていません。これは、Sectionブロックが行うことです。 もちろん、Sectionブロックは、背景、パディング、幅のオプションを備えたコンテナにすぎず、任意のブロックを挿入できます。 また、より複雑なレイアウトの場合は、セクションブロックを列ブロックに挿入できます。

＃6461を参照してください。

私は実際、最低1列のアイデアは悪い解決策ではないと思います。 実際、インスペクターを使用してスライダーの「最小」属性を1に変更し、1つを選択すると、期待どおりに機能します。

ただし、意味的にはセクションブロックの方が理にかなっています。 内部コンテンツ（つまり、フルウィズセクション内の最大幅セクション）は、2つのセクション（フル幅内のコンテンツ幅）をネストすることで実現できます。

背景色のアイデアは素晴らしいですが...多分少し2つの特定のものです。 より一般的なアプローチは、セクションでカスタムクラスを使用することだと思います。 フロントエンドCSSは、それとすべての子を直接キャッチできます。

＃6461での議論の結果、私の行ブロック+列ブロックのアイデアは正しい方法ではないと判断しました。 ＃5351（コメント）のものと同様のレイアウトブロックは、おそらくはるかに混乱が少なく、はるかに柔軟です。 いずれにせよ、Sectionブロックは間違いなく存在するはずであり、WordPress5.0リリースの前に必ず追加する必要があると思います。

背景色のオプションについては、セクションに背景色のオプションを設定するのが理にかなっていると思います。 クラスオプションがあるだけでは少し制限があるようです。 多くの場合、Sectionブロックにネストすることの全体的なポイントは、複数のものが背景を共有することです。 さらに、背景画像やグラデーション背景などの他の背景オプションが実装されている場合は、無地の無地の背景の代わりにそれらが必要になることがよくあります。 ネストされたセクションブロックでは、背景色を1つのブロックに適用することもできます。つまり、段落ブロックの背景色オプションが不要になる場合があります。

2つの別々の幅設定の代わりにセクションブロックをネストすることに関しては、それはうまくいくと思います。 私が抱える最大の懸念は、セクションブロックをネストすることによって追加される余分なパディングの量であり、これはパディングオプションにつながります。

Sectionブロックには、使用するパディングの量をカスタマイズする機能、または少なくともデフォルトのパディングを削除する機能が不可欠だと思います。 もちろん、これにより、別のブロックがネストされている場合に、Sectionブロックをどのように選択するかという疑問が生じます。 この問題は、＃6471やtry/alternate-hover-approachブランチで作業中のものなどの改善によって解決されると思います。

：+1：

特に幅の設定では、一般的な行/コンテナブロックが本当に必要です。

理想的には、「背景色」や「テキスト色」などの他の設定は、すべてのブロックの「追加」設定タブの下にあるべきだと思います（他の一般的に適用可能なCSS設定に加えて）。

レスポンシブに関しては、「レスポンシブ」ブロックを追加する必要があると思います。

背景色とテキストの色の問題は単純です：それはどこで終わるのですか？ すでにこのスレッドだけで、リンクの色を提案している人がいます。 ボーダーの色、太さ、スタイルを変えてみませんか？ 正直に言うと、パディングとマージンが最も理にかなっています。 ドロップシャドウ、背景画像、配置オプション、表示モードについてはどうですか？ フォントのスタイルとサイズ、行の高さと最小の高さ？ 何百ものCSSプロパティがあり、必要なものはデザインによって異なります。

これは、子孫要素を含むすべてのスタイルを設定するために使用できるクラス、またはテーマdivがフックして必要なものを追加できるようにCSSプロパティのフィルター可能なリストのいずれかである必要があります。

@tmdesignedこれは、Webページのスタイル、フォーマット、およびレイアウトに対する機能が完全で直感的なWYSYWIG制御で終わります。 これがグーテンベルクの目標ではありませんか？

グーテンベルクは、新鮮で、よく計画された、最先端の、テンプレート化可能で、拡張可能なWebコンテンツWYSYWIGを世界に提供しています...私たちは今それをどれだけ利用したいかを考えなければなりません。

最終的なアイデアは、CSSの作成、ハッキーなCSSオーバーライドの作成、繰り返しのコンテンツタスクの実行など、現在行っている作業の量を減らすことです。

特に、ターゲットが不十分なクラスやオーバーライドできない属性の場合は、すべてをクラスで定義できるわけではなく、定義する必要もありません。

たとえば、ユーザー定義の数値設定を考えてみましょう。 値ごとにクラスを定義するのは面倒であり、ブロック開発者は値をstyle属性に直接挿入したくなるかもしれません。

ブロックとして存在し、ユーザー定義のCSSスタイルを適用できる場合は、キーと値のペアのテキストボックスのパネルであっても、そのための統一された標準化された手段が理想的です。

必要に応じて、懸念に対処する方法でこれを行うための私の提案された方法を

APIに関するあなたの提案を読みましたが、キーと値のペアを追加できるようにするためのフックの追加について私が言っていたことからそう遠くはありません。

しかし、私の元のポイントはまだ有効だと思います。 私が言ったように、何百ものプロパティがあり、いくつかはより一般的ですが、そのようなリストは急速に成長するでしょう。 そのルートをたどって、Classicに含まれていたのと削除されたTinyMCE機能のような「適切な妥協点」を見つけようとすることができます。 しかし、ここにはもっとたくさんのプロパティがありますので、それは挑戦になるでしょう。

しかし、もっと重要なことは、ブロックレベルの直接スタイルを追加するというアイデアは、1つのブロックだけを考慮するのではなく、少しズームアウトすると機能しなくなります。 1ページまたは複数ページに同様のブロックが複数ある場合、それらすべての値を再入力する必要はありません。 CSSクラスのような抽象化が必要になります。

個々のブロックレベルのスタイリングを許可する（または奨励する）ことは、再利用できないため理想的ではありません。 すべてがクラスに抽象化されるべきではないが、CSSは理由のために開発されたものであり、それほど早く風に流されるべきではないと言うのは正しいです。

@tmdesignedフィードバックに感謝します。 私は混乱を理解していると思うので、明確にしようと思います。

目標は、CSSクラスの量を排除または削減することではありません。

目標は、非常に具体的には、ユーザー定義のブロックスタイリング設定を単一のUIまたは少なくとも単一のAPIに統合する

Web開発者、ブロック開発者、テーマ開発者はすべて、ブロックのスタイルを設定するためのCSSコードを引き続き作成し、開発者がスタイルを設定できるように、ブロックにはクラス、属性、およびIDがあります。

それらは現在とまったく同じクラスを持ち、現在とまったく同じレイアウトを持ちます。

だが

ブロック開発者が、ユーザーが構成できる/構成

これにより、Webページコンテンツの一般的なスタイルベースの構成をプログラム以外で制御する場合に、（開発者とユーザーの両方に）単一の共通インターフェイスが作成されます。

これにより、ユーザーと開発者の両方が、ブロックスタイルを表示、追加、削除、変更、およびオーバーライドする単一の一貫した手段を提供します。これらは、結局のところ、すべて単純なCSSプロパティに要約されます。

このスレッドで多くのノイズを発生させて申し訳ありません。 おそらく、関連する問題にさらに議論を移すべきです。

編集注：

抽象化についてのポイントに取り組むのを忘れました。

ユーザーがまったく同じスタイルをまったく同じブロックに2回適用する必要があるのは、CSSクラス（そのブロック）のユーザー定義のスタイル設定を破棄する

言い換えると、ユーザー定義のスタイル設定は、ユーザーがブロックを好みに合わせてカスタマイズするための一貫したメカニズムを提供します。これは、（あるべき姿で）1回限りのユニークなものか、1ページごとに100回か、どのように構造を選択するかです。それはまだ完全にあなた次第です。

私たちはほとんど同意すると思います。 最初の投稿での私の提案は、コントロールを追加/削除するためのフックを持つことでした。 私はスタイルのブロックレベルのユーザーカスタマイズに反対していません。リストが指数関数的に増加することなく、「汎用セクションブロックでデフォルトで持つ価値のあるもの」を選択するのは難しいです。 特に他のコントロールの追加を許可する場合は、最小限の数で十分です。 いずれにせよ、マージンとパディングがセクションブロックの背景色よりも普遍的に役立つわけではないことに驚いています。

FWIW、生成されたクラスを出力にするというあなたのアイデアが好きなので、！importantを使用しなくてもオーバーライド可能です。

@rchipka @tmdesignedこれは2週間以上前のことですが、別の号でこれらの詳細のいくつかをハッシュ化することに興味がありますか？ このコンボにもっと目を向けることは有益だと思います。

以前の会話に基づいて、このブロックをもう一度見てみました。

私のアイデアを共有する最も簡単な方法は、プロトタイプを使用することです： https ：

いくつかの注意：

• 簡単な投票に基づく： https ：//wordpress.slack.com/archives/C02QB2JS7/p1527283199000343名前を_Section_から_Container_に変更しました。
• @jvisickで示されているように、特定のセクション内で列のレイアウトを組み合わせて使用​​するのが妥当であるため、列の設定を削除しました。
• 背景色に加えて、背景画像のサポートを追加しました。 設定は、コアの既存の背景画像機能に基づいています。
• コンテナブロックをコンテナブロックにネストさせる必要がありますか？

@melchoyceよさそうだ！

私が見たい優れた機能の1つは、ブロックのHTML要素を<aside> 、 <div> 、および<section>間で切り替えるためのインスペクターでの選択です。

私の意見では、コンテナをネストする機能は間違いなく許可されるべきです。 上記で提案されたHTML要素の提案を使用して、単一のセマンティックセクション内に異なる色の領域がある場合に役立つだけでなく、単一のブロックに背景がないときに背景を与えたい場合にも役立ちます。背景色オプション自体。

一部のデザインではかなり人気があるように見えるため、もう1つの優れた機能はグラデーションの背景です。

コンテナをネストできるようにするための@ melchoyce + 1。

@SuperGeniusZebがHTML要素を変更できることも私の心の

@jvisickええ、それは私が考えていたものでした。 Beaver BuilderとElementorはどちらも、行/セクションにそのような設定があります。

@melchoyceコンテナは無限にネスト可能である必要があると思います。 これにより、ユーザーは他のコンテナーを含む任意のブロックの周りにカスタムクラス（またはカスタムCSS）をラップできます。

汎用コンテナブロックにネスト制限を追加する理由はありません。

セマンティックHTML要素の価値は理解していますが、その機能をプラグインに委任して上級ユーザー向けのオプションとして利用できるようにする方法があるのではないかと思いますが、平均的なユーザーはそれについて考える必要はありません。 それを追加した瞬間に、機能を提供する責任だけでなく、セマンティックの意味についてユーザーを教育する責任も負います…これはしばしば非常に状況に応じたものです。

@chriskmnds良い点。 コンテナタグを設定するのは間違った場所だと思います。

コンテナブロックは、意味的な意味のない汎用コンテナとして機能する必要があります。

<aside>コンテンツがテンプレートの一部になり、 <section>別の部分になるように、セマンティックな意味は（将来の）ブロックテンプレート機能によって提供される必要があります。

このようにして、ユーザーは、セマンティックな意味に影響を与えることなく、コンテンツをコンテナー内で（任意の深さレベルで）好きなように整理できます。

HTML要素を交換できることは、ほとんどの人にとって少し進んでいるように思われ、おそらくグーテンベルクの基本設定には属していないことに同意します。

<aside>コンテンツがテンプレートの一部になり、 <section>別の部分になるように、セマンティックな意味は（将来の）ブロックテンプレート機能によって提供される必要があります。

これは間違いなく探索するのに良いでしょう。

基本UXをシンプルに保つためのポイントに同意しませんが、 <section> 、 <nav> 、 <header>などのラッピング要素をどこに追加しますか？ 本質的にラッパー要素である汎用コンテナーブロックは、自然な選択のように思われます。 これは、これらの各ケースで重複ブロックよりも優先される場合があります。 デフォルトは<div>で、ユーザーは必要な場合を除いて設定に触れる必要はありません。

HTML要素のオプションが、テーマまたはプラグインからサポートされている要素の配列を設定できる、alignwide / full設定と同様に機能した場合はどうなりますか？

@jvisick理想的には、これらの折り返し要素は、ページ/投稿の「ブロックレイアウトテンプレート」を使用して作成されます。

ブロックレイアウトテンプレートを使用すると、デフォルトのコンテナブロックの束を設定し、コンテナブロックの生成されたタグ名を（コードで）設定することができます。

@rchipkaコンテンツを管理するための事前定義された領域をユーザーに提供するレイアウトテンプレートを使用することで、どこから来ているのかわかります。 定義されていないページのページビルダーとしてグーテンベルクを使用し、エディターから使用するHTML要素のタイプを設定できると便利な観点からこれをさらに検討しています。 どちらのシナリオも重要だと思います。

そうは言っても、コンテナブロックの最初の実行にはHTML要素の設定は必要ないという@melchoyceに同意しますが、次の「ページビルダー」フェーズで検討する価値があると思います。

セクションは基本的に1列です。まあ、列です。

3.0.0 Columns（beta）ブロックでは、スライダーに1列を使用できないことに気づきました。

Columnブロックのみを使用して、これらの実装を組み合わせる方がよいかどうかはわかりません。 欠点は何ですか？

追加するのが良いことの1つは、コンテナ（セクション）を全幅にするか、含めるかを切り替えることです。 含まれている場合は、テーマ（＃5650）で設定されているcontent_widthを尊重する必要があります。含まれていない場合は、全幅である必要があります。 そこにあるページビルダーの大多数がこの機能を持っていると思います。

うん、それは私の最後のモックアップのクイックツールバーに含まれています。

@melchoyceセクション/コンテナブロック自体は全幅である必要があるが、セクション/コンテナブロック内のコンテンツはそうではない場合があることに注意してください。 これはどのように処理されますか？

デフォルトでは、コンテナー自体が全幅になる可能性があると考えましたが、コンテナー内でネイティブに全幅をサポートしないコンテンツ（画像/カバーブロックなど）は、エディターの幅に制限されます。

@melchoyce私があなたを正しく理解していると仮定すると、Containerブロックの幅コントロールはコンテナの背景にのみ影響し、コンテンツには影響しないということですか？ それは理にかなっている。 明確にしていただきありがとうございます。 ：+1：

うん、それは私が考えていることです！

議論されたかどうかはわかりませんが、セクションは「セクション」HTML要素であり、「記事」、「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タグを選択するためのドロップダウンはまだ良い考えだと思います。 過度に類似したブロックを大量に作成することなく、 <aside>や<section>などのセマンティックHTML要素を統合する最も簡単な方法のように感じます。

@nbrummerstedt初期の基本的な実装は素晴らしいですが、ブロックはコンテナブロックと<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 );

これがWordPress5.0のマイルストーン@mtiasから削除されたのはなぜですか？ これは、それがいかに便利で単純であるかという理由だけで、おそらく最初のリリースに組み込まれるべきもののようです。 多くのブロックには、Containerブロックを使用することが想定されているため、バックグラウンド設定がありません。 このブロックを実装するのはそれほど難しいことではありませんか？ なぜこれをWordPress5.0以降のリリースに戻す必要があるのか​​わかりません。

別の注意点として、私は最近Oxygenをチェックしていて、そのフレックスボックスベースのレイアウトシステムに感銘を受けました。 Containerブロックがこれらの機能のいくつかを実装した場合はどうなりますか？ 私はそれが本当に強力であり、Columnsブロック以外のレイアウトを持つための代替方法を提供する可能性があると思います...多分それはColumnsブロックを不要にする可能性さえありますか？

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

これをチェックすることを強くお勧めします。 実は、酸素をじっくりと見てみることをお勧めします。 他のすべてのページビルダープラグインとは大きく異なり、グーテンベルクが使用できる優れたアイデアがたくさんあると思います。

私は間違いなく同意します。これは5.0リリースである必要があります。列ブロックを使用するハッキーなソリューションを回避するには、コンテナーが必要です。

また、このブロックは遅かれ早かれ利用可能になるはずだと思います。 多くのWordPress開発機関は、グーテンベルクで構築する前にこのブロックを待っています。

@ dingo-dと@ericvaloisええ、レスポンシブ列、等しくない幅の列、コンテナブロックの3つが不足しているため、ブログ投稿以外にグーテンベルクを使用することは控えています。

Oxygenが行うことを採用するContainerブロックについて前に述べたことを詳しく説明すると、Containerブロックには、ネストされたブロックの流れの方向をデフォルトの垂直から水平に変更するオプションがあると思います。 Oxygenのような垂直方向と水平方向の配置オプションもあります。 これらは非常に強力です。特に、ほとんどのページビルダープラグインで許可されているように、これらのオプションをレスポンシブに変更する機能と組み合わせると効果的です。

もちろん、Flexboxベースの配置/レイアウトを使用するコンテナブロックでは、フロート配置されたブロックを直接ネストできないという注目すべき問題があります。 しかし、それには簡単な解決策があると思います。コンテナに標準のCSS display: blockレイアウトまたはFlexboxレイアウトのいずれかを使用させる機能を追加します。 標準のdisplay: blockモードがデフォルトになります。これは、ルートドキュメントが使用するモードだからです。 フレックスボックス表示モードを有効にすると、すべての適切な配置オプションがインスペクターに表示されます。 また、2つのレイアウトモードにインスペクターで異なる名前を付けて、よりユーザーフレンドリーにすることもできます。 しかし、あなたがそれらを何と呼ぶか​​はわかりません。 多分「標準」と「柔軟」？

コンテナブロックがフロートをサポートするモードまたはより優れた配置/レイアウトオプションを備えたモードのいずれかを使用できるようにすると、非常に便利です。 必要に応じて、コンテナブロックをネストして両方の種類のレイアウトを使用できます。 これをContainerブロックが持つ可能性のある他の機能（バックグラウンドオプション、カスタムHTMLブロックに頼らずに意味を追加するためにHTMLタグを選択する機能など）に追加すると、Containerブロックが最も重要なものの1つになります。コアWordPressの便利なブロック。

特に、2つのレイアウトモードを持つContainerブロックが機能が多すぎるように聞こえる場合（そして私はそれが問題になるとは思わない）、2つの別々のブロックが存在する可能性があります。

• フロートをサポートするが、すべての高度な配置/レイアウトオプションを備えていない標準のコンテナブロック
• Flexboxレイアウトを使用し、すべてのきちんとしたオプションを提供するAdvanced Container（またはAdvancedLayoutまたはFlexibleLayoutなどと呼ばれるもの）ブロック

このOxygenのドキュメントビデオをチェックして、レイアウトシステムがどのように機能するかを確認することをお勧めします。 それは本当に印象的です：

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

ここには、グーテンベルクを非常に強力にする可能性がたくさんあると思います。 もちろん、最初の実装では、Containerブロックにバックグラウンドオプション、使用するHTML要素を変更する機能、およびコンテナーを全幅にするオプション（ただし、コンテナー内のコンテンツは含まない）のみが含まれると思います。 たぶん、バックグラウンドオプションだけでも。

実際には、CSSを介してブロックのグループのスタイルを設定するのが簡単になるため、オプションがないContainerブロックがあるだけでも便利です。

5.0以降で停止する場合と同じように、グーテンベルクについて考えることが重要です。 これは非常に便利なブロックであり、調査されますが、フェーズ1では、編集に重点を置く必要はありません。 プロジェクトが単純な編集を超えてレイアウトに拡張される場合、そこで解決策が必要になることは間違いありません。 これが作成されないとは誰も言っていません。それは、エディターとは何か、そしてフェーズ2に入るものを優先することの問題です。

しかし、大多数の人々は、投稿を書くためではなく、レイアウトの目的でグーテンベルクを使用しています。

人々はワード文書のような投稿を書くことに慣れているので、投稿ページでグーテンベルクを無効にしています。

しかし、大多数の人々は、投稿を書くためではなく、レイアウトの目的でグーテンベルクを使用しています。

この仮定の基礎となるデータソースはどれですか？

私はベオグラードでのWCEUの間に何人かの人々と話をしました、彼らは皆、グーテンベルクで投稿を書くのは奇妙だと思うので、投稿でそれを無効にしていることに同意しています。

@ dingo-dが見たものとは対照的に、私は投稿にグーテンベルクのみを使用します。 私は実際、グーテンベルクでのポストメイキングの経験がクラシックエディターよりもはるかに優れていると感じています。 部分的にはよりモジュール化された性質とコンテキストコントロールのため、そして部分的にはどこにでも挿入された迷惑な目に見えない<p>タグがないためです。 それはいつも私を悩ませました。

Gutenbergを使用してページを作成するには、Containerブロック（オプションのないものでも）と適切なColumnsブロック（またはその他のレイアウトブロック）が必要です。 Columnsブロックはある種の基本的な応答性を獲得しているようです（＃6048を参照）。つまり、より多くのコンテキストでGutenbergを使用することを妨げているのはContainerブロックがないことです。

Containerブロックは明らかにある時点で（おそらくWordPress 5.1までに）追加されることは知っていますが、WordPress5.0がリリースされる前に追加する必要があると強く信じています。 投稿を作成する場合でも、コンテナーは、セマンティクスを追加するための<aside> （HTML要素選択ドロップダウン機能がある場合）のようなものに役立つ可能性があります。 現在、セマンティクスを追加するために別のHTML要素で何かをラップする場合は、カスタムHTMLブロックを使用する必要があります。つまり、そのカスタムHTMLブロック内の段落の段落ブロックの機能を利用することはできません。そのカスタムHTMLブロック内の画像のImageブロックの機能など。

@karmatosed

これが作成されないとは誰も言っていません。それは、エディターとは何か、そしてフェーズ2に入るものを優先することの問題です。

私の意見では、Containerブロックは絶対にフェーズ1に属するものです。

私が奇妙だと思うのは、ColumnsブロックがWordPress 5.0に組み込まれるように見えることです（おそらくまだその「（ベータ）」ラベルが付いていますが、Containerブロックはそうではない可能性がありますか？現在の焦点が書き込みにあると想定されている場合投稿の場合、なぜColumnsブロックが追加されたのに、Containerブロックが追加されなかったのですか？私の意見では、Containerブロックは、Columnsブロックよりも投稿のコンテキストではるかに便利です。もちろん、Containerブロックには多くの利点があります。ページ構築のコンテキストも同様です。

ContainerブロックがWordPress5.0に組み込まれない場合、それは5.1まで出てこないことを意味します。これにより、ほとんどの人が数か月間使用できなくなります。 グーテンベルクを成功させたいのですが、WordPress 5.1まで、Containerブロックのような基本的なもののリリースを差し控える理由はないと感じています。 第一印象を良くするために、WordPress4.9.8コールアウトの前に追加することをお勧めします。

人々が提案したすべての機能を備えているとは思いません。 その単なる存在は、Columnsスライダーを手動で1に設定してColumnsブロックを使用するというかなりハッキーなソリューションを除いて、現在カバーされていない多くの一般的なユースケースを解決するのに十分です。そして、背景色オプションのような1つのオプションがあります。それはずっと便利になるでしょう。

これはクールで便利なブロックであることに同意しますが、これは常にプロジェクトのフェーズ2に関するものであり、本当に集中する必要があります。そうしないと、出荷されません。 ネストされたブロックインフラストラクチャを構築したのは、抽象化を正しく行い、カスタムレイアウトブロックを構築できるようにすることが重要であったため、このような実際のコアブロックはそれほど重要ではありません。 ネストされた子UIを一般的に正しく取得することに焦点が当てられています（モルモットとして_Columns_を使用）。

この問題も5か月間公開されており、色、幅、ブロックの方向とネストされた列、カバー画像との重なりなどを含む確実な実装提案はありません。現状では、私たちが行う必要のある他の汎用作業や、WordPressでの差し迫った「試行」通知よりも優先しないでください。 これは、特に誰かがコードで提案を提案したい場合に、それがカットを行わないという意味ではありません。

また、私にとって最大の問題は、実装にコミットするための理想的なユーザーエクスペリエンスが何であるかが明確ではないことです（ここでの会話からのみわかります）。 HTMLタグを公開するようなことは、通常のユーザーにとっては明らかに複雑で直感的ではないように思われます。 コンテナの概念そのものは、それが最良のレイアウト抽象化であるかどうかを確認するために、より広範なテストが必要なものです。これも、次のフォーカスフェーズで理解する必要があります。 このようなブロックがスタイルを内部の任意のブロックにカスケードする方法についても不明な点がいくつかあります。コアブロックを説明するのは比較的簡単ですが、任意のブロックを説明することはできません。

同時に、カスタムブロックを提供したい開発者は、 InnerBlocksを使用して、必要なタグと一緒に（上記のスニペットのように）簡単にまとめてユーザーフィードバックを収集する必要があります。 したがって、そのようなブロックを持つ（そしてそれを維持する必要がある）コアへの圧力は少なくなります。 とはいえ、PRを介して誰でも気軽に提案を行い、ユーザーによるテストの支援をしてください。 5.0で削除される可能性があるという考えで、プラグインに「実験的」として追加しても問題ありません。

@SuperGeniusZeb酸素はかなりクールです！ これらの調査のいくつかについては、間違いなく検討する必要があります。

好奇心から、テーマとプラグインが独自のセクションブロックを追加し、ユーザーがプラグインを非アクティブ化するか、テーマを変更するとどうなりますか？ 何らかのフォールバックがありますか？ または、ユーザーはコンテンツを失いますか？

@tomusborneそのような状況についての問題があります：＃7811。

ああ！ これがここで議論されているとは知りませんでした。 そこで、必要に応じてプラグインも作成しました。

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

私はこのスレッドを見ていて、それに入るすべての考えに感謝しています。 最近、 Atomic Blocksプラグインで、余白、パディング、コンテナー幅、背景画像と色のオプションを備えたコンテナーブロックをリリースしました。 これがお役に立てば幸いです。コアブロックが後日到着するまで、私たちを引き留めることができます。

この問題に続いて..列の構造やその他のオプションを選択できるブロック「コンテナ」を作成しました。
「Columns」ブロックを改善したり、コアに新しいブロックを作成したりするのに役立つ場合は、 https ：

@MarieCometそれは

おそらく、Containerブロックを使用して個々のColumnブロックを置き換えることもできますが、Sectionでは意味をなさないColumnに必要なオプションがいくつかある場合があります。

HTMLとCSSを使用してレイアウトを作成する将来は、ほとんどのページビルダーのように常に列を使用するのではなく、CSS FlexとGridを使用して、より少ない<div>を使用してコンテンツを表示することであることに気付きました。マークアップとより柔​​軟でクリーンなスタイリングがあります。 私は主に酸素がしていることに触発されています。 私はこのコメントで酸素について話しました。

この問題は、現在、columnsブロックを置き換えることではありません。 この問題が何であるか、セクションブロックに焦点を合わせ続けることが重要です。

@karmatosed @melchoyceそういえば、この問題の名前を変更するべきではありませんか？ <section>要素との混同を避けるために、これを「セクション」と呼ぶのをやめ、「コンテナ」に切り替えました。

名前は決まっていないので、少しそのままにしておいても大丈夫です。

現在、グーテンベルクのエディターと一緒にテーマを実装しようとしています。

Webサイトのレイアウトには、段落やリストなどのいくつかの項目を含む、さまざまな背景を持つさまざまな領域があります。 これは、レイアウトとナビゲーションを目的としています。 セクション/コンテナブロックはアンカーとして機能する必要があります/一意のCSSIDを持っている必要があります。

独自のブロックを作成して「グーテンベルクにハッキング」せずにこのテーマを完成させることはできません。 代わりに、これをコアブロックとして使用して実行できます。 プレーンテキストと単純なレイアウトのためだけにグーテンベルクエディタを使用することはありません。将来のレイアウト/デザインは、グーテンベルクのテーマとブロックシステムと一緒に行う必要があります。

このトピックがより優先されることを心から願ってい

Columnsブロックと組み合わせて、あらゆる場所でサードパーティのコンテナブロック（Atomic Blocksなど）を使用しています。 それらは非常に便利で、私の最も人気のあるブロックです。 将来的に、またはアドオンとして検討されるのは奇妙だと思います。 コアにある必要があります。

それ以外の場合は、HTMLビューでコンテナーを手動で作成するだけですが、HTMLビューはクリックするだけの余分なメニューであるため、煩わしく非効率的です。 HTMLビューのキーボードショートカットがあります... shift +オプション+ cmd + M ...そうです。 そして、それは前後にさえ切り替わりません。 ショートカットをもう一度押しても何も起こりません。 WYSIWYGビューに戻るには、メニューを確認する必要があります。 メインツールバーの大きな分厚いトグルスイッチは壮大です。

誰かが現在実際に実装のリストをカタログ化/維持していますか？ また、「正しいことと間違ったこと」のある種のパラメータマトリックスも必要だと思います。 たとえば、関連するパディング/マージンにハードコードされた単位（px）を指定する（間違っている）場合、単位はおそらくユーザーに任せておく必要がある場合（右）などです。

https://editorblockswp.com/library/にはカタログにいくつかあり

私の意見では、基本的なコンテナブロックには少なくとも次のオプションがあります。

• 背景画像
• 背景色
• 画像に背景色をオーバーレイし、不透明度を制御する機能
• 4方向すべてのパディングとマージンのオプション、値ごとに個別に使用される単位を切り替える機能
• 左フロート、右フロート、ワイド、およびフルアライメントのサポート
• 含まれているブロックの最大幅を何らかの方法で制御する機能
• コンテナで使用されるhtml要素を選択する機能

さらに、私は次のものも持っていることを望みます：

• CSSフレックスレイアウトオプション：コンテンツの流れの方向を上下から左右、左右、上下に設定する機能。 コンテンツの垂直方向と水平方向の配置を設定する機能
• もちろん、フレックスオプションの使用はフロート配置と互換性がないため、ブロックには少なくとも2つのレイアウトモード（標準とフレックス）が必要です。そうでない場合は、別のフレックスコンテナブロックが必要になります。
• コンテナ内のコンテンツのデフォルトを設定し、含まれるすべてのブロックに個別に設定する必要をなくすためのフォントサイズと色のオプション

Felix Arntzは、セクションブロックの実装に関するブログ投稿を公開しました。
レスポンシブな背景画像が好きです。
https://felix-arntz.me/blog/building-a-reusable-gutenberg-section-block/

過去数週間、私はMarc Lacroixの実装を実験してきましたが、これは問題なく動作しますが、gutenberg 3.9.0https 。

私はこれについてしばらく考えていました。 非常に多くの実装が出現したという事実は、それが非常に価値があることを意味し、断片化を回避するためにコアが一貫したメカニズムを提供する方がおそらく良いでしょう。 私の主な心配事は、ユーザーにとっての「セクション」ブロックの複雑さです。

コンテナ（単一のInnerBlocks領域）、幅広で完全な配置、背景色の設定（画像なしなど、そのための「カバー」があります）を使用して、非常に単純なものから始めることを提案します。

5.0で必要な場合は、それを行う時間があまりありません。

@mtiasコンテナブロックをエンドユーザーに公開することが懸念される場合は、おそらくすべてのブロックにデフォルトでコンテナまたはコンテナ設定が必要です。

そうすれば、背景画像などの特定のものを含めるために、コンテナで何かをラップする必要があることをエンドユーザーに教えることを心配する必要はありません。

これは実際には良い考えだと思います。そうすれば、任意のブロックを拡張またはラップしたい人はそれを行う明確な場所があり、エンドユーザーはすべてのブロックにあるのでそれに慣れているでしょう。

おそらく、「コンテナ設定」は「ブロック設定」の横のタブである可能性があります。 これは、開発者が背景画像の設定や幅の設定などをドロップイン（またはフィルターで除外）するための（拡張可能な）場所になります。

これにより、開発者は、レスポンシブ/ブレークポイントコントロールなど、ほとんどすべてのブロックに適用できるより複雑な設定を配置することもできます。

@rchipka技術的には、ほとんどのブロックは親divでラップされており、説明しているブロックレベルの設定の種類は、ブロックが現在実行できるものです。

コンテナーの能力は、正確に1つのブロックにあるわけではなく、コンテナー内に他のブロックを追加して、より複雑なレイアウト、セクション、およびページ構造を作成することができます。

@mikemcalister良い点ですが、エンドユーザーはブロックツリーを視覚的にグループ化/整理する方法が必要です。

哲学は同じだと思います。 エディターにツリースタイルのブロックグループ化メカニズムがある場合（つまり、「コンテナーブロック」インターフェイスがない場合）、子ブロックの「コンテナー設定」は、そのグループの設定（つまり、ツリー内のそのレベル）を反映します。

繰り返しになりますが、このアイデアの唯一のポイントは、エンドユーザーに関係するステップの数を減らし、したがって学習曲線を減らし、発見可能性を高めることです。

主な問題は、現在グーテンベルクが標準の投稿/ページコンテンツに非常に限定されていることだと思います。 Section / Containerブロックがないと、ユーザーが全幅のセクション（背景の単色/グラデーションカラーまたは全幅の背景画像）を含むフロントページを作成して、すべての種類のコンテンツを内部に（できればネストされたブロックを介して）作成する方法がありません。

セクション/コンテナブロックはここで完璧です。 テーマ/プラグインによるより多くのコントロールで拡張できる基本的なものですら。 そこにもいくつかの配置設定を取得したいと思います。 私たちはすでにCMBで何かを行って、ページ上に疑似ページビルダーを配置していますが、グーテンベルクがこれをすべての人にとってより柔軟にすることができることを本当に望んでいます。

@JiveDigグーテンベルクチームを含め、ある種のブロックコンテナメカニズムに反対している人はいないと思います。

グーテンベルクチーム（この場合および他の多くのチーム）からの主な躊躇は、UI / UXの観点からコアインターフェイスをSquarespaceレベルの複雑さに抑えることです。

これをコアに実装するための主要な問題は、エンドユーザーに余分な負担をかけずにこれを表現できる方法を見つけることだと思われます。

私の意見では、大したことではないように思えますが、「コンテナブロック」は、その目的と使用法の知識を必要とするため、エンドユーザーに小さな負担をかけます。

そのため、エンドユーザーにとって「コンテナ」のより親しみやすいアナロジーとして「グループ化」の概念を提案しました。

エンドユーザーは、ブロックをコンテナーにラップすることを考えず、代わりにブロックをグループ化することを考えます。これは、より直感的に思えます。

このように、エンドユーザーは、ブロックをグループ化してそのグループに設定を適用するために、事前に何も知る必要がありません。

もちろん、これらの「グループ」は、内部的にはContainerブロックとまったく同じように機能し、より統合された直感的なフロントエンドインターフェイスです。

@rchipkaアプローチする非常に簡単な方法は、1つ以上のブロックを選択し、[詳細]メニューの[選択したブロックをコンテナブロックに移動する]オプションをクリックすることです。 この方法では、ブロックに_additional_設定パネルは必要ありません。

はい、セクションブロックはコアにある必要があります。 HTMLで単純なdivをレンダリングするだけで十分です。 ただし、提供できる属性は文字通り何百もあるため、代わりに、提供する必要がある2つの属性はCLASSとID（IDが最も重要度が低い）であることを強くお勧めします。 そうすれば、要素をCSSで適切な場所にスタイル設定できます。

-
ウェスモード
アメリカの川の人々の秘密の歴史
http://peoplesriverhistory.us

私のアップルから送られました] [e

2018年10月12日には、8:09で、マティアスベンチュラの[email protected]は書きました：

私はこれについてしばらく考えていました。 非常に多くの実装が出現したという事実は、それが非常に価値があることを意味し、断片化を回避するためにコアが一貫したメカニズムを提供する方がおそらく良いでしょう。 私の主な心配事は、ユーザーにとっての「セクション」ブロックの複雑さです。

コンテナと背景色の設定（画像なしなど—そのための「カバー」があります）だけで、非常に単純なものから始めることを提案します。

5.0で必要な場合は、それを行う時間があまりありません。

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信するか、GitHubで表示するか、スレッドをミュートしてください。

この場合も、すべてのブロックにクラス属性を設定する機能が必要です。 タイプに関係なく。

-
ウェスモード
アメリカの川の人々の秘密の歴史
http://peoplesriverhistory.us

私のアップルから送られました] [e

2018年10月12日には、8:40で、ロビーChipkaの[email protected]は書きました：

@mtiasコンテナブロックをエンドユーザーに公開することが懸念される場合は、おそらくすべてのブロックにデフォルトでコンテナまたはコンテナ設定が必要です。

そうすれば、背景画像などの特定のものを含めるために、コンテナで何かをラップする必要があることをエンドユーザーに教えることを心配する必要はありません。

これは実際には良い考えだと思います。そうすれば、任意のブロックを拡張またはラップしたい人はそれを行う明確な場所があり、エンドユーザーはすべてのブロックにあるのでそれに慣れているでしょう。

おそらく、「コンテナ設定」は「ブロック設定」の横のタブである可能性があります。 これは、開発者が背景画像の設定や幅の設定などをドロップイン（またはフィルターで除外）するための（拡張可能な）場所になります。

これにより、開発者は、レスポンシブ/ブレークポイントコントロールなど、ほとんどすべてのブロックに適用できるより複雑な設定を配置することもできます。

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信するか、GitHubで表示するか、スレッドをミュートしてください。

（クラス属性を割り当てることができる限り）グループ化方法に反対しませんが、そのように構築したい場合は、コンテナーブロックもあれば嬉しいです。

-
ウェスモード
アメリカの川の人々の秘密の歴史
http://peoplesriverhistory.us

私のアップルから送られました] [e

2018年10月12日には、午前10時50分AMで、クリス・ヴァン・パッテンの[email protected]は書きました：

@rchipkaアプローチする非常に簡単な方法は、1つ以上のブロックを選択し、[詳細]メニューの[選択したブロックをコンテナブロックに移動する]オプションをクリックすることです。 この方法では、ブロックに追加の設定パネルは必要ありません。

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信するか、GitHubで表示するか、スレッドをミュートしてください。

@chrisvanpatten同意しますが、このソリューションは、コンテナまたはセクションの概念をエンドユーザーに公開するという@mtiasの当初の懸念に適切に対処していません。

@mtiasによって提起された問題は、ブロックをコンテナーに配置するロジスティクスに関するものではなく、エンドユーザーにそのインターフェイスを直感的に提示することです（追加のブロックタイプを公開することなく）。

「ブロックをコンテナに入れる方法」の議論が必要です。 ただし、必ずしもユーザーにとって複雑すぎるとは限りません。 多くのユーザーはそれを使用しないか、少なくともホームページの外では使用しません。 私たちのクライアントやテーマの顧客の多くは、セクションブロックにふさわしい視覚的な用語でウェブサイトの要望/ニーズを表現しています。 彼らは、「きれいな画像で大きな全幅の{bar / area / section / block / panel / span}が欲しい」、続いて「そして{そのセクションにコンテンツリクエストを挿入}」のようなことを言います。 セクション自体（コンテナ）がその中のコンテンツから分離されていることを視覚的に理解します。

確かに、UIを介してそれを行う方法を理解する必要がありますが、うまくいけば、上記の点が理にかなっています。

@chrisvanpatten私の前のステートメントは、ブロックタイプのセマンティクスのみに基づいています。

ここでセマンティクスについて議論している唯一の理由は、 @ mtiasに代わってです。これは、そもそもこれらのセマンティクスを公開する複雑さで問題が発生したためです。

私はあなたの提案が好きですが、私のアナロジーに従っているのであれば、おそらく「選択されたブロックをグループ化する」というセマンティクスを変更するでしょう。

@rchipkaそれは私が彼のコメントを解釈した方法ではありません-提案されたブロックは単純である必要がありますが、それ自体がブロックである必要があることを意味すると解釈しました（InnerBlocks領域の場合は、で囲む必要がありますブロック）。 おそらく、インサーターからそれを非表示にし、複数のブロックを選択して「コンテナーに配置」オプションを提供することによってコンテナーブロックのみを作成する方法がありますが、それでも専用ブロックを意味するシステムの私の理解に基づいています。

それは私が間違っていることをとても嬉しく思っていると言った:)

@JiveDig私は非常に同意します...。

ただし、グーテンベルクチームは、グーテンベルクコアのエンドユーザーにこれらのものを公開することに非常に敏感であるようです。

これは、これらの議論を提起し、これらのアイデアを提示するための私の唯一の基礎です。

繰り返しになりますが、もしそれが私なら、私たちはただいまいましいコンテナブロックを持っているでしょう。

コンテナブロックはUIが乱雑になるため、実際には意味がないと思います。 MicrosoftWordにインラインで表示される「SectionBreak」マーカーのようなものが見たいです。 セクション区切りを追加すると、セクションのクラス名、背景色、テキストの色、ドロップシャドウなど、セクションをスタイル的に定義するものが何であれ、インスペクターにいくつかのスタイルオプションが提供されます。 他のブロックと同じように挿入し、他のブロックと同じように移動できます。

@rwrobeそのアイデアは、ネストされたコンテナでは機能しません。

私は現在、グーテンベルクでサイトを構築しており、マーカシグのセクションブロックの修正バージョンを

• 「セクション」はブロックの最良の名前です。 その意味は開発者とエンドユーザーには明らかであり、<section>ブロックを論理的に使用することでマークアップ/オプションの複雑さを回避します。

• 必要なコンテキストメニューオプションは、alignnormal / wide / fullだけです（実際、私はalignfullのみを使用しています）。 位置合わせは、独自の位置合わせオプションがない限り、通常の位置合わせ内にとどまる内部ブロックには影響しません。 主な使用例は、通常の位置合わせされたテキストブロックを含むalignfull背景色を作成することでした。これは、現在は不可能な非常に一般的なデザインパターンです。

• 必要なサイドバーブロック設定は、背景色と背景画像（関連する固定/不透明度オプションを含む）のみです。 追加のカスタマイズは、カスタムCSSクラスで処理できます。 （[背景画像]オプションを含めると、これがカバーブロックのはるかに便利なバージョンに変わるという副作用もあります。）（ただし、 @ mtiasが正しい場合は、[背景色]オプションのみを含めることで会話を回避すると、解消されます。ドアが速くなれば、私はそれですべてです。）

• 使いやすさはシンプルです。 しばらく前から存在しているColumnsよりも簡単です。 唯一の潜在的な問題は、セクションが最初に追加されたときに、フォーカスがセクション内の段落に切り替えられることです。そのため、マウスオーバーするまで、セクションが追加されたばかりであることがわかりにくい場合があります。 そのための1つの可能な解決策は、デフォルトで明るい灰色の背景色にすることです。

@ZebulanStanphillコラムについて話しているのですか？ 垂直方向に分離されたコンテンツに対して「セクション」ブロックが機能しているのを見ることができました。前のセクションからスタイルを継承するためのトグルもあり、セクション内にスタイルのバリエーションを「ネスト」することができます。

グーテンベルクが全幅のブロックで上から下にページを構築する方法のために、列のように、水平方向の構成は必然的に難しいようです。

@mikedanceまさにそれが必要だと思います。 IMOでは、背景画像のオプションが重要になります。 おそらく、このブロックがカバーブロックに置き換わる可能性がありますが、名前は、基本的なテキストが上にある背景画像のみが必要な人にとってはわかりにくい場合があります。 機能にはいくつかの重複がありますが、bgイメージのサポートを追加せずに、Sectionブロックのユースケースの大部分を取り除くことになります。

@rwrobe水平に配置されたブロックを持つことができることに注意してください。 列（「s」がないことに注意してください）ブロックはまさに​​それです。 Columnsブロックは、それらを水平に配置します。 UIはおそらく一部の領域で改善される可能性がありますが、ブロックは全幅または垂直にレイアウトされていることに限定されません。

@mikedance

「セクション」はブロックの最良の名前です。 その意味は開発者とエンドユーザーにとって明らかであり、論理的に使用することでマークアップ/オプションの複雑さを回避します

ブロック。

<section>要素にはセマンティクスが付加されているため、多くの場合、ラップする必要があるため、 <section>ではなく<div>を使用することを選択できれば最適です。いくつかのブロックですが、それらは意味的にセクションの一部ではありません。 実際、 <aside>や<header>などの要素を使用することもできれば、さらに良いでしょう。後者は、ページ作成の背景付き見出しにセマンティクスを追加する場合に特に便利です。

別の注意点として、Containerブロックで利用可能な背景画像オプションがあると非常に便利だと思います。 もちろん、カバーブロックの概念との重複は非常に明白になります。 Coverブロックをより柔軟にすると、基本的にはContainerブロックになります。したがって、Coverブロックの概念は存在する必要がないのではないでしょうか。 コンテナブロックは、それが行うほとんどすべてのことを行うことができます。 カバーのコンセプトは、再利用可能なブロックテンプレートである可能性があります。

@ZebulanStanphill同意します。 セクション、ヘッダー、脇、div（デフォルト）のいずれであるかを選択できる高度な構成が役立ちます。 はい、ほとんどのユーザーはそのオプションを使用しないかもしれませんが、それは優れたWeb開発をサポートするオプションです。

テーマはどのように統合できますか？ この場合、テーマはブロックに「バリエーション」を追加できますか？
セクションブロックとユーザーは、ilstから直接1つを選択して、適用された結果のスタイルを確認できますか？
また、セクションブロックにフィルターまたはフックを追加して許可することも非常に役立つ場合があります。
テーマは、スタイリングに必要なラッパーやその他の要素を追加します。

@ZebulanStanphill @wmodes含まれている要素を選択するオプションを含めると、コア開発者を

@mikedance同意しました。おそらく<div>使用する必要があります。 セマンティックレイアウトが問題になる場合は、コンテナブロックの拡張として処理するのが最適です。

@strarsisテーマは、既存のブロックスタイルAPIを使用して、ブロックにスタイルを追加できます。 （コアのButtonおよびQuoteブロックには、デフォルトで複数のスタイルバリアントが含まれています。）残念ながら、この機能に関するドキュメントは見つかりません。 （現在のドキュメントの不足を追跡する複数の問題があります：https：//github.com/WordPress/gutenberg/milestone/500）

@mikedance

ある観点から

要素は、ユーザーがブロックを作成することによってすでに「セクション」として定義しているため、可能な限りセマンティックです。

私はあなたが言っていることを理解していると思いますが、私は同意しません。 多くの場合、Containerブロックは、独自の背景（または他のスタイル）オプションを持たないカップルまたは1つのブロックに背景色を追加するために使用されます。 コンテナにラップされて背景色を付けて強調表示するリストブロックは、リストが独自のセクションにあることを意味するものではありません。

しかし、ええ、 <div>は意味的な意味がないため、最も中立的な選択です。 HTML要素を変更するオプションがコアにない場合は、 <div>が最適です。

HTMLタグを選択できるようにしたい主な理由は、カスタムHTMLブロックやカスタムブロックを追加するプラグインに頼ることなく、セマンティックページや投稿をより簡単に作成できるためです。 今すぐグーテンベルクで<section>タグを使用したい場合は、そのセクションのすべてをカスタムHTMLブロックに配置する必要があり、段落やリストなどの視覚的な編集機能が失われます。そうでなければ持っているでしょう。 おそらく、タグスイッチャーはインスペクターのAd​​vancedグループの下に表示される可能性がありますか？

@strarsis @ZebulanStanphill

ハンドブックの拡張性https://wordpress.org/gutenberg/handbook/extensibility/extending-blocks/#block-style-variationsでBlock Stylesを追加するためのドキュメントを見つけることができます。

@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ブロックがより「構成」であった場合、そのブロックを追加すると、見出し付きの事前構成されたセクションボックが実際に追加されます。またはその中にネストされたテキスト/段落ブロック？

@JiveDig

Coverブロックが「構成」であり、そのブロックを追加すると、HeadingまたはText / Paragraphブロックがネストされた事前構成済みのSectionボックが実際に追加されるとしたらどうでしょうか。

これは、再利用可能なブロックがスタンドアロンブロックとして挿入されているように聞こえます。 おそらくコアには、そのようなデフォルトでいくつかの再利用可能なブロックテンプレートを含めることができます。 再利用可能なブロックをスタンドアロンとして簡単に挿入できるようにするには、UIを改善する必要があります。 ＃8403を参照してください。

新しいセクション/コンテナブロックをテストするためのフォークはありますか？ 私はそれで遊んで、それをテストするのを手伝うことに興味があります。

コンテナ/セクションブロックは非常に便利です、私は使用しなければなりませんでした
高度なグーテンベルクブロックコンテナブロックは今のところ。
また、セクション/コンテナブロックを簡単に表示して選択できるようにすることが重要です。

セクションブロックはテンプレート開発に非常に役立つことに注意するためのコメントの一部。

これがコアにある代わりにカスタムセクションブロックを作成したところ、ブロックが同じままで属性が変更されている場合にブロック属性が更新されないという問題が見つかりました。

これはPR＃12406（上記）で解決されました

セクションブロックは5.1（2019年2月21日を対象）以降も検討されていますか？

私はセクションブロックプラグインを作成しました。これはいくつかのプロジェクトで使用しており、プラグインリポジトリに対してより一般的なものとしてリリースしたいと考えています。 これにより、背景色と画像またはビデオを設定したり、テーマによって定義されたクラスを設定して、 innerblocks領域に含まれるアイテムをフォーマットしたりできます。

私のユースケースでは、クライアントが「アイテム」を積み上げることができる内部ブロック領域の上に事前定義された（オプションの）タイトルと説明フィールドを置く方が簡単でした。私のユースケースでは、別のブロックで作成した疑似ウィジェットでした。タイプ。 しかし、これは単純なネストされたセクションである可能性があり、最初のセクションブロックには見出し、段落、次に別のセクションブロックが含まれ、次にアイテムが含まれていました...

セクションとは、gutenbergが、表示がflex設定されているセクションを適切に処理し、直接の子のflexプロパティを適切にレンダリングできる必要があることを意味します。

セクションをJSでレンダリングしますが、コードにはハックと見なされるものがいくつかあります。 PHPでそれらをレンダリングするのは簡単なことです...内部ブロックのコンテンツをPHPに送信することを除いて、まだ解決されていませんね。

列ブロックによって実装される列は、列を手動でキュレーションする必要があるため、完全に実行不可能なソリューションです。これはモバイルフレンドリーなものではなく、セット内の別のアイテムの追加または削除が非常に面倒でイライラします。

セクション内の「列」は単なるフレックスベースの宣言であり、同じように簡単に行である可能性があり、そうあるべきであり、アイテムの実際のコンテナではなく、単にそれらがどのように流れるかの定義です。 セクションの概念を、その中のアイテムのコンテナとして列に似たもので傷つけないでください。

セクションに設定されたプロパティは、そのセクションに含まれるブロックによって簡単に検出される必要があります。 親があれば、親で行われた選択にスマートな方法で応答できるブロックタイプを作成できるはずです。 現状では、1400行のコードのように見えるものを書かずに、親の属性について何かを発見することは困難です。

ブロックは、それらのブロックの親/子コンテキストがそれらの表示および編集方法に不可欠であるため、ネストされています。 文脈が存在しないふりをすることは、最悪の場合理想主義です。

ネストされたブロックは、親属性を簡単に、デフォルトで参照できる必要があります。 まれな場合を除いてサーバー側でブロックをレンダリングしないことが目標である場合、コンテキスト情報の受け渡しが_発生する必要があります_。そうでない場合、 render()は新しくて便利なreturn null荒れ地になります。しかし、複雑なブロックが表示されます。

（ columnsブロックは、[まだ実験的な] CSS columnsプロパティを実装した方が便利だと思います。基本的には、すべてを取得する特別なタイプのsectionになります。その中のアイテムと、インスペクターで定義された列プロパティを介してそれらをフローします： column-width 、 column-count 、 column-ruleなど）

このブロックタイプ（ブロックの追加：セクション）のリリース日はありますか？

@JQOzいいえ。この問題は次の市長バージョンのロードマップにありますが、人々が取り組んでいるオープンプルリクエストはありません。 このブロックのアイデアや機能がある場合は、ここから追加を開始できます。

こんにちは、

一度だけではなく考えます。 セクションは全幅のコンテナである必要があります。 セクション内のコンテナにガターを追加して、 add_theme_support('alignwide')ように機能させ続けることはできますか？

ケースの場合：

https://tech.cornell.edu/

さまざまなセクションがあります。 それらのいくつかはコンテナの中で生きています。 一部はそうではありません。 しかし、それらすべてに単一のコンテナーが必要です。

グーテンベルクの列ブロックは入れ子クラスが多すぎてあまり役に立ちません。 グリッド構造に従い、親>子クラスを使用して機能を維持する必要があります。

https://www.luminasolar.com/開発を行うときは、構造を維持するために、それらをtemplateキーでラップする必要があります。

ページレイアウトの戦略の一環として、サードパーティのテーマとページビルダーのプラグイン開発者に独自のインターフェイスとベルとホイッスルを追加するためのフック/ APIを提供することを検討することをお勧めします。

WPTavernでこの項目に認識し始め、レイアウトの特定のブロックにロックインして、長年問題となっている問題の古い栗に戻り始めているようです：テーマまたはページビルダーとレイアウトの変更消えるか、新しいブロックエディタの場合は、明らかに、石に設定されているために変更できないコードです。

CoBlocks、Kadence（またはあなたが自分で持っているもの）がオーバーライドできる共通の標準レイアウトを持つことで、これを解決できます。 プラグインまたはテーマを変更しても、少なくともコンテンツは同じ基本レイアウトを維持します。

これは基本的に、私のサイトでelementorを維持するための唯一の不足している機能です...

WPTavernでこの項目に認識し始め、レイアウトの特定のブロックにロックインして、長年問題となっている問題の古い栗に戻り始めているようです：テーマまたはページビルダーとレイアウトの変更消えるか、新しいブロックエディタの場合は、明らかに、石に設定されているために変更できないコードです。

CoBlocks、Kadence（またはあなたが自分で持っているもの）がオーバーライドできる共通の標準レイアウトを持つことで、これを解決できます。 プラグインまたはテーマを変更しても、少なくともコンテンツは同じ基本レイアウトを維持します。

はいはいはい！ 柔軟なセクションブロックは、グーテンベルクに欠けている最大の機能の1つだと思います。 将来のリリースの計画を聞いてうれしいですが、現在誰もそれに取り組んでいないことに失望しています。 これがないと、ユーザーは一般的なページフォーマットをレイアウトできず、テーマ開発者は、ユーザーが実際に合理的に一般的なページレイアウトを作成できる場所に到達するために、独自の手法に頼る必要があります。

より複雑なページをレイアウトし、それでもテーマを切り替えることができるという問題を最終的に解決するために、セクションブロックはコアグーテンベルクにある必要があります（そしてテーマによって構成可能で拡張可能です）。

確かに、テーマデザイナーとして、独自のカラーパレットを追加し、テーマに一致するように余白とパディングを制御し、一致するように画像をフォーマットし、これらすべての種類のテーマ固有の「デザイン」のものを追加します...しかしユーザー任意のWordPressテーマに切り替えて、少なくともそのコンテンツを基本的に同じレイアウト（グループ化されたセクション、列など）で保存し、Gutenbergブロックとして編集できる必要があります（カスタムHTMLブロックに切り替える必要はありません）。

私はセクションブロックプラグインを持っていますが、これは初期のバージョンで動作しており、今週後半に更新してリポジトリに送信したいと考えています。 これにより、ブロックを無限にネストできます（つまり、当然のことながら、私は推測します）。 プラグインを使用すると、テーマまたはプラグインで必要に応じて独自のセクションスタイルを定義することもできます。これは、ユーザーが選択できます。 必要に応じて、テーマによって無効にできるデフォルトのスタイルをいくつか含める予定です。

インスペクターパネル

• _Background._私のプラグインでは、必要に応じて背景色や画像を設定でき、画像の配置、ブレンド、彩度の低下、さらには色のオーバーレイを制御できます。
• _寸法、パディング、マージン。_デフォルトでは、セクションはコンテンツに対して自動高さであり、左右が45％で、完全、幅、中央の配置に従います。 そうは言っても、指定された幅や高さを許可するコントロールを追加し、InnerBlocksの周りにパディングし、ブロックの周りにマージンを追加します。 _しかし、グーテンベルクの問題については以下を参照してください。_
• _Columns ... and Rows._ flexを使用して多くの実験を行った後、列ベースのレイアウトを使用する場合は、直接の子用のCSS_grid_が最適な方法です。 グリッドの使用はトグルです。 それ以外の場合、子は通常のブロックです。 （正直なところ、行は実行可能ですが、編集インターフェイスに多くの複雑さが加わります。これは、新しい行を開始する必要があるときに、作業中のセクションの下に新しいセクションを追加することで最も適切に処理できる可能性があります。）グリッドはflexは、列を作成しているだけの場合でも、コンテナまたは子アイテムのいずれかに設定する特定の非パーセンテージの高さを必要とするため、柔軟性が大幅に低下します。

モバイル
グリッドを使用するセクションプラグインの問題の1つは、定義されたモバイルブレークポイントでグリッドに何が起こるかです。 ユーザー（またはテーマの作成者）は、セクションが3つのアイテムの表示から2つのアイテム、1つのアイテムの表示に移行するタイミングを定義できる必要があります。

ブレークポイントはテーマによって定義できる必要があり、ブロック自体に属しているようには感じられません。これは、インスペクターの選択肢がさらに増えるためです。ブレークポイントは、投稿やページ間で一貫している必要があります。 。 ただし、グリッドオプションを使用する場合、ブロックはブレークポイントについて認識している必要があり、ユーザー（またはテーマ）がセクションレイアウトをブレークポイントにどのように適応させるかを指定できるようにする必要があります。

これを行うためのエレガントな方法があると確信していますが、便宜上、ブロックがconfigを介してブレークポイントについて「学習」できるようにし、定義済みの値のコンマ区切りリストを使用するだけです。ブレークポイント（ここでスクリーンショットを想像してください）：

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

など（明らかに、単一の列は100％であり、指定する必要はありません）。

テーマとプラグインに関する考慮事項
テーマ（またはプラグイン）は、すべての属性を含むセクションを定義し、それらの属性をすべてユーザーから非表示にして、混乱を避けることができます。または、テーマは、ユーザーが変更できるようにしたいものだけを公開できます。 （たとえば、選択した実際の背景画像）。 テーマやプラグインは、スタイルシートを使用してセクションタイプを指定することで、自由に繁栄を追加することもできます...実際、理論的には、すべてのインスペクターボックスを無視し、すべてのインスペクターパネルをユーザーから非表示にし、シートで完全にスタイルを設定できます。 ただし、これにより、ユーザーがテーマを生き残る可能性がなくなります。セクションをそのままにして移動します。

ユーザーに関する考慮事項
テーマがうまく機能し、ブロック内で利用可能なさまざまなパスを使用してセクションとその属性を「適切に」定義したと仮定すると、テーマが変更された場合、これらの属性はすべて存続し、これまでテーマがユーザーからそれらを隠していた場合は、再露出。 これは、「事前スタイル設定セクション」セレクターの最上位の選択肢が「カスタム」であるためです。これにより、ユーザーはすべてを変更できます。これは、以前に選択したスタイルが使用できなくなった場合にブロックがデフォルトで使用するものです。 直接のスタイルシートの選択ではなかったテーマが行ったすべての設定は、引き続き存在します。

これは、セクションが見栄えのする方法で存続することを保証するものではありません（非常に広いレイアウトのテーマがあり、狭いレイアウトのテーマに移動した可能性があるため、6列のセクションはもはや最良の選択ではない可能性があります...ただし、そのまま残ります。ユーザーは、そのレイアウトを再利用可能なブロックとして保存できます。

セクションスタイルを選択するときに、事前定義されたセクションからカスタムに移行すると、事前定義されたセクションのインスペクター属性が続くため、ユーザーは、テーマ内のそのセクションの定義を変更することなく、事前定義されたセクションを変更できます。プラグイン。

グーテンベルクの問題
したがって、グーテンベルクは次のことをうまく行いません。

• 垂直方向に突き合わせる必要があるブロック。セクションをイメージできる場合があります。
• フレックスまたはグリッドとして何かを表示するためのあらゆる種類の呼び出し。 エディターのdivスープのため、CSS呼び出しをinnerblocksラッパーのgridまたはflexに設定解除し、エディターブロックの1つでリセットする必要があります。
• 左揃えと右揃え。 私はこれについてバグを提出しましたが、グーテンベルクは左または右のブロックのフロートを左または右（または中央）のデータ属性を持つブロックの直接の子のみに制限しないため、後続のすべてのネストされたブロックは左または右にフロートされます正しい。
• 新しいブロックを追加することは、多くの場合、それらが挿入される完全な謎です...あなたはあなたがあなたのセクションの一番下にいて、新しい内部ブロックを望んでいると思います、そして代わりにエディターはあなたのドキュメントの一番下にそれを挿入します
• ブロックを移動するためのグーテンベルクのドラッグアンドドロップモデルは、水平位置を持つことができるブロックでは確実に機能しません

試してみる
誰かが興味を持っているなら、私が見る価値があると思うバージョンをgithubにドロップするときに、このスレッドにリンクを投稿します。 私はこれに数ヶ月を費やしました、そしてそれはおそらくまだ素晴らしいものではありませんが、それは何かです。

フォントフェースや見出しのサイズなどは、セクションブロックが直接言うべきものではないと強く信じていることを付け加えておきます。 私が設定しているインスペクター属性は、テーマ間でセクションの「全体像」属性を保持するため、またはプラグインの削除によってサイトの外観が完全に損なわれるのを防ぐために必要な基本のように感じます。

あなたが見服用を検討してください@rogerlos Kadenceブロックを。 彼らはフレックスボックスベースの列をかなりうまく処理しているようです。

フォントフェースや見出しのサイズなどは、セクションブロックが直接言うべきものではないと強く信じていることを付け加えておきます。

私はこれに完全に同意します。 唯一の例外は、セクションレベルの「フォントの色」設定です。 これが必要なのは、フォントが主に暗いサイトでは、背景画像/オーバーレイが暗いセクション内で十分なコントラストが得られないためです。

これは、Kadenceの行レイアウトブロックがブロックツールバーの[整列モード]を再利用して、3つの異なる内部コンテンツ幅、調整可能な列幅、調整可能な上下の行マージン、および背景とテキストの色設定を可能にする方法の

これらの「コンテンツセクションの最大幅」設定は、セクションブロックが考慮する必要があるほぼ唯一のグローバルに繰り返される（したがってテーマ定義の）パターンです（許可されるフォントの色、列のガターサイズなど、グローバルに継承されるコンポーネントの制限を除く）。 ）

Webエージェンシーの経験から、私が受け取ったデザインには3つ以下の異なるコンテンツセクション幅があります。 これらの3つの幅以外のものは、コンテンツ固有のバリエーションである傾向があり、テーマのデザインパターンから意図的に繰り返されない方法で切り離されます。

優れたセクションブロックは、ユーザーをテーマ定義のデフォルト（元の​​デザインのパターンに従う）に向けますが、場合によっては、合理的な方法でそれらのパターンから脱却できるようにします。

すべての画面サイズで一貫性のある予測可能なレイアウトを適用するために、セットアップのルートレベルで「テキスト指向」のブロックを使用することはできません。

すべての非画像/埋め込みブロックは、ルートレベルの「セクション」（Kadence行レイアウト）に含まれている必要があります。これにより、テーマのコンテンツセクション幅が適用され、任意の数の列と全幅の背景を持つ完全にカスタマイズ可能な行が許可されます。オプションなど。

コンテナ要素は、スタッキング用のレイヤー要素（z-index）も許可する必要があります。
これにより、たとえば、背景または視差効果としてのビデオ要素またはスライダーが可能になります。

@strarsisいい考えです。

理想的には、セクションブロックはz-indexを使用して、切り替え可能な前景/背景編集モードを提供します。

このように、セクションブロック自体は、組み込みのCoverImageブロックですべて利用できる背景画像/オーバーレイのものを再発明しません。

背景コンテンツは幅に制約されないため、テーマ開発者は、セクションの背景に入れることができるブロックを定義する機能を備えている必要があります。 フォアグラウンドコンテンツの幅は、テーマによって提供される特定の最大幅に制限されます。

ユーザーが特定のコンテンツビットを指定してデフォルトの幅から外れる必要がある場合は、次に大きい幅のセクションを選択し、それに応じて側面を埋めることができます。

前景コンテンツがセクションの最大幅の外側に視覚的に分割される必要があるインスタンスは、その特定のブロックの負のマージンを調整するスタイルバリエーションとして登録する必要があります。

この理由は、ユーザーはパディング値をかなり安全に調整できますが、負のマージンをユーザー定義のものにしたくないためです。

エディター内で負のマージンの定義を許可すると、さまざまな画面サイズ、コンテンツセクションのサイドパディング、特定のブレークポイントでのガター幅などに応答するときに混乱するため、テーマ/コードと緊密に結合して、より高いレベルの抽象化として公開する必要がありますエンドユーザーに。

開発者コントロールに関して：「ハード」コンテナを提供するMeshプラグインがあります。
テーマによって強制されるべきです。
テーマは、ページ全体の左上隅だけのように、使用可能な領域を制約する必要がある場合があります。
グーテンベルクは、テーマがページエディタ内にこれらの「ハード」コンテナを設定するためのメカニズムを提供する必要があります。

@strarsis私の意見では、 the_content()領域の外で発生することは、Gutenbergエディターの内部では何の関係もありません。

これらの「領域」はページテンプレートの一部であり、ページコンテンツではないため、他の場所で処理する必要があります。

ページコンテンツとページテンプレート（/レイアウト）

エディタ内のコンテンツ/セクションは、周囲のレイアウトが存在しないことを前提とし（編集中）、代わりに特定のレイアウト内（フロントエンド）に配置されたときに適切に応答するように装備する必要があります。

次の場合、要素はページテンプレートの一部です（ページコンテンツではありません）。

1. 要素は、全体としてthe_content()領域の構造化、境界、または配置を定義または依存し、
2. 要素は繰り返しパターンの一部です（つまり、2つ以上のパーマリンクで見られる可能性があります）

いくつかの経験に基づく背景

繰り返されるテンプレート/レイアウト要素は通常、カスタム投稿タイプに固有であり、コンテンツヒーロー、コンテンツサイドバー、コンテンツフッターが含まれます。

いずれの場合も、これらのレイアウト要素内のコンテンツは、カスタムフィールド、分類法、またはブロックレベルではなく投稿レベルにあるその他の設定にある情報から十分に派生していることがわかりました。

そして、すべての場合において、これらのセクションがグーテンベルクエディター内のブロックとして実装されていれば、これらのセクションを一括変更またはスタイル変更することは信じられないほどの仕事になるだろうという私の信念を強化しました。

だからついに

セクションの定義（および最終的な実装）は、 the_content()に関するテーマのデザインパターンのニーズを処理するのに十分なだけ拡張する必要があります。

「コンテンツ」ではなく「テンプレート」に該当するものはすべて、セクションブロックの外部およびグーテンベルクエディターの外部で処理する必要があります（現時点では）。

グーテンベルクが他の人と同じようにコンテンツとインラインでテンプレートを作成できるようにしたいのですが、まだそこにいないようです。適切にテンプレートを処理する前に、このセクションブロックを確実に特定する必要があります。

数日前、私は基本的なレイアウトを作成したかったので、これが必要でした。 だから私はプラグインAをインストールすることから始めて、それを試しましたが、バグがありました。 アンインストール、プラグインBの検出、インストール、セクションブロックの試行、それはbaaadでした。 次のプラグインCはバグが多く、プラグインDはそれをコンテナと呼んでいました。 次のプラグインE、F........。
ページを作成してコンテンツを作成したい場合、現在のグーテンベルクの「エコシステム」は非常に苛立たしいものであると確信できます。
ここの人々が「プラグインXを見てください」、「この機能が必要な場合はプラグインYをインストールしてください」などと言い続けるという事実は、人々がこれを必要としていることを明確に示しています。 彼らはそれを_望んでいません_、彼らはそれを
グーテンベルクが太陽の下ですべての機能を追加する必要があると言っているわけではありませんが、これは基本的な機能です。 そこにある必要があります。 考えられるすべてのオプションがある必要はありませんが、基本はそこにある必要があり、開発者は必要に応じて拡張できます。
基本的なコンテナには20の異なる実装があり、どれも期待どおりに機能しないという段階に達しています（もちろん個人的な意見です）。

簡単な代替手段として、列ブロックを使用して列数を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エディターのすべてのインスタンスに、任意の投稿/ページ/投稿タイプのルートレベルで単一のコンテナーブロックのみを許可するように強制します。

ルートコンテナブロックは、その中に追加できるブロックの限定されたサブセットを適用します。

テキストまたは全幅以外のブロックを追加するには、最初にKadence Row Layoutを挿入する必要があります。この場合、これはメインセクションのラッパー要素として機能します。

コア内で必要なのは、単純な拡張可能なコンテナブロックだけです。 スタイリングに関してこのブロックを拡張することは、プラグイン/テーマ開発者に任せるべきです。 また、独自のコンテナブロックを構築したい開発者にフォールバック変換状態を提供する必要があります。

私がテストしたコンテナ/セクション/行を提供する既存のすべてのサードパーティプラグインは、コンテンツのロックインに関して重大な問題の影響を受けます。 これらのプラグインを非アクティブ化すると、エディター内から内部ブロックコンテンツにアクセスできなくなり、それらを変換するとHTMLが削除されます。 ユーザーが十分に知っておくべきこと。

見る：
https://github.com/WordPress/gutenberg/issues/13391#issue -401130412

OK。 私はGutengergをテストしました、それは良いです、しかしはい、それは確かにセクションのものを欠いています。
確かに、多くのブロックには、cssクラスを追加できるコンテナがあり、スタイルが設定されています。 ただし、メインコンテンツはコンテナなしで記述されているため、クラスも記述されていないため、スタイルを設定することはできません。 また、メインコンテンツは他のすべてのブロックと同じステージで作成されるため、他のブロックとは異なる方法でボックス化することは非常に困難です。

言い換えれば、私はクラシックに戻り、セクションを提供するまで待ちます。

よろしくお願いします。

ええ、その通りです。 現在開発中の他のすべてのブロックよりもさらに重要だと思います。 @youknowriadもっと優先さ

すでにフェーズ2のスコープにありますhttps://github.com/WordPress/gutenberg/issues/13113誰かが進んでやって

@youknowriad私は開発者ではないのではないかと思います。 しかし、開発はすでに進行中であったことを覚えています。 Wordpress 5のリリースの少し前に、すでに非常に進んだPRがありました。 詳細はまだ明らかにされていませんが、ほぼ準備ができていました。 残念ながら、PRはもう見つかりません。 誰かがそれがどこにあるか考えていますか？

はい、心配しないでください。

これがPRです。 https://github.com/WordPress/gutenberg/pull/10562

これはオープンソースプロジェクトであり、ボランティアに基づいていることを明確にしたいと思いました。 私はグローバルな方向性を示し、助けを求めることはできますが、人を割り当てることはできません。 人々はそうではないと考える傾向があります。

これがより迅速に行われることを確認し、支援したい開発者がいる場合は、Core Slack＃core-editorチャネルでの毎週の会議（および会議）に歓迎され、話し合い/共同作業/支援を求めます。

ああ、そうだね！ すごい！ 概要があります!!!

はい、それは真実であり、非難すべきではありません。 私が単に自問したこと：重要でさらに重要なタスクはありませんか？ 50人がRSSブロックを必要とし、1000人がコンテナブロックを必要とする場合、全体をより具体的に集中することは理にかなっています。 コンテナブロックは今ではエキゾチックなものではありません。 これが_すべてのデザインの基礎_だと思います。

誤解しないでください：あなたは素晴らしい仕事をしています。 そして、フェーズ2リーダーとしてのあなたは、一流の仕事をしています。 それはすべて焦点を合わせるという問題についてです。 次のスラックチャットで乾杯します... ;-)

どうもありがとうございました！

よろしくお願いします。 私は彼らに個人的に同じ重要性を与えます。 フェーズ2の中間ステップは、ウィジェット画面でブロックを使用することです。 したがって、RSSブロックを要求していなくても、ウィジェット画面（フェーズ2の重要なステップ）でブロックを使用するようになると、使用しているRSSウィジェットが見つからない場合はブロックを使用します。それについて文句を言う。

これら2つのタスクはどちらも、複雑さの点で「中」のタスクであり、機能に関しては重要ですが、フレームワークに関しては重要ではありません。 現時点での私の個人的な最優先事項は、フェーズ2の目標（ウィジェット画面のブロック、post_contentの外部のエディター）を可能にするフレームワークです。これらの競合する問題は、後でではなく早く実験して明確にすることが重要です。

OK。 私はGutengergをテストしました、それは良いです、しかしはい、それは確かにセクションのものを欠いています。
確かに、多くのブロックには、cssクラスを追加できるコンテナがあり、スタイルが設定されています。 ただし、メインコンテンツはコンテナなしで記述されているため、クラスも記述されていないため、スタイルを設定することはできません。 また、メインコンテンツは他のすべてのブロックと同じステージで作成されるため、他のブロックとは異なる方法でボックス化することは非常に困難です。

言い換えれば、私はクラシックに戻り、セクションを提供するまで待ちます。

よろしくお願いします。

これは、新しいブロックエディタのこれと他の欠点を形にするまで私が取っているスタンスです。 新しいエディターにはいくつかの素晴らしい側面があるので、これが起こることを願っています。

セクションブロックは素晴らしいでしょう。バックエンド開発スキルが不足しているのに、私は何ができるでしょうか。

現在、たくさんのブロックプラグインがありますが、必要なブロックはセクションまたはコンテナブロックだけなので、追加してほしいと思います。

WordPressコアには、ブロックエディターのセクション、行、列のレイアウト構造の独自の実装を含める必要があります。これは標準であり、すべてのサードパーティのプラグイン、テーマ、ページビルダーで使用できます。 何度も述べたように、APIを提供して、独自のインターフェイス、ベル、ホイッスルを追加できるようにする必要があります。 これらのサードパーティソリューションのいずれかをオフにすると、ページ構造はそのまま残ります。

すべての方向から来るセクション/行に対するサードパーティのソリューションがありますが、ネイティブコアブロックとサードパーティブロックを混合し始めると、多くの不整合とブロックがクラッシュし、解決する必要があることがわかります。 これらのレイアウトソリューションを提供する人々の努力を批判したいのではなく、彼らは非常に必要な機能を埋めています。 それらの多くは良いですが、全体的な経験について何かが完全に正しくありません。

私はコアブロックエディタをシンプルに保ち、サードパーティが機能と洗練を追加できるようにすることに全力を注いでいますが、それを強化する必要があります。そうしないと、受け入れの牽引力を得るのは簡単ではありません。

ここでの大きな問題は、誰がそれを処理するかです。 それを行うための時間とエネルギーを持っている開発者は数人いませんか？

はいはいはい！ 柔軟なセクションブロックは、グーテンベルクに欠けている最大の機能の1つだと思います。

まだ存在しないなんて信じられない…

別の方法は、columnsブロックに1つの列のみを持たせ、背景色を列に設定できるようにすることです。 TA-DA：セクションブロック。

まあ、それが誰かを助けるなら：私たちは少し前に私たちのプロジェクトのためにセクションブロックを書きました。 私はそれがいくつかの点できれいになることができると確信しています、しかしそれは良い出発点であるかもしれません：

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は、この問題に目を
https://github.com/WordPress/gutenberg/issues/13391#issue -401130412

セクションブロックは素晴らしいでしょうが、セマンティックマークアップのみにしてください！ セマンティックHTML構造で物事を維持すると、最も不可知論的なコードベースが作成されます。
<section>, <article>, <header>は、 <div class="wp-section">などの方がはるかに優れています。

@talldan申し訳ありませんが、コメントを逃しましたが、これを採用しても100％大丈夫です🙌きっとあなたはそれを揺るがすでしょう！

テキスト＆メディアブロック＃10925の焦点を使用できることも素晴らしいことです。 もちろん、これは画像の背景がある場合にのみ意味があります。

ちなみに、多くのページビルダーも持っている素晴らしいことです。 または少なくともそのようなもの：

ここでは、フォーカルポイントピッカーが最適であることに同意しました。 それはカバーブロックで本当にうまく機能します！

そのことを念頭に置いて、セクションブロックの以前のモックアップを更新しました。 これは、背景色と画像を調整できるコンテナ要素として純粋に機能します。

プレビュー：

ここでプロトタイプをチェックできます。

いくつかの追加の注意：

• 背景画像なしで起動し、背景/テキストの色だけを起動する必要があると思います。 それを押し出したら、次に背景画像を組み込むことができます。 これにより、既存のパターンを使用して迅速に処理でき、それでも膨大な数のユースケースをカバーできるはずです。
  
  
  
  • 最初のバージョンをマージすると、テキストブロックから背景とテキストの色を非推奨にする可能性があります。 代わりに、段落ブロックにインラインカラーオプション/ハイライトオプションを含めることができます。 これは、段落の全体的なパターンとしては優れているようです。
  
  
• このブロックは常に単なるコンテナであるため、レスポンシブ設定は含まれません。 コンテナ内のコンテンツ（列ブロックなど）は、応答性の高い動作を提供します。

同意します。当面は、必要に応じてcssを使用して背景画像を追加できます：+1：

最初のバージョンをマージすると、テキストブロックから背景とテキストの色を非推奨にする可能性があります。 代わりに、段落ブロックにインラインカラーオプション/ハイライトオプションを含めることができます。 これは、段落の全体的なパターンとしては優れているようです。

セクションブロックをブロックレベルの色に適した場所と見なす理由の1つは、そうでない場合は、リスト、見出し、およびその他の基本的なテキストブロックにこれらの色のオプションがない理由に答える必要があるためです。 そして、それらはブロックレベルで分割されるため、これらすべてに連続してまたがる背景画像を作成することはできませんが、セクションブロックはそれを修正します。

これらの色を廃止する方法は、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私はこれを2番目にします。

誰かの仕事を減らすことはありませんが、これを何らかのレベルで組み込む必要があります。

特にこの問題がある世界では。

＃13391の適切な解決策が見つかった場合、無数のコンテナブロックの実装が存在することはおそらく問題ありません。

サードパーティのプラグインが拡張できるレイアウト要素（コンテナ、セクション、行、列）の標準的な基盤を持つ新しいブロックビルダーがクラックされるまで、サードパーティのブロック、テーマ、ビルダーのオンとオフを切り替える混乱が続きます（レイアウトの問題に対処しようとしている人）、コンテンツとページレイアウトを失うことになります。

この機能はいつ期待できますか？

すでに最新バージョンになっているはずです：
https://github.com/WordPress/gutenberg/releases/tag/v5.5.0

@ksere ：プラグインのv5.5.0の変更ログが空であるためか、それを見逃しました。

これまでのところ、これに関する実装を実際に掘り下げています。 5.5でリリースされたばかりだと理解していますが、背景画像（およびその配置）、背景色の不透明度などの追加がいつ期待されるのでしょうか。これは2019年後半までに期待すべきことですか、それとももっと長く話しているのでしょうか。 -それよりも期間？

@nathansnelgroveフィードバックをありがとう。 グループブロックには確かにいくつかの改善があります。これはすでに進行中の2つです。

• スタイリングを簡単にするための内部コンテナーの追加-https：//github.com/WordPress/gutenberg/pull/15210
• 選択したブロックをグループ化/グループ解除するためのエディターオプションの追加-https ：//github.com/WordPress/gutenberg/pull/14908

背景画像と不透明度についておっしゃった問題がどこでも追跡されているのを見たことがありません。この問題は現在解決されているので、時間があれば、別の問題を作成する価値があるかもしれません。

背景画像/色/不透明度は元の提案からのものです—私はそれらのために新しい問題を作成します。

WordPress 5.2.4をインストールしましたが、「Section」または「Group」ブロックが見つかりません。 何が起きてる？

@patrikhuber ：これは現在11月12日にリリースされる予定のWordPress5.3に含まれます。

@noisysocksなるほど、どうもありがとう！