Case 1: enqueue_block_editor_assets へのエンキュー

ブロックエディタのページの head 要素で読み込まれるスタイル。

body 要素には .post-type-{$post_type} なクラス名がついているので、投稿と固定ページで別のスタイルを当てる場合にはこれを使う。

Case 2: add_editor_style() でのスタイル登録

以前の TinyMCE エディタ(クラシックエディタ)のスタイルは add_editor_style()で設定していた。

body { color: #000 }
.content { color: #000 }
.post-type-post { font-size: 1em }
.post-type-page { font-size: 1.2em }

こうした指定がそのままエディタの iframe 内の HTML にスタイルとして読み込まれた。

body 要素が .content や .post-type-page などのクラスを持っていたので、これをベースにエディタ用の CSS ファイルを準備していた。

Gutenberg での add_editor_style() の振る舞い

add_editor_style() で登録したスタイルは、すべて .editor-styles-wrapper 以下のセレクタとして動的にラップされる。body はそのまま .editor-styles-wrapper に置き換わる。 html も同様だった。

つまり、 .editor-styles-wrapper 以下のスタイルしか設定できないため、enqueue_block_editor_assets のように、投稿タイプごとのスタイルを記述するのも難しい。

子孫セレクタなどを使用するとセレクタが意図せず適用されなくなる可能性があるので、シンプルなスタイル指定が重要。

editor-style.css のスタイル例:

html { font-size: 16px }
body { color: #000 }
ul { padding-left: 2rem }
ul li + li { margin-top: 1rem }
.post-type-post { font-size: 1em }
.post-type-page { font-size: 1.2em }

ラップ後のスタイル例:

.editor-styles-wrapper { font-size: 16px }
.editor-styles-wrapper { color: #000 }
.editor-styles-wrapper ul { padding-left: 2rem }
.editor-styles-wrapper ul li + li { margin-top: 1rem }
.editor-styles-wrapper .post-type-post { font-size: 1em }
.editor-styles-wrapper .post-type-page { font-size: 1.2em }

remが使えない

html も body も .editor-styles-wrapper になるため、 font-size や margin などの単位を rem で指定している場合も対応の検討が必要。あるいは WordPress では rem は使わないという選択肢も取り得る。

以下のフィルタでは、rem の設定のために wp-block-editor のインラインスタイルとして html のフォントサイズを 10px としている。

add_action( 'enqueue_block_editor_assets', function(){
  wp_add_inline_style( 'wp-block-editor', 'html{font-size:10px}' );
} );

画面を印刷する場合は @media が必要になるけれども、まぁ、そんなことにはならないだろう。.editor-styles-wrapper によるラッピングが @media を指定した場合どうなるか、どこかでちょっと確認してみよう…。

投稿タイプ別にスタイルを分けられない

投稿と固定ページのスタイルは別れていたほうが都合の良いケースは多い。カスタム投稿タイプの場合は言うまでもない。こうした場合は、素直に enqueue_block_editor_assets を使おう。また、セレクタには .editor-styles-wrapper を含めておくといいだろう。Sass のありがたみである。

クラシックブロック内でのスタイルの挙動

クラシックブロックの中では、編集可能エリアが以前のような iframe ではなく、div 要素になった。そのため上のスタイルがそのまま反映される。

検討すべきは何か

クラシックエディタユーザーとブロックエディタユーザーが混在している場合。いずれブロックエディタに移行することを考えれば、あえてコストを払って互換性を保つ努力をする必要はなく、とっとと移行してしまったほうが良い。その調査のために費やした時間は戻ってこず、得た知識は、その後どこにも使い途がないのだから。