Gutenberg 8.3は、ブロックカテゴリを更新し、親ブロックセレクターを含み、新しいデザインコントロールを追加します

昨日、Gutenbergチームは、ブロックエディターの背後にある進行中のプラグインのバージョン8.3をリリースしました。 チームの焦点の多くは今後のフルサイト編集にありますが、この更新には、ブロックカテゴリの再編成セット、親ブロックセレクター、間隔コントロール、リンクカラーオプションなど、ユーザー向けの機能がいくつか含まれています。

小さな拡張機能の1つに、作成者による最新の投稿ブロックをフィルタリングする機能があります。 Headingブロックのレベルコントロールも変更されました。 ブロックオプションのサイドバーでレベルを選択する代わりに、レベルセレクターがエディターツールバーに配置されるようになりました。

Gutenberg 8.2では、画像ブロックのキャプションフィールド内でEnterキーを押すと、新しい段落が作成されました。 8.3では、その機能はキャプション付きのすべてのブロックに拡張されました。

チームは、最新リリースで20を超えるバグ修正を修正しました。 全体として、新しいプラグインの更新は、1日使用した後も安定しているように見えます。 ただし、新しいパディングコントロールなど、実験的な追加のいくつかは、いくつかの懸念に値する場合があります。 テーマの作成者は、これをテストし、フィードバックを提供し、開発が正しい方向に進んでいることを確認する必要があります。

新しいブロックカテゴリ

グーテンベルクチームは、ブロックカテゴリの名前を変更し、再編成しました。 新しいリストはより理にかなっているようで、適切なグループに統合されています。

• 文章
• メディア
• 設計
• ウィジェット
• 埋め込み

私は新しいカテゴリ名のファンですが、現時点では、カテゴリは実用的な目的には役に立たないと思います。 グーテンベルクがタブ付きインターフェースをブロックインサーターに落としたときから、それはブロックの大きな壁のように感じられました。 スクロールしてスクロールし、使用可能なブロックのリストをスクロールして、必要な特定のブロックを見つけると、目は自然にカテゴリ名をスキップします。 私はほとんどの場合、ブロックの挿入にキーボードのスラッシュコマンドを使用します。 私がそうしない場合、それは理想的なユーザーエクスペリエンスではなく、新しいカテゴリはあまり役に立ちません。

親ブロックを選択

グーテンベルクでのより苛立たしい経験の1つは、ネストされたブロックのシナリオで親ブロックを選択しようとすることです。 あまりにも頻繁に、ユーザーは、編集する必要のあるブロックに実際に移動できるスイートスポットに到達することを期待して、ランダムにクリックしているように感じます。 それは最高の瞬間に欲求不満の練習です。

グーテンベルクのチームは、この痛みを和らげるための一歩を踏み出しました。 エディタツールバーの[ブロックタイプまたはスタイルの変更]ボタンにカーソルを合わせると、親ブロックを選択するための新しいボタンが表示されます。

これが問題を処理する正しい方法であるかどうかはわかりません。 ホバリングせずに表示されるある種の矢印ボタンを使った実験をいくつか見たいと思います。 今のところ、チームが問題を解決しようとしていることに満足しており、将来の反復でネストされたブロック内のナビゲーションが改善されることを期待しています。

トップツールバーモードが有効になっている場合、この機能は機能しないようです。 このモードを使用する場合、親ブロックを選択する最良の方法は、エディターの下部にあるブレッドクラムナビゲーションを使用することです。

実験的な間隔/パディング制御

テーマの作成者は、 add_theme_support( 'experimental-custom-spacing' )を介して実験的なパディングコントロールのサポートを追加できるようになりました。 サポートされると、エンドユーザーには、カバーブロックのブロックオプションサイドバーの下に新しい[間隔]タブが表示されます。これは、将来、他のブロックで使用できるようになるはずです。 デフォルトでは、ユーザーは単一の値でブロックの4辺すべてのパディングを制御できます。 また、パディングの「リンクを解除」して、上、下、左、右の値を個別に制御することもできます。

おそらく、グーテンベルクチームはこの間隔機能を拡張して、マージンコントロールも含める予定です。 それは自然な動きであり、ユーザーが過去数年間一緒に暮らさなければならなかったスペーサーブロックの死につながることを願っています。

ただし、エンドユーザーが明示的な値でパディングを制御できるようにすることはできません。 パディング値を無計画に変更すると、多くのテーマ作成者が時間をかけて綿密に計算する垂直方向のリズムが崩れます。 ピクセル値（デフォルト）を使用する場合、ユーザーはタブレットとモバイルの画面サイズで問題が発生する可能性があります。 基本的に、それは間隔の完全な混乱を作成します。

私はその考えに反対していません。 これがWordPressに登場する直前に実行してほしい。 テーマの作成者は、スタイルシートを介して処理される名前付きクラスを登録できる必要があります。 これは、WordPressがデザインフレームワークを持っているという考えに戻ります。 スペーシング用のユーティリティクラスのセットを作成します（oh、hello、Tailwind）。 テーマの作成者に、デザインに基づいて間隔を定義させます。 ユーザーにそれらから選択させます。 次に、ユーザーが自分の手で問題を処理したい場合に備えて、カスタムオプションを提供します。 その時点で、彼らはテーマの作者が選択したデザインフローから脱却するという明確な決定を下しました。

リンクの色

ブロックエディタのスタイリング時にテーマの作成者が直面しなければならなかった困難なハードルの1つは、ユーザーがブロックの背景色を変更したときにリンクの色をどうするかを理解することです。 そのシナリオでは、ユーザーは長い間テキストの色を制御してきました。 ただし、リンクの色はすぐにアクセスできなくなったり、まったく醜いものになる可能性があります。 先進的なテーマの作成者は、テキストの色を継承するようにこれらのリンクの色をスタイル設定しますが、それが常に理想的な解決策であるとは限りません。

そこでユーザーが制御するリンクの色が登場します。カスタムリンクの色のサポートを追加するには、テーマの作成者はadd_theme_support( 'experimental-link-color' )を介して機能をオプトインする必要があります。 これにより、段落、見出し、グループ、列、およびメディアとテキストの各ブロックに新しいカラーセレクターが追加されます。

この機能をテーマサポート関数呼び出しで機能させることができなかったため、問題を見つけるためにコードを少し掘り下げる必要がありました。 テーマの作成者がリンクの色のサポートを追加するには、次のCSSコードスニペットに示すようにデフォルトのリンクも定義する必要があります。

 a { color: var( --wp--style--color--link, #000 ); }

WordPressは自動的に--wp--style--color--link変数を設定します。 さらに具体的にするために、テーマの作成者は.has-link-color aターゲットにすることもできます。