グーテンベルクは、CPTによって宣言されたエディターのサポートを尊重し、サポートされていない場合はロードされません。

これがGutenbergがまったく読み込まれず、代わりにClassicエディターが使用されることを意味する場合、Gutenberg環境とClassic環境の間で分割されたフラクチャされたWP管理者への道に私たちを設定します。 これは多くの点でWordPressにとって悪いことです。

• 新規ユーザーは、2つのタイプのインターフェースが異なる主な方法と微妙な方法を学ぶ必要があります。 投稿を公開したり、テキストビューに変更したりするのと同じくらい簡単なアクションは、グーテンベルクとクラシックのエディターで異なる働きをします。

• 既存の開発者は、両方の環境でテーマとプラグインの機能を維持することを余儀なくされます。 移行期間について話しているのではありません。 私たちは無期限に話している。 あらゆる投稿タイプを拡張することを目的としたプラグインが最も影響を受けます。 これらの開発者がメタボックスをブロックに変換することになった場合でも、グーテンベルク以外の投稿タイプでプラグインを使用する場合に備えて、古いメタボックスを維持する必要があります。

• WordPress開発に参入する新しいプラグイン開発者は、2つの異なる方法でプラグインを構築する方法を学ぶ必要があります。 彼らがグーテンベルクブロックを採用していると仮定すると、それらのプラグイン機能は、クラシックエディタを使用した投稿タイプでも利用できない可能性があります。

メタボックスを機能させる必要があると私は信じていますが、グーテンベルクをオフにするだけでは、長期的には最善の解決策ではありません。

これがGutenbergがまったく読み込まれず、代わりにClassicエディターが使用されることを意味する場合、Gutenberg環境とClassic環境の間で分割されたフラクチャされたWP管理者への道に私たちを設定します。

CPTがエディターをまったく有効にしたくない場合は、それが最善の方法のように思われます。 これは単に異なる管理ビューであり、異なるエクスペリエンス用に最適化されています。 （たとえば、ウーからの「注文」ビュー。）グーテンベルクのコンテキスト内でそれらをレンダリングしようとする人は誰も助けません。

これは、カスタマイザーの出現に似ています。これは、異なるコンテキストで同じことのいくつかを実行する新しいインターフェースパラダイムでした。 常に「管理」インターフェースと「編集」インターフェースが必要です。 これが、インターフェースのさまざまな目的を明確にすることで、部分的に前進する方法です。

しかし、グーテンベルクのスコープクリープのために、それは単にエディターのタイプを有効または無効にすることではありません。 グーテンベルクが編集インターフェース全体を決定するようになったため、上記のエディタータイプに関連する副作用の全リストがあります。

常に「管理」インターフェースと「編集」インターフェースが必要です。

これらはまさに、エディターとメタボックスが今日果たす役割です。 それらは孤立した経験ではありません。 彼らは一緒に働きます。

次に、スコープクリープに対処し、グーテンベルクをwp_editor()が存在する領域に制限する必要があります。 それは確かに多くの互換性の問題を解決するでしょう。

スコープクリープ

スコープクリープに対処することは私の好みであり、私たちの多くが過去数か月にわたって求めてきたものです。 そうすることで、管理エクスペリエンスを分割することなくエディターを改善できます。

投稿タイプごとにグーテンベルクを有効にする

投稿タイプごとにグーテンベルクを無効にする機能に関して、問題を回避することは解決策に到達することと同じではないことを強調したいと思います。 投稿タイプごとにGutenbergをオフに切り替えると、一部のプラグインのメタボックスの非互換性を回避できる場合がありますが、長期的にはWordPressの状況に悪影響を及ぼします。

理由がわからない場合は、グーテンベルクが統合されてから2年後に業界に参入する新しいプラグイン開発者になることを想像してみてください。

