以上3点の関係性を確認する必要があります。12:55もう少し補足を入れておきます。添付画像は私の環境(余白2.0emの設定)で、マイクロテキストブロックの上寄りをさらに追加したときの上がブロックエディター側、下が記事本文側での表示です。双方に反映される一方、記事本文と編集画面のスタイル指定が1:1でないため、修正方法で挙げたように個々のブロック、個々のタグ・コンポーネントごとに別々に調整していく必要があります。いった意味で、独自カスタマイズやブロックディレクトリーによる追加ブロックなどまで考慮すると、あまり現実的な仕様ではないと思った次第です。『分かりやすい新たなルール(統一された設計・規則)等』について、例えば別途管理画面用に指定されるcss-custom.php#L630-L633の部分が必要なくなる(=記事本文と編集画面のスタイル指定が1:1となる)よう、ブロックエディターに合わせたコンポーネントベースで余白を設計し直した方が、最終的には管理する項目もスタイルの記述量も抑えることができるのではと思います。)含むコンテンツを作成するとします。グループブロック部分を見逃しておりました。公開ページで再現しました。記事本文と編集画面のスタイル指定が1:1にするように書くとすると、全ての必要なCSSセレクタを記入するか、そうでないとしてCSSを簡単に書くとしたら構造的にclassを追加するしかなさそうですね。他のサイトも見てみて、参考にしながら考えてみます。...における問題点が具体的にお分かりいただけたかと思います。記事本文と編集画面のスタイル指定が1:1にするように書くに関しては飽くまで例で、私自身フロントエンドは素人なので最適解なのかどうかは分かりません。...でも結果的にある程度成り立っていました。...」と構造的なマークアップにすることでよりリッチなコンテンツを簡単に作成することができるようになっています。ここに1階層目しか成り立たない現在の仕様を当てはめると考えた場合、1階層目と2階層目以降で分離されてしまうため、簡単に修正できる方法は私では思いつきませんでした。テーマをWordPress本体の仕組みに従って作成することでプラグイン等の恩恵が得られるのと同様に、ブロックエディターの仕組みを基準にスタイル設計を見直すのが方向性としては正しいのではないかと思い、編集画面に対する記事本文が1:1となる形を例に挙げたまでです。何か参考になる資料等はないかと軽くググったところ、https://www.slideshare.net/manabuyasuda1/ss-71261608が上で説明した私のイメージに近い内容になっています。ちなみに、今ある公式ブロックの中でのグループブロックは、ただ単に単一または複数のブロック(コンポーネント)を入れるラップコンポーネントとしての役割だけでなく、セクション的な役割も担っていると考えており、実際に活用しています。15:53参考になるかは分かりませんが、上で挙げた資料に関して私のブロック周りのカスタマイズを例に追記しておきます。Blocksの利便性について」でも書き込んだように、同じマークアップ構造(=クラス名の変更+各々のスタイル指定)で表現できるコンポーネントはひとつのブロックにまとめて管理しています。これはつまり、Cocoonブロックでアイコンボックス付箋風ボックス白抜きボックスなど、コンポーネントごとにそれぞれブロックが用意されているのに対し、先日行われたアップデート「ブロックエディターの複数ブロックをグループブロックを使ってまとめて装飾する方法」のグループブロックと全く同じで、その他のCocoonブロックや独自カスタマイズについても同様に行っており、5.5から新たにブロックパターン機能が加わる点も含め、コンポーネントの裏にあるマークアップで考えた方が整理はしやすくなったと実感しています。資料の第一章に書かれてあるコーディング面でのメリットデザイン面でのメリットそのものです。現在のCocoonはブロックもスタイル指定もコンポーネントごとに独立していると思うのですが、特に『デザインの再利用』という観点で見ると、余白等の見通しが悪くなっている一因なのかもしれません。15:10新たな不具合についての報告です。To”を使用する前後の編集画面で、使用するとデザインが崩れます。原因はgutenberg.js#L12で挿入するクラスが当機能によってリセットされるためです。Toは初めて気づきました。22:57キーボードでブロックを移動できるようにするための機能です。カーソルで上下の移動先を指定(マウスだとドラッグ)し、エンターで移動(マウスだとドロップ)します。To”を選択する必要がありますが、おそらく機能自体はまだ未完成で、最終的には一連の動作をショートカットキーで実現させ、キーボードのみでブロックを移動できるようにするのだと思います。To”により、段落ブロックのスタイルオプションは廃止&グループブロックで統一し、スタイル指定をインナーコンテナ側に寄せた方がよさそうです。コンポーネントを構成するマークアップの一番外側にあるタグは、余白等のアウトラインを決める程度に留める設計が好ましいということになるのかと。16:07ブロックライブラリが左サイドバーで表示されるようになりましたが、Cocoonが用意しているツールバー周りの機能を全て使用する状態だと画面幅とスクリーンの表示形式によっては収まらないので、整理していった方がよいかもしれません。(ブロックエディターのレスポンシブデザインを考慮すると、追加ツールバーボタンは4~5個くらいまでが理想的に感じます。)添付画像1~3は1500px前後での通常スクリーン表示です。1はトップツールバーの場合、2・3は各ブロックのツールバー(両サイドバーを開いた状態)となっています。整理について例えば、文字装飾のツールバーボタンは4にあるテキスト制御内に集約したり、インラインタグでないショートコードは5のようにショートコードブロック等に移動させるなどが考えられます。19:50キーボードでブロックを移動できるようにするための機能です。ありがとうございます。段落ブロックのスタイルオプション廃止も含めて修正を検討したいと思います。ツールバーもそうかもしれませんね。ブロックエディター黎明期ということもあるのでしょうが、結構変わりますね...。21:325.4では大きな変更があまりありませんでしたし、ブロックディレクトリが実装されたのに合わせて多くの調整が入りましたね。GutenbergはWordPress本体と別プロジェクトかつ3倍速くらいで開発されているにもかかわらず、アップデートのタイミングが本体と一緒なのもあると思います。あと、余白等のスタイル設計やツールバーに関する問題点は5.5以前からあり、個人的には対応していたものの旧エディターとの兼ね合いからテーマ側での修正が容易ではないので、問題が表面化するまで報告を後回しにしていたせいもあります。ハンドブックやロードマップに書かれている方針を基準にしつつ、編集中にちょっとでも使いづらいと感じたところはgithubレポジトリで検索すれば大抵issueで議論されていたりするので、その都度ブラッシュアップしておくといいかもしれません。@lococoあと、余白等のスタイル設計やツールバーに関する問題点は5.5以前からあり、個人的には対応していたものの旧エディターとの兼ね合いからテーマ側での修正が容易ではないので、問題が表面化するまで報告を後回しにしていたせいもあります。ありがとうございます。僕も、余白が反映されないのは以前から把握はしていたのですが、おっしゃる通りクラシックエディターとの兼ね合いと、修正がかなり大掛かりなことから、見えないふりをしてスルーしていました。現状は、簡単に修正する方法はないっぽいので、一つ一つCSSセレクタを書いていくしかないのかもしれません。その方法だと、プラグインが挿入するブロックには対応できない等は出てくると思います。17:22そうですね。0;}などを基準にできますが、現状のブロックにおけるマークアップ構造と旧エディターから引き継いでいるスタイルを維持しようとすると、一つ一つCSSセレクタを書いていくのが無難なように見えます。プラグインが挿入するブロックには対応できない等は出てくる#post-37305などで追加ブロック等については言及しましたが、上記の方法でもう少し先のアップデート(フェーズ2内)まで広げて見ると、その他にショートコードやウィジェット等のブロック化メニューやウィジェットのブロックエディター化ブロックスタイルシステムでの制御といった点で影響が考えられるため、修正時には合わせて視野に入れておいた方がよさそうです。20:22とりあえずは、こんな感じで変更してみました。22:50とりあえず適当にブロックを並べてある記事上で見つかった点を書き込んでおきます。ブログカードに不要なmarginが入るようです。カラムブロック内の組み合わせによってはlast-of-typeの影響でmarginが入ったり入らなかったりします。タイムラインブロックも2と同様です。テーブルブロック(横スクロールやキャプション含む場合)のmarginが適切でないようです。どこから不具合と捉えればよいのかが難しいため、細かいところは個々で対応ということになりそうですね。20:25ありがとうございます。@lococoちなみに、新たにブロックを用意する度に余白設定のところにCSSセレクタを加えていくという認識でよろしいでしょうか?現時点では、そうするしかないかなと思っています。@lococoカラムブロック内の組み合わせによってはlast-of-typeの影響でmarginが入ったり入らなかったりします。可能でしたらこちらのスクリーンショットいただくことはできますでしょうか。@lococoまた、記事本文以外(articleクラス外)のブロックエディターで作成するコンテンツについては、それぞれの箇所やブロック毎に別途CSSセレクタを書いていくという認識でよろしいでしょうか?これは例えばどいた時でしょう?カテゴリページとかの編集をブロックエディターでしているときとかでしょうか。@lococoブログカードに不要なmarginが入るようです。21:00カラムブロック内の組み合わせによってはlast-of-typeの影響でmarginが入ったり入らなかったりします。これは、カラムの中にブロックをいろいろ入れてみたら、ここではないかという部分を修正してみました。ついでにスクロールテーブルとタイムラインの部分も。22:27添付画像を例に、last-of-typeはタグの種類ごとに作用するため、pタグとdivタグ、blockquoteタグなどを組み合わせて並べたとき、それぞれの最終タグに作用します。ブログカードはリンクタグ内の要素にmarginが指定されているため、スキンを含めほとんどのブログカードデザインでリンクが下に伸びると思います。記事本文以外(articleクラス外)のブロックエディターについては、カテゴリーページというより#post-37642で書き込んだように各ウィジェットエリア内が分かりやすいのではないかと思います。現在の修正から考えると、Cocoon設定での余白は本文に限っているので、それ以外(=.article外)の余白に対しては別途CSSセレクタを書いていくことを予定しているのかと思い、質問しました。@lococolast-of-typeはタグの種類ごとに作用するため、pタグとdivタグ、blockquoteタグなどを組み合わせて並べたとき、それぞれの最終タグに作用します。ブログカードはリンクタグ内の要素にmarginが指定されているため、スキンを含めほとんどのブログカードデザインでリンクが下に伸びると思います。こちらについては修正してみました。23:12修正ありがとうございます。テーブルブロックにはfigureタグとtableタグの両方にmargin指定があるので、figureタグにラップされる場合はtableタグのmargin-bottomは0にするのがよさそうなのですがいかがでしょう。追加で、ギャラリーブロックはlast-childのmargin-bottomを0にする必要はなさそうなのですが、何か問題があったのでしょうか。@lococoテーブルブロックにはfigureタグとtableタグの両方にmargin指定があるので、figureタグにラップされる場合はtableタグのmargin-bottomは0にするのがよさそうなのですがいかがでしょう。@lococo追加で、ギャラリーブロックはlast-childのmargin-bottomを0にする必要はなさそうなのですが、何か問題があったのでしょうか。要素の中に多数の要素があるものは書いておいた方が良いと、思い込みでそのようにしていました。ギャラリーブロックは除外しました。16:14修正ありがとうございます。ギャラリーブロックは横並びの画像が同じ高さになるよう修正されていましたが、テーブルブロックは#post-37897で説明した通り、figureタグとtableタグの関係からテーブルとスクロールバーの間に余白が入ってしまうようです。テーブルブロックに加え、グループ埋め込み案内ボックス囲みボタンが子ブロック以下にある場合は設定した余白が入らず、グループブロック内の子ブロックについてはlast-childにmargin-bottom:0が指定されていません。記事本文以外(articleクラス外)のブロックエディターで作成するコンテンツについては、それぞれの箇所やブロック毎に別途CSSセレクタを書いていくという認識でよろしいでしょうか?まだ回答いただけていない#post-37661や#post-37711での質問内容に戻るのですが、どこまでをテーマ側の不具合と捉え、どこからを各自の対応とみなせばよいのでしょうか?articleクラス外もテーマ側で別途指定するかどうかでarticleクラス内にも影響が出てくるパターンも考えられますし、ウィジェット・ショートコードとの兼ね合いも考える必要があるかと思います。質問の意図をもう少し具体的に説明します。@lococoまだ回答いただけていない#post-37661や#post-37711での質問内容に戻るのですが、どこまでをテーマ側の不具合と捉え、どこからを各自の対応とみなせばよいのでしょうか?出来れば、それぞれの内容についてはコピペで簡単なもので良いので別のトピックに立てていただいてよろしいでしょうか。1つのトピック内に話題が混在すると、意味を分離するために改めて何度も読み返す必要があり、ちょっときついです。一つ一つ返信させていただいていました。書き手は意味を理解した上で書き込んでおられると思いますが、読み手はテキストメッセージから完全な内容をイメージするのはなかなか難しいので、その上話題が混在するとかなり厳しいです。出来れば分けていただけると問題解決ごとにトピックを閉じて情報を排除することができるので助かります。ほんとお手数で恐縮なんですがよろしくお願いいたします。00:16検索案内ブロックが重なる不具合については修正が入ったと思うので、それ他の項目について以下のトピックに分けました。検討項目として挙げた点や主観的な判断に基づく項目も含まれるため、最終的に見送る等の判断をしたトピックがあれば、そのまま閉じてもらっても構いません。20:47ありがとうございます。これでそれぞれに返信しやすくなりました。あとはそれぞれのトピックに書き込んで行かせていただければと思います。お手数をおかけして申しわけありません。フォーラム書き込みテスト。2.4.0問題の解決に至った場合には、トピック冒頭の「解決済み」をクリックしていただけますと幸いです。有用な回答があった場合は返信右下にある「いいね!」もご活用ください。回答者の励みになります。「いいね!」機能はフォーラム登録者のみが利用できる機能です。2.1)準じていれば(リンクを貼っていただければ)転載も自由です。カスタマイズ記事を書く際にコード等をコピペ利用していただいて構いません。フォーラムの使い方がよくわからない場合は、テストトピックで自由にテストしていただいて構いません。最近の書き込みはこちら。詳細なカスタマイズ依頼をするならこちら。フォーラム書き込みテスト。常に最新版で動作させていますが、言われる現象は発生していません。Ver.2.7.9.2でも起きていません。現在はエラー無く動作しています。フォーラムの文章中に画像を入れる方法。スマホからですので端的に。追伸)Swiper機能以外に表示が乱れるサイトにはドロップダウンメニューを使っていました。フォーラムの文章中に画像を入れる方法。フォーラムの文章中に画像を入れる方法。2食欲ないのは困りますね。食が細いと回復も遅れてしまいます。2僕もなかなか良くならなくて困ってます。FAQブロックのアコーディオンをデフォルトで開きたいFAQは、一問一答だと思っていましたので、あまりネストを考えたことがないのですが。以下のコードで、FAQブロックのスタイル「アコーディオン」は閉じた状態で初期表示としている。1日前FAQブロックのアコーディオンをデフォルトで開きたいいつもお世話になっております。以下の部分にパラメータを追加。文字の間隔が編集時と異なる無事変更することができました。ありがとうございました。すみません、上記ですがunset→normalとしてください。