WordPress テーマの CSS の記述方法は、大幅な変更の最中にあります。 私は最近、次のテクニックを共有しました WordPress に Fluid タイプのサポートを追加する 経由して theme.json、新しいファイル WordPressは懸命に推進してきました フルサイト編集 (FSE) 機能をサポートする WordPress テーマでスタイルを定義するための信頼できる中心的な情報源になること。

待って、いいえ style.css ファイル？ 私たちはまだそれを持っています。 実際には、 style.css is まだ必要なファイル ただし、その役割はテーマの登録に使用されるメタ情報に大幅に縮小されます。 とは言え、事実は theme.json はまだ活発に開発中です。 styles.css またはブロックレベルでも。

では、WordPress FSE 時代のスタイリングは実際にはどのように見えるのでしょうか? それが、この記事でカバーしたいことです。 ブロック テーマのスタイリングに関するドキュメントが不足しています。 WordPress テーマ開発者ハンドブック、したがって、ここで取り上げていることはすべて、現在の状況と、WordPress テーマの将来についての議論について私が収集したものです.

WordPress スタイルの進化

に含まれる新しい開発機能 WordPressの6.1 で完全に定義されているスタイルのシステムに近づけます。 theme.json、しかし、完全に信頼できるようになるまでには、まだやるべきことがたくさんあります。 将来のリリースで何が来るかを知る XNUMX つの方法は、 グーテンベルクプラグイン. これは、実験的な機能の予行演習が行われることが多い場所です。

私たちがどこにいるのかを感じるもうXNUMXつの方法は、 デフォルトの WordPress テーマ. 現在、サイト全体の編集をサポートする XNUMX つの既定のテーマがあります。

ただし、CSS の取引を開始しないでください。 style.css の JSON プロパティと値のペア theme.json まだ。 でサポートする必要がある CSS スタイリング規則がまだあります。 theme.json そうすることを考える前に。 残りの重要な問題は現在、すべての CSS スタイル ルールを完全に移行することを目的として議論されています。 theme.json のさまざまなソースを統合する theme.json グローバル スタイルを設定するための UI 直接 WordPressサイトエディター.

そのため、私たちは比較的厳しい状況に置かれています。 あるだけでなく テーマ スタイルをオーバーライドする明確な方法がない、しかし、これらのスタイルのソースがどこから来たのかは不明です。 theme.json ファイル、 style.css、Gutenberg プラグイン、またはその他の場所でしょうか?

なぜ theme.json style.css?

なぜ WordPress が従来の CSS ファイルではなく、JSON ベースのスタイル定義に移行しているのか疑問に思われるかもしれません。 Gutenberg 開発チームの Ben Dwyer は、その理由を雄弁に説明しています。 theme.json アプローチはテーマ開発者にとってメリットがあります.

Ben の投稿は読む価値がありますが、要点は次の引用にあります。

CSS のオーバーライドは、レイアウト、プリセット、またはブロック スタイルのいずれであっても、統合と相互運用性に障害をもたらします。フロントエンドとエディターの間の視覚的な同等性を維持することがより困難になり、ブロック内部へのアップグレードがオーバーライドと競合する可能性があります。 さらに、カスタム CSS は、他のブロック テーマ間での移植性が低くなります。

テーマ作成者に使用を奨励することによって theme.json API が可能な場合、「ベース > テーマ > ユーザー」で定義されたスタイルの階層を正しく解決できます。

CSS を JSON に移行する主な利点の XNUMX つは、JSON が機械可読形式であることです。つまり、API をフェッチすることで WordPress サイト エディターの UI に公開できるため、ユーザーはデフォルト値を変更したりサイトの外観をカスタマイズしたりできます。あらゆる CSS を作成します。 また、ブロックを一貫してスタイルする方法を提供すると同時に、ユーザー設定が theme.json. のテーマレベルのスタイル間の相互作用 theme.json グローバル スタイル UI のユーザー定義スタイルは、JSON アプローチを非常に魅力的なものにしています。

開発者は JSON の一貫性を維持し、ユーザーはコードレスのカスタマイズで柔軟性を得ることができます。 それは双方にとって好都合です。

