これを投稿してくれてありがとう！ 可能性に非常に興奮しています😍

これらの定義されたスタイルは、ユーザーのサイト全体にグローバルに適用できます（たとえば、フォントスケール、色、またはすべてのボタンの外観の宣言）。

現時点では、グーテンベルクはブロックごとのレベルでのスタイルのカスタマイズのみをサポートしています。 したがって、1つの投稿でボタンを更新しても、他のページのボタンはさかのぼって更新されません。

明確にするために、ユーザーはエディターUIを使用して、すべてのボタンの色、またはすべての段落のフォントサイズを更新できますか？ もしそうなら、彼らはまだブロックごとに調整を行うことができますか？

グーテンベルクブロックの保存/レンダリングと同様に、グローバルスタイルから出力されたHTMLを保存および保存できます。 このHTMLには、生成された変数が含まれています。これらの変数は、PHPを介してヘッドに挿入できます。つまり、ロード時に変数/スタイルの統合は必要ありません。 それはすでに行われています。

フロントエンドでCSS変数を使用する代わりに良い方法はありますか？ ここでの懸念は、WPを使用しているWebサイトがIEで機能しなくなることです。 プロジェクトとしてのWPがIEのサポートを停止することを決定したとしても（将来のある時点で可能性が高い）、ユーザーがそれを使用してIE互換のWebサイトを構築できなくなった場合、それを使用する政府やその他の公的機関にとって大きな問題になる可能性があります。 WP。

とてもクールで、この機能が待ちきれません！

フロントエンドでCSS変数を使用する代わりに良い方法はありますか？ ここでの懸念は、WPを使用しているWebサイトがIEで機能しなくなることです。 プロジェクトとしてのWPがIEのサポートを停止することを決定したとしても（将来のある時点で可能性が高い）、ユーザーがそれを使用してIE互換のWebサイトを構築できなくなった場合、それを使用する政府やその他の公的機関にとって大きな問題になる可能性があります。 WP。

これは重要なポイントであり、残念な現実です。 しかし、これがどの程度の影響を与えるかについての確かなデータを入手できれば素晴らしいと思います。

そうは言っても、 https：//www.npmjs.com/package/postcss-css-variablesのようなものが、最終的なcssを支援するためにビルドプロセスで使用できるものになるのではないかと思い

@tellthemachines + @nerradフィードバックありがとうございます！ 私は同意します、CSS変数と（古い）ブラウザサポートの欠如に関する懸念は非常に現実的です。

たぶん、CSS出力をオンザフライで処理して（そのパッケージを使用して）IEに適した出力にトランスパイルし、それを必要とするサイトで使用できるWPのプラグインがあるでしょうか？

それは面白いでしょう！ JSベースのポリフィルフィルクライアント側の必要性を減らすためのサーバー側の何か。

このプロジェクトのスタイリングメカニズムにCSS変数を使用できることを本当に望んでいます。 @nerradが提案したような手法、ポニー/ポリフィル、またはその他の手法を使用します。

そうは言っても、

最も重要な部分は、テーマ、ブロック、およびユーザーのカスタマイズ（グローバル+ 1回限り）が互いにうまく機能できるようにするシステムを作成することだと思います。 Block Developers andThemersの複雑さとオーバーヘッドを削減するシステム。 これにより、ユーザーによりまとまりのあるエクスペリエンスが提供されます。 おそらく、物事を頻繁にカスタマイズしたり、さまざまなブロック作成者からのさまざまなカスタムブロックを使用しようとしたりするユーザーです。

そのユーザーエクスペリエンスに焦点を当てることは、最終的にはグーテンベルクエクスペリエンスの大きな部分だと思います:)。 @nerradが書いたコメント（以下のリンク）でそれを思い出しました。そこで彼はWordPress内のユーザーエクスペリエンスの重要性を雄弁に強調しました。

https://github.com/WordPress/gutenberg/pull/16384#issuecomment -573430079

👋すべてのハロー！

更新があります。 私は@karmatosedと

グローバルスタイルがブロックやテーマでどのように機能するかのフロー+階層を示すプロトタイプを作成しました

プロトタイプとコンセプトを説明するスクリーンキャストを録画しました。

：video_camera：ビデオ
https://www.loom.com/share/73f721797f524dfeb2c3a222e9e24561

：raised_hands：デモ
https://yvz8y.csb.app/#/v2/post

長すぎる、見なかった

心配ない！ <3を要約しようと思います

スタイル階層は、次のピラミッドで表すことができます。

コア：グーテンベルク/グローバルスタイリングシステムに付属する基本スタイル
テーマ：
グローバル：サイト全体を対象とした、ユーザーが適用するカスタムスタイル
ドキュメント：特定のページ/テンプレートパーツ（FSE）を対象とした、ユーザーが適用するカスタムスタイル
ブロック：個々のブロックに対して、ユーザーが適用するカスタムスタイル

上記のピラミッドでは、他のレイヤーでスタイルが定義されていないため、コアスタイル（黒いテキスト）がずっと上に保持されていることがわかります。 次のような結果になります。

テーマを青に切り替えると、青のテーマのカスタムスタイル（この場合は青のテキスト）がコアのスタイルを上書きします。 他のカスタムスタイルが適用されていないため、上向きに持続します

次のようなサイトになります。

グローバルスタイルを適用すると、テーマの次のものが上書きされます。

ドキュメントスタイルを適用すると、グローバルのスタイルが上書きされます（該当する場合）。

最後に、特定のブロックをカスタマイズすると、他のレイヤーが上書きされます。

その結果：

カスタム設定を「リセット」または削除する機能もあります。 この例では、ユーザーがグローバルスタイル設定を削除したとします。 ただし、ドキュメントスタイルは残り、次のようにレンダリングされます。

テーマの切り替え

グローバル+ドキュメントスタイルはテーマと組み合わされています。 それらはユーザーテーマ構成と考えることができます。 ユーザーが別のテーマに切り替えると、そのテーマのグローバル+ドキュメントスタイルが適用されます。

ユーザーが既存のテーマ（「青」）をたくさんカスタマイズしたとしましょう。
ユーザーが新しいテーマ（「赤」）をインストールしたとします。 ダウンロードしたばかりのテーマ。

それらが切り替わると、グローバル+ドキュメントスタイルがリセットされます。

その理由は、彼らがまだ「赤」のテーマで何もカスタマイズしたことがないからです。

「青」に戻すと、以前のグローバル/ドキュメントスタイルが復元されます。

TLDR（長すぎる、読みませんでした）

• スタイル階層があります-コア、テーマ、グローバル、ドキュメント、ブロック
• グローバル、ドキュメント、ブロックのスタイルはユーザーがカスタマイズします
• グローバル+ドキュメントスタイルはテーマに関連付けられています
• これにより、副作用を最小限に抑えてテーマを切り替えることができます

どうもありがとうございました！ 考え+フィードバックを歓迎します🙌

素晴らしい内訳、@ ItsJonQに感謝します！
テーマとグローバルはほとんど同じではありませんか？
つまり、テーマの将来がどのようになるかを考えると、ほとんどのテーマは、カスタマイザーの使用からグローバルスタイルシステムに切り替わる可能性があります。 カスタマイザーに現在存在する設定は、このシステムに移行されます...それらは同じものと考えることができます。 テーマがカスタマイザーを使用している場合は「テーマ」、テーマがグローバルスタイルシステムを使用している場合は「グローバル」と呼ぶことができますが、どちらか一方であるため、カスタマイザーとグローバルの両方で同じ設定を持つテーマはありません。スタイルエディタを使用する理由がないため、両方を使用してもメリットはありません。

