CSS custom propertiesは共通値を集めてもfallbackを別に確認する

CSS custom propertiesを入れるときは、色や寸法を名前付きでまとめる作業と、対応しないbrowserでも表示を保つ作業を分けます。共通の値を一か所へ集めれば、変更する箇所は探しやすくなります。しかし、変数を読めないbrowserまで同じように読めるようになるわけではありません。先に通常の宣言を残し、その後でvar()を重ねて、公開画面で確認します。

変数に置き換える目的は、CSSを短く見せることではありません。たとえば、見出しの色、問い合わせボタンの文字色、現在位置を示す線に、同じ青を「案内の色」として使うなら、同じ意味の値を同じ名前で扱う価値があります。反対に、たまたま同じ色コードになっているだけで、片方は本文の文字色、もう片方は警告の背景色なら、一つの名前へ押し込めません。修正するときに、どこまで変わる値なのか分からなくなるからです。

名前を付ける値とそのまま置く値を分ける

W3Cの2015年12月のCandidate Recommendationは、custom propertiesを、著者が選んだ名前へ値を設定し、var()でほかのpropertyから参照する仕組みとして定義しています。custom propertyの名前は--で始まります。

サイト全体で使う案内色をまとめるなら、次のように書けます。

:root {
  --brand-color: #2e5f87;
}

.button {
  color: #2e5f87;
  color: var(--brand-color, #2e5f87);
}

最初のcolorは、var()を解釈できないbrowserが後の宣言を読めなかった場合にも残る値です。二行目はcustom propertyを扱えるbrowserで--brand-colorを参照します。var()の第二引数は、custom propertyが見つからない、または参照した値を使えない場合に使うfallbackです。第二引数だけを置いても、var()そのものを扱えないbrowserのためにはなりません。対応しない環境を考えるなら、通常の宣言を前に残す必要があります。

ここで大切なのは、色コードではなく役割を見ることです。--blueのような名前では、後から別の青へ変えたときに意味が残りません。--brand-colorのように、その値を何のために使うのかが分かる名前にします。ただし、名前を細かく増やせば整理されるわけでもありません。使う場所が一つしかなく、今後も共通化する予定がない値は、通常の宣言のままにしておく方が、読む人には明快です。

fallbackは二つの場面に分ける

2015年12月時点の仕様はCandidate Recommendationです。W3Cの正式な勧告として確定したことを示す段階ではありません。採用するなら、仕様の段階と、実際に自分のサイトへ来るbrowserで表示できることを別々に確認します。

fallbackにも二つの場面があります。一つはvar()を扱えるbrowserで、参照先のcustom propertyが定義されていない場合です。この場合はvar(--brand-color, #2e5f87)の第二引数が役に立ちます。もう一つは、var()を扱えないbrowserです。この場合は、先に書いたcolor: #2e5f87;が必要です。どちらのための値なのかを分けずに書くと、テストしたつもりで一方しか確認していない状態になります。

値を一時的に消して確認する方法もあります。--brand-colorの定義を外した状態で、第二引数の色が出るかを見ると、参照先がない場合の表示を確かめられます。次にvar()を使う宣言だけを外し、通常の宣言で必要な色が残るかを見ると、対応しないbrowser向けの値を確認できます。二つの確認を同じものとして済ませると、どちらが失敗したのか分かりません。

たとえば通常時だけを確認して、hover時の背景色を変数にしたとします。対応しないbrowserではhover時の宣言だけが無効になり、通常時は読めても、操作したときの色が想定と違うことがあります。ボタン、リンク、入力欄のfocus、警告表示のように状態が変わる箇所は、通常時と同じように確認します。見た目だけでなく、文字が背景と重なって読めるか、押せる場所が分かるかまで見るべきです。

小さく置き換え、戻せるようにする

最初から全CSSを変数へ置き換える必要はありません。まず、三回以上使っている色を一つ選び、その色が本当に同じ意味で使われているかを確かめます。次に通常の宣言とvar()を並べ、対象browserで通常時と状態変化を確認します。問題があれば、その値だけ通常の宣言へ戻せます。作業範囲を小さくすれば、崩れた理由も探しやすくなります。

変更前後のCSSを分けて残すことも有効です。色を変数へ置き換える作業と、色そのものを変える作業を同時にすると、表示が変わった理由を追えません。まず値の置き場だけを変え、公開画面が同じであることを確認します。色の見直しはその後に別の変更として行えば、問題が出たときに戻す範囲を絞れます。

制作後に色を変えるとき、HTML、画像、CSS、外部サービスの設定までを同じ変更として扱うと、修正漏れが起きます。custom propertiesが集められるのはCSSの値だけです。画像内の文字色や、広告サービス側の配色まで変わるものではありません。どの画面を誰が更新するのかを分け、CSSで持つ共通値だけをCSSへ残します。

最初の一手は、既存のCSSから案内色を一つ選び、使われている箇所を一覧にすることです。同じ意味なら名前を付け、違う意味なら同じ色でも分けます。その一覧があれば、次に色を変えるとき、変更する範囲と確認する画面を先に決められます。