もちろん他にもメリットはありますが、 WP Engine の Mike McAlister は、この Twitter スレッドにいくつかのリストを掲載しています. これでさらに多くの利点を見つけることができます 詳細な議論 Make WordPress Core ブログをご覧ください。 そして、それを読んだら、JSON アプローチの利点を比較してください。 クラシック テーマでスタイルを定義およびオーバーライドするための利用可能な方法.

JSON 要素を使用したスタイルの定義

テーマのどの部分まで、すでに多くの進歩が見られます theme.json スタイリングが可能です。 WordPress 6.1 より前は、スタイルの見出しとリンクしかできませんでした。 さて、WordPress 6.1 では、 ボタン、キャプション、引用、見出しを追加できます ミックスに。

そして、定義することでそれを行います JSON 要素. 要素は、WordPress ブロックに存在する個々のコンポーネントと考えてください。 見出し、段落、ボタンを含むブロックがあるとします。 これらの個々のピースは要素であり、 elements 内のオブジェクト theme.json スタイルを定義する場所:

{
  "version": 2,
  "settings": {},
  // etc.
  "styles": {
    // etc.
    "elements": {
        "button": { ... },
        "h1": { ... },
        "heading": { ... },
    },
  },
  "templateParts": {}
}

JSON 要素を説明するより良い方法は、ブロックの複雑さを必要としないテーマとブロックの低レベル コンポーネントとして説明することです。 それらは HTML プリミティブの表現です ブロック内で定義されていませんが、ブロック間で使用できます。 それらが WordPress (および Gutenberg プラグイン) でどのようにサポートされているかについては、 ブロックエディタハンドブック この 完全なサイト編集チュートリアル カロライナ・ナイマーク著。

たとえば、リンクは elements オブジェクトですが、それ自体はブロックではありません。 ただし、リンクはブロックで使用でき、ブロックで定義されたスタイルを継承します。 elements.link 内のオブジェクト theme.json. ただし、これは要素の定義を完全にカプセル化するものではありません。一部の要素は、Heading ブロックや Button ブロックなどのブロックとしても登録されますが、これらのブロックは他のブロック内で引き続き使用できます。

以下は、現在スタイルに使用できる要素の表です。 theme.json, カロライナの礼儀:

ご覧のとおり、まだ初期段階にあり、Gutenberg プラグインから WordPress Core に移行する必要があるものはまだたくさんあります。 しかし、CSS ファイルや DevTools でセレクターを探すことなく、テーマ内のすべての見出しをグローバルにスタイル設定するなどの処理を行うと、いかに迅速に処理できるかがわかります。