css-varsについて：IEのサポートについて心配する必要はありません...コンテンツを解析してcss-varsをそれらの値に置き換えることは、PHPで行うのは難しくありません。
Css-varsを使用できるIMOと、PHP側でサーバー側の検索と置換を行う単純なフィルターは完全に正常に機能します。

フロントエンドでCSS変数を使用する代わりに良い方法はありますか？ ここでの懸念は、WPを使用しているWebサイトがIEで機能しなくなることです。

これは、次のようなフォールバックを作成することで解決できます。

p {
    font-size: 16px; // Fallback for IE.
    font-size: var( --font-size-paragraph );
}

https://www.npmjs.com/package/postcss-custom-propertiesを使用して自動化できます。CSSは泥だらけになりますが、別のアプローチはSASSミックスインです（少しだけ<strong i="11">@include</strong> font-size-mixin( 16px );を書く必要があります）不自然。年配のWeb市民を克服するオプションがあるため、CSSカスタムプロパティを使用しても問題ありません。

＃9534とこの号をすべて読んだばかりですが、これまで読んだ限りではまだ触れられていない視点を取り上げたいと思います。

ユーザーのスタイリングとビルダーのスタイリング

上記のすべては、主に「ユーザー」の最大限の柔軟性と制御に関係しており、コアとテーマのスタイリングの形で強固な基盤を提供しますが、最終決定権とWebサイトのスタイリングを変更するための幅広い機能を提供します。

これは有効で、間違いなく最も一般的なユースケースですが、私はまったく異なる（反対ではない）方向から来ています。複数のユーザーがいるサイトと、デザイナー、開発者、編集者が明確に分離されているサイトです。 その設定では、ユーザーは特にサイトのスタイルをまったくまたは少なくともほとんど制御できないようにする必要があります。 それらは、（大幅にモデレートされた）ブロックのセットを使用してセマンティックコンテンツを作成し、デザイナーと開発者の手にスタイリングを残します。 一貫性を保つために、コンテンツとレイアウト/スタイリングの間の関心の分離を考えてください。

そのような状況では、スタイリングはテーマによってのみ定義されるべきであるため、上記の「スタイル階層」は必要または望まれるものではありません。 グローバル、ドキュメント、ブロックレベルで何かを変更することはできません。 そして、コアスタイリングでさえ意見が多すぎるかもしれません。 代わりに、テーマレベルは、すべてのスタイルを決定するための最初、最後、そして唯一のレベルである必要があります。

制御しているユーザーを受け入れるべきではありませんか？

一般的にはそうですが、ここではないかもしれません。 理由を見てみましょう。

ウェブサイトは、企業の設計に基づいている場合はのマイクロ管理のものユーザーのための必要は（コンテンツエディタを考える）が存在しませんボタンの背景色。 個々のユーザー制御では、グローバルな一貫性を維持することは不可能です。

（さらに個人的には、スタイリングに関連するもののようないくつかの選択肢を取り除くことで、ユーザーがスタイリングについて考える必要がなくなるため、コンテンツ編集者になるのに役立つと思います。これにより、技術的にはそうでなくても、実際にはユーザーがよりコントロールしやすくなります。_ 「オプションではなく決定」_）

コアスタイルは常に意見が分かれています。

ある程度のベースラインが必要であることは理解していますが、それでも削除しなくても大幅に変更する必要があることがよくあります。 簡単な例：現在、列ブロックとギャラリーブロックはレイアウトにCSS Flexboxを使用しているため、サイト全体のレイアウトをCSSグリッドに基づいている場合でも、コアブロックCSSは完全に廃止されます。

したがって、基本的にここでは、多層上書きの概念全体は、無効化、上書き、または可能な限り多くの制御を行うことができるという事実を超えて、無関係のどこかにあります。 また、ユーザーがスタイリングできるものがあるとしても、テーマレイヤーが一番上にあり、ユーザーが特定のスタイリングの選択肢を「通過」するだけであるなど、ピラミッドがシャッフルされているのがわかります。

したがって、このシステム全体がユーザーに現在よりもさらに多くのスタイリング制御を提供する場合は、ユーザー制御可能として導入されている設定に、無効化、制限、または上書きする方法があることを確認してください。 これは、カスタムの色/グラデーション、フォントサイズ、列数、ドロップキャップなど、現在のように制御を維持するのが難しくないようにするためです。

最終的な考え

物事を閉じるために、グーテンベルクが向かっている一般的な方向は、コンテンツ編集への非常に視覚的なアプローチであることを私は知っています。 WordPressは常にコンテンツとレイアウトの分離にまったく気づいていませんでしたが、現在、これが棺桶の最後の釘になるリスクがあると考えています。バインドされていないスタイリングパワーをユーザーに提供します。

その設定では、ユーザーは特にサイトのスタイルをまったくまたは少なくともほとんど制御できないようにする必要があります。

@kraftnerこれは本当に現在のところ、ユーザーが独自のWebサイトのレイアウトを細かく管理できるようにするプラグインが不足することはありません。

この新しいシステムをコアに実装することで、その慣行は最終的にWordPress自体によって容認されます。これは、設計システムが何であるか、したがってそれらの関連性と影響についての手がかりがない特定の種類のユーザーにとって、IMOは最善の利益ではありません。 そして、この種のユーザーはユーザーベースの大部分を占めているとさえ言えます。

これは、先に進む前に取り組むことが重要なことです。

詳細な考えをありがとう、 @ kraftner 、これらは良い点です。

上記のすべては、主に「ユーザー」の最大限の柔軟性と制御に関係しており、コアとテーマのスタイリングの形で強固な基盤を提供しますが、最終決定権とWebサイトのスタイリングを変更するための幅広い機能を提供します。

ここでは必ずしもそうとは限りません。 システムは、より適切に制御できる方法でブロックのスタイル機能を構造化する方法を提案しますが、誰がこの制御を行うかについてはあまり言及していません。 これらのほとんどが、必ずしもエンドユーザーにではなく、管理者やデザイナーにテーマビルダーツールとして公開される可能性は十分にあります。

これは、必ずしもすべてのスタイルの詳細をユーザーに制御させるというよりも、「テーマエディター」の進化と考えてください。 後者は非常に圧倒されるため、ほとんどのユーザーにとっても優れていませんが、テーマではブロック（特に存在すら知らないブロック）をより適切かつ簡単に制御する必要があります。

複数のユーザーがいて、デザイナー、開発者、編集者が明確に分離されているサイト。 その設定では、ユーザーは特にサイトのスタイルをまったくまたは少なくともほとんど制御できないようにする必要があります。

これは完全に合理的であり、言うまでもなく、通常のユーザーがPHPテーマエディターにアクセスできないのと同じように、サイトがこれらのツールを公開するかどうか、どの役割、どの容量に公開するかを制御できます。

そして、コアスタイリングでさえ意見が多すぎるかもしれません。 代わりに、テーマレベルは、すべてのスタイルを決定するための最初、最後、そして唯一のレベルである必要があります。

このように設定するのはあなたの管理下にあるはずです—デフォルトのブロックスタイル（おそらく構造的なものの外）をロードせず、グローバルおよびローカルのブロックスタイルオプションを編集する機能を制限してください。 あなたが概説しているのは、完全に有効なユースケースであり、簡単に対応して改善できるはずだと思います。

したがって、このシステム全体がユーザーに現在よりもさらに多くのスタイリング制御を提供する場合は、ユーザー制御可能として導入されている設定に、無効化、制限、または上書きする方法があることを確認してください。