• 開発者として、プラグインUIをブロックまたはメタボックスとして記述しますか？ すべての投稿タイプをサポートする場合は、両方として記述する必要があります。
• ユーザーがプラグインを検索しているとき、プラグインページで約束した機能は、グーテンベルク対応の投稿タイプでのみ機能することをユーザーは知っていますか？ クラシックエディタと一緒に使用できないことに気付いたとき、彼らはがっかりしますか？
• 同じユーザーがサポートを求めてあなたに連絡したとき、彼らがあなたのプラグインがクラシックエディタまたはグーテンベルクエディタでどのように機能するかについて尋ねているかどうか知っていますか。 その顧客は違いさえ知っていますか？
• リリースから数か月後に機能を追加したい場合、開発時間を増やして、その機能をPHPメタボックスとJSブロックの両方に組み込むことをいとわないでしょうか。

これらは、2人のエディターで前進し、UIの特異性への道がない場合に、状況を混乱させる質問のほんの一部です。

show_in_rest

show_in_restが設定されていない場合、投稿でGutenbergを使用できないという事実は、編集エクスペリエンスに影響を与える無関係な機能のもう1つの例にすぎません。 REST APIでの公開投稿の可視性に対する私の好みが、編集時に使用するインターフェースに影響を与える理由はありません。 私は技術的な理由を理解していますが、ロジックはありません。多くの開発者は、これが現時点での制限であることにさえ気づいていないのではないかと思います。

グーテンベルクがwp_editor（）パラメータの範囲外になった方法は、今でも私を困惑させます。 グーテンベルクの「エディター」がwp_editor（）に制限される場合、投稿タイプごとの「オプションとしての有効化」が現実のものとなり、将来的にははるかに管理しやすく拡張可能になります。 グーテンベルクスコープクリープを縮小できず、wp_editor（）内に含めることができない理由についての合理的な説明はまだ見ていません。

エディターを使用せず、フロントエンドに直接表示されないカスタム投稿タイプに対してグーテンベルクを有効にすることは意味がありません。

CPTが本物の投稿タイプだけでなく、さまざまな設定や要素の管理インターフェイスを作成する方法として使用されているさまざまなWebサイトを見てきました。

たとえば、私が取り組んだ著者サイトには、「本」と「ショップリンク」のCPTがあります。 グーテンベルクを本のリストページの編集者として持つことは絶対に理にかなっています。 ただし、「ショップリンク」には独自の投稿やページはありませんが、各「ブック」ページのオンライン書店へのリンクのロジックを提供するために使用されます。 書籍ページテンプレートには、地域（英国、米国など）と形式（電子書籍、印刷物など）に一致する製品ページへのショップリンクが表示され、投稿メタフィールドに保存されているISBNが各オンラインストアのURL構造に挿入されます。スクリーンショットを参照してください。

CPTは、この種のデータと設定を管理するための最良の方法ではないかもしれませんが、エディターなしのCPTとカスタムメタフィールドを使用してさまざまな機能を組み合わせたWebサイトがたくさんあります。この種の使用法の他の例を提供できます。 エディターをまったく使用しないCPTにグーテンベルクエディターを強制することは、混乱を招き、逆効果になります。

エディターを使用せず、フロントエンドに直接表示されないカスタム投稿タイプに対してグーテンベルクを有効にすることは意味がありません。

いいえ、それは意味がありませんが、グーテンベルクがフルスクリーンの代替品である限り、グーテンベルクを含めるか除外するかの決定は、投稿タイプにエディターが必要かどうかを超えて、より大きな影響を及ぼします。

たとえば、プラグイン開発者であり、「ショップリンク設定」メタボックスをグーテンベルクを使用する1つの投稿タイプと、使用しない2番目の投稿タイプで使用できるようにしたいとします。 プラグインをあらゆる投稿タイプで機能することを期待している何千人ものユーザーに配布する場合、選択する余裕はありません。 そのとき、 https： //github.com/WordPress/gutenberg/issues/3330#issuecomment-341867663で言及されている質問が出てき