さらに、の構造がどのように見えるかを確認することもできます。 theme.json グローバルな要素 (例: headings) 個々の要素 (例: h1)、およびブロック レベルのスタイル (例 h1 ブロックに含まれています）。

JSON 要素に関する追加情報は、 この Make WordPress の提案 および このオープンチケット Gutenberg プラグインの GitHub リポジトリにあります。

JSON と CSS の特異性

CSS の特異性について話を続けましょう。 スタイリングへの JSON アプローチが階層を確立することは前に述べました。 そして、それは本当です。 の JSON 要素で定義されているスタイル theme.json デフォルトのテーマ スタイルと見なされます。 また、グローバル スタイル UI でユーザーが設定したものはすべて、デフォルトをオーバーライドします。

言い換えると： ユーザー スタイルは、デフォルトのテーマ スタイルよりも具体的です. これがどのように機能するかを理解するために、Button ブロックを見てみましょう。

私は使っています 空のテーマ、CSS スタイルのない空白の WordPress テーマ。 新しいページに Button ブロックを追加します。

OK、WordPress Core には軽いスタイリングが付属していることはわかっています。 ここで、WordPress 3 からデフォルトの TT6.1 テーマに切り替えて有効化します。 ボタンでページを更新すると、ボタンのスタイルが変わります。

あなたは正確に見ることができます それらの新しいスタイルはどこから来ているのか TT3で theme.json ファイル。 これは、JSON 要素のスタイルが WordPress のコア スタイルよりも優先されることを示しています。

次に、TT3 をオーバーライドして変更します。 theme.json ボタンブロックのデフォルトの背景色が赤に設定されている子テーマのファイル。

しかし、最後のスクリーンショットの検索ボタンに注目してください。 それも赤いはずですよね？ 私が行った変更がグローバルレベルである場合、それは別のレベルでスタイルが設定されていることを意味する必要があります. 変えたいなら 両言語で ボタンの代わりに、サイト エディターのグローバル スタイル UI を使用してユーザー レベルで行うことができます。

両方のボタンの背景色を青に変更し、グローバル スタイル UI を使用してテキストも変更しました。 そこの青がテーマ スタイルよりも優先されることに注意してください。

スタイルエンジン

これは、WordPress のブロック テーマで CSS の特異性がどのように管理されるかについて、非常に簡単ですが、良いアイデアです。 でもまだ不明なので全貌ではない コラボレー それらのスタイルが生成されます。 WordPress には独自のデフォルト スタイルがあり、どこかでデータを消費します。 theme.json より多くのスタイル ルールを取得し、グローバル スタイルで設定されたものをオーバーライドします。

それらのスタイルはインラインですか？ それらは別のスタイルシートにありますか? たぶん、それらはページに注入されます ?

それが新しいものです スタイルエンジン うまくいけば解決するでしょう。 Style Engine は WordPress 6.1 の新しい API で、スタイルの生成方法とスタイルの適用場所に一貫性を持たせることを目的としています。 言い換えれば、スタイリングの可能なすべてのソースを取得し、ブロック スタイルを適切に生成する責任を単独で負います。 分かってる。 いくつかのスタイルを作成するためだけに、他の抽象化の上にさらに別の抽象化を追加します。 しかし、スタイルが多くの場所から取得される可能性があることを考えると、スタイル用の集中型 API を持つことは、おそらく最も洗練されたソリューションです。

Style Engine はまだ初見です。 実際、これまでに完成したものは次のとおりです。 チケットによると:

• コードがバックエンドでブロック サポート CSS を生成する場所を監査して統合し、(複数の場所ではなく) 同じ場所から配信されるようにします。 これは、マージン、パディング、タイポグラフィ、色、ボーダーなどの CSS ルールをカバーしています。
• 反復的なレイアウト固有のスタイルを削除し、セマンティック クラス名を生成します。
• ブロック、レイアウト、および要素のサポートのために、ページに印刷するインライン スタイル タグの数を減らします。

基本的に、これはテーマのすべての CSS スタイル ルールを含む単一の API を確立するための基盤です。 WordPress が 6.1 より前にインライン スタイルを挿入する方法をクリーンアップし、セマンティック クラス名のシステムを確立します。

スタイル エンジンの長期的および短期的な目標の詳細については、こちらを参照してください。 WordPress コア ディスカッションを行う. フォローすることもできます 追跡の問題 および プロジェクトボード より多くの更新のため。

JSON 要素の操作

で JSON 要素について少し話しました。 theme.json ファイルと、ヘッダー、ボタン、リンクなどのデフォルト スタイルを定義するための基本的な HTML プリミティブである方法を説明します。 では、実際に見てみましょう JSON 要素と、それがさまざまなスタイリング コンテキストでどのように動作するか。

JSON 要素には通常、次の XNUMX つのコンテキストがあります。 グローバルレベル と ブロックレベル. グローバル レベルのスタイルは、ブロック レベルよりも具体性が低く定義されており、ブロックが使用されている場合は常にブロック固有のスタイルが一貫性のために優先されるようになっています。

JSON 要素のグローバル スタイル

新しいデフォルトの TT3 テーマを見て、そのボタンのスタイルを調べてみましょう。 以下は、TT3 の省略されたコピペです。 theme.json ファイル（ここに 完全なコード) グローバル スタイル セクションを示していますが、元のコードはここにあります。

{
  "version": 2,
  "settings": {},
    // ...
  "styles": {
    // ...
    "elements": {
      "button": {
        "border": {
          "radius": "0"
        },
        "color": {
          "background": "var(--wp--preset--color--primary)",
          "text": "var(--wp--preset--color--contrast)"
        },
        ":hover": {
          "color": {
            "background": "var(--wp--preset--color--contrast)",
            "text": "var(--wp--preset--color--base)"
          }
        },
        ":focus": {
          "color": {
            "background": "var(--wp--preset--color--contrast)",
            "text": "var(--wp--preset--color--base)"
          }
        },
        ":active": {
          "color": {
            "background": "var(--wp--preset--color--secondary)",
            "text": "var(--wp--preset--color--base)"
          }
        }
      },
      "h1": {
        "typography": { }
      },
      // ...
      "heading": {
        "typography": {
          "fontWeight": "400",
          "lineHeight": "1.4"
      }
      },
      "link": {
        "color": {
          "text": "var(--wp--preset--color--contrast)"
        },
        ":hover": {
          "typography": {
            "textDecoration": "none"
          }
        },
        ":focus": {
          "typography": {
            "textDecoration": "underline dashed"
          }
        },
        ":active": {
          "color": {
            "text": "var(--wp--preset--color--secondary)"
          },
          "typography": {
            "textDecoration": "none"
          }
        },
        "typography": {
          "textDecoration": "underline"
        }
      }
     },
    // ...
  },
  "templateParts": {}
}