間違いなく。 繰り返しになりますが、この基盤は、ブロックに対するテーマをより慎重に制御できるものだと思います。 副作用として、CSSを記述してPHPテンプレートを手動で変更するのではなく、GUIを使用してそのレベルの制御を行いたい場合に、ユーザーに公開される可能性のあるシステムができあがりますが、これは1つではありません。 -size-fits-all-use-cases、WordPressの世界は非常に多様であり、多様なユースケースに対応するツールが必要です。

自分からそのコントロールを放棄していると感じるものの例が他にもある場合は、それらを問​​題として報告し、議論して対処できるようにしてください。 私は、現在、無効にしたいすべてのことを実行するのに努力が必要であることに同意します。 より包括的なブロックスタイルシステムの動機の一部は、これを開いたり閉じたりすることによって、これを制御しやすくすることです。

あなたが概説しているのは、完全に有効なユースケースであり、簡単に対応して改善できるはずだと思います。

これは素晴らしい@mtiasに聞こえます。 私はこれをもう一度強調したかったのですが、特に、これらのユーザーが制御できる機能のいずれかが、プラグインまたは少なくともコアに入るのは、制御するオプションが付属している場合にのみ、ブロック要件である必要があると思います。 （構成、制限、無効化）。

私がここに来た理由は基本的に、あなた、私、そして@mがこの特定のトピックについて話している6月のWCEUのオフィスアワーであなたがほとんど同じことを言ったという事実によるものです。 しかし、私はすでに、これは、難しい要件や優先事項ではなく、後で「持っておくと便利な」ものと見なされているという印象を持っていました。

私が話しているコントロールの喪失の例に関しては、それらのほとんどはすでに問題を抱えていますが、残念ながら、それらの多くにとって、動きはほとんどまたはまったくありません。 また、対応するバグがどのように発生する可能性があるのか​​、開発中に新しい機能をオフにしようとしない理由もよくわかりません。
したがって、最終的には、非常に苛立たしい「モグラたたき」の状況のように感じます。すべての機能について、制御を取り戻すことができ、制御できない2つがエディターに入力されます。 私が話していることを強調するために、これは私が現在または以前に苦労していた問題のリストであり、それらを制御する方法がないか、ハックな方法しかありません。 （これは、まさにこのトピックに関する今後のWCトークのための

• ドロップキャップ：＃6184 /＃14654->＃6023（これは、WP 5.0よりずっと前に問題があることがわかっていた/報告されていましたが、なぜこの機能がまったく機能しなかったのですか？）
• テーブル＃16478 /＃19659の背景色（「トレードオフ」が問題なく、ブロッキングの問題ではなかったのはなぜですか？）
• フォントサイズ＃13824/ 46290 （これはどのようにすり抜けることができますか？オプションを追加した後、ものを無効にすることは最初に試みることの1つです、いいえ？）
• グラデーション：＃18213（この機能は、一般的なソリューションが無効になるのを待たず、代わりに実験的なフラグを追加し、ドキュメントを追加せ
• 列数＃10791->＃18892（一般的なソリューションの必要性は理解していますが、それまで新機能が保留されないのはなぜですか？）
• テンプレートのロック＃8112 /＃7845（これらは、CPT構造をロックダウンして、古いカスタムフィールドプラグインのアプローチを置き換えることができるようにするための緊急の要件です）

このリストの最後で、私はスタイリングの問題からいくらか逸脱していることを知っていますが、これらすべてが一緒になって、包括的なテーマを示していると思います。グーテンベルクを支配することは、依然として困難と不可能の間のどこかにあります。

誤解しないでください。グーテンベルクはまだ開発が進んでおり、これらすべての問題を個別に見ると、もちろんバグが発生していると言えます。完璧なものはなく、次々と取り組むことしかできません。 しかし、上記のすべての合計は、プロジェクトリーダーによって優先事項と見なされていないように感じます。最初にコンテンツ編集でこの重要な問題を解決する代わりに、私たちはすでに次のさらに複雑な領域に進んでいます。フルサイト編集の。

TL; DR：ユーザーの能力を管理することは、グーテンベルク全体で重要かつ緊急の必要性であり、これにもう少し焦点を当てる時が来たと思います。 これ以上の機能を実装する前に、制御を戻してください。 ：祈る：

雑草をあまり掘り下げたくないのですが、問題の説明の例の1つで、1つのことが飛び出しました。

ブロックがグローバルスタイルの使用を開始するには、システムによって出力されたCSS変数を使用するようにCSSをリファクタリングする必要があります。

そして、これは例の一部です。

border: 1px solid var(--wp-gs-color-primary-dark20);

特定のセマンティクスに基づいて色を作成するのは難しいため、テーマに関しては色は常に困難です。 基本的に、これはテーマスキーマとブロックのスタイルの間の関係をハードコーディングすることであり、制限される可能性があります。 間違っているかもしれませんが、定義できる色の数や種類が決まっているということだと思います。 また、ブロックの実装者は、テーマの構成と、これをどのような色にするかを判断する必要があります。 これらのスタイルがテーマのスキーマに接続されている別のレイヤーが必要かどうか疑問に思いました。

代わりに、これはおそらく次のように定義されます。

border: 1px solid var(--wp-button-block-border-color);

そして、関係が定義されます（テーマによって？）：

--wp-button-block-border-color: --wp-gs-color-primary-dark20

私がそれを明確に説明したかどうかはわかりません。 すでにかなり複雑に聞こえますが、解決する必要があると私は予想しています。

編集：さらに、私が提案したものがサードパーティのブロックでどのように機能するかはわかりませんが。 おそらく問題は、セマンティクスをより明確に定義する必要があるため、「暗い」または「明るい」という名前を付けないようにすることです。

私は視覚的であるため、これは、何かが繰り返されるたびに何が影響を受けるかを誰かが確認するのに役立つのではないかと思いました。 たとえば、レイヤーがどのようにフィルターダウンするか。 これは、 @ ItsJonQが作成したピラミッドカスケードに基づいて構築され、共同で実行されます。

これが行うことは、特定のアクションを調べることです。

• スタイルをグローバルに変更する：たとえば、ベースラインフォントサイズを大きくする。 この場合、それはグローバルとしてすべてに行き渡ります。 ドットは、それが最上位（階層を尊重）であり、したがって何が影響を受けるかを示します。
• スタイルを変更するローカル/ドキュメント：たとえば、ベースラインのフォントサイズは約ページで増加します。
• ブロックスタイルの変更：たとえば、引用ブロックでベースラインフォントサイズを変更するだけです。

相互作用のない2つの列があることに気付いた場合、これらは相互作用を行う前にずっと持続します。

ブロックに注意するもう1つのポイントには、いくつかのことが含まれます。

• スタイルバリエーション
• カスタムスタイリング
• 開発者（プラグイン）ブロックスタイル

この画像では、テーマはコアのデフォルトの隣のレイヤーであり、その上で一番上のブロックまでグローバルに変化するものです。

グローバルスタイル-最初の反復

今朝（トロント時間）、私は@nosoloswと@jorgefilipecostaとの電話に飛び乗って、この新しいグローバルスタイルの焦点に同期しました。

私たちはそれぞれ、ある時点でこの問題に独自に取り組んできました。 グローバルスタイルの多くの側面が（グーテンベルクの文脈で）まったく新しいものであり、さまざまな可動部分のすべてに含まれる複雑さを考えると、私たちの経験、考え、実験を共有するために、同期するのが良いと感じました。計画を開始します。

3つの部分

さまざまな実装の詳細とさまざまなエッジケースについて説明した後、最初に提案された概念を3つの主要部分に簡略化しました。

• リゾルバー（会議中は「マージ」と呼びました）
• ブロック
• コントロール

