提案されたWebフォントAPIがWordPress5.9に対応しておらず、おそらく最初にグーテンベルクに上陸

公開: 2021-11-12

WordPress 5.9のシューインのように見えた後、提案されたWebフォントAPIは保留になりました。この機能は、テーマとプラグインの開発者がフォントをロードする方法を標準化し、将来のユーザー向け機能の基礎を築きます。

Jono Aldersonは、2019年2月にこの機能のチケットをオープンしました。ここ数か月で、提案はスピードを上げました。プルリクエストには、200を超えるチケット内メッセージ、93のコミット、および2つのコアコミッターからのコード承認が含まれていました。 APIは準備ができているようでした。しかし、ここ数日で行き詰まりました。

リードWordPress開発者であるAndrewOzzは、5.9で新しいAPIが上陸する可能性を本質的に止めました。彼は、提案がWordPressの準備ができているとは思わないと述べた。

「純粋にコードとしては見栄えが良い」と彼はチケットに書いた。「それは本当によく文書化されています（[Tonya Mark]に感謝します！）。しかし、これが短期的および長期的にWordPressをどのように改善するかはまだわかりません。私たちは[AndreiDraganescu]とチャットしていましたが、彼は理想的にはこれが機能プラグインであるべきだと提案しました、そして私は同意します。そうすれば、本番環境で実際にテストし、作成中に行われた仮定を検証（または拒否）して、WordPressに本当に価値のある追加にすることができたでしょう。残念ながら、これには5.9では遅すぎます。」

APIの機能プラグインをテストする際の問題の1つは、他の人がチケットに記載しているように、APIが頻繁に採用されないことです。ほとんどの場合、開発者は本番環境でそれらに依存しません。そして、平均的なエンドユーザーは開発者に固有のものをインストールしません。

「これを機能プラグインとして実行することを提案することは、何かを数年間遅らせるためのエレガントな方法です」と、APIの開発者の1人であるAriStathopoulos氏は述べています。ただし、REST APIは、WordPressに移植するのに十分なパフォーマンスを発揮する1つの例外であると彼は指摘しました。

コアとなるWordPressの提案は、さらなる調査のためにGutenbergプラグインにプッシュされる可能性があります。これは、個別の機能プラグインとして起動することとWordPress5.9に移行することの間の一種の妥協点になります。

WebフォントAPIは、ブロックシステムに直接関連していません。従来のテーマとブロックテーマの両方、およびプラグインは、今日この機能を利用できます。ただし、いくつかのGutenbergの提案は、テーマの作成者がtheme.jsonファイルを介してWebフォントを定義できるようにするなど、APIの存在に依存しています。

Ozzは提案に関するいくつかの質問をリストし、いくつかの開発者がそれぞれに回答しました。ただし、彼の主な議論は、APIのすべてが必要である理由の実用性に依存しており、以前の返信は「原則として」行われ、仮定に基づいているように思われたと述べています。

最も基本的なレベルでは、WebフォントAPIを使用すると、開発者はローカルでホストされているフォントまたはGoogleFontsのフォントを登録して読み込むことができます。開発者は、2つのデフォルト以外にカスタムプロバイダーを追加することもできます。提案されたAPIの最初のイテレーションは、将来のWordPressリリースで構築するための基盤を確立することに関するものでした。

この機能の魅力は、単にフォントをロードすることではありません。技術的には、テーマの作成者は、必要に応じて1行のコードでそれを行うことができます。少なくともフロントエンドで、現在のコアWordPress標準に準拠したい場合は、4行のコード。

Stathopoulosは、そのようなAPIがWordPressとその拡張機能にもたらす改善のリストをガラガラと鳴らしました。

テーマは、 theme.jsonファイルを介してフォントを定義できます。
エディターのフォントファミリーセレクターでのフォントプレビュー。
フォントファミリの有効なフォントの太さとスタイルを表示します。
フロントエンドのパフォーマンスが向上しました。
パフォーマンスとプライバシーを向上させるためのサーバー側のローカリゼーション。

これは、コアWordPressにAPIを含めることを支持する議論の小さなサンプルでした。

「グーテンベルクには、WebフォントAPIを待っている、途方に暮れている多くの改善点があります」と、Stathopolousはチケットに書いています。「現時点では、WebフォントAPIがないことがブロッカーです。ウィッシュリストにあるのは良いアイテムではありません。前進するための要件です。」

現在、WordPressのWebフォントに特に関連する標準はありません。テーマの作成者は、サードパーティのスタイルシートまたは@font-faceルールを使用したカスタムスタイルシートをキューに入れるための既存の関数に便乗します。これは、何年にもわたってテーマ作成者コミュニティで一般的に受け入れられてきた慣習です。

しかし、多くの人がそれをしぶしぶ受け入れています。いくつかは、問題点を緩和するためにカスタムスクリプトを作成しました。他の多くの人は、最新のデフォルトのWordPressテーマがたまたま使用している方法をコピーするだけです。

目標の1つは、開発者がWebフォントのロードに伴う余分な作業をすべて行うことを心配する必要がないようにすることです。エディターとフロントエンドの両方でそれらをロードする方法、プリロードを処理する方法、またはローカリゼーションを説明する方法を理解するために、テーマは実際には必要ありません。テーマが古くなり、Google FontsなどのサードパーティAPIが変更されると、WordPressが内部で処理する場合、テーマを更新する必要はありません。

プラグインをミックスに投入すると、Webフォントをロードするのに最適な方法の問題が倍増します。一般的に、テーマはデザインに関してすべての面倒な作業を行います。ただし、一部のプラグインは、WordPressの世界のその側に飛び込んで、スタイルオプションを追加します。同じフォントの複数のコピーをロードするときの競合を解決する方法はありません。また、テーマのフォントを無効にしてプラグインを介して置き換える確実な方法もありません。

そのようなプラグインの作成者の1人が、私がすでに知っていたニュースを知らせるために私に電子メールを送りました。 WebフォントAPIはWordPress5.9に搭載されなくなったようです。開発者は、新機能に加えて新しいWebサイトとサービスを立ち上げる準備をしていました。彼らはマスコットさえ持っていました。今のところ、それはただ待たなければならないかもしれません。

機能の凍結期限は2日前でした。したがって、WebフォントAPIがWordPress5.9マイルストーンに追加される可能性はほとんどありません。たぶん、開発者は6.0が着陸したときにそれを見るでしょう。たぶん、それをグーテンベルクプラグインにプッシュすることで、それに息を吹き込み、貢献者がそれに依存する新機能を前進させることができます。