すべてのボタンは、グローバル レベルでスタイル設定されます (styles.elements.button).

これは DevTools でも確認できます。 と呼ばれるクラスに注意してください。 .wp-element-button セレクターです。 インタラクティブな状態のスタイルにも同じクラスが使用されます。

繰り返しになりますが、このスタイリングはすべてグローバル レベルで行われています。 theme.json. ボタンを使用するときはいつでも、同じセレクターを共有し、他のスタイル ルールがそれをオーバーライドしていないため、同じ背景を持つことになります。

余談ですが、WordPress 6.1で追加された インタラクティブな状態のスタイリングのサポート ボタンやリンクなどの特定の要素に対して、疑似クラスを使用する theme.json —含む :hover, :focus, :active — またはグローバル スタイル UI。 自動技師 デイブスミス 実証 この機能 YouTubeビデオで。

ボタンの背景色を次のいずれかでオーバーライドできます。 theme.json (デフォルトの WordPress テーマを使用しているため、できれば子テーマで) またはサイト エディターのグローバル スタイル設定で (コードの変更を必要としないため、子テーマは必要ありません)。

しかし、その後、ボタンは一斉に変化します。 ボタンが特定のブロックの一部であるときに背景色をオーバーライドしたい場合はどうすればよいでしょうか? そこで、ブロック レベルのスタイルの出番です。

要素のブロック レベルのスタイル

ブロック レベルでスタイルを使用およびカスタマイズする方法を理解するために、検索ブロックに含まれるボタンの背景色を変更してみましょう。 Button ブロックがあることを思い出してください。ただし、ここで行っているのは、Search ブロックのブロック レベルで背景色をオーバーライドすることです。 そうすれば、新しい色をすべてのボタンにグローバルに適用するのではなく、そこにのみ適用することができます。

そのために、 styles.blocks 内のオブジェクト theme.json. そうです、すべてのボタンのグローバル スタイルを定義すると、 styles.elements、ボタン要素のブロック固有のスタイルを定義できます styles.block、同様の構造に従います。

{
  "version": 2,
  // ...
  "styles": {
    // Global-level syles
    "elements": { },
    // Block-level styles
    "blocks": {
      "core/search": {
        "elements": {
          "button": {
            "color": {
              "background": "var(--wp--preset--color--quaternary)",
              "text": "var(--wp--preset--color--base)"
            }
          }
        },
        // ...
      }
    }
  }
}

わかりますか？ 私は background および text のプロパティ styles.blocks.core/search.elements.button WordPress にあらかじめ設定されている XNUMX つの CSS 変数を使用します。

結果？ 検索ボタンが赤色になりました (--wp--preset--color--quaternary)、デフォルトの Button ブロックは明るい緑色の背景を保持しています。

DevTools にも変化が見られます。

他のブロックに含まれるボタンのスタイルを設定したい場合も同様です。 ボタンは一例に過ぎないので、別のものを見てみましょう。

例: 各レベルでの見出しのスタイル設定

例を挙げて、このすべての情報を家に持ち帰りましょう。 今回は、次のことを行います。

• すべての見出しをグローバルにスタイルする
• すべての見出し 2 要素のスタイルを設定する
• クエリ ループ ブロックのスタイル見出し 2 要素

まずは基本的な構造から theme.json:

{
  "version": 2,
  "styles": {
    // Global-level syles
    "elements": { },
    // Block-level styles
    "blocks": { }
  }
}

これにより、グローバル スタイルとブロック レベル スタイルのアウトラインが確立されます。

すべての見出しをグローバルにスタイルする