これらの3つのパーツは、「トランスフォーマー」、「フック」、「レンダラー」の部分が簡略化され、「リゾルバー」と「ブロック」に統合されたことを除いて、元のデザインの精神を今でも体現しています。

リゾルバ

リゾルバーは、 theme.jsonファイルと、データベースから以前に保存されたグローバルスタイルデータをチェックする役割を果たします。 次に、データセットをマージして、グーテンベルクが消費するものを準備します。

ブロック

ブロックは、私たち全員が知っていて大好きなグーテンベルクブロックです！ グローバルスタイリングシステムのコアとなるCSS変数の使用を開始するには、ブロックの.cssを更新する必要があります。

コントロール

コントロールは、ユーザーがグローバルスタイルの値を調整できるようにするユーザーインターフェイスです。 これらは、フルサイト編集エクスペリエンス内で表示されます。

注：コントロールは、個々のブロックインスタンスにも存在します。 これらは、ブロックのInspectorControls使用できるさまざまな制御フィールドです。 この更新では、ハードコードされた値ではなく、スタイル値の適用方法、つまりインラインスタイルのCSS変数の追加のみが調整されます。 （これについては後で詳しく説明します）

フロー（「バックエンド」）

以下では、グローバルスタイルシステムのバックエンドフローについて詳しく説明します。

リゾルバ

Resolverが起動すると、最初にローカルでtheme.jsonファイルを探します。

1. theme.json

この提案の場合、 theme.jsonファイルは、テーマが次のことを行うための簡単な方法です。

NS。 グローバルスタイルへのオプトイン
NS。 テーマ固有のスタイル値を宣言する

theme.jsonの例は、次のようになります。

{
    "name": "Awesome Theme",
    "global": {
        "color": {
            "background": "black",
            "text": "red"
        }
    },
    "blocks": {
        "core/paragraph": {
            "color": {
                "text": "hotpink"
            }
        }
    }
}

この例では、テーマはグローバルデフォルトのcolor.backgroundとcolor.textオーバーライドしています。 また、コア段落ブロックのcolor.text具体的に調整しています。

2.データベースの確認

theme.jsonが見つかった場合、リゾルバーはデータベースで以前に保存されたグローバルスタイルをチェックします。

テーマ固有のグローバルスタイル

グローバルスタイルは、テーマに固有の方法で保存されます。 これにより、スタイルの美的矛盾なしにテーマを安全に切り替えることができます。

これは、このデモで実証できます

（いくつかのグローバル/ドキュメントスタイルを適用し、テーマを切り替えてみてください）。

3.マージ

theme.jsonデータとデータベースデータはマージされ、グーテンベルクによって消費される準備が整います。

ブロック

1.レンダリング

ブロックは、グーテンベルクエディタによってロードおよびレンダリングされます。 ブロックは、グローバルなスタイル設定規則に対応する一連のCSS変数を使用します。

CSS変数

以下は、グローバルスタイルを使用したコア段落ブロックの例です。

p {
    color: currentColor;
}

.wp-gs p {
    color: var(--wp-gs-paragraph-color-text, var(--wp-gs-color-text));
}

.wp-gsスコープ

最初の実装では、特定のCSSセレクター（ .wp-gs ）をhtmlまたはbody DOMノードに適用して、「グローバルスタイルでサポートされる環境」を効果的に確立するというアイデアです。 。

これにより、グローバルスタイルのブロックに対するCSSの特異性が高まります。

上記の例では、グローバルスタイルを使用しない<p>レンダリング（現在のように）は、親セレクターからその色を継承します。

ただし、「グローバルスタイルでサポートされる環境」内では、 .wp-gs pルールが適用されます。

var(...)

ここで使用する規則は、グローバルスタイルのCSS変数の前に--wp-gs （WordPressグローバルスタイル）を付けることです。 上記の例では：

.wp-gs p {
    color: var(--wp-gs-paragraph-color-text, --wp-gs-color-text);
}

var()は次のように設定されます：

1. カスタムブロック固有のスタイルのレンダリングを処理する
2. 一般的な値へのフォールバック

フォールバックでブロック固有のスタイルを使用するという慣習により、システムはより細かい粒度の制御と安定性の両方を実現します。

2.ブロックxコントロール

ブロックインスタンスにカスタムの美的変更（textColorの更新など）がある場合、更新された属性はインラインスタイルとしてレンダリングされます。 現在の実装と提案されている実装の違いは、ハードコードされた値に対するCSS変数の使用です。

現在：

<p style="color: red;">...</p>

提案：

<p style="--wp-gs-paragraph-color-text: red;">...</p>

多くの点で、効果は同じです。 ただし、CSS変数を使用すると、CSSカスケード効果のほとんどを適用できます。

コントロール

コントロールは、フルサイト編集からのサイト編集フロー内に存在します。

1.更新

更新が行われると、更新された属性がリゾルバーに送信されます。

リゾルバーはそれを実行し（おそらく@wordpress/dataストアと調整します）、更新された消耗品データをグーテンベルクにプッシュします。

最後に、その更新されたデータ（および更新されたCSS変数）はハイドレイトされ、FSEユーザーインターフェイスと表示されているブロックにレンダリングされます。

フロー（「フロントエンド」）

私たちが（現在）思いついたソリューションでは、 Resolverがtheme.jsonとデータベースをチェック/読み取り、特定のページのスタイル値の最新の組み合わせを取得および作成する必要があります。

これは、ページの読み込み時にサーバー側で発生します。

次に、リゾルバーは、ロード時にページの<head>に挿入される<style>タグを作成します。 例：

<head>
    ...
    <style>
        :root {
            --wp-gs-color-text: black;
            --wp-gs-color-background: white;
            --wp-gs-color-primary: blue;
            ...
            --wp-gs-paragraph-color-text: hotpink;
        }
    </style>
</head>

最後に、ブロックからグローバルスタイルをアクティブ化するには、 .wp-gs CSSセレクターを挿入する必要があります。

- <html>
+ <html class="wp-gs">

以上です！

最初のイニシアチブ

@ nosolosw 、 @ jorgefilipecosta 、および私は協力して、上記の3つの部分を作成します。

• リゾルバー-@ jorgefilipecosta
• ブロック-@ nosolosw
• UIコントロール-@ itsjonq

私たちが構築しようとしている最初のイニシアチブでは、ユーザーは次のことができます。

1. デフォルトのテキスト色のグローバルスタイルを設定する
2. コアの段落+見出しブロックがグローバルスタイルを使用できるようにします
3. テーマがデフォルトのテキストの色、見出し、段落ブロックのテキストの色をカスタマイズできるようにする

ガッチャ

現時点での最大の落とし穴は、IEを適切にサポートする方法がわからないことです。 現在のシステムは、CSS変数と、IE11でサポートされていないブラウザーのネイティブ機能に大きく依存

利用可能なポリフィルはありますが、必要なレンダリングの統合を行うには十分ではありません（少なくとも、箱から出してはいけません）。

私たちはこのギャップに非常に注意を払っています。 今のところ、システムの仕組みとフローを検証したいので、CSS変数ベースのソリューションに進みます。 それらは機能するだけでなく、下位互換性を損なうべきではなく、Block Builders、Themers、およびUsersが（冗長なAPIやCSSの煩わしさなどによって）圧倒されるのではなく、感じるのに役立つはずです。

フィードバック+ありがとう！

まず、（これをスキミングしたかどうかに関係なく）読み終えたら、

私の意図は、設計、実験、および実装に関して可能な限り透明にすることです。

グローバルスタイルには多くの可動部分が含まれます。 私が提供できるコンテキストと更新が多ければ多いほど、このプロジェクトに関係する人々はより多くの情報を得ることができます。 これは、より良い議論と決定につながります。