独自の投稿タイプ内で分離されたメタボックスは、グーテンベルクによる影響が最も少ないことを繰り返す価値があります。したがって、投稿タイプ全体で機能するプラグイン機能にどのように影響するかを考慮する必要があります。

はい、グーテンベルクと非グーテンベルクの両方のインターフェースをサポートする必要があるプラグインは、進行中の主要な問題であることがわかります

問題は、エディターをサポートしないCPTをGutenbergがどのように処理するかということになると思います。ブロックからページを作成するのが意味をなさないコンテキストでGutenbergはどのように機能するのでしょうか？

...グーテンベルクはエディターをサポートしないCPTをどのように処理する必要がありますか？ブロックからページを構築することが意味をなさないコンテキストでグーテンベルクはどのように機能しますか？

グーテンベルクが縮小し、 https： //github.com/WordPress/gutenberg/issues/3304#issuecomment -341474018で述べたYoastの概念のようにエディターのみを置き換える場合、グーテンベルクの有効化または無効化は非常に簡単になります。

• editorが有効になっている場合、ブロックエディターが存在し、使用されているフックに応じて、メタボックスがその上または下に表示されます。
• editorが無効になっている場合、ブロックエディターは存在せず、メタボックスが上にスライドして投稿タイプのプライマリインターフェイスになります。

これが今日の基本的な動作であり、その動作を維持することで、プラグインが意味のある場合にメタボックスをブロックに徐々に移行できるようになります。 また、分割管理エクスペリエンスに関連する上記の多くの紛らわしい質問を回避できます。

キックオフポストとプロジェクトが受けた祝福を考えると、「スコープクリープ」は使用するのに奇妙な用語だと思います。 全体として編集体験を向上させる方法について話し合い、研究を始めた1月11日以来、公の場ですでに行われている作業に軽蔑しているように感じます。 何も私たちに忍び寄りませんでした、これは常に計画でした、そしてそれが焦点のための決まった期間がない理由です。

とはいえ、デザインの観点について少しお話ししたいと思います。コンテンツ領域を置き換えるだけでエディターを設計することは、完全性を維持するためだけに、途方もなく妥協する経験だったと思う理由です。過去10年間にエディターを拡張するために構築されたすべてのプラグインとの下位互換性。 現状維持は簡単な方法ですが、常に正しい方法であるとは限りません。

フローを再考せずに既存のエディターにブロックを追加すると、すでに複雑さがあった場合に複雑さが増します。

ポストオーサリングを再考して、ショートコード、カスタムHTML、ウィジェットなどを置き換えるブロックを含めるという使命を考えると、執筆、編集、公開のフロー全体を全体的に見ないことで、デザイナーとしての責任を無駄にすることになります。

プロジェクト全体が将来に向けて大胆な措置を講じない限り、 WordPressが5年以内に

画面全体を見ずに優れたエディタを設計することは不可能です。 これは不便であり、プロジェクトを困難にし、WordPressのレガシーを考えると、それはさらに困難になります。 それは簡単なことではありませんでした。特に、グーテンベルクをネイティブに拡張する方法については、まだ先に進む方法があります。 しかし、中途半端な手順を踏んで、コンテンツのテキストエリアのみを置き換えるようにGutenbergを構築することは、WordPressにとって大きな不利益であり、起動するのに悪い設計になります。

グーテンベルクの1つのコンポーネント、エディターキャンバスだけを、現在の編集画面に

問題は、エディターをサポートしないCPTをGutenbergがどのように処理するかということになると思います。ブロックからページを作成するのが意味をなさないコンテキストでGutenbergはどのように機能するのでしょうか？

@CalebWoodbridgeこれはすでにそれがどのように機能するかです。 参照： https ：

次に、「スコープクリープ」という用語を使用するのは正しくありません。 これは、グーテンベルクが何であるかを実行することを目的としたプロジェクトには確かに当てはまらない用語です。