を追加してみましょう headings グローバル スタイルに反対し、いくつかのスタイルを適用します。

{
  "version": 2,
  "styles": {
    // Global-level syles
    "elements": {
      "heading": {
        "color": "var(--wp--preset--color--base)"
      },
    },
    // Block-level styles
    "blocks": { }
  }
}

これにより、すべての見出しの色が WordPress の事前設定された基本色に設定されます。 グローバル レベルでも見出し 2 要素の色とフォント サイズを変更してみましょう。

{
  "version": 2,
  "styles": {
    // Global-level syles
    "elements": {
      "heading": {
        "color": "var(--wp--preset--color--base)"
      },
      "h2": {
        "color": "var(--wp--preset--color--primary)",
        "typography": {
          "fontSize": "clamp(2.625rem, calc(2.625rem + ((1vw - 0.48rem) * 8.4135)), 3.25rem)"
        }
      }
    },
    // Block-level styles
    "blocks": { }
  }
}

これで、すべての見出し 2 要素がプライマリ プリセット カラーに設定されます。 滑らかなフォントサイズ. しかし、おそらく私たちは固定したい fontSize Query Look ブロックで使用される場合の見出し 2 要素の場合:

{
  "version": 2,
  "styles": {
    // Global-level syles
    "elements": {
      "heading": {
        "color": "var(--wp--preset--color--base)"
      },
      "h2": {
        "color": "var(--wp--preset--color--primary)",
        "typography": {
          "fontSize": "clamp(2.625rem, calc(2.625rem + ((1vw - 0.48rem) * 8.4135)), 3.25rem)"
        }
      }
    },
    // Block-level styles
    "blocks": {
      "core/query": {
        "elements": {
          "h2": {
            "typography": {
              "fontSize": 3.25rem
            }
          }
        }
      }
    }
  }
}

これで、見出し 2 要素の 2 つのレベルのスタイルがあります。すべての見出し、すべての見出し 2 要素、およびクエリ ループ ブロックで使用される見出し XNUMX 要素です。

既存のテーマの例

この記事ではボタンと見出しのスタイル設定の例だけを見てきましたが、WordPress 6.1 は追加要素のスタイル設定をサポートしています。 それらを概説した表があります 「JSON 要素でスタイルを定義する」 のセクションから無料でダウンロードできます。

おそらく、どの JSON 要素がどの CSS プロパティをサポートしているか疑問に思っていることでしょう。それらをどのように宣言するかは言うまでもありません。 公式文書を待っている間、私たちが持っている最高のリソースは theme.json 既存のテーマのファイル。 テーマがカスタマイズする要素に基づいてテーマへのリンクを提供し、どのプロパティがカスタマイズされるかを指摘します。

それぞれ必ずあげてください theme.json これらのテーマには、 styles.blocks オブジェクト。

包み込む

フルサイト エディターへの頻繁な変更は、 多くの人を苛立たせる主な原因含みます テクノロジーに精通したグーテンベルク ユーザー. クラシック テーマでうまく機能する非常に単純な CSS ルールでさえ、ブロック テーマでは機能しないようです。 特異性の新たな層 前に説明しました。

について GitHub の提案 新しいブラウザ モードでサイト エディタを再設計するには、 Sara Gooding が WP Tavern の投稿に書いています:

ツール内で昼夜を問わず作業していない限り、Site Editor を回避しようとすると簡単に迷子になります。 ナビゲーションは、特にテンプレートの参照からテンプレートの編集、個々のブロックの変更に移動するときに、不安定で混乱します.

Gutenberg のブロック エディターとブロック アイ テーマの世界で熱心な初期のライダーとしても、私は自分自身のフラストレーションが山ほどあります。 私は楽観的ですが、サイト エディターが完成すれば、ユーザーや技術に精通したテーマ開発者にとって革新的なツールになると期待しています。 これ 希望のつぶやき すでにそれを確認しています。 それまでの間、私たちはさらに多くの変化に備え、おそらくでこぼこした乗り物に備える必要があるようです.

参考文献

この記事の情報を調査する際に使用したすべてのリソースをリストしています。

JSON 要素

グローバルスタイル

スタイルエンジン

読んでくれてありがとう！ ブロック テーマの使用方法と CSS の管理方法について、ご意見をお聞かせいただければ幸いです。