いつものように、考えやフィードバックは大歓迎です！

再度、感謝します ：）

現時点での最大の落とし穴は、IEを適切にサポートする方法がわからないことです。 現在のシステムは、CSS変数と、IE11でサポートされていないブラウザーのネイティブ機能に大きく依存しています。

人々がチャイムを鳴らすのに役立つ場合に備えて、IE11に関する統計を明らかにするだけです。

• 2020年1月現在のIE11使用量1.43％（ CanIUse経由）
• IE11スクリーンリーダーの使用率は、2019年8月から9月の時点で10.9％です（ WebAim経由。 2017年には23.3％でした）。

IE11のサポートを「完全な視覚的」レベルではなく「機能的」レベルのままにすることは、一般的な業界標準です。

ここでも、特にスクリーンリーダーのユースケースを考慮すると、残りのテーマとブロックスタイルがフォールバックとして機能するので十分かもしれません。

ie11CustomPropertiesポリフィルなど、どれほどしっかりしているのかわかりませんが、開発者は必要に応じていつでも手動で含めることができます。 ある種のオプトイントグルを介してコアから提供することもできますか？

IE11の使用量2020年1月現在1.43％（CanIUse経由）

2019年1月から2020年1月までのすべてのデスクトップ訪問のうち、IE11の使用量は次のとおりです。

• 全世界で4.09％（ statcounter ）
• オランダでは6.17％（ statcounter ）

IE11のサポートを「完全な視覚的」レベルではなく「機能的」レベルのままにすることは、一般的な業界標準です。

同意しました

ie11CustomPropertiesポリフィルなどがどれほど堅固かはわかりませんが、開発者は必要に応じていつでも手動で含めることができます。 ある種のオプトイントグルを介してコアから提供することもできますか？

個人的な経験から、ほとんどのcss-varsポリフィルは正常に機能せず、機能するとパフォーマンスが大幅に低下します。

IE11のサポートを「完全な視覚的」レベルではなく「機能的」レベルのままにすることは、一般的な業界標準です。

それは私たちのほとんどがcss-varsとIEの難問に対処する方法です... css-varsによってオーバーライドされるいくつかの正気のグローバルCSSルールを定義します。 訪問者がIEを使用している場合でも、配色や間隔などを変えるだけで、Webサイトを完全に問題なく使用できます。
WordPressはIE11と互換性がありますが、「IE11と互換性がある」ということは、IE11が恐竜後のブラウザーがそれらをレンダリングする方法で物事を表示する必要があるという意味ではありません...それが機能している限り、私たちは明確です。

私はie11CustomPropertiesのautorです。 https://github.com/nuxodin/ie11CustomProperties/
一方、Polyfillは非常に高速で、多くのことをサポートします。
試してみたいという方は、問題があれば喜んでサポートさせていただきます。

@nuxodinは公平を

その後、リゾルバーはを作成します

@nuxodinうわー！ これは有望に見えます！ どうもありがとう。 IE11のテストを開始する準備ができたら、ie11CustomPropertiesを確実に探索します。

私はこれがそこでどのように機能するかを考え始めたばかりですが、この問題に早期にフラグを立てたかったのです。
@kokeありがとう🙏!! 私はあなたと他の人ができるだけ早く問題/落とし穴について考えてくれて本当に感謝しています。

訪問者がIEを使用している場合でも、配色や間隔などを変えるだけで、Webサイトを完全に問題なく使用できます。
WordPressはIE11と互換性がありますが、「IE11と互換性がある」ということは、IE11が恐竜後のブラウザーがそれらをレンダリングする方法で物事を表示する必要があるという意味ではありません...それが機能している限り、私たちは明確です。

@aristath 、私はこの感情に非常に同意します。 IE11が主要なブラウザーである場合、現代のWebが今日提供しているものの多くをすでに見逃していると思います。 そのフォールバックバージョンが機能し、アクセス可能である限り、それは問題ないはずですが、これは、あなたが他の誰かのWordPressサイトを閲覧している_サイト訪問者_である場合にのみ当てはまる可能性があります。

IE11ブラウザでWordPressを使用する_サイト管理者_の観点からは、編集/カスタマイズエクスペリエンスがどのようになるかを知るのは困難です。 IE11ブラウザーを使用する場合、WordPressサイト管理者のグローバルスタイルを無効にするために何かを追加する必要があるかもしれません。 そうしないと、彼らは自分たちが行ったカスタマイズを見ることができず、それは彼らにとって壊れた経験のように感じるかもしれません。

IE11のサポートを「完全な視覚的」レベルではなく「機能的」レベルのままにすることは、一般的な業界標準です。

ここでも、特にスクリーンリーダーのユースケースを考慮すると、残りのテーマとブロックスタイルがフォールバックとして機能するので十分かもしれません。

私は、エディター側でこのオプションを使用できることを嬉しく思います。 私の主な関心事は、フロントエンドでCSS変数を出力することです。これは、WPを使用してWebサイトを作成する人には、必要に応じてIEを完全にサポートするオプションがなくなったことを意味します。 そして、私の以前のコメント（十分に明確でなかった場合は申し訳ありません）で、これは、その完全なサポートを提供する必要があるかもしれない政府や他の公的機関にとって問題になる可能性があることを指摘するつもりでした。

また、パフォーマンスに影響するため、ポリフィルルートを使用することにも消極的です。 フロントエンドでCSS変数を使用せずにこれを実現する方法を少し調査する価値があるかもしれません（エディターで使用している場合でも）。

私の主な関心事は、フロントエンドでCSS変数を出力することです。これは、WPを使用してWebサイトを作成する人は、必要に応じてIEを完全にサポートするオプションがなくなったことを意味します。

有効にするとサーバー側で実行されるPHPパーサーを追加し、css-varsを実際の値に置き換えることができます。 これにより、IEで表示されるものはすべて、最新のブラウザーで表示されるものとまったく同じになります。
私が働いている代理店のために以前にそれをしました、そしてそれは完全にうまく働きます。
このようなタスクに必要なすべてのフィルターはすでに配置されているため、克服できないタスクではありません。

有効にするとサーバー側で実行されるPHPパーサーを追加し、css-varsを実際の値に置き換えることができます。 これにより、IEで表示されるものはすべて、最新のブラウザーで表示されるものとまったく同じになります。

これは間違いなく行く方法です。 1つの制限がありますが、CSS変数が：rootまたは同様のトップレベルセレクターに保持されている限り、私は推測します。 https://jhildenbiddle.github.io/css-vars-ponyfill/に似てい

有効にするとサーバー側で実行されるPHPパーサーを追加し、css-varsを実際の値に置き換えることができます。 これにより、IEで表示されるものはすべて、最新のブラウザーで表示されるものとまったく同じになります。 私が働いている代理店のために以前にそれをしました、そしてそれは完全にうまく働きます。

このPHPのアイデアは、フォールバックと同じ制限に苦しんでいない場合は特に、非常に興味深いものに聞こえます。 この動作のPRまたはコードスニペットを見てみたいです—かなり有望に聞こえます:-)

確かに、私はこのためのPHP実装に取り​​組むことができます...
基本的に2つのものが必要です。

1. CSS変数の値を取得します。
2. IE11のフォールバックスタイルを追加します。

1つ目は、フィルターの追加についてhttps://github.com/WordPress/gutenberg/pull/19883#pullrequestreview-349737431にコメントを残しました。 そのフィルターを使用して、css-varsとその値を取得できます。

