ボタンにマウスを載せたら色が変わる、リンクにキーボードのフォーカスが当たったら枠線が出る。ウェブサイトではごく当たり前の動きですが、WordPressのブロックエディタでこれを整えようとすると、これまでは追加CSSの欄にセレクタを書き足すか、テーマのスタイルシートを直接触るしかありませんでした。次のバージョンで、ここに標準の指定方法が入ります。

7月15日に公開された7.1のベータ1の告知では、ブロックが操作にどう反応するかを、サイト全体の設定と個々のブロックの両方で共通のコントロールから指定できるようになる、と説明されています。派手さはありませんが、制作側と運用側の分担にじわじわ効いてくる種類の変更です。正式リリースは8月19日、WordCamp USに合わせた日程が示されています。

これまでは追加CSS頼みだった領域

ホバーやフォーカスといった状態ごとの見た目は、CSSでは擬似クラス(:hover、:focus、:active)で書く領域です。ブロックエディタのサイドバーには色やタイポグラフィの入り口はあっても、状態別の入り口はありませんでした。結果として、テーマが用意した見た目をそのまま受け入れるか、追加CSSで上書きするかの二択になります。

後者はセレクタの書き分けが面倒でした。サイト全体のボタンをまとめて変えるのは比較的簡単でも、あるページの一つのボタンだけ挙動を変えたいとなると、そのブロックに固有のクラスを振り、そのクラス向けの記述を足すことになります。運用担当の方が触れる範囲ではなく、結局は制作会社への小さな依頼として積み上がっていく部分でした。

この標準化はGutenbergのリポジトリで数年前から要望が出ていたもので、ようやく本体に入る形になります。

全体にも一つのブロックにも当てられる

今回の仕組みで押さえておきたいのは、適用範囲が二段構えになっている点です。グローバルスタイル側で指定すればサイト全体のボタンの反応が揃い、個別のブロック側で指定すればその一つだけが別の反応になります。テーマの土台は崩さないまま、例外だけを局所的に作れるということです。

もう一つ、フォーカス時の見た目を編集画面から扱えるようになる意味は小さくありません。キーボードだけでサイトを操作する人にとって、今どこにいるかを示す枠線は迷子にならないための唯一の手がかりです。装飾を優先してこの表示を消してしまう実装は今も見かけますが、逆に言えば、消すのではなく背景色に対して見やすい色に調整するという判断を、コードを触らない担当者でもできるようになります。

対応するブロックはまず限られる

期待しすぎないほうがよい部分もあります。ベータの段階で状態指定に対応しているのはボタンとナビゲーションリンクなど、対象はまだ絞られています。すべてのブロックに広がるのはこの先の版で、本体側でも段階的に範囲を広げていく方針が示されています。

また、テーマ開発の側ではtheme.jsonから擬似要素を扱えるようにする整備も並行して進んでいます。編集画面のコントロールとテーマの定義ファイル、両方から状態のスタイルを扱えるようにしていく流れの一部と見ておくと、位置づけを取り違えずに済みます。開発者向けの月次まとめでも、この周辺は7.1の柱の一つとして扱われています。

更新前に確認しておきたいところ

実務で気をつけたいのは、既存サイトで追加CSSを使ってホバーの見た目を上書きしている場合です。新しいコントロールから指定した内容と、これまで書いてきた記述が重なると、どちらが勝つかは書き方次第になります。更新のタイミングで、追加CSSにどんな状態指定が残っているかを一度洗い出しておくと、後から原因を探す手間が減ります。

本番にいきなり当てるのではなく、複製した検証環境で主要なページを一通り見てから、というのはこの種の更新では毎回変わらない手順です。ボタンとナビゲーションが対象である以上、影響が出るとしたら問い合わせ導線やグローバルメニューという、サイトの中でも動いてほしくない場所になります。

小さな見た目の調整を運用側で完結できる範囲が広がるのは、更新を続けていくサイトにとっては地味に効きます。制作時に決めた見た目を固定するのではなく、運用しながら少しずつ手を入れられる状態にしておく。ブロックエディタが年々進んでいる方向は、おおむねそこに向いているように見えます。