これについては傍観してくれて許してください、しかしそれは言う価値があると思います。 開発者が技術的なことを言うときに敬意を払うのと同じように、同じ観点からデザイナーについて考えてください。 このプロジェクトに携わっているデザイナーは多くの経験とスキルを持っています。私はその仕事を深く尊敬しています。このような素晴らしいデザイナーと一緒にプロジェクトのデザインリーダーになることを嬉しく思います。

グーテンベルクにいるデザイナーと仕事をする機会を持てたことを光栄に思います。 それは毎日の楽しみであり、WordPressで常に得られるとは限りません。 ほとんどの場合、コアのデザイナーとしてあなたは孤独な人間ですが、一緒に仕事をすることは素晴らしいことです。

デザインアプローチを見るとき、経験が鍵となります。 完全な経験の基盤を設定@matiasと一緒にオリジナルのビジョンに@jasmussen。 2番目のデザインリードとして、それは私が大切にし、維持したいものです。

設計の観点から見た過去のWordPressの大きな問題の1つは、小さな反復に加えて小さな反復のスパイラルでした。 最初の数日間は機能しますが、時間の経過とともに、改善のパッチと一緒に保持されるエクスペリエンスが追加されます。 これに苦しむWordPressはたくさんあります。 編集者は1つであり、メディアはもう1つであり、指摘できることはもっとたくさんあります。

グーテンベルクは私たちにパッチを削除し、私たちが持っているものを見て、再び構築するためのスペースを与えてくれました。 その結果、カスタマイズ以降に移行するための強力な視覚言語が始まりました。 WordPressを次の10年に前進させる視覚言語を実際に持つこと。 はい、私たちはそれをはるかに先に考えなければなりません。

フランケンデザインに対しても警告する点を指摘したいと思います。 世界中のすべてのデザイナーは、ある時点で、「xをここに置くかyをそこに置く」ことを誰かに提案してもらいました。 これは、設計者が設計することを許可していません。 プロジェクトとして、デザイナーにデザインを任せなければ、私たちは下向きのスパイラルに陥っています。 これは、率直に言って、デザイナーの火を消すようなプロセスです。 火を続けましょう。

これはグーテンベルクを超えた個人的なメモです。 私は、デザイナーが成長し成長できる空間を作ることに情熱を注いでいます。私たちは常にプロジェクトとして活動しているわけではありません。 グーテンベルクと一緒にそれをしていることを示しましょう。 情熱は素晴らしいですが、WordPressの技術的ビジョンと同じようにデザインビジョンを尊重してください。 最新のJSフレームワークについて話しているデザイナーの話を聞くのと同じくらい、デザイナーの話を聞いてみましょう。

@jasmussenによって大胆に育てられるという点で、良いデザインは大胆です。 いつもそうだった。 また、探索して考えるためのスペースも必要です。グーテンベルクはそのために信じられないほど素晴らしいものでした。 私たちには（まだ）、取り組むにはプロジェクトとしては多すぎると感じる前に考えていたアイデアを探求できるスペースがあります。 繰り返し、実験し、試す自由がありました。 これはいくつかの素晴らしいデザインを生み出しました、それを忘れないでください。

はっきりさせておきたいのですが、グーテンベルクが「完成」したり、デザインとして完璧だと言っているのではありません。 反復する必要があり、テストする必要があります。 私たちが必要としないのは、確立された強力なデザイン言語から離れて、後戻りすることです。 フランケンデザインする必要はありません。 必要なのは、テストしてフィードバックを取得し、設計者が反復できるようにすることです。

設計の観点から見た過去のWordPressの大きな問題の1つは、小さな反復に加えて小さな反復のスパイラルでした。 最初の数日間は機能しますが、時間の経過とともに、改善のパッチと一緒に保持されるエクスペリエンスが追加されます。