2つ目は、それらのcss-varsを使用する実際のcssがどこに出力されるかによって異なります。 ブロックでインラインになりますか？ その場合、 render_blockフィルターを使用して、下位互換性のあるCSSの挿入を処理できます。
そうでない場合は、PRまたはこれらがどのように/どこに印刷されるかについてのアイデアはありますか？ それとも、テーマはwp_enqueue_styleを使用してスタイルシートをキューに入れるだけですか？
wp_enqueue_styleが使用されている場合でも実行可能ですが、キューに入れられたファイルの内容を解析し、css-varsを探し、これらの変数がファイルで使用されている場合は、追加する必要のあるスタイルを計算して印刷する必要があります。 TBHテーマが大きなファイルを追加するとオーバーヘッドが増える可能性があるため、この最後のオプションは避けたいと思います。

グローバルスタイルロードマップ

皆さん、これまでの考え/フィードバックに感謝します！

有効なシステムの特定の側面（CSSレンダリングなど）に関していくつかの議論がありました。 システム全体や部品がどのように組み合わされているかについては、あまり抵抗や懸念がないようです。これは良い兆候です。 私たちは正しい方向に進んでいるようです！

今週は、調査と計画に焦点を当てました。 技術的な詳細、実装の詳細、制約、要件、およびユースケースを検討します。 グローバルスタイルは、多くの可動部分を備えた実質的なプロジェクトです。 これは、ユーザーエクスペリエンスとエコシステムに大きな影響を与える可能性のあるプロジェクトです。

このため、明確な（高レベルの）ビジョンを提供することが非常に重要だと思います。関係者が理解し、フォローしやすくするためです。

システムがどのように機能するかについての概要と、作業のフェーズを順序付けるための大まかなロードマップをまとめました。

📹ビデオスクリーンキャスト/チュートリアル
https://www.loom.com/share/9e63b821916a4f70821a52ced069b92b

ビデオでは、システムのレンダリングフローをウォークスルーし、フェーズを確認します。

レンダリングフロー

図（上）は、グローバルスタイルのレンダリングフローを示しています。 システムのスタイル階層を視覚化します。 私はこれを「合成カスケード」と呼びました。

それは左側から始まります（グーテンベルクとブロックで）。 ブロックのスタイルは、テーマレイヤー、グローバルレイヤー、スコープレイヤー、および最後にグーテンベルクエディター内でローカライズされた変更を通過するときに変更できます。 最後に、これらの蓄積された変更はすべて、ユーザーのサイトのフロントエンドにレンダリングされます。

「スコープ付き」

「スコープ」という用語は、FSEエクスペリエンスの「ドキュメント」または「テンプレート」の部分を指します。 基本的に、ブロックを含む「コンテナ」ブロック。

サードパーティブロック

サードパーティのブロックは、コア以外のブロックです。 システムは、独自のカスタムスタイルを登録する方法を提供し、グローバルスタイル編集インターフェイスを介してそれらのスタイルをカスタマイズできるようにする必要があります。

サードパーティグローバル

サードパーティグローバルは、ブロックに関連付けられていない非コアスタイルを指します。 たとえば、サイト全体のアニメーション速度のためにカスタムグローバルスタイルを追加します。 または、おそらくサイト全体のタイポグラフィフォントの組み合わせ（ヘッダー/本文）。

フェーズ

私は作業を6つの異なるフェーズ（上記）に分解しました。 注：活気は、その領域に必要な焦点を強調します。 たとえば、最初のフェーズである赤では、コア/ブロック領域が非常に活気に満ちています。

🔴赤

最初のフェーズ！ 目標は、コア内に基本システムを作成し、いくつかのコアブロックをグローバルスタイリングシステムに組み込むことです。 また、これらの値を更新するためのシンプルなインターフェイスを提供する必要があります。 最後に、最初のクライアント側（Gutenberg）およびサーバー側（Site）スタイルのレンダリングシステムを作成する必要があります。

まず、 core/paragraph core/headingブロックと

これをMVPと考えてください！

🟠オレンジ

第二段階！ このフェーズでは、システムにテーマサポートを導入することに焦点を当てます。 テーマオプションとtheme.jsonファイルがコアデフォルトとどのように相互作用するか。 最後に、テーマで定義された値がどのようにレンダリングされ、グローバルスタイルエディターUI内で変更できるか。

🟡黄色

第三段階！ このフェーズでは、グローバルスタイルエディターに焦点を当てます。 ブロックスタイル値の表示方法と変更方法。 ユーザーがカスタマイズしたグローバルスタイルがテーマとコアバリューにどのように影響するか。

これは、多くのビジュアル/インタラクションデザインを含む最初のフェーズです。

🟢緑

第4フェーズ！ このフェーズでは、引き続きグローバルスタイルエディターに焦点を当てますが、ドキュメント/テンプレートパーツ、およびそれがFSEエクスペリエンスにどのように影響するかについて説明します。 システムは、スコープ変更がスタイル階層で正しく機能することを確認する必要があります。

🔵ブルー

第5フェーズ！ このフェーズでは、スタイルレンダリングの側面に重点を置きます。 ここでは、CSS変数が正しい解決策である場所を再検討します。 そうでない場合は、システムの残りの部分で作業しながら、その経験を再現するために何ができるでしょうか。 ソリューションに取り組んでいる間、スコープとテーマのオーバーライドが期待どおりに機能することを確認する必要があります。 最後に、このフェーズでは、サードパーティのブロックサポートの調査を開始し、システムの他の部分とどのように連携するかを確認します。

🟣紫

第6フェーズ！ このフェーズでは、レンダリングに引き続き重点を置き、ユーザーのサイトのフロントエンドで正しく機能するようにします。 また、（潜在的に）新しいレンダリングメカニズムが残りのスタイル階層で機能することも保証します。 最後に、サードパーティのブロックとサードパーティのグローバルサポートを統合します。

私たちはどこにいますか？

現在のところ、上記のフェーズで、最初のイニシアチブで🔴レッドフェーズを

@jorgefilipecostaは、このフェーズのすべての側面に触れる最初のPRを作成しました。

@karmatosedは、グローバルスタイル編集インターフェイスのデザインを検討してい

@nosoloswは、システムのResolverxクライアント側レンダラーの側面に取り組んでいます。

私はコントロールを見るために先を突っ込んできました。

タイムライン

プロジェクトの正確なタイムラインはまだ提供できません。 ビルド、テスト、マージを開始すると、物事の感覚がよくなると思います。 それまでは、うまくいけば、フェーズの内訳が役立つでしょう。

いつものように、考えやフィードバックは大歓迎です！ 最後までやり遂げましたので、よろしくお願いします！ ：心臓：

確かに、私はこのためのPHP実装に取り​​組むことができます...
基本的に2つのものが必要です。

1. CSS変数の値を取得します。
2. IE11のフォールバックスタイルを追加します。

1つ目は、フィルターの追加について＃19883（レビュー）にコメントを残しました。 そのフィルターを使用して、css-varsとその値を取得できます。

2つ目は、それらのcss-varsを使用する実際のcssがどこに出力されるかによって異なります。 ブロックでインラインになりますか？ その場合、 render_blockフィルターを使用して、下位互換性のあるCSSの挿入を処理できます。
そうでない場合は、PRまたはこれらがどのように/どこに印刷されるかについてのアイデアはありますか？ それとも、テーマはwp_enqueue_styleを使用してスタイルシートをキューに入れるだけですか？
wp_enqueue_styleが使用されている場合でも実行可能ですが、キューに入れられたファイルの内容を解析し、css-varsを探し、これらの変数がファイルで使用されている場合は、追加する必要のあるスタイルを計算して印刷する必要があります。 TBHテーマが大きなファイルを追加するとオーバーヘッドが増える可能性があるため、この最後のオプションは避けたいと思います。

