こんにちは、みみです。
もう9月も終わりかけですが、前回のブログでお伝えしたデザインから考えるWordPress、無事に？始動しまして先日#1を開催することができました。ご参加くださった皆様ありがとうございます。
それでですね、発表資料的なものを共有できていないことに今頃気がつきまして。毎度間抜けですみません。。。取り敢えずブログ記事のカタチで共有しておこうと思います。
WordPressのボタンブロックの構造について
というわけで#1の勉強会の前半でお話した、ボタンブロックの構造についての発表資料的なテキストを以下に共有します。当日のYoutubeと共に良かったらご覧ください。
WordPressのブロックエディター機能は大部分がReactでできています
Webだけでなく、あるモノのデザインを考えるためには、そのデザインが実装される技術や背景についてある程度は知っておく必要がある、と個人的に考えています。
ということで、HTTPSとかHTMLとかの、Webの基本技術についてはさすがに割愛しますが、まずは超ざっくり、これから扱うWordPressのブロックエディターの概要を説明しておこうと思います。
知っている方には耳にタコかもしれませんが、ちょっと我慢して流してください。
Gutenberg: WordPressのエディター機能開発プロジェクトは大体Reactでできています
2003年にリリースされたWordPressはPHPをベースに開発され、当初はシンプルなブログツールでしたが、現在はCMSとして世界シェア４割を超えて利用されているオープンソースソフトウェアです。
そのエディター機能を中心に刷新しようと2017年に始まったのがGutenbergというプロジェクトです。
Gutenberg −ブロックエディター機能を始めとしたWordPressの新機能開発プロジェクトhttps://github.com/WordPress/gutenberg
7割以上がJavascriptで構成されており、ほぼReactというJavascriptライブラリをベースに構成されています。
ReactはWebサイト上のUIパーツを構築するためのライブラリで、WordPress5.0より実装された「ブロックエディター」を開発するために採用されました。
Reactはコンポーネントという単位でUIを考えるため、自然とブロックエディターもコンポーネントをベースとした作りになっています。このためブロックエディターで構成されたWordPressサイトもコンポーネントの概念を無視できない構成になっています。
WordPress本体にはメジャーアップデート毎に取り込まれる
そしてWordPress本体コードはこちら（ミラーリング）https://github.com/WordPress/WordPress
こちらは圧倒的にPHPの割合が高いです。
現在、Gutenbergプロジェクト上で開発・テスト・検証が行われた機能を、基本的にWordPressのメジャーアップデート毎にWordPress本体に取り込む形で実装が行われています。
WordPress5.8の段階で80個ほどあるコアブロックは、コードとしてはこのあたりにあります。
今日はそのうちのボタンブロックをピックアップして掘り下げていこうと思います。
なぜボタンブロックを選んだかというと、段落ブロックや画像ブロックという基本的な機能のブロックに次いでよく使われつつ、テーマやサイト独自のスタイルを当てる機会が一番多そうなブロックだから、です。
Buttons（親ブロック）とButton（子ブロック）
早速、実際のエディタで見てみましょう。
ボタンブロックは、実は2つのブロックで構成されています。
Buttonsブロックの中にButtonブロックが配置されるという構成です。
Buttonsブロックでボタンの集合要素の配置を、
Buttonブロックでボタンの実際の見た目をコントロールできます。
日本語訳ではどちらもボタン、です。
ボタンに当てられているコアのスタイル
では、これらのボタンに当てられているスタイルをみてみましょう。
ボタンのスタイルは、WordPress本体そのものが当てているスタイルと、テーマやプラグインが当てているスタイルがあります。
そのうち、コアのスタイルは以下の通りです。
wp-includes/blocks/button/style.css
https://github.com/WordPress/WordPress/blob/master/wp-includes/blocks/button/style.css
wp-includes/blocks/button/editor.css
https://github.com/WordPress/WordPress/blob/master/wp-includes/blocks/button/editor.css
実際に、DEV toolで確認してみます。
エディタ側のスタイルはこのように自動生成されたCSS（テーマやプラグイン由来だとインラインCSS）として読み込まれます。（SCRIPT_DEBUGが効いていると、CSSファイルを直接読み込みます。）
ブロックのスタイルはこのように、現在のところフロント側とエディター側で別のCSSとして書かれています。それはエディター上のDOM構造がフロントとは異なるからです。
その上でブロックエディターではエディター上の見え方とフロント側の見え方をなるべく一致させる必要があるため、クラシックエディター時代に比べて単純に工数が1.5倍ぐらいになります。（クライアントを説得してエディター側の見え方を揃えない、という選択肢もあるとは思います。）
蛇足の解説（動画の中で私が焦っているワケ）
実は、SCRIPT_DEBUGがtrueになっている環境だと、自動生成されたphpファイルではなくて元のCSSファイルが読み込まれます。
ちゃんとデバック出来るので普段は助かるのですが、この時は通常の読み込まれ方をお見せした方が良いと思ってfalseにしたハズなのにリロードを忘れて反映されていなくて焦っていたのでした。。。
CTA要素であるボタンに特有のState(状態)
そしてボタンブロックには、CTA要素であるために必要ないくつかのStateがあります。
特に以下の4つについてはコアのスタイルの時点で最低限のスタイルが当たっていることもあり、最低でも確認しておくべきStateとなるでしょう。
:hover:focus:active:visited
既存の２つのブロックスタイル「塗りつぶし」と「輪郭」
ブロックスタイルについて
そしてさらに、これらのブロックそのもののスタイルとは別に、ブロックスタイル、という概念があります。
名前がややこしいですが、ボタンブロックだけでなく様々なブロックにいくつかの見た目のバリエーションを与えるものです。
実際のエディター画面で確認してみましょう。
ボタンブロックには「塗りつぶし」と「輪郭」というスタイルがあります。これらはWordPress本体によるブロックスタイルで、この他にテーマやプラグインなどで独自に作成することもできます。
block.jsonの中でこのように設定されています。
"styles": [
{ "name": "fill", "label": "Fill", "isDefault": true },
{ "name": "outline", "label": "Outline" }
],これらのスタイルを選択すると、”name”の部分が末尾についたis-style-“name” というクラス名が該当のブロックに付与されます。
ボタンブロックの場合はこちらです。
is-style-fillis-style-outline
また、
"isDefault": true
が与えられているほうがデフォルトになります。
なので、is-style-fillのスタイルがコアには明記されていません。
ここが落とし穴なのですが、うっかりis-style-fillにだけスタイルを当てると、スタイルを選択していない状態と明示的に塗りつぶしを選択した状態のスタイルが異なってしまいますので、スタイルの当て方に注意が必要です。
そして、サイトのデザインにも依るとは思いますが、視覚的な強さを考えると「塗りつぶし」より「輪郭」のほうがスタイルとしてデフォルトに相応しいのではないかなあと個人的には思うので、最近は以下のようなスタイルの当て方をしています。
.wp-block-button {
.wp-block-button__link {
// common style
}
// ボタンのスタイルを明示的に選択しない場合はoutlineと同じとする
.wp-block-button__link,
&.is-style-outline .wp-block-button__link {
// outline style
}
&.is-style-fill .wp-block-button__link {
// fill style
}
&.is-style-CUSTOM .wp-block-button__link {
// other custom style
}
}エディター上で調整できるスタイル
さらに、5.8からボタンブロックについては、
色、フォントサイズ、角丸、幅の設定ができるようになっています。
Buttonsブロックでは、
縦に並べるか、横に並べるかのバリエーション
flexベースの、justify-contentで配置が調整
これらを記事作成者が触っても違和感のないスタイルを当てる必要があります。
サイトの特性によって、どこまで自由度を上げるか、そもそもベースとしているテーマがある場合はテーマの設定によってその自由度もバラバラですが、デフォルトテーマがこの方向性で作成されることを考えると、ガチガチにスタイルを固定するよりも自由度を上げて編集者の裁量に任せた作り方のほうがUXが良いように個人的には思い始めています。
…以上で発表資料の代わりとさせていただきます、すみません！
次回のデザインから考えるWordPressは、KITERETZ inc.からお三方をゲストに迎えての、Figmaがっつり基礎回です。お見逃しなく！