このような声明をこのような公の声明と一致させようとすると、 http：//matiasventura.com/post/gutenberg-or-the-ship-of-theseus/は、ユーザーが仕事について正直なコミュニケーションを受けていると感じるのを非常に難しくします。行われています。 WordPressは何百万もの人々によって何百万もの方法で使用されており、メタボックスのサポートやポストストレージ形式などの技術的側面に関しては、可能な限り破損の少ない段階的なアプローチが必要であることが十分に明らかにされています。 この決定は、実装のいくつかの部分を複雑にし、最適ではないが多くの方法でより適切にサポートされる決定を強制しました。

開発をある標準に、設計を別の標準に保つことは合理的ではありません。 合理的な生産のために、「大胆なデザイン」を縮小する必要がある場合があります。 これは自動車製造でよく知られており、グーテンベルクをコンセプトカーと比較するのが簡単な理由です。

確かに、管理者全体にjavascriptを使用する全体的なデザインが必要ですが、何百万人ものユーザーのエクスペリエンスを損なうことなく、v5リリースにすることはできません。 代わりに、編集ページではなくエディターに焦点を合わせるように縮小すると、破損することなく、はるかに優れたエクスペリエンスを提供できます（cssを適切に使用することで2番目の目標の多くを達成できます）。

次に、十分に文書化されたFields APIを提供することで、プラグインとテーマをGutenbergブロックのメンタリティに変換し、同じインターフェイスをより簡単かつ論理的に作成できるようにします。 非常に迅速に、メタボックスは物事を行うための古い方法になり、すべての高価値プラグインはブロックに切り替わります...もう一度、これは有機的に行われる必要があります。 機能を廃止したり、プラグインの作成者がグーテンベルクとメタボックスの両方をコーディングしなければならない分割インターフェースを作成したりして、人々の手を強制することはできません。

メディアのオーバーホールを手直しが必要な領域として言及するのは良いことです...それは暴走し、柔軟性のないオーバーホールのために苦しんだ領域です。 これは、JSフレームワークを完全に採用したWordPressの最初のセクションであり、開発者にとっては大きく後退しました。 メディアライブラリにカスタマイズがないことは、それが完璧であることを示すものではなく、将来および現在のユースケースを考慮に入れた思慮深いデザインが欠けていることを示しています。 私は何度もメディアインターフェイスを変更しようとしましたが、ある時点で、主要なコンポーネントをバックボーンテンプレートにハードコーディングする必要があると誰かが判断したことがわかりました。 私は昨日、文字通りこれらのケースの1つに遭遇しました！ （ここの7番目の段落で見ることができるように：https：//gschoppe.com/wordpress/disable-attachment-pages/）

編集ページではなく、グーテンベルクを編集者に戻すと、すべてを壊すことのない前進の道が得られます。 グーテンベルクがカスタム投稿インターフェースの基盤として十分に確立されると、JavaScriptのみのビジョンが移動して編集ページの残りの部分を引き継ぐことができます。 この種の反復は、（マットが受け入れられないと主張しているように）LTSリリースを提供し、各メジャーバージョンを完全な重大な変更にしない限り、大規模なソフトウェアパッケージでは絶対に重要です。

あなたが陥る危険を冒す2つの穴があります、そしてあなたは1つを特定しました。 はい、最新のテクノロジーを使用した統一されたインターフェースに移行しなければ、WordPressは今後5年間で死ぬ可能性があります。 しかしまた、この移行中にWordPressが開発者やプロのユーザーの大規模なコミュニティに適切なサポートを提供できなかった場合、WordPressははるかに早く消滅します。

既存のワークフローを壊すことなく、ビートを取り、縮小し、ツールボックスをユーザーに開放する何かを提供します。 次に、バージョンごとにスケールアップできます。 あなたは美しいコンセプトカーを持っていますが、私たちに必要なのは、実際の運転のすべてのエッジケースに対応するプロダクションカーです。 しかし、概念を提供することにより、そのアイデアをより限定された範囲に適用することができ、1年以内にそれらの原則は遍在するようになります