こんにちは@aristath 、

あなたのアイデアを共有し、この問題に対処しようとしてくれてありがとう。

2番目のシナリオが存在していると思います。 wp_enqueue_styleが使用されます。 変数を使用するスタイルは通常のブロックスタイルであり、ほとんどの場合、wp_enqueue_styleを使用してキューに入れられます。 さらに、これらの変数を含むコアブロックスタイルがWordPressスタイルの連結システムを使用して読み込まれるというさらに大きな問題があるため、これらは巨大なスプレッドシートの一部です。

もう1つのポイントは、varの単純な置換は機能しない可能性があるということです。これは、将来、特定のブロック内のもの（たとえば、特定のグループ内の原色が青）のグローバルスタイルをカスタマイズできるようになるためです。 変数が持つことができる値は静的ではありません。 それらはコンテキストに依存します。

IEで機能するCSS変数のポリフィルを作成する必要があると思います。 特定のニーズに合わせてカスタマイズすることもできます。たとえば、変数の値を使用してサーバーからjavascriptオブジェクトを渡すことができます。

その後、リゾルバーはを作成します

@ItsJonQ

それは右側から始まります（グーテンベルクとブロックで）

左側から始まるということですか？

私がまだ理解していないこと：カラーパレット、特に背景色はこれにどのように影響しますか？

• グローバルレベルでさまざまな要素の色を制御できる場合、エディターのカラーパレットとして使用されるカラーパレットを定義することもできますか？
• 背景色のカラーパレットがある場合、要素がさまざまな背景でどのように見えるかをグローバルレベルで制御できますか？

ボタンを例にとってみましょう。 デフォルトのボタンの背景として赤い色を選択した場合、オレンジなどのさまざまな背景でどのように表示されますか？

オレンジ色の背景のボタンの背景色をグローバルに制御できますか？ または、ボタンが異なる背景に表示される場合でも、各ボタンの背景色を個別に選択する必要がありますか？

カラーパレット、特に背景色はこれにどのように影響しますか？

@gchtrそれは素晴らしい質問+例です！ 私があなたの質問/ユースケースを正しく理解している場合...次の場合に対処する必要があるようです：

• すべてのボタンは、背景がいます
• ただし、背景が衝突するもの（オレンジなど）に表示される場合は、別の色（白、黒のテキストなど）をレンダリングする必要があります。

そこで、カスタムグローバルスタイルを「スコープ」するというアイデアが役立ちます。

HTML / CSSに関しては、次のことを想像できます。

<button>...</button>
<div class="orange-section">
    <button>...</button>
</div>

button { background: red; }

.orange-section button {
    background: white;
    color: black;
}

トリッキーな部分はです。 このモデル/スタイル階層をGutenbergグローバルスタイルシステムでどのように複製しますか？
グーテンベルクの文脈では、これらのビットはブロックになります。

ある意味で...次のようになります。

<Block>
<Block>
    <Block />
</Block>

またはそれを見る別の方法...

<Block>
<ContainerBlock>
    <Block />
</ContainerBlock>

つまり、「コンテナ」ブロックに固有のスタイルのスコープを設定して、（ターゲットを絞った）子ブロックがこれらのスタイルを継承できるようにする必要があります。 スタイルシステムは、UIパースペクティブ（スタイル編集コントロール）およびレンダリングパースペクティブからこれをサポートする必要があります。

うまくいけば、それは理にかなっています!!! 🙏

左側から始まるということですか？

@ZebulanStanphillはい！ どうもありがとう！ 私はそれを修正しました:)

ねえ@ItsJonQ 、

これは非常にエキサイティングに見えますが、グローバルスタイルシステムがカラーパレットでどのように機能するのかも疑問に思っています。 グーテンベルクを使用してクライアント用のミニページビルダーを作成しました。クライアントはレイアウトを完全に制御できますが、配色は制御できません。 彼らがカラーパレットで利用可能な色に変更を加える必要がある場合、私は彼らのためにそれをしなければなりません、しかし彼らが彼ら自身でそれをする可能性があるならば私はむしろむしろ好むでしょう。

見出しとボタンの背景に同じ色が使用される可能性があるため、カラーパレットコンポーネントは私の設定で大きな役割を果たします。これを少し明確にする例を次に示します。

Oxygenはすでにそれを素晴らしい方法で行っており、グローバルな色を変更し、その効果をライブで確認することができます。 この振る舞いが何らかの形でグローバルスタイルシステムにももたらされることを願っています。

Oxygenはすでにそれを素晴らしい方法で行っており、グローバルな色を変更し、その効果をライブで確認することができます。 この振る舞いが何らかの形でグローバルスタイルシステムにももたらされることを願っています。

@dnnsjskあなたのサポートとその素敵な例をありがとう！

はい、この相互作用をサポートする必要があります。

最終的に、この全体的な取り組みは、（エンド）ユーザーエクスペリエンスを向上させることです。 調整によって期待するものが変わるだけでなく、それらの調整を行っている間、エクスペリエンスは快適でなければ

確かに、この問題で共有したテキストの壁に基づいて、この経験を見つけるのは難しいです😅。 私は主に技術的な側面とそれらの要素がどのように連携するかに焦点を当ててきました。 優れたエンドユーザーエクスペリエンスに加えて、開発者エクスペリエンスも優れている必要があります。 私たちが確立するワークフローは、ThemersとBlockの開発者にとってより簡単でより良いものだと感じています。

@ karmatosed 、 @ shaunandrews 、その他はここでこの体験のデザイン/ UXを探求し始めています：

https://github.com/WordPress/gutenberg/issues/19255

私たちはまだ非常に早いです！ 最近のロードマップは、devxの設計作業が連携するのに役立つと思います。

こんにちは！ https://github.com/WordPress/gutenberg/issues/19255#issuecomment -582315718に長いコメントを書いたところですが、おそらく代わりにここに投稿する必要がありますか？ いずれにせよ、そのコメントからの重要なポイントは、基本的なブロックパターンを設計する努力の一環として、グローバルスタイルシステムで実現できることを望んでいるアイテムのウィッシュリストを誤って作成したことです（フォントの太さ、線など） -高さ、ドロップキャップサイズ）、主に私がすでに言及したもの。

スライダーを「少し粘着性がある」ようにして（滑らかなスライダーは広い範囲でひどいユーザーエクスペリエンスです）、現在の値を表示してください。

@ carike-codes更新されたRangeControlコンポーネントにこれらの機能があります🙌
https://github.com/WordPress/gutenberg/pull/19916

スライダーは、デフォルトのHTML input[type="range"]とまったく同じように動作します。 min: 0, max: 1000, step: 1ように多くのステップがある状況では、インクリメントする1000値があるため、「スムーズ」に感じられます。

（お役に立てば幸いです）

_注：このコメントはreact-nativeの互換性に関するものです_

そのAPIには、テーマのデフォルトスタイルは含まれず、ユーザーのカスタマイズのみが含まれます。 したがって、WordPressのデフォルトとテーマのデフォルトの結合を提供する別のAPIがおそらく必要になります。 この問題は、FSEで発生する問題と非常によく似ています...

それで、これを正しく理解していれば、そのAPIを使用するリゾルバーのクライアント側バージョンを実装したいと思いますか？ コントロールでグローバルスタイルが更新されるときに、FSEがブロックスタイルを更新できるようにするのにも役立ちませんか？

その場合、グーテンベルクネイティブはこのクライアント側リゾルバーを再利用したいと思うでしょう。

react-nativeでサポートされていないcss変数の問題がまだあります。 postcss変換は、APIへの新しいフェッチで更新するために動的である必要があるため、機能しません。

ネイティブではインラインスタイルしか使用できないという事実を考慮すると、エディターの特定のブロックのスタイルを入力するための追加のモジュールが必要になります。

ユーザーがInspectorControlsでこのブロックのテキストの色を上書きしたブロックスタイリングの例を見てみましょう。次のようになります。

--wp-gs-color-text: #fff;
--wp-gs-background-color: yellow;
--wp-gs-paragraph-color-text: #000;

.wp-gs p {
    color: var(--wp-gs-color-text);
    background-color: var(--wp-gs-background-color);
}

<!-- wp:paragraph {"textColor":"red"} -->
<p style="--wp-gs-paragraph-color-text: red;">
Lorem ipsum dolor sit amet</p>
<!-- /wp:paragraph -->

モバイルでは、まったく同じコードを生成する必要があるため、 saveは変更しないでください。 ただし、 editはcss変数の使用を避ける必要があります。

<RichText style={ { color: "red", backgroundColor: "yellow" } } .../>

Xプラットフォームブロックの作成に関して、どのような影響があるのか​​はまだわかりません。 特定のブロックのすべてのスタイルを自動的に解決するこのようなモジュールを作成することは、少なくともいくつかのCSSプロパティに制限し、RichTextコンポーネント内にカスタマイズ可能な要素がいくつかない場合は実行可能です。
Webとモバイルはおそらくこれを共有できますが、パフォーマンスに影響を与える可能性があります。その場合、これはモバイルでのみアクティブ化する必要があります。 @jorgefilipecosta @kokeこれについて何か考えがあるかどうか

@kokeこれについて何か考えがあるかどうか

はい、私は同様の懸念を共有していますが、まだ明確な答えはありません。 私の現在の本能は、CSS変数（およびダークモード、メディアクエリ、 @ supportなど）を実際にサポートするためにネイティブで使用するCSSパーサーを実際に改善することが最善の策かもしれないということです。 CSSを1つのステップでStyleSheetに変換しようとする代わりに、実行時にいくつかの変数とクエリを調整できるDynamicStyleSheetを生成させることができます。 これは大変な努力のように思えるので、私はまだもっと簡単かもしれない代替案を探しています。

これを使用して、ブートストラップで定義されたscss変数を上書きできますか？

ブロックベースのWebサイトでの複雑なグローバルシステムの冒険-パート1を読み終えたところですが、ここで共有することをお勧めします。 長いですが、興味深い読み物であり、ここにいる人々にいくつかのアイデアを与えるかもしれません。

私たちはグローバルスタイルで遊んでいて、いくつかの考え/アイデア/質問があります。

グローバルスタイルの現在の方向性

私が現在の方向性を理解している場合、アイデアは、グローバルスタイル変数をブロックにハードコーディングして、それらが使用されるようにすることです。

これについての難しい部分は、きめ細かいコントロールが非常に多くて広範囲になり、カスタムの場所で利用するのが難しいことです。 たとえば、これらはきめ細かいコントロールが機能する方法である可能性があります（概念的に言えば、構文上の例ではありません）。

gs-another-background-color
gs-yet-another-background-color
gs-h1-font-color
gs-h1-font-color-exception
gs-yet-another-h1-font-color-variation
...many more variables required

グローバルスタイルの方向性に関する別のアイデア

そのアプローチで遊んだ後、私たちはグローバルスタイルがより「不可知論的」であり、次のように単純化できるかどうか疑問に思いました。

gs-color-2
gs-color-3
...more variables required, but no values are ever duplicated

ここでの考え方は、ブロックが背景をgs-color-1 、 gs-color-2 、またはgs-color-3いずれにするかを選択できるということです。 おそらく、グローバルスタイルセレクターUIを介しても。 これは、それがどのように見えるかについての_本当に_大まかなモックアップです。

このアプローチのいくつかの利点：

• 必要なグローバルスタイル変数の合計が少なくなります。
• スタイルの適用はブロックに移動し、設計の柔軟性が大幅に向上します。
• 値を複製する必要はありません（ #fffffをgs-color-1として、何度も選択するのではなく、1回選択してください）
• ブロックユーザーは、適切と思われる場所でグローバルスタイルを使用できる柔軟性を備えています。 たとえば、背景、フォント、または境界線の場合がありますが、 #fffff 3回別々に定義する代わりに、すべてでgs-color-1使用できます。

2つから選択する必要がある場合は、アプローチBを使用しますが、テーマのために着陸したこのバージョンは、アプローチBの上に構築されたアプローチAのより詳細でないバージョンです。

まず、色の束を定義します。

--white: #ffffff;
--gray-light: #d4d4d4;
--gray-dark: #333333;
--black: #141414;
--aqua: #7fdbff;
--blue: #0074d9;
--navy: #00203f;
--teal: #38cccc;
--fuchsia: #f012bc;
--purple: #b00dc9;
--maroon: #85144b;

（Wordpress全体で提案されたより一般的な--color-1タイプのセットアップの利点を見ることができますが、原則は同じです。）

次に、それらを次のような比較的一般的な高レベル変数にマップします。

--text-color: var(--black);
--text-color-secondary: var(--gray-dark);
--accent-color: var(--aqua);
--background-color: var(--white);
--heading-color: var(--navy);
--action-color: var(--purple);
--action-color--invoked: var(--maroon); /* hover & focus states */

次に、テーマの要件に応じて、これらをより具体的な変数にカスケードできます。

--focus-ring-color: var(--accent-color);

--link-color: var(--action-color);
--link-color--hover: var(--action-color--invoked);

--input-color: var(--text-color);
--input-border-color: var(--input-color);
--input-background-color: var(--background-color);

--button-color: var(--action-color);
--button-color--hover: var(--action-color--hover);

/* whatever other theme-specific variables I want to make up */

テーマの作成者は、ここで好きなだけ細かくすることができます（--h2-color、-page-title-color、-subhead-colorなど）が、カスケードを念頭に置いて、常にコアから構築しようとすることができます。 。 たとえば、テーマに暗い配色のブロックを追加した場合：

.is-theme-dark {
    --text-color: var(--white);
    --text-color--secondary: var(--gray-light);
    --accent-color: var(--aqua);
    --background-color: var(--navy);
    --heading-color: var(--blue);
    --action-color: var(--fuchsia);
    --action-color--invoked: var(--purple);
    /* whatever other theme-specific variables I want to switch */
}

ギアを切り替えると、そのようにトップレベルの色を使用したレシピプラグインを作成している人は、テーマの作成者の.is-theme-darkグループブロックにドロップすると、正常に機能する可能性が十分にあります。

.recipe {
   color: var(--text-color);
}
.recipe__image {
    border: 0.5rem solid var(--accent-color);
}
.recipe-print-button {
   color: var(--action-color);
}
.recipe-print-button__icon {
   color: var(--accent-color);
}

IE11のサポートについて：

このソリューションを確認しましたか： https ：

ブロックスタイルシステムに関して私たちがどこにいるのかを明確にするよう提案されました。 私は2つの主要なスレッドにあるものを統合しようとしています：ビジョンhttps://github.com/WordPress/gutenberg/issues/20331翌日更新します。

この問題が作成されて以来、実装に関して多くの進歩を遂げまし、エディターを制御する役割についてのより成熟した理解があり新しい設計ツールをしました。ブロックスタイルシステムのブロックレベルとグローバルレベルを接続すると、私が見逃している以上のものがあります。

この問題はその目的を果たしたので、私はそれを閉じます。 上記のヒントは、私たちが歩く必要のある具体的なステップを明らかにするために、この会話がいかに基本的であったかを証明するものとなるはずです。