@gschoppe 、返信に時間を割いていただきありがとうございます。

まず、いくつかの明確さ。 私のコメントがMatiasによる投稿に反することに同意しません。 私は彼が完全に作ったポストに立っています。それは私のビジョンでもあり、私たちはこのプロジェクトのリーダーとして、方向性を見る方法で団結しています。 あなたの個人的な意見はあなた次第ですので、その点から先に進みましょう。

開発をある標準に、設計を別の標準に保つことは合理的ではありません。

私は同意し、私のコメントは、デザインがより多く聞かれたり、異なる基準を持っていることを目的としていません。それは、すべての声を聞き、すべてに同じ基準を適用することです。

メディアのオーバーホールを手直しが必要な領域として言及するのは良いことです...それは暴走し、柔軟性のないオーバーホールのために苦しんだ領域です。

デザイナーや開発者とゼロから焦点を合わせたメディアを見たいのですが、そうではありませんでした。

しかしまた、この移行中にWordPressが開発者やプロのユーザーの大規模なコミュニティに適切なサポートを提供できなかった場合、WordPressははるかに早く消滅します。

誰も機能を奪っていないので、これを言うのは興味深いことです。 グーテンベルクによる設計提案はそれをしていません。 いずれにせよ、クラシックエディタプラグインを使用している場合でも、既存のすべての機能を実行できます。

UIをつなぎ合わせるためにiframeに依存することほど、Frankendesignを考えることはできません。 メタボックスが設計プロセスに大きな影響を及ぼしていることは理解していますが、設計の一部は制限に対処しています。 これらの制限が存在しないかのように前進したり、移行計画を最後まで延期したりすると、すでに心配していて懐疑的なコミュニティにさらなる懸念が加わります。

グーテンベルクの長期計画がプラグインの領域である場合、私は無制限に実験を行うと言います。 しかし、それがオプトアウトするのではなくオプトインしなければならないプラグインであることが運命づけられていない場合、それはコアとそれがもたらすすべての荷物を現実的に処理する必要があります。

私のコメントは、デザインがもっと聞かれることを目的としていません

世界中のすべてのデザイナーは、ある時点で、「xをここに置くかyをそこに置く」ことを誰かに提案してもらいました。 これは、設計者が設計することを許可していません。 プロジェクトとして、デザイナーにデザインを任せなければ、私たちは下向きのスパイラルに陥っています。 これは、率直に言って、デザイナーの火を消すようなプロセスです。 火を続けましょう。

世界中のすべてのビジネスで、設計は実装の制約に合わせて調整されます。 メタボックスの下位互換性が制約である場合、設計はそれを受け入れ、制約内で機能する必要があります。

率直に言って、アクセシビリティや設計上の制約を失うことなく、メタボックスを完全にサポートしていますか？ 他の何千人もそうするように、私は明確な答えが欲しいです。

グーテンベルクによる設計提案はそれをしていません。 いずれにせよ、クラシックエディタプラグインを使用している場合でも、既存のすべての機能を実行できます。

現在、グーテンベルクはすべてのメタフィールドをiframeに配置しています。 それは非常に深いレベルで機能を壊します。 私たちはアクセシビリティの時代にあり、カスタムユーザーエクスペリエンスを作成してiframeでジェイルするという主に期待される方法を採用すると、これらのツールからすべてのアクセシビリティが根本的に削除されます。 また、エディターのロードに必要なリクエストの数が3倍になり、ユーザーにひどいUIを提供し、フルスクリーンのモーダルエクスペリエンスを小さな領域に投獄します。

現在、このスレッドでは、グーテンベルクがカスタム投稿タイプをオプトインするかオプトアウトするかについて説明しています。 オプトインした場合、すべての投稿タイプをサポートしたい開発者によって行われた以前は一貫性のあるUIの決定は、グーテンベルクエクスペリエンスと従来のエクスペリエンスの間で分割され、両方に合理的なユーザーエクスペリエンスを提供するために、開発作業が2倍必要になり、一貫性がなくなります。ユーザーエクスペリエンスの。

現在、 wp_editor()関数（編集されていないページに編集エクスペリエンスのフル機能のコピーを実装するための現在のベストプラクティスの方法）はGutenbergインターフェイスを提供していません。つまり、私はできません。投稿以外のページでカスタム編集エクスペリエンスを作成します...ユーザーに分割UXを提供する以外に、そこに進むための私の道は何ですか？

グーテンベルクを削除するプラグインはいくつかの問題を解決するかもしれませんが、プラグイン開発者向けのソリューションとして出荷することはできません。 「投稿タイプ間で一貫性のあるアクセス可能なユーザーインターフェイスが必要な場合は、新しいエディターを無効にする必要があります」と言う自由はありません。

機能の削除は、標準ワークフローの下位互換性ではありません。 機能の削除は、ファーストクラスのエクスペリエンスとして対応できないユーザーの1％にとっての最後の手段です。 この場合、私が示した例はどれも1％の問題ではありません。

炎に少し油を加えるには：先週、iFrameの使用に関して大きな問題が発生しました。 デスクトップシステムではうまく機能するかもしれませんが、テストされたケースの90％で、モバイル/レスポンシブでは大規模に失敗します。 多数の掲示板スレッド、ネット上の記事、Stack Overflowに関する質問を掘り下げた後、応答性が非常に複雑になるため、iframeアプローチを完全に放棄することにしました。 一部の変換タスクは、iframeに依存する代わりに、「プロジェクトが存在する実際のサブドメインへのリダイレクトを使用する」など、かなり簡単に実行できました。

それでも、RWDを適切に取得するために、そして何よりも信頼性が高く、保守しやすく、iframeを操作するために私がしなければならない膨大な量の作業と比較すると、ターンアバウトははるかに少ない労力であり、したがってより良い方法でした。

要約すると、iframeは一見簡単な方法のように見えますが、（多くの）アクセシビリティの問題だけでなく、非常に悪い設計上の選択です。

ちょうど私の.02セント、
cu、w0lf。

この問題を表示していただきありがとうございます@mtias 。
以下、GutenbergがWordPressプラグイン開発者に門戸を開く方法についての私の考えを投稿しています。

既存のブロック用にカスタマイズ可能なCSSクラス

必要：各ブロックラッパーのCSSクラスと、それをカスタマイズするためのフルアクセス。 グーテンベルクがサードパーティの開発者からでも最上位の要素にCSSクラスを必要とする場合は素晴らしいでしょう。

目的：このようにして、高度なスタイリングのためにカスタムクラスをブロックに追加できます。 クラスを使用して、アニメーションやその他の高度なブロックプロパティを追加することもできます。

使用例：厳密に定義されたデザイン言語を使用して、大規模なクライアント向けのWebサイトを作成します。 サイドエディターは、特にこのクライアントのために、デザイナーによって作成された事前定義された数のスタイルでブロックを作成できる必要があります。

既存のブロックのカスタマイズ可能なデータ属性

必要：任意のブロックラッパーのカスタマイズデータ属性を追加する可能性。

目的：上記のカスタムCSSクラスに代わるよりクリーンで柔軟な代替手段。 データ属性を使用すると、ページ上の任意の要素のスタイルを設定できます。 スタイリングに加えて、カスタムデータ属性を使用してJSの追加のメタデータを保存できます。

使用例：

• レスポンシブブロック：モバイル/デスクトップにのみ表示されるブロックをマークします
• 条件付きブロック：表示/非表示にするブロックをJS <div data-condition="if-adblock"... 、 <div data-condition="if-from-facebook"...マークします
• ブロックアニメーション：アニメーション化するブロックにマークを付ける<div data-animation="on-load animation-style-3"...
• ブロックデザイン： <div data-skin